GTM Click-Trigger feuern nicht: Wenn die interne _triggers-Variable spinnt

Es gibt viele gute Gründe, etwas an einem Tag Manager Container zu ändern. Zum Glück kann man in der Vorschau testen, ob alles funktioniert. Und wenn ein Trigger nicht wie gewünscht auslöst, findet man in Variablen, dem dataLayer, dem Consent Mode oder irgendwo anders üblicherweise den Grund: Der CSS Selektor ist falsch, das Variablenformat stimmt nicht (mehr), vormals zuverlässige Keys aus der Datenschicht sind ausgefallen. Die Gemeinsamkeit: Man hat es selbst in der Hand oder findet zumindest einen nachvollziehbaren Grund. Normalerweise. Und dann gibt es da Click-Trigger im Google Tag Manager, die trotz erfüllter Bedingungen einfach nicht auslösen wollen. Alles zehnfach kontrolliert und auf gleiche Weise hunderte Male schon gebaut... und dann funktioniert es nicht. Stößt man bei der Suche im Tag Assistant auf eine nicht erfüllte "Regex-Bedingung", die man selbst gar nicht definiert hat, hat man ein Problem. Ein seltenes, aber reales Problem, das sich weder durch Löschen und Neuanlegen der Trigger noch durch Neupublikation beheben lässt. Was tun?

Das Symptom

Ein Link-Click-Trigger mit einer simplen Bedingung - Click URL enthält billing.example.com - feuert nicht. Im Tag Assistant sieht man beim Debugging des zugehörigen Tags drei Filterbedingungen. Die ersten beiden liegen hier z. B. an der Art des Trigger, die zweite bildet die Bedingung ab... aber die dritte ist selten im Fokus, weil sie eigentlich nie etwas anderes als einen grünen Haken zeigt. Hier aber:

Diese dritte Bedingung ist nichts, was man selbst definiert hat. Sie gehört zum internen Mechanismus des Tag Managers. Der Wert aus dem Screenshot repräsentiert den Inhalt der Variable "_triggers", die sich aus dem Inhalt von "gtm.triggers" im dataLayer speist. Er gelangt dort mit dem "gtm.LinkClick" Push hin (zumindest in diesem Fall, da es ein Link Click Trigger ist). Der Tag Manager ist also selbst für dieses dataLayer Ereignis zuständig. Doof, denn wir können es nicht selbst reparieren, wenn wir es nicht selbst versemmelt haben.

Was _triggers ist und wie es funktionieren sollte

Wenn im dataLayer das gtm.linkClick ankommt, schreibt GTM selbst eine komma-separierte Liste von IDs in das triggers Feld. Diese IDs repräsentieren die Trigger, die für diesen Event-Typ registriert sind. GTM prüft dann per Regex, ob der konkrete Trigger in dieser Liste enthalten ist. Der Sinn dahinter ist (vermutlich), dass nicht jeder Trigger alle Bedingungen gegen das Ereignis prüfen muss, wenn schon sein Typ ausschließt, dass er sich mit dem Ereignis befassen muss. Das ergibt zumindest einen Sinn, denn es dient der Performance, denn Trigger können über diese Extra-Bedingung prüfen, ob sie sich mit dem Rest der Regeln überhaupt befassen müssen.

Das erwartete Format für diese Liste bzw. die Einträge darin ist containerId_triggerId - also z. B. 123456789_42 für den Trigger mit ID 42 im Container 123456789. Der Regex dazu sieht so aus:

Er matcht entweder einen leeren String (Trigger ohne weitere Einschränkung = alle müssen sich damit befassen) oder den exakten Eintrag 123456789_42 in der Liste. In einem funktionierenden Container sieht der Wert von triggers im dataLayer bei einem Link-Klick beispielsweise so aus:

Die Liste enthält sowohl Einträge im containerId_triggerId-Format als auch nackte Nummern (nennen wir sie "interne Runtime-Indizes", zu welchem Zweck spielt hier keine Rolle). Der Regex matcht gegen die Einträge mit Präfix - und alles funktioniert, wenn diese Referenzen auch im dataLayer zu finden sind.

Das Problem

Im betroffenen Container sah der Wert von triggers so aus:

Das Problem ist dieser Part hier:

Nur Indizes, keine Einträge im containerId_triggerId-Format. Der Regex sucht nach 187654321_63, findet aber nur 26,27 - keine Übereinstimmung, der Trigger feuert nie.

