Check · C03 · Tracking-Kern

dataLayer prüfen: initialisiert, befüllt, vor dem Container

Der dataLayer ist die Schnittstelle zwischen Website und Tag Manager. Fehlt er oder bleibt er leer, hängen Tags an CSS-Selektoren und brechen beim nächsten Redesign.

Was wird geprüft

Der Check liest im ausgelieferten HTML, ob window.dataLayer angelegt wird und ob mindestens ein push() darauf folgt. Beide Schreibweisen zählen: das explizite window.dataLayer = window.dataLayer || [] und das w[l]=w[l]||[] aus dem offiziellen GTM-Snippet. Ein push ohne sichtbare Initialisierung gilt als befüllt, denn ohne Initialisierung würde der Browser einen Fehler werfen.

Was der Scan nicht sieht: Pushes aus nachgeladenen JavaScript-Bundles, Events, die erst nach Klicks entstehen, und die Frage, ob die Parameter zur GA4-Schreibweise passen. Dafür braucht es einen Browser: im Tiefenscan für view_item auf Shops, für alles andere den Audit.

Warum ist das wichtig

Der dataLayer ist der Vertrag zwischen Website und Tag Manager. Ohne ihn hängen Trigger an CSS-Klassen und DOM-Pfaden. Das funktioniert genau bis zum nächsten Redesign, dann bricht die Conversion-Messung, und niemand merkt es, weil GA4 einfach weniger zählt. Mit einem dataLayer bleiben die Events stabil, egal wie das Frontend aussieht. Aufbau und Namenskonventionen erklärt der Leitfaden Was ist ein dataLayer?

Häufige Ursachen

GTM wurde ohne dataLayer-Konzept eingebaut, alle Trigger hängen an Klick-Selektoren statt an Events.
Das Theme initialisiert den dataLayer nach dem GTM-Snippet und überschreibt dabei die bereits gesammelten Events.
Ein Shop-System bringt einen eigenen dataLayer mit anderem Namen mit, GTM hört auf den Standard-Namen.
Events werden nur auf einzelnen Templates gepusht, Checkout oder Formulare bleiben stumm.

So beheben

window.dataLayer vor dem GTM-Container initialisieren, nie danach neu zuweisen. Für jedes Business-Event ein push() mit GA4-Namen und -Parametern (event, ecommerce.items, value, currency), festgehalten in einem Measurement-Plan. Danach im GTM-Vorschaumodus prüfen, dass jedes Event genau einmal ankommt.

Passende Vorlage

GA4- und Google-Ads-Consent-Mapping

Dokumentiert, welche Daten von GA4 zu Google Ads fließen und welches Signal jeden Fluss steuert.

Worksheet holen →

Erst selbst prüfen

Der Tracking-Check testet diesen Punkt zusammen mit allen anderen in Sekunden.

Tracking-Check starten →

Verwandte Checks

Analytics-Tag →Tag Manager →Doppelte Google-IDs →

Häufige Fragen

Warum meldet der Check „kein dataLayer“, obwohl GTM läuft?

Der Scan liest nur das ausgelieferte HTML. Das offizielle GTM-Snippet legt den dataLayer als w[l]=w[l]||[] an, das erkennt der Check seit September 2026. Wird der dataLayer erst von einem nachgeladenen Bundle angelegt (SPA, Shop-Theme), sieht der statische Scan ihn nicht. Dann hilft ein Blick in die Browser-Konsole: window.dataLayer.

Reicht ein dataLayer mit gtm.js-Events?

Nein. Die Events gtm.js, gtm.dom und gtm.load schreibt der Container selbst. Was zählt, sind Ihre Business-Events: view_item, add_to_cart, generate_lead, purchase, mit Parametern in der GA4-Schreibweise. Ob view_item auf Produktseiten ankommt, prüft der Tiefenscan auf erkannten Shops; den Rest übernimmt der Audit.

Was ist der Unterschied zum Befund „Doppelte Google-IDs“?

Der dataLayer-Check fragt, ob es eine Schnittstelle gibt. Doppelte Google-IDs fragt, ob dieselbe Messung zweimal ankommt. Beides sind Tracking-Kern-Befunde mit verschiedenen Ursachen: hier ein fehlendes Konzept, dort eine liegen gebliebene Altlast.

Behebung

Verdrahtet in Tagen, nicht in Sprints.

Befunde aus dem Tracking-Check gehen im Audit Sprint in eine Reihenfolge mit Aufwand, jeder Baustein mit Abnahmekriterium.

Zur Leistung Audit Sprint anfragen