Trackum

Tracking funktioniert nicht? Fehlersuche in neun Schritten

Keine Daten in GA4, kein Tag in der Vorschau? Mit diesem Prüfablauf findest du die häufigsten Tracking-Fehler in der richtigen Reihenfolge.

Fehler finden · · 6 Min. Lesezeit · Mit KI erstellt und KI-gestützt geprüft am

Tracking funktioniert nicht? Fehlersuche in neun Schritten
Foto: Vandan Patel auf Unsplash

Tracking funktioniert nicht? Dann liegt es fast immer an einer von neun Ursachen: Der Google-Tag-Manager-Container lädt nicht, er ist doppelt eingebunden, ein Trigger passt nicht, die Einwilligung blockiert das Tag, die Mess-ID ist falsch, die neue Version wurde nicht veröffentlicht, ein Adblocker greift ein, ein Caching-Plugin liefert alten Code aus oder das Ereignis passiert, bevor der Container bereit ist. Die Ursache findest du meist selbst, mit drei kostenlosen Werkzeugen: der Vorschau im Google Tag Manager, dem Netzwerk-Tab in den Entwicklertools deines Browsers und dem Echtzeitbericht in Google Analytics 4 (GA4).

Tracking funktioniert nicht: erst eingrenzen, was fehlt

Bevor du suchst, beschreib das Problem so genau wie möglich. „Google Analytics funktioniert nicht“ kann vieles heißen. Kommen gar keine Daten an, fehlen nur bestimmte Ereignisse, oder sind die Zahlen deutlich niedriger als erwartet? Kein einziger Besucher im Echtzeitbericht von GA4 deutet auf ein grundsätzliches Problem mit der Einbindung hin. Fehlen nur Formularanfragen, liegt es eher am Trigger oder am Ereignis selbst. Sind die Zahlen nur niedrig, steckt oft die Einwilligung oder ein Adblocker dahinter. Notiere dir außerdem, seit wann der Fehler besteht. Fällt der Beginn mit einem Relaunch, einem Plugin-Update oder einem neuen Cookie-Banner zusammen, hast du schon einen starken Verdacht.

Schritt 1 bis 3: Lädt der Google Tag Manager überhaupt?

Öffne deine Website in einem privaten Fenster ohne Erweiterungen, öffne die Entwicklertools und wechsle in den Netzwerk-Tab. Lade die Seite neu und filtere nach „gtm.js“. Taucht dort eine Anfrage mit deiner Container-ID (GTM-…) auf und hat sie den Status 200, lädt der Google Tag Manager. Fehlt sie, ist der Code nicht eingebunden, wurde bei einem Theme-Wechsel entfernt oder wird erst nach dem Cookie-Banner geladen.

Siehst du zwei Anfragen an gtm.js mit derselben ID, ist der Container doppelt eingebunden. Das passiert häufig, wenn ein Plugin den Code einfügt und zusätzlich jemand den Code von Hand in das Theme kopiert hat. Die Folge sind doppelte Seitenaufrufe und doppelte Conversions. Siehst du zwei verschiedene IDs, prüfe, ob der zweite Container noch gebraucht wird oder eine Altlast eines früheren Dienstleisters ist. Achte im selben Schritt auf direkt eingebaute Google-Tags (gtag/js?id=G-…). Läuft GA4 einmal fest im Quelltext und einmal über den Google Tag Manager, zählt jeder Seitenaufruf doppelt.

Der dritte Punkt in diesem Block ist die Mess-ID. Öffne in GA4 die Einstellungen des Datenstreams und vergleiche die dort angezeigte Mess-ID (G-…) mit der ID im Google-Tag des Containers. Ein vertauschtes Zeichen oder die ID einer Testproperty reicht, damit alle Daten in einer anderen Property landen. Das fällt oft erst Wochen später auf, weil die Seite technisch einwandfrei sendet.

Passend dazu: GA4 Thresholding: warum Daten fehlen und was hilft

Schritt 4 und 5: Warum wird das Tag nicht ausgelöst?

Wenn ein Tag nicht ausgelöst wird, liegt es meistens am Trigger, also an der Regel, die festlegt, wann ein Tag feuert. Starte die Vorschau im Google Tag Manager, gib deine Adresse ein und führe die Aktion aus, die gemessen werden soll, zum Beispiel ein Formular absenden. Links in der Vorschau erscheint jedes Ereignis, das auf der Seite passiert ist. Klicke das passende Ereignis an und sieh nach, ob dein Tag bei den ausgelösten oder bei den nicht ausgelösten Tags steht. Bei nicht ausgelösten Tags zeigt dir die Vorschau, welche Bedingung des Triggers erfüllt war und welche nicht. Typisch sind falsche Seitenpfade, etwa „/danke“ statt „/danke/“, ein Formular, das per JavaScript sendet und deshalb kein klassisches Absenden-Ereignis auslöst, oder eine CSS-Klasse, die sich nach einem Update geändert hat.