Das Tückische: Die Trigger-Konfiguration selbst ist einwandfrei. Typ, Bedingungen, Optionen - alles identisch mit einem funktionierenden Container; die grünen Haken bestätigen dies. Das JSON des Containers, exportiert und in einen komplett neuen Container importiert, funktioniert zudem auf Anhieb. Es liegt also nicht an der Konfiguration, sondern an der internen Verarbeitung des Containers - dem Schritt, in dem GTM aus der Workspace-Konfiguration das ausgelieferte JavaScript baut, welches dann auf der Website geladen wird und - in diesem Zustand - sowohl live als auch in der Vorschau im Tag Assistant versagt, wenn es um das Auslösen von Tags geht, die an solchen Triggern hängen.

Was nicht hilft

Folgende Maßnahmen wurden im vorliegenden Fall versucht und haben das Problem nicht behoben:

• Trigger löschen und neu anlegen - die neuen Trigger zeigen das gleiche Verhalten
• Neuer Trigger mit anderer Bedingung - gleiches Ergebnis. Die Bedingung war ja nicht das Problem
• Neue Version veröffentlichen - die Kompilierung produziert denselben fehlerhaften Output
• Workspace leeren und alle Elemente per JSON reimportieren - der Container "erinnert" sich offenbar an seinen kaputten Zustand

Was hilft

Option 1: Neuer Workspace per API (kein ID-Wechsel nötig)

Einen neuen Workspace im selben Container anlegen und alle Elemente neu erstellen. Hier wurde die API verwendet und wenn das Problem einmal weg ist, lässt es sich (zum Glück!) nicht einfach wieder "reaktivieren", also sind andere Wege vielleicht auch möglich. Sicher ist nur, dass es über die Tag Manager API nachweislich funktioniert. Nach dem Merge dieses neuen Workspace enthält die vom GTM generierte Container-Version die korrekten containerId_triggerId-Einträge.

Das kann in der Vorschau verifiziert werden und funktioniert auch wie gewünscht noch nach der Veröffentlichung; die Tags werden wie gewünscht ausgeführt, weil die "triggers-Bedingung" jetzt funktioniert:

Ob die Bestückung per JSON-Import statt API in einen neuen Workspace ebenfalls funktioniert hätte, ließ sich im Nachhinein nicht mehr verifizieren, da der ursprüngliche fehlerhafte Zustand nicht reproduzierbar war. Es ist also möglich, dass schon das Leeren des Default-Workspace im Rahmen der vorherigen Versuche das Problem bereits "gelockert" hat und erst der zweite Versuch mit neuem Workspace den Effekt zum Tragen brachte.

Option 2: JSON-Export in neuen Container (ID-Wechsel nötig)

Den Container als JSON exportieren und in einen neuen Container importieren. Das funktioniert nachweislich ebenso. Es erfordert aber den Wechsel der GTM-Container-ID auf der Website, was dies freilich nur zur zweitbesten Lösung macht. Klappt aber alles andere nicht, ist der Reimport des JSON Exports aus dem betroffenen Container eine zuverlässige Option.

Wie erkennt man das Problem?

Wenn Click-Trigger (oder andere Event-basierte Trigger wie Form Submit) nicht feuern und im Tag Assistant eine nicht erfüllte Regex-Bedingung auf _triggers sichtbar ist, stimmt etwas nicht:

1. Im Tag Assistant den dataLayer-Eintrag des Events öffnen
2. Den Wert von triggers prüfen
3. Wenn dort nur nackte Nummern stehen (z. B. 26,27) statt Einträge im Format containerId_triggerId (z. B. 187654321_63): Mist!

Fazit

In über zehn Jahren GTM ist mir dieses Problem genau einmal begegnet. Es ist selten, aber real - und wenn man darauf trifft, führt kein offensichtlicher Weg zur Lösung, weil die Ursache offenbar in einem internen Verarbeitungsschritt liegt, den man nicht beeinflussen kann. Weder die Konfiguration noch die üblichen "Löschen und Neuanlegen"-Reflexe ändern etwas am Ergebnis. Nur ein Neuaufbau per API oder in einem neuen Container erzwingt offenbar eine saubere Neukompilierung. Wenn Du dies hier gefunden hast, weil genau das gleiche Problem auftritt: Spiel Lotto. Dieses Problem scheint ähnlich selten zu sein wie ein Treffer mit Zusatzzahl. Nur nicht so schön 😉