GA4 Debugging: Wie man Tracking-Fehler systematisch findet

Inhaltsverzeichnis

tl;dr: Ich war am 3. September 2026 beim Webinar „GA4 Debugging: Tracking-Fehler und wie man sie findet“ von Bloofusion dabei. Die folgenden Tipps stammen von Maximilian Geisler, Senior Web Analyst bei Bloofusion, nicht von mir. Ich beschäftige mich selbst ebenfalls seit über 10 Jahren mit diesem Themenbereich und fasse daher zusammen, was für mich hängen geblieben ist.

Fehler vorbeugen, bevor sie entstehen

Der erste Punkt aus dem Webinar: Fehlerquellen minimieren, bevor überhaupt debuggt werden muss. Der konkrete Rat dazu: IDs in Google Tag Manager nicht einzeln in jedes Tag eintippen, sondern einmal als Konstante anlegen und für alle Tags wiederverwenden. Bei einem Setup mit 50+ Tags reicht ein Tippfehler, damit das Tracking überall kaputt ist.

GE: Dies kann ich aus eigener Erfahrung nur bestätigen. Immer wenn es geht, Konstanten oder Variablen anlegen und diese dann in Tags verwenden. Wer kann, sollte auch immer auf einen zentralen dataLayer setzen, den zumeist das CMS bzw. Plugins oder Extensions liefert, statt sich Werte einzeln per Custom JavaScript (CJS) von der Seite zu holen.

Der zweite Punkt: regelmäßige Audits. Bei neuen Kunden macht sein Unternehmen laut Geisler grundsätzlich zuerst ein Audit und findet dabei in 100% der Fälle Fehler. Meist sind das keine spektakulären Totalausfälle: eher fehlende oder doppelt übergebene Parameter. Sein Punkt dazu: solche Fehler sehen in den Daten oft nicht wie Fehler aus, man findet sie nur, wenn man aktiv danach sucht. Der dritte Punkt: Änderungen dokumentieren. Markups in GA4, die Versionierung im Tag Manager verwenden, ein einfaches Google Sheet erstellen. Hauptsache es ist nachvollziehbar, was wann geändert wurde.

GE: Auch dies kann ich aus eigener Erfahrung nur bestätigen. Wenn ich ein neues Tracking-Setup beginne, erstelle ich zuerst einen Tracking-Plan. Änderungen dokumentiere ich immer konkret in der Versionierung. Wenn ich wichtige Dinge an Tags oder Variablen ändere, dann erstelle ich eine Notiz direkt am Tag.

Der Grundsatz: vom Großen ins Kleine

Für den eigentlichen Debugging-Prozess nutzt Geisler ein Bild, das bei mir hängen geblieben ist: den Stromausfall zu Hause. Wenn der Strom ausfällt, baut niemand zuerst den alten Fernseher auseinander. Man geht zum Sicherungskasten, prüft den Schalter und testet dann Raum für Raum, was betroffen ist. Genauso soll man beim Tracking vorgehen: erst grob eingrenzen, was überhaupt fehlt, dann Schritt für Schritt näher ran.

Davor soll man sich zwei Fragen stellen, die seiner Erfahrung nach oft übersprungen werden.

Liegt überhaupt ein Fehler vor? Etwa einer von zwölf gemeldeten Fehlern stellt sich bei ihm am Ende als normales Verhalten heraus, zum Beispiel eine Messe, eine Newsletter-Aussendung oder ein Ausfall bei einem externen Anbieter wie Google oder Meta selbst.
Wann genau ist der Fehler passiert? Wer den Zeitpunkt kennt, kann ihn mit dem Änderungsverlauf im Tag Manager oder in GA4 abgleichen und findet die Ursache oft in wenigen Minuten.

Drei Arten von Tracking-Fehlern

Im Webinar wurde zwischen drei Fehlerbildern unterschieden, die jeweils eine andere Debugging-Strategie brauchen:

a) Es kommen gar keine Daten mehr

Der dramatischste Fall, aber auch der am leichtesten zu findende. Prüfschritte: Läuft der Tag-Manager-Container im Vorschau-Modus überhaupt? Blockiert der Consent alles? Ist der Container-Code an der richtigen Stelle im Quellcode verbaut? Stimmt die Tracking-ID?

b) Ein einzelner Dienst oder ein einzelnes Event fehlt

Zum Beispiel: GA4 und Microsoft Ads bekommen Daten, aber der Google-Ads-Purchase fehlt. Der Rat dazu: zuerst den Trigger prüfen, dann das Timing zum Consent. Das ist der häufigste Grund für diesen Fehlertyp. Wenn ein Event beim Laden der Seite feuert, das Consent-Signal aber erst danach ankommt, ist das Event schon weg oder wird nur eingeschränkt erfasst. 20 bis 30% aller Debugging-Fälle, mit denen man zu tun hat, Timing-Probleme mit dem Consent.

c) Es kommen Daten an, aber die falschen

Der (auch meiner Meinung nach) schwierigste Fall: zu viele oder zu wenige Conversions, falscher Umsatz, doppelte Events. Der Rat aus dem Webinar: möglichst nah an der ursprünglichen Datenquelle bleiben, also erst dataLayer und Variablen im Google Tag Manager prüfen. Wenn dort alles stimmt, geht der Blick nach außen: Plugins, Consent-Tools, Checkout-Systeme und vor allem Single-Page-Applications, die automatisch bei jedem History-Change tracken und dadurch Seitenaufrufe verdoppeln können, die gar keine echten Aufrufe sind.

