GA4 richtig implementieren: Events, Conversions, Fehler

Von all den Analytics-Audits, die wir durchgeführt haben, haben wir noch keine einzige perfekte GA4-Installation gefunden. Nicht eine. Der Normalfall: doppelte Events, die die Metriken aufblähen, ein falsch konfigurierter Consent Mode, der die Hälfte der Daten verwirft, und undefinierte Conversions — womit Paid-Kampagnen blind optimieren.

Und das Problem ist ernst: Das gesamte Growth Marketing steht auf den Daten. Wenn das Tracking kaputt ist, ist jeder A/B-Test, jede Budgetentscheidung und jedes darauf gebaute Dashboard kontaminiert. In diesem Leitfaden erklären wir, wie man GA4 richtig implementiert: das Event-Modell, was zu messen ist, wie man es mit Google Tag Manager aufsetzt und die Fehler, die wir in fast allen Konten wiederfinden.

Warum die meisten GA4-Installationen kaputt sind

Drei Ursachen erklären 90% der Desaster, die wir auditieren:

1. Doppelte Daten. Die klassische Kombination: das gtag.js-Snippet direkt im Template und GA4 zusätzlich über den Google Tag Manager ausgelöst. Ergebnis: zwei page_view pro Seite, doppelte Conversions und Quoten, die nicht zum Geschäft passen. Das passiert auch mit CMS-Plugins, die “Analytics schon enthalten” und parallel zum manuellen Tag laufen.
2. Consent Mode falsch aufgesetzt (oder fehlend). Seit März 2024 ist Consent Mode v2 Pflicht, um Google-Zielgruppen und Remarketing im EWR zu nutzen. Wir sehen ihn ständig falsch implementiert: Der Cookie-Banner blockiert GA4 komplett (Totalverlust der Daten aller Ablehnenden) — oder umgekehrt, alles feuert ohne Einwilligung (rechtliches Problem).
3. Undefinierte Conversions. GA4 weiß nicht, was für Ihr Geschäft wichtig ist. Wenn niemand Events als Conversion (Key Events) markiert, optimiert Google Ads auf Klicks, die Berichte beantworten keine Geschäftsfragen und “Analytics haben” bleibt ein Besucherzähler.

Die gute Nachricht: Nichts davon ist schwer zu reparieren. Schwer ist, es zu entdecken — denn ein kaputtes Tracking produziert genauso hübsche Zahlen wie ein gesundes.

Das Event-Modell von GA4: vergessen Sie die Kategorien von Universal Analytics

Wenn Sie von Universal Analytics kommen, heißt der erste Schritt: umlernen. UA hatte verschiedene Hit-Typen (Pageviews, Events mit Kategorie/Aktion/Label, Transaktionen). In GA4 ist alles ein Event mit Parametern:

Event: sign_up
Parameter: { method: "google", plan: "free" }

Das hat zwei praktische Konsequenzen:

• Packen Sie die Information nicht in den Event-Namen. click_gruener_button_home ist ein Anti-Pattern; richtig ist ein generisches Event (cta_click) mit Parametern (location: "home", cta_text: "..."). Weniger Events, mehr Parameter.
• Benutzerdefinierte Parameter erscheinen nicht von Zauberhand in den Berichten. Sie müssen in der Property als benutzerdefinierte Dimensionen oder Metriken registriert werden. Das ist das häufigste Versäumnis: parameterreiche Events, die niemand auswerten kann.

GA4 bringt außerdem automatische Events mit (page_view, session_start) sowie Events der optimierten Analyse (scroll, ausgehender click, file_download, video_start…). Prüfen Sie diese, bevor Sie eigene anlegen: Messen Sie nicht manuell, was schon serienmäßig kommt.

Was messen: ein Messplan entlang des Funnels

Der Grundfehler ist meist nicht technisch, sondern konzeptionell: messen ohne Plan. Unser Ausgangspunkt ist immer derselbe: ein sauber definiertes Event pro Phase des AARRR-Funnels.

Der Messplan ist ein Dokument (eine Tabelle genügt) mit: Event-Name, Auslösezeitpunkt, Parametern, wer es konsumiert und für welche Entscheidung. Wenn ein Event keine Antwort auf “Welche Entscheidung speist es?” hat, wird es nicht implementiert. Zehn dokumentierte Events sind mehr wert als hundert improvisierte.

Implementierung mit Google Tag Manager

Unsere Standardempfehlung: ein einziger Eintrittspunkt (GTM) und ein gut befüllter dataLayer. Kein hartcodiertes gtag.js parallel zum Container.

• Der dataLayer ist der Vertrag zwischen Entwicklung und Marketing. Das Produktteam pusht Events mit ihren Parametern (dataLayer.push({event: "sign_up", method: "google"})) und GTM übersetzt sie in Tags. So überlebt das Tracking Redesigns: Es hängt nicht an CSS-Klassen oder fragilen Selektoren.
• Namenskonventionen ab Tag eins: immer snake_case (GA4 unterscheidet Groß-/Kleinschreibung: sign_up und Sign_Up sind zwei verschiedene Events), englische Verben konsistent mit den von Google empfohlenen Events (sign_up, purchase, generate_lead) und Präfixe für Eigenes, wenn es hilft (sw_ für eigene Events). Dokumentiert im Messplan.
• Umgebungen und Versionen: GTM erlaubt Tests im Preview-Modus, Veröffentlichung mit Versionen und Rollback. Nutzen Sie das. Eine ungetestete Tracking-Änderung ist ein Datenvorfall mit Terminvormerkung.

