Tag-Management & Data Layer

Ein Tag-Management-System ist schnell eingerichtet. Danach fügen verschiedene Teams und Dienstleister Tags hinzu, Namen werden uneinheitlich vergeben, und alte Skripte laufen weiter. Irgendwann widersprechen sich Zahlen, Seiten werden langsamer, und die Frage „Was messen wir da eigentlich?“ hat keine schnelle Antwort mehr.

Das System selbst ist nur ein Werkzeug für Ordnung und schnelle Änderungen. Ob die Daten am Ende stimmen, entscheiden Messkonzept, Data Layer und Aufbau des Containers. Darum fangen wir nicht im Container an, sondern bei den Fragen, die die Daten beantworten sollen.

Audit: Was im Container wirklich läuft

Ein Container besteht aus Tags (Code, der Daten an ein Zielsystem sendet), Triggern (den Bedingungen, unter denen ein Tag auslöst) und Variablen (den Werten, die beide verwenden, etwa Bestellwert oder Seitentyp). Im Audit gehen wir alle drei durch und suchen Dubletten, pausierte Tags, Tags für beendete Aktionen oder gekündigte Dienste und Verweise auf Seitenelemente, die es nicht mehr gibt. Dazu kommen Skripte, die fest im Seitencode stehen und am Container vorbei Daten senden. Die findet man nur, wenn man die Seite selbst ansieht.

Wir prüfen außerdem, was tatsächlich ankommt, und gleichen ein paar zentrale Zahlen mit dem Quellsystem ab, zum Beispiel die Bestellungen im Shop mit den erfassten Käufen. Und wir klären, wer Tags anlegt, wer sie pflegt und wer veröffentlichen darf. Ergebnis ist eine Liste, was bleibt, was angepasst wird und was entfällt.

Messkonzept: erst die Fragen, dann die Ereignisse

Das Messkonzept leiten wir aus den fachlichen Fragen ab und nicht aus dem, was technisch messbar wäre. An welchem Schritt des Bestellprozesses brechen die meisten Vorgänge ab? Welche Formulare führen zu Anfragen, die im CRM ankommen? Zu jeder Frage legen wir Ereignis, Parameter, Auslöser, Zielsystem und Definition fest. So bleibt das Konzept überschaubar, und es entstehen keine Ereignisse, die niemand auswertet.

Die Definitionen stimmen wir mit dem KPI-Katalog der BI ab, damit eine Kennzahl im Dashboard und im Tracking dasselbe meint.

Der Data Layer als Vertrag zwischen Website und Tags

Der Data Layer ist ein strukturiertes Objekt auf der Seite, in das die Website Informationen und Ereignisse schreibt, etwa Seitentyp, Produkt, Warenkorb oder Bestellung. Tags lesen ihre Werte von dort und nicht mehr aus Texten oder Elementen der Seite. Ein neues Design bricht dann das Tracking nicht mehr, und alle Tags bekommen dieselben Werte, zum Beispiel denselben Bestellwert mit oder ohne Versand. Die Zahlen stammen außerdem aus dem System, das sie kennt, nämlich dem Shop und nicht dem Frontend.

Wir beschreiben den Data Layer als Spezifikation: Ereignisnamen, Felder, Datentypen, Beispielwerte und der Zeitpunkt, zu dem ein Ereignis gesendet wird. Die Entwicklung setzt das um, das Analytics-Team baut darauf die Tags, und wir prüfen das Ergebnis. Auch wenn Daten später über einen eigenen Server weitergeleitet werden, bleibt der Data Layer die Quelle.

Ordnung im Container

Im Container sorgen wenige Regeln für Übersicht. Ein festes Namensschema aus Typ, Ziel und Ereignis, zum Beispiel tag_analytics_purchase, trg_event_purchase und var_dl_order_value, zeigt ohne Nachfragen, was ein Element tut. Trigger und Variablen werden einmal definiert und mehrfach genutzt, Ordner gliedern nach Themen.

Bei den Rechten gilt: Wenige Personen dürfen veröffentlichen, und Zugänge von Dienstleistern werden befristet vergeben. Google Tag Manager kennt dafür pro Container die Stufen Lesen, Bearbeiten, Freigeben und Veröffentlichen.

Für die Ladezeit zählt, dass nur Tags laufen, die gebraucht werden, und zwar nur auf den passenden Seiten. Skripte externer Anbieter schauen wir uns genauer an, weil sie die Ladezeit am stärksten beeinflussen. Welche Tags erst nach einer Einwilligung starten dürfen, wird ebenfalls im Container abgebildet, das ist ein eigenes Thema.

Versionen, Umgebungen und Freigabe

Änderungen am Container wirken sofort auf die Datenerfassung. Jede Veröffentlichung sollte deshalb eine benannte Version mit kurzer Beschreibung erzeugen, damit man bei Problemen auf die letzte funktionierende zurückgehen kann. Google Tag Manager schlägt Name und Beschreibung einer neuen Version inzwischen selbst vor, anhand der Änderungen im Workspace.

Ob ein System Umgebungen mitbringt, ist beim Vergleich ein echtes Kriterium. Tealium iQ hat Dev, QA und Prod fest eingebaut, in Google Tag Manager legt man eigene an, und auch die Systeme von Adobe und Matomo kennen Entwicklungs-, Staging- und Live-Stufen.

Einen eingebauten Freigabe-Workflow bietet Tealium optional für die Produktion, bei Google gibt es ihn laut Google erst in der Variante 360. Wo das System keinen vorsieht, legen wir die Freigabe durch eine zweite Person als Prozess fest.

Getestet wird im Vorschaumodus: Löst das Tag beim richtigen Ereignis aus, stimmen die Werte? Für kritische Ereignisse wie Bestellungen kommen automatisierte Browser-Tests infrage. Dokumentiert werden Messkonzept, Data-Layer-Spezifikation, Namenskonvention und ein Änderungsprotokoll mit Verantwortlichen.

Welches System passt, und was vom System unabhängig bleibt

Die Wahl folgt meist der Analytics-Plattform und weniger einzelnen Funktionen. Wer Adobe Analytics einsetzt, ist mit dem zugehörigen Tag-Management am besten bedient. Wer Matomo selbst betreibt und Datenhoheit will, kann dessen Tag Manager nutzen. Ohne solche Bindung ist Google Tag Manager der Normalfall. Hosting- und Datenschutzanforderungen, die Größe der Teams und der gewünschte Freigabeprozess entscheiden im Zweifel.

Messkonzept und Data Layer sind vom Werkzeug unabhängig, denn sie beschreiben, was gemessen wird, nicht wo es ausgeführt wird. Wer sie sauber und herstellerunabhängig aufbaut, kann das System später wechseln oder Teile der Messung auf einen Server verlegen, ohne das Tracking neu zu erfinden.