Die Tool-Kette fürs Debugging

Es wird zu einer festen Reihenfolge an Tools geraten:

Google Tag Manager Preview-Mode, um Events, Trigger, Variablen und Consent-Signale zu sehen. Das ist auch aus meiner Erfahrung die erste und wichtigste Anlaufstelle.
GA4 Debug View (findet man unter GA4 > Verwaltung > Datenanzeige > DebugView), um zu prüfen, was tatsächlich bei GA4 ankommt. Nur weil etwas im GTM-Preview feuert, heißt das nicht, dass es bei GA4 ankommt.
Explorative Datenanalysen in GA4, um Daten nach Filtern und Attribution zu sehen und um über einen längeren Zeitraum den genauen Tag eines Einbruchs zu finden.
Browser-Entwicklertools (z.B. Chrome Dev Tools): Elements für den verbauten Quellcode, Konsole für dataLayer-Werte und JavaScript-Fehler, Network für die rohen Requests, die den Browser tatsächlich verlassen, Application für Cookies sowie Local- und Session-Storage
Browser-Extensions wie Google Tag Assistant oder Meta Pixel Helper für einen schnellen ersten Blick. Sie sind leider nicht immer verlässlich, deshalb sollte man das Ergebnis immer mit einem der anderen Tools gegenprüfen.
KI-Tools wie ChatGPT oder Claude als Zuarbeiter, vor allem wenn man wirklich keinen Anhaltspunkt hat oder sich Code erklären lassen will. Sein Hinweis: den Output nie ungeprüft übernehmen und beim Weiterleiten an die IT ruhig dazu schreiben, dass eine KI mitgeholfen hat.

Debugging-Regeln zum Mitnehmen

Das sind die im Webinar genannten Kernregeln („Debugging ist zu 90% Analyse und zu 10% Fixen“):

Immer nur einen Fehler gleichzeitig fixen und testen. Ein Setup hat fast nie nur einen Fehler. Wer alles auf einmal ändert, weiß am Ende nicht, welcher Fix die Lösung bewirkt hat.
Erst identifizieren und testen bzw. verifizieren, dann fixen.
Vom Großen ins Kleine prüfen, nicht sofort bei einzelnen Parametern anfangen.
Consent und Timing immer mitdenken (Anm. aus eigener Erfahrung spielt dies eine große Rolle).
Änderungen an Kunden oder an die IT bzw. den Entwickler früh melden, statt Fehler zu sammeln und erst nach Wochen eine lange Mail mit verschiedensten Problemen zu schreiben.
Tools kombinieren und Ergebnisse aus Extensions und KI immer gegenprüfen.

Anekdote: Als das Cookie-Banner an der Conversion Rate schuld war

Zum Schluss wurde ein Beispiel aus der eigenen Praxis zitiert, das zeigt, warum die Reihenfolge „Fragen vor Fixen“ wichtig ist. Ein Kunde meldete eine plötzlich gesunkene Conversion Rate. Naheliegend wäre gewesen, direkt ins Kauf-Tag zu schauen. Stattdessen fragte Geisler zuerst, was sich am Setup verändert hatte, und die Antwort war: Das Cookie-Banner wurde umgestellt.

Durch die neue Gestaltung lehnten deutlich mehr Nutzer den Consent ab. Der Google Consent Mode v2 (Advanced) des Kunden hat daraufhin stärker modelliert, um die fehlenden Signale auszugleichen, und dabei mehr Sitzungen hochgerechnet, als die Seite tatsächlich hatte. Die Zahl der Käufe blieb gleich, die modellierte Nutzerzahl stieg, und dadurch fiel die berechnete Conversion Rate. Der eigentliche Fehler saß also in der Kombination aus Cookie-Banner und Consent-Modellierung: mehr Ablehnungen im Banner, mehr modellierte Sitzungen, gleichbleibende Käufe, tiefere Rate.

Fazit zum Webinar

Nachdem ich mich selbst seit 2015 mit dem Google Tag Manager, GA4 und die letzten Jahre auch mit Server-Side Tracking und Consentmanagement beschäftige, fand ich vor allem zwei Dinge aus dem Webinar mitnehmenswert. Beides deckt sich mit dem, was ich aus eigener Erfahrung im Tracking-Alltag immer wieder beobachte.

Die klare Reihenfolge: fragen > eingrenzen > verifizieren > fixen
Consent-Timing als häufigster Fehlerquelle.

Wenn du beim Lesen des Artikels an dein eigenes Setup gedacht hast: Genau solche Fehler finden wir bei MONOBUNT laufend in Audits, auch bei Setups, die auf den ersten Blick sauber aussehen. Ob GA4, Google Ads Conversion Tracking oder Server-Side-Tracking mit Stape, wir schauen uns dein Tracking systematisch an und sagen dir ehrlich, wo die Zahlen stimmen und wo nicht. Melde dich bei uns, wenn du wissen willst, ob deine Daten wirklich belastbar sind.