Sechs Uhr morgens. Der Radiowecker spielt Sonny und Cher. Ein Wettermoderator steht auf und erlebt einen Tag, den er möglichst schnell hinter sich bringen möchte.
Am nächsten Morgen: sechs Uhr. Derselbe Song. Derselbe Tag.
Und am Morgen danach wieder.
In „Und täglich grüßt das Murmeltier“ steckt Bill Murray in einer Zeitschleife. Alle anderen erleben ihren Tag zum ersten Mal. Nur er weiß schon, was gleich passiert.
Wer schon einmal dieselbe GTM-Änderung zum dritten Mal veröffentlicht hat, kennt zumindest einen kleinen Teil dieses Gefühls.
Veröffentlichen. Website aufrufen. Nichts. Noch einmal veröffentlichen.
Leider hat der Tag Manager keinen eingebauten Abspann, der dir nach genügend Wiederholungen die Lösung verrät.
Wir unterbrechen die Schleife deshalb mit einer anderen Frage: An welcher Stelle fehlt deine Änderung überhaupt? Im veröffentlichten Stand, auf der Website oder bei der Ausführung im Browser?
1. Im Tag Manager: Deine Änderung ist gespeichert, aber nicht im veröffentlichten Stand
Im Google Tag Manager arbeitest du mit einem Container. Darin liegen deine Tags, also kleine Mess- oder Funktionsbausteine, und die Regeln, nach denen sie ausgeführt werden.
Wenn du einen solchen Baustein bearbeitest, änderst du zunächst einen Entwurf in einem Arbeitsbereich. Mit „Speichern“ bleibt deine Arbeit erhalten. Für die normalen Besucher deiner Website ist sie damit noch nicht veröffentlicht.
Auch eine neu angelegte Version beweist das nicht. Eine Version hält einen bestimmten Containerstand fest. Du kannst diesen Stand speichern, ohne ihn live zu schalten.
Prüfe den Inhalt der tatsächlich veröffentlichten Version
Öffne im Tag Manager „Versionen“ und suche den aktuell für „Live“ veröffentlichten Stand. Verlasse dich nicht einfach auf die höchste Versionsnummer: Eine neuere Version kann unveröffentlicht sein, und eine ältere kann erneut veröffentlicht worden sein.
Öffne diesen Stand und kontrolliere den betroffenen Tag samt Einstellungen. Ist deine Änderung dort wirklich enthalten?
Wenn nicht, prüfe den richtigen Arbeitsbereich. Für eine Veröffentlichung führt der Weg über „Senden“, „Veröffentlichen und Version erstellen“ und schließlich „Veröffentlichen“. Kontrolliere vorher sämtliche Änderungen, die dabei mitgehen.
Nehmen wir ein ausgedachtes Beispiel: Du möchtest Klicks auf „Termin vereinbaren“ künftig unter dem Ereignisnamen „termin_klick“ an Analytics melden. Bisher hieß das Ereignis „button_click“.
In deinem Entwurf steht bereits „termin_klick“. Im veröffentlichten Tag steht aber weiterhin „button_click“.
Dann brauchst du weder den Browser auszutauschen noch WordPress neu zu starten. Deine Änderung hat den veröffentlichten Stand schlicht noch nicht erreicht.
Achte dabei auf einen kleinen, aber entscheidenden Unterschied: Der Name des Tags im GTM und der an Analytics gesendete Ereignisname sind zwei verschiedene Einstellungen. Wenn du nur den Tag zur besseren Übersicht umbenennst, ändert sich dadurch nicht automatisch der Name im Analytics-Bericht.
Eine funktionierende Vorschau ist noch kein Beweis
„Aber in der Vorschau hat es doch funktioniert!“
Das kann vollkommen stimmen.
Die Vorschau aus deinem Arbeitsbereich lässt dich gerade den Entwurf testen, bevor er veröffentlicht ist. Du kannst deshalb bereits die neue Messung sehen, während normale Besucher weiterhin den alten Stand erhalten. Genau dafür gibt es diese Funktion.
Beende die Debug-Sitzung im Tag Assistant und öffne die Website anschließend direkt über ihre normale Adresse. Verwende dafür keinen geteilten Vorschaulink.
Prüfe auch, wohin du veröffentlicht hast
Manche Einrichtungen verwenden zusätzliche GTM-Umgebungen, beispielsweise für eine Testwebsite. Dort können andere Containerstände gelten als auf der öffentlichen Website.
Eine Veröffentlichung in eine solche Testumgebung aktualisiert nicht automatisch die Live-Umgebung. Prüfe deshalb sowohl das Veröffentlichungsziel als auch die Umgebung, die deine Website tatsächlich verwendet.
Wenn du keine zusätzlichen Umgebungen eingerichtet hast, musst du hier kein neues Problem suchen. Dann konzentrierst du dich auf den normalen Live-Stand.
2. Auf der Website: Du veröffentlichst den richtigen Stand, aber die Seite lädt etwas anderes
Angenommen, deine Änderung ist im Live-Stand enthalten. Trotzdem passiert auf der Website weiterhin das Alte.
Dann solltest du prüfen, ob die Seite überhaupt den Container lädt, den du gerade bearbeitest.
Das klingt banal. Nach einem Agenturwechsel, einem Website-Umzug oder mehreren Einrichtungsversuchen ist es aber durchaus möglich, dass im Tag Manager ein anderer Container geöffnet ist als derjenige, der auf der Website eingebaut wurde.
Beide heißen vielleicht „Website“. Das macht sie noch lange nicht zum selben Container.
Entscheidend ist die Kennung, die mit „GTM-“ beginnt. Beim üblichen Einbau verwendet die Website diese Kennung, um die passende Containerdatei namens „gtm.js“ zu laden.
So schaust du nach, was dein Browser anfordert
In Chrome kannst du das direkt auf der betroffenen Seite prüfen:
- Öffne die Seite außerhalb einer GTM-Vorschau.
- Klicke mit der rechten Maustaste auf eine freie Stelle und wähle „Untersuchen“.
- Wechsle im geöffneten Werkzeug zum Reiter „Network“ beziehungsweise „Netzwerk“.
- Wähle den Dateitypfilter „All“ beziehungsweise „Alle“ und lade die Seite neu.
- Gib in das Filterfeld „gtm.js“ ein.
- Klicke auf einen passenden Eintrag. Unter „Headers“ beziehungsweise „Header“ findest du die vollständige Anfrageadresse.
Der Netzwerkbereich zeigt, welche Dateien und Daten dein Browser anfordert oder verschickt. Die Aufzeichnung muss beim Laden bereits geöffnet sein.
Vergleiche die GTM-Kennung in der Anfrageadresse mit der Kennung deines Containers.
Stimmen sie nicht überein, hast du einen konkreten Ansatzpunkt: Die Website fordert einen anderen Container an. Prüfe dann, wo die Einbindung verwaltet wird, etwa in einem WordPress-Plugin oder in den Einstellungen deines Website-Layouts.
Füge nicht einfach noch einen zweiten Container hinzu, damit der gewünschte „auch irgendwie drin ist“. Sonst laufen möglicherweise alte und neue Messungen nebeneinander.
Findest du keinen Eintrag, prüfe zunächst, ob ein Einwilligungsbanner das Laden verzögert oder eine Browsererweiterung es blockiert. Bei besonderen Einrichtungen kann die Containerdatei außerdem über eine eigene Adresse oder unter einem anderen Namen geladen werden. Ein leerer Filter allein beweist deshalb noch nicht, dass GTM fehlt.
Und selbst eine erfolgreiche Anfrage mit der passenden Kennung beweist zunächst nur, dass die richtige Containerdatei angefordert wurde. Welche Version und welches Verhalten du erhältst, musst du im Zusammenhang mit der Umgebung und dem anschließenden Test beurteilen.
Wann der Cache tatsächlich eine Rolle spielt
„Lösch mal den Cache“ ist einer dieser Ratschläge, die erstaunlich schnell fallen, wenn niemand so genau weiß, was los ist.
Ein Cache ist ein Zwischenspeicher. Er bewahrt beispielsweise eine bereits erzeugte Webseite auf, damit sie beim nächsten Aufruf schneller ausgeliefert werden kann.
Beim üblichen GTM-Einbau lädt die Website die Containerdatei separat von Google. Eine reine Änderung innerhalb dieses Containers erfordert deshalb normalerweise keinen neuen Einbau in WordPress und auch nicht automatisch das Leeren des WordPress-Seitencaches.
Anders sieht es aus, wenn du die Website selbst verändert hast.
Beispielsweise hast du dort eine alte GTM-Kennung durch eine neue ersetzt. Oder die Website soll jetzt eine zusätzliche Erfolgsmeldung bereitstellen, auf die dein Tag wartet. Wird Besuchern noch die alte Seitenfassung ausgeliefert, fehlt diese Änderung weiterhin.
Dann muss die dafür zuständige Zwischenspeicherung geprüft werden: etwa das Cache-Plugin, der Hosting-Cache oder ein vorgeschalteter Auslieferungsdienst. Bei einer Einrichtung, die GTM-Dateien selbst zwischenspeichert oder verändert, gehört auch dieser Weg zur Prüfung.
Den lokalen Browsercache kannst du für einen Test im Netzwerkbereich mit „Disable cache“ beziehungsweise „Cache deaktivieren“ umgehen und die Seite anschließend neu laden. Diese Einstellung gilt, solange die Entwicklertools geöffnet sind. Sie leert keinen Cache auf deinem Webserver.
Auch ein seit einer Stunde geöffneter Tab ist kein sauberer Veröffentlichungstest. Die bereits geladene Seite übernimmt einen neuen Containerstand nicht einfach mitten im Besuch. Lade die Seite für deinen Test vollständig neu.
3. Im Browser: Der Container ist angekommen, aber dein Tag wird nicht ausgeführt
Jetzt wird die richtige Einrichtung geladen. Trotzdem erscheint dein neues Ereignis nicht.
Hier ist eine weitere Unterscheidung nötig: Ein geladener Container bedeutet nicht, dass sofort jeder darin enthaltene Tag ausgeführt wird.
Dafür gibt es Trigger. Das sind Auslöseregeln. Sie legen beispielsweise fest, dass ein Tag nur bei einem bestimmten Klick oder auf einer bestimmten Seite starten soll.
In unserem Beispiel soll „termin_klick“ gemeldet werden, wenn jemand auf „Termin vereinbaren“ klickt. Wenn du nach der Veröffentlichung lediglich die Startseite öffnest und auf Analytics starrst, fehlt die entscheidende Handlung.
Der Tag wartet. Und zwar möglicherweise völlig zu Recht.
Prüfe die Bedingungen genau an der passenden Handlung
Für die Fehlersuche kannst du gezielt die veröffentlichte Version als Vorschau öffnen: unter „Versionen“ die betreffende Version auswählen und deren Vorschaufunktion verwenden. Damit untersuchst du den gewünschten Stand, statt versehentlich einen inzwischen weiterbearbeiteten Arbeitsbereich zu testen.
Im Tag Assistant kannst du anschließend die aufgezeichneten Ereignisse und die dazugehörigen Tags untersuchen.
Führe die Handlung aus, die du messen möchtest, und schaue beim zugehörigen Ereignis nach:
- Ist die erwartete Handlung im Tag Assistant überhaupt erkennbar?
- Stimmen die Bedingungen der Auslöseregel?
- Ist der Tag pausiert oder durch eine Ausnahme ausgeschlossen?
- Liegen die benötigten Werte zu diesem Zeitpunkt vor?
Angenommen, die Regel verlangt einen Klick auf einen Link, dessen Zieladresse „/termin/“ enthält. Der neue Button führt aber zu einem externen Buchungsdienst. Dann passt die Bedingung nicht mehr.
Du kannst diese Regel hundertmal veröffentlichen. Sie wird dadurch nicht richtiger.
Dasselbe gilt, wenn dein Tag auf eine technische Meldung der Website wartet, die dort noch gar nicht eingebaut wurde. Die Veröffentlichung im GTM ergänzt diese fehlende Website-Funktion nicht von allein.
Die gezielte Vorschau hilft dir, solche Bedingungen zu untersuchen. Den abschließenden Test machst du zusätzlich außerhalb der Vorschau, damit du auch das normale Besucherverhalten prüfst.
Vergleiche die Einwilligungsentscheidung
Vielleicht hast du beim ersten Test alle Cookies akzeptiert. Beim zweiten Test verwendest du ein frisches Browserfenster und hast noch gar nichts ausgewählt.
Dann vergleichst du zwei unterschiedliche Situationen.
Je nach Einrichtung werden Tags bis zur erforderlichen Einwilligung blockiert oder passen ihr Verhalten an. Bei Googles erweitertem Einwilligungsmodus können beispielsweise auch ohne erteilte Zustimmung eingeschränkte Signale ohne Cookies versendet werden. „Nicht zugestimmt“ bedeutet deshalb nicht bei jeder Einrichtung automatisch „überhaupt keine Anfrage“.
Halte fest, welche Auswahl du getroffen hast, und prüfe den tatsächlichen Einwilligungsstatus zum Zeitpunkt der Handlung.
Entferne nicht einfach die Einwilligungsprüfung, damit der Tag endlich grün angezeigt wird. Du willst herausfinden, ob die vorgesehene Messung funktioniert. Dafür müssen auch ihre vorgesehenen Bedingungen gelten.
„Ausgelöst“ heißt noch nicht „im Bericht angekommen“
Selbst wenn der Tag Assistant einen Tag als ausgelöst anzeigt, ist die Prüfung noch nicht abgeschlossen. Die ausgehende Anfrage kann beispielsweise blockiert werden oder an den falschen Analytics-Datenbestand gehen.
Bei einer direkten GA4-Übertragung findest du im Netzwerkbereich häufig Anfragen mit „collect“ im Namen. Entferne dafür den vorherigen „gtm.js“-Filter. Prüfe die passende Anfrage, ihre Zielkennung und den gesendeten Ereignisnamen. Wenn ihr über einen eigenen Trackingserver sendet, muss zusätzlich dessen Weiterleitung geprüft werden.
Für die Kontrolle beim Empfänger eignen sich der Analytics-Echtzeitbericht oder – bei aktiviertem Debug-Modus – DebugView. Ein leerer Standardbericht unmittelbar nach dem Test beweist keinen Veröffentlichungsfehler: Die vollständige Verarbeitung kann dort 24 bis 48 Stunden dauern. Auch eine falsche Mess-ID, Datenfilter oder Werbeblocker können fehlende Daten erklären.
Wenn dein Browser bereits „termin_klick“ an den vorgesehenen Empfänger sendet, bringt eine weitere GTM-Veröffentlichung dich bei einem anschließenden Berichtsproblem nicht weiter.
So grenzt du den Fehler ein, bevor du wieder auf „Veröffentlichen“ klickst
| Was du beobachtest | Wo du als Nächstes prüfst |
|---|---|
| Die Änderung fehlt im aktuell veröffentlichten Stand. | Arbeitsbereich, Versionsinhalt und Veröffentlichungsziel. |
| Die Website fordert eine andere GTM-Kennung an. | Einbindung auf der konkreten Seite. |
| Die Website liefert noch eine alte Einbindung oder benötigte Funktion aus. | Veröffentlichung der Website-Änderung und deren Zwischenspeicherung. |
| Der passende Container ist geladen, der Tag startet aber nicht. | Handlung, Auslöseregeln, verfügbare Werte und Einwilligungsstatus. |
| Die neue Messung wird gesendet, erscheint aber nicht wie erwartet. | Empfänger, Filter und Verarbeitung im Auswertungssystem. |
Ändere bei der Fehlersuche möglichst eine Sache nach der anderen. Wenn du gleichzeitig einen Trigger umbaust, drei Caches leerst und das Einwilligungsbanner umkonfigurierst, weißt du hinterher vielleicht, dass es funktioniert. Warum es funktioniert, weißt du dann immer noch nicht.
Und genau dieses Wissen brauchst du beim nächsten Mal.
„Meine GTM-Änderung ist nicht sichtbar“ ist ein Ausgangspunkt. „Die veröffentlichte Version enthält meine Änderung, aber die Website lädt einen anderen Container“ ist bereits ein Befund, mit dem du etwas anfangen kannst.
Bis dahin musst du kommen. Danach kannst du gezielt das Problem beheben, statt auf Verdacht immer wieder dieselbe Veröffentlichung loszuschicken.
Der nächste Kampagnenstart darf gern ohne dieses Gefühl stattfinden: Alle warten, und du kannst gerade nur noch dieselben Knöpfe drücken.
In meinem Videokurs „Was passiert im Browser?“ holst du dir den Überblick, um selbst einen Anfang zu finden und gezielt weiterzufragen.
Du wirst dadurch kein Entwickler. Du bist aber auch nicht mehr auf bloßes Ausprobieren angewiesen, sobald das Gespräch technisch wird.
Schau dir den Kurs vor deinem nächsten Start an. Den heutigen Tag musst du dafür nicht noch einmal erleben.