Funktioniert alles in der Vorschau, aber nicht für echte Besucher, wurde die neue Version vermutlich nicht veröffentlicht. Die Vorschau zeigt immer den aktuellen Arbeitsbereich. Besucher bekommen nur die zuletzt veröffentlichte Version. Klicke oben rechts auf „Senden“ und veröffentliche die Version mit einer kurzen Beschreibung. Ein Blick in die Versionsliste zeigt dir außerdem, wer wann etwas geändert hat, was bei mehreren Beteiligten viel Rätselraten erspart.

Schritt 6: Blockiert die Einwilligung das Tag?

Mit dem Google Consent Mode v2 richten sich Google-Tags nach dem Einwilligungsstatus, und viele weitere Tags sind im Google Tag Manager an eine Einwilligung gebunden. Das ist richtig so, führt aber zu einem typischen Tracking-Fehler: Das Tag wartet auf eine Zustimmung, die nie im Google Tag Manager ankommt. Das passiert, wenn das Cookie-Banner seine Entscheidung nicht an den Consent Mode weitergibt, wenn der Standardwert fehlt oder wenn das Banner nach einem Update andere Ereignisnamen verwendet. Prüfe in der Vorschau den Bereich zur Einwilligung (Consent). Dort siehst du für jedes Ereignis den Standardzustand und den Zustand nach der Aktualisierung. Stimmst du im Banner zu und ändert sich analytics_storage nicht auf „granted“, liegt der Fehler in der Verbindung zwischen Banner und Google Tag Manager.

Prüfe auch den umgekehrten Fall. Lehnst du ab, dürfen keine Cookies von Google Analytics gesetzt werden. Werden sie trotzdem gesetzt, misst du zwar, aber nicht so, wie es sein soll. Dieser Artikel ist keine Rechtsberatung, doch ein Banner, das nur in eine Richtung funktioniert, ist in beiden Fällen ein Problem.

Passend dazu: GA4 Direct Traffic und Unassigned: Ursachen und Lösungen

Schritt 7 bis 9: Adblocker, Caching und Timing

Manche Ursachen liegen außerhalb des Google Tag Managers. Diese drei solltest du kennen:

  • Adblocker und Browser-Schutz: Erweiterungen und einige Browser blockieren gtm.js oder die Anfragen an Google Analytics. Im Netzwerk-Tab siehst du dann blockierte oder fehlgeschlagene Anfragen. Teste immer in einem sauberen Profil.
  • Caching- und Optimierungs-Plugins: Sie liefern alte Seitenversionen aus, fassen Skripte zusammen oder verzögern JavaScript bis zur ersten Interaktion. Nimm den Google Tag Manager von der Verzögerung aus und leere den Cache nach jeder Änderung am Code.
  • Ereignis vor dem Container: Wird ein Ereignis per gtag() oder dataLayer.push gesendet, bevor der Code bereit ist, oder überschreibt ein Skript später den dataLayer mit einer neuen Liste, geht es verloren.
  • Seitenwechsel zu schnell: Leitet ein Formular sofort weiter, bricht der Browser die Anfrage manchmal ab, bevor sie raus ist. Ein Ereignis auf der Dankeseite ist dann zuverlässiger.

Zum Abschluss prüfst du das Ergebnis dort, wo es ankommen soll. Im Netzwerk-Tab filterst du nach „collect“ und siehst jede Anfrage an GA4 mit dem Ereignisnamen im Parameter en. Im Echtzeitbericht von GA4 sollte dein Besuch innerhalb kurzer Zeit erscheinen. Für einzelne Ereignisse mit allen Parametern ist die DebugView in GA4 das bessere Werkzeug, weil sie Aufrufe aus der Vorschau gesondert anzeigt.

Neun Ursachen, wenn Tracking nicht funktioniert
UrsacheWoran du sie erkennstLösung
Container lädt nichtKeine Anfrage an gtm.js im Netzwerk-TabCode wieder einbinden, Theme und Plugins prüfen
Container doppelt eingebundenZwei Anfragen an gtm.js oder GA4 zusätzlich fest im QuelltextEine Einbindung entfernen
Falsche Mess-IDDaten landen in einer anderen GA4-PropertyMess-ID mit dem Datenstream vergleichen
Trigger passt nichtTag steht in der Vorschau bei den nicht ausgelösten TagsBedingung an das echte Ereignis anpassen
Version nicht veröffentlichtVorschau funktioniert, live fehlt das TagVersion im Google Tag Manager senden
Einwilligung kommt nicht ananalytics_storage bleibt nach Zustimmung auf deniedVerbindung zwischen Banner und Consent Mode reparieren
AdblockerBlockierte Anfragen im Netzwerk-TabIn sauberem Profil testen, Abweichung einplanen
Caching- oder Optimierungs-PluginAlter Code im Quelltext, Skript verzögertCache leeren, Google Tag Manager von der Verzögerung ausnehmen
Ereignis vor dem ContainerEreignis fehlt in der VorschaudataLayer vor dem Container anlegen, nicht überschreiben

Beispiel aus der Praxis: Handwerksbetrieb ohne Anfragen

Ein Malerbetrieb schaltet Google Ads und sieht seit drei Wochen keine Conversions mehr, obwohl wie gewohnt Anfragen per E-Mail kommen. Der Netzwerk-Tab zeigt: Der Google Tag Manager lädt, Seitenaufrufe kommen in GA4 an. In der Vorschau steht das Conversion-Tag beim Absenden des Kontaktformulars bei den nicht ausgelösten Tags. Der Trigger wartet auf den Seitenpfad „/danke“. Bei einem Plugin-Update hat das Formular aber umgestellt: Statt auf eine Dankeseite weiterzuleiten, zeigt es die Bestätigung jetzt direkt auf derselben Seite an. Die Dankeseite wird nie aufgerufen, also feuert nichts. Die Lösung ist ein Trigger auf das Ereignis, das das Formular-Plugin beim erfolgreichen Absenden in den dataLayer schreibt, statt auf die Adresse. Viele Formular-Plugins bieten so ein Ereignis an, sonst hilft ein kleiner Zusatzcode. Nach dem Veröffentlichen kommen die Conversions wieder an. Seit dem Update fehlen allerdings drei Wochen an Daten, und Smart Bidding hat in dieser Zeit ohne die echten Conversions geboten. Genau deshalb lohnt sich eine regelmäßige Prüfung statt einer Suche, wenn es schon zu spät ist.

Abkürzung: den Tracking-Fehler automatisch finden lassen

Wenn du dich nicht durch Entwicklertools und Vorschau klicken willst, nimm den Gratis-Check von Trackum. Ein echter Browser öffnet deine Seite dreimal mit frischem Profil: Cookie-Banner ignoriert, abgelehnt und akzeptiert. Du siehst, welcher Dienst wann sendet, ob Consent Mode v2 richtig gesetzt ist und ob Seitenaufrufe doppelt gezählt werden. Formulare schickt der Check nicht ab, die prüfst du mit der Vorschau. Jeder Befund steht mit einem Festpreis zum Beheben daneben. Der Check kostet nichts, braucht keine Anmeldung und dauert etwa zwei Minuten. Willst du die Fehler nicht selbst beheben, erledigt die Reparatur für 79 € zzgl. MwSt. alle Befunde im vorhandenen Google Tag Manager, getestet und mit kurzem Bericht. Mit dem Abo für 19 € pro Monat prüft Trackum deine Seite danach jede Woche und repariert ohne Aufpreis, was Trackum eingerichtet hat und nach einem Update kaputtgeht.

Häufige Fragen

Wie lange dauert es, bis Daten in Google Analytics 4 erscheinen?

Im Echtzeitbericht und in der DebugView siehst du Aufrufe innerhalb weniger Sekunden bis Minuten. Die Standardberichte werden später verarbeitet, laut Google-Hilfe kann die Verarbeitung 24 bis 48 Stunden dauern. Fehlen Daten nur in den Standardberichten, warte deshalb einen Tag, bevor du suchst.

Warum wird mein Tag im Google Tag Manager nicht ausgelöst?

Der Trigger passt nicht zum tatsächlichen Ereignis, oder das Tag wartet auf eine Einwilligung, die nicht erteilt wurde. In der Vorschau siehst du bei jedem Ereignis, welche Bedingung des Triggers erfüllt war und welche nicht.

Warum funktioniert das Tracking in der Vorschau, aber nicht live?

Fast immer wurde die neue Version im Google Tag Manager nicht veröffentlicht. Die Vorschau zeigt den Arbeitsbereich, Besucher bekommen nur die zuletzt veröffentlichte Version. Prüfe in der Versionsliste, wann zuletzt veröffentlicht wurde.

Können Adblocker das Tracking verhindern?

Ja. Viele Adblocker und manche Browser blockieren Anfragen an Google Analytics oder das Skript des Google Tag Managers. Teste deshalb immer zusätzlich in einem Browser ohne Erweiterungen und rechne damit, dass ein Teil der Besucher nie gemessen wird.

Quellen

  1. Google Tag Manager-Hilfe: Vorschau und Fehlersuche für Container support.google.com
  2. Google Tag Manager-Hilfe: Veröffentlichen, Versionen und Freigaben support.google.com
  3. Google Tag Manager-Hilfe: Unterstützung für den Einwilligungsmodus support.google.com
  4. Google Analytics-Hilfe: Ereignisse in DebugView beobachten support.google.com
  5. Google Analytics-Hilfe: Datenaktualität support.google.com
Hilfe