Conversions und Zielgruppen

Wenn die Events fließen, bleiben zwei Schritte, die fast niemand geht:

1. Markieren Sie nur als Conversion (Key Event), was Geschäft ist: Lead, Registrierung, Kauf, angefragte Demo. scroll oder page_view als Conversion zu markieren zerstört den Nutzen der Daten und verwirrt Google Ads. 3 bis 5 gut gewählte Conversions sind der Normalfall.
2. Bauen Sie Zielgruppen auf Verhalten: Nutzer, die aktiviert, aber nicht bezahlt haben; abgebrochene Warenkörbe; Pricing-Besucher ohne Conversion. Nach Google Ads exportiert, verwandeln sie Ihre Analytik in Remarketing-Muskeln und Similar Audiences. Das ist der Teil von GA4, der die Rechnung bezahlt.

Consent Mode v2 und der Datenverlust

Mit korrekt implementiertem Consent Mode v2 sendet GA4 bei abgelehnten Cookies anonyme Pings (ohne Cookies), statt gar nichts zu senden. Auf dieser Basis wendet Google Verhaltens- und Conversion-Modellierung an: Es schätzt die Daten der Ablehnenden statistisch aus den Mustern derer, die zugestimmt haben.

Was man akzeptieren muss: Sie werden so oder so Granularität verlieren. Bei den in Europa üblichen Ablehnungsquoten von 20-40% sind Ihre absoluten Zahlen teilweise modelliert. Die praktischen Konsequenzen:

• Konfigurieren Sie den Consent Mode im erweiterten Modus (anonyme Pings) und nicht im Basis-Modus (Totalblockade), wenn die Modellierung funktionieren soll.
• Behandeln Sie GA4 als direktionales Werkzeug: verlässliche Trends und Vergleiche, ungefähre Absolutzahlen.
• Die geschäftliche Quelle der Wahrheit (Verkäufe, Leads) muss Ihr Backend oder CRM sein — niemals das Analytics-Tool.

Wann der nächste Schritt kommt: Server-side und Produktanalytik

Ein gut aufgesetztes Client-side-GA4 deckt viel ab, hat aber eine Obergrenze:

• Server-side-Tracking (GTM Server-Side): sinnvoll, wenn Adblocker und ITP einen relevanten Teil der Daten fressen und die Paid-Investition es rechtfertigt, ihn zurückzuholen — oder wenn Sie Events mit Backend-Daten anreichern und kontrollieren wollen, was mit welcher Plattform geteilt wird. Das ist Infrastruktur: Es braucht Engineering, nicht nur Konfiguration.
• Produktanalytik-Tool (PostHog, Mixpanel, Amplitude): wenn die Fragen nicht mehr Marketing sind (“Welcher Kanal konvertiert?”), sondern Produkt (“Was tun Nutzer, die bleiben, das die Abwandernden nicht tun?”). Flexible Kohorten, Ad-hoc-Funnels, Session Replay und Feature Flags — Terrain, das GA4 nicht erreicht.

Die übliche Kombination in Unternehmen mit digitalem Produkt: GA4 für Marketing und Kampagnen + ein Produkt-Tool für Verhalten. Wenn Sie an diesem Punkt sind, ist das genau das, was wir in unserem Data-&-Analytics-Service aufbauen.

GA4-Audit-Checkliste

Bevor Sie das Tracking abnehmen:

• Ein einziger Auslösepunkt (GTM oder gtag, nicht beide) und keine doppelten page_view in DebugView
• Dokumentierter Messplan: Events, Parameter, Verantwortliche und gespeiste Entscheidung
• Konsistente Namenskonvention (snake_case, Googles empfohlene Events, wo vorhanden)
• Benutzerdefinierte Parameter als benutzerdefinierte Dimensionen/Metriken registriert
• Conversions (Key Events) definiert: nur Geschäfts-Events, 3 bis 5
• Consent Mode v2 im erweiterten Modus, verifiziert mit dem Banner bei Zustimmung und Ablehnung
• Datenaufbewahrung von 2 auf 14 Monate erhöht (Standard sind 2)
• Interner und Entwicklungs-Traffic gefiltert
• Verknüpfung mit Google Ads und Search Console aktiv
• Prüfung in DebugView und Realtime nach jeder GTM-Veröffentlichung

Häufige Fehler (und wie man sie vermeidet)

Fazit

GA4 richtig zu implementieren heißt nicht, ein Snippet einzukleben: Es heißt, einen Messplan entlang des Funnels zu entwerfen, ihn mit Engineering-Disziplin umzusetzen (dataLayer, Konventionen, Versionen, Verifizierung) und die Grenzen einwilligungsbasierter Daten ehrlich zu akzeptieren. Der Unterschied zwischen gut und mittelmäßig ist auf der Website unsichtbar — er zeigt sich drei Monate später, wenn die auf diesen Daten getroffenen Entscheidungen funktionieren oder nicht.

Und wenn wir beim Auditieren von Konten eines gelernt haben: Es ist viel billiger, das Tracking einmal richtig aufzusetzen, als sechs Monate lang auf kaputten Daten zu entscheiden.

Der Verdacht, dass Ihr GA4 falsch misst? Wir auditieren es und bringen es in Form →