DataLayer vs. DOM-Scraping: So wird Ihr Event-Tracking zuverlässig

Veröffentlicht von Thomas dans la catégorie Konformität am 26.11.2025 Letzte Aktualisierung : 29.09.2026 à 09h45


Inhaltsverzeichnis

Montagmorgen ruft ein Kunde seine Agentur an: Seit Freitag kommen in Google Ads keine Verkäufe mehr an. Die Ursache? Der Entwickler hat das Design aktualisiert und die CSS-Klasse des Buttons «In den Warenkorb» von .btn-green in .btn-blue umbenannt. Das Tracking, das an dieser Klasse hing, hat ohne Vorwarnung aufgehört zu funktionieren.

Kurz gesagt

  • DOM-Scraping liest die angezeigte Seite: Es bricht bei der kleinsten Änderung an Design, Text oder Sprache.

  • Der DataLayer übergibt strukturierte Daten an Google Tag Manager, unabhängig vom Design.

  • Für E-Commerce folgen Sie dem offiziellen GA4-Format (purchase, transaction_id, value, currency, items).

  • Nie Personendaten im Klartext in den DataLayer.

Was ist der DataLayer?

Ihre Website spricht HTML, CSS und JavaScript; Google Tag Manager (GTM) erwartet klare Informationen. Der DataLayer verbindet die beiden.

Technisch ist er ein JavaScript-Array (window.dataLayer), in das die Website im richtigen Moment strukturierte Informationen legt. GTM liest sie und leitet sie an Ihre Messtools weiter.

  • Ohne DataLayer: GTM errät, was passiert, indem es die Seite beobachtet (Klasse eines Buttons, angezeigter Text). Das ist fragil.

  • Mit DataLayer: Die Website meldet ausdrücklich «Soeben erfolgte ein Kauf, hier sind Betrag und ID». Das ist zuverlässig.

Bei A-Track starten wir kein grösseres Projekt, ohne einen strukturierten DataLayer zu prüfen oder einzurichten.

Warum DOM-Scraping eine schlechte Praxis ist

Vergleich DOM-Scraping und DataLayer: Scraping hängt an CSS-Klassen und Texten und bricht bei jedem Redesign, der DataLayer übergibt ein strukturiertes purchase-Ereignis, stabil und im GA4-Format.

Beim DOM-Scraping wird GTM so konfiguriert, dass es Elemente der Seite «liest». Beispiel: das Tag Kauf auslösen, wenn die Seite den Text «Danke für Ihre Bestellung» enthält.

  1. Sprachwechsel: Die französische Version zeigt «Merci pour votre commande». Der Trigger findet nichts mehr.

  2. Redesign: Eine umbenannte Klasse oder eine geänderte HTML-Struktur, und der CSS-Selektor greift nicht mehr.

  3. Ungenaue Werte: Ein am Bildschirm gelesener Preis («CHF 1'254.00 inkl. MWST») muss bereinigt werden, und jede Formatänderung verfälscht den Umsatz.

Diese Ausfälle bleiben stumm: keine Fehlermeldung, nur verschwindende Conversions. Genau solche Lücken deckt unsere Checkliste für Tracking-Audits auf.

Der GA4-Standard: die Sprache von Google sprechen

Für E-Commerce müssen Sie das Rad nicht neu erfinden: GA4 definiert ein präzises Format, beschrieben in der E-Commerce-Dokumentation von Google. Geben Sie sie Ihren Entwicklern.

Bei einem Kauf pusht die Website ein Ereignis purchase mit einem Objekt ecommerce, das Folgendes enthält:

  • transaction_id: die eindeutige Bestell-ID (zum Beispiel T_12345);

  • value und currency: den Betrag (254.00) und die Währung (CHF);

  • items: die Produktliste mit item_id, item_name, price und quantity.

Google empfiehlt, das Objekt ecommerce vor jedem neuen Ereignis zu leeren (dataLayer.push({ ecommerce: null })), damit sich keine Produkte aus einem früheren Ereignis einmischen. So aufgebaut, hängt die Messung weder von der Farbe des Buttons noch von der Sprache der Website ab.

Tipp von A-Track

Pushen Sie nie PII im Klartext (user_email: «jean@beispiel.ch») in den DataLayer: Jeder kann sie in der Browserkonsole lesen. Für Enhanced Conversions akzeptiert Google bereits mit SHA-256 gehashte Daten (Google-Ads-Hilfe); das Hashing kann auch in einem serverseitigen GTM-Container erfolgen.

Wer macht was: Agentur, Entwickler und Tracking-Experte

DataLayer-Prozess in vier Schritten: Tagging-Plan durch den Tracking-Experten, Einbau der dataLayer.push durch den Entwickler, Konfiguration von Google Tag Manager und gemeinsame Validierung im Vorschaumodus.

Hier entstehen oft Reibungen: Der Marketer programmiert nicht, der Entwickler kennt GTM nicht. Wir empfehlen diese Rollenverteilung:

  1. Der Tracking-Experte schreibt den Tagging-Plan: «Auf der Bestätigungsseite das Ereignis purchase mit diesen Variablen pushen.»

  2. Der Entwickler baut die dataLayer.push-Aufrufe gemäss diesen Spezifikationen ein, ohne GTM anzufassen.

  3. Der Tracking-Experte konfiguriert GTM, damit es den DataLayer liest und die Daten an GA4, Google Ads, Meta oder LinkedIn sendet, unter Beachtung der Einwilligung.

  4. Alle validieren gemeinsam im Vorschaumodus vor dem Livegang.

CMS oder Individualentwicklung: Wer muss programmieren?

Die gute Nachricht: Bei gängigen CMS ist Programmieren oft nicht nötig.

  • WordPress / WooCommerce: Bewährte Plugins wie GTM4WP erzeugen einen GA4-kompatiblen DataLayer. Prüfen Sie trotzdem die Werte (Steuern, Rabatte).

  • Shopify: Die nativen «Customer Events» und spezialisierte Apps erledigen die Arbeit.

  • Individuelle Website (Laravel, React, Angular...): Der Entwickler muss eingreifen, und ein präziser Tagging-Plan erspart Rückfragen.

Fazit: drei Massnahmen für ein Tracking, das nicht mehr bricht

  1. Listen Sie in GTM die Trigger auf, die auf CSS-Klassen, Texten oder Selektoren beruhen: Das sind Ihre Bruchstellen.

  2. Ersetzen Sie sie durch DataLayer-Ereignisse, zuerst bei den Conversions (Kauf, Formular, Terminbuchung).

  3. Testen Sie nach jedem Update der Website. Mehr dazu in unserem Leitfaden zur Messung der Marketing-Performance.

Bricht Ihr Tracking bei jedem Redesign?

A-Track erstellt den Tagging-Plan, spezifiziert die dataLayer.push-Aufrufe im GA4-Format für Ihre Entwickler und ersetzt fragile DOM-Trigger.

Besprechen wir Ihr Setup in einem 30-minütigen Gespräch mit einem Experten.

Meinen DataLayer absichern