Google Tag Manager (GTM)

Google Tag Manager

Mit der integrierten Google Tag Manager Lösung kannst du den Tag Manager ohne weitere Plugins einbinden und E-Commerce-Daten erfassen. Die E-Commerce-Events nach dem Standard von Google Analytics 4 (z. B. view_item, add_to_cart, begin_checkout, purchase) erzeugt DZM Resources zentral für alle Tracking-Dienste. NIU Plus gibt sie an den dataLayer des Tag Managers weiter – sobald der Besucher eingewilligt hat. Wie die Einwilligung funktioniert, liest du unter Consent & Tracking einrichten.

Das Seitenaufruf-Event (page_view) sendet dein GA4-Tag im Container selbst. NIU Plus schickt es deshalb nicht zusätzlich in den dataLayer.

Disclaimer: Bitte prüfe dein Setup sorgfältig. Je nach Shop und Plugins können Anpassungen notwendig sein für ein zielgerichtetes Tracking. Passe unbedingt die Sprachvariablen für die Consent Items an. Tracke nicht ohne die Einwilligung deiner User. Ergänze deine Datenschutzerklärung entsprechend und lass diese prüfen. Lass ggfs. auch die Integration auf rechtskonforme Implementierung prüfen. Die Integration wurde nach bestem Wissen und unter den Best Practices der Google Tagmanager und Google Analytics Dokumentation entwickelt. Die Nutzung unterliegt der eigenen Verantwortung und Sorgfalt.

Allgemein

Hier aktivierst du die Schnittstelle und hinterlegst deine ID.

boolean

Aktiviere diesen Schalter, um den Google Tag Manager in deinem Shop zu verwenden. Geladen wird er je nach Consent Mode erst nach der Einwilligung (Basic) oder sofort (Advanced).

string

Trage hier deine Container-ID ein. Diese findest du in deinem Google Tag Manager Konto oben rechts neben dem Container-Namen. Mögliche Formate:

GTM-XXXXXX – Älteres Format mit 6 alphanumerischen Zeichen (z. B. GTM-AB12CD)
GTM-XXXXXXX – Neueres Format mit 7 alphanumerischen Zeichen (z. B. GTM-AB12CDE)
GTM-XXXXXXXX – Erweitertes Format mit 8 Zeichen bei neueren Konten

Hier steuerst du, für welche Google-Dienste eine Einwilligung eingeholt wird und wie NIU Plus den Google Consent Mode v2 behandelt.

Zeigt im Consent-Banner den Dienst Google Analytics 4 an. Wenn deaktiviert, gilt der Consent für GA4 als verweigert.

Zeigt im Consent-Banner den Dienst Google Ads an. Wenn deaktiviert, gilt der Consent für Google Ads als verweigert.

Legt fest, wann der Tag Manager lädt.

Basic (empfohlen): Der Tag Manager lädt erst, wenn der Besucher dem Google Tag Manager und Google Analytics 4 oder Google Ads zugestimmt hat. Vorher geht keine Anfrage an Google.
Advanced: Der Tag Manager lädt sofort, mit verweigertem Consent als Ausgangszustand. Google erhält dann Signale ohne Cookies und modelliert fehlende Conversions. Solange Google Ads nicht erteilt ist, schwärzt Google Anzeigen-Klick-IDs (ads_data_redaction). Der Banner-Eintrag „Google Tag Manager“ hat in diesem Modus keinen Einfluss darauf, ob der Tag Manager lädt – er wirkt nur noch über die Kopplung auf GA4 und Google Ads.

Ist weder „Consent für GA4 einholen“ noch „Consent für Google Ads einholen“ aktiv, lädt der Tag Manager in Basic nach Einwilligung in den Google Tag Manager allein. Nicht angebotene Google-Dienste meldet NIU Plus im Consent Mode immer als verweigert.

Advanced lädt den Google Tag Manager ohne Einwilligung. Das ist deine Entscheidung als Betreiber und geschieht auf eigene Verantwortung. Ob das Laden des Tag Managers ohne Einwilligung zulässig ist, ist rechtlich umstritten: Das VG Hannover hat die Einbindung als einwilligungspflichtig eingestuft. Lass das Setup rechtlich prüfen, bevor du es live nimmst.

NIUplus (Standard): NIU Plus meldet den Consent Mode an Google – Ausgangszustand „verweigert“, danach die Entscheidung des Besuchers: Google Analytics 4 steuert analytics_storage, Google Ads steuert ad_storage, ad_user_data und ad_personalization.
Consent-Manager-Plugin: Wähle diese Option, wenn dein Consent-Plugin den Consent Mode bereits selbst an Google meldet (z. B. Webstollen EU Cookie ab Version 2.6). NIU Plus fasst den Consent Mode dann nicht an.

Es darf immer nur eine Quelle den Consent Mode setzen. Melden beide, widersprechen sich die Signale.

Wähle „Consent-Manager-Plugin“ nur, wenn dein Plugin den Consent Mode wirklich setzt. Der JTL Consent Manager tut das zum Beispiel nicht – im Modus Advanced liefe der Tag Manager dann ganz ohne Consent Mode. Das Backend zeigt bei dieser Kombination einen Hinweis.

Im Consent-Banner sind die Google-Schalter gekoppelt: Wer Google Analytics 4 oder Google Ads erlaubt, erlaubt automatisch auch den Google Tag Manager. Wird der Tag Manager abgelehnt, sind auch GA4 und Google Ads aus. Mehr dazu unter Consent & Tracking einrichten. Nutzt du Webstollen EU Cookie, beachte Google Tag Manager unter EU Cookie.

Enhanced Conversions

Übergibt SHA-256-gehashte Kundendaten als user_data in den dataLayer. Das verbessert das Matching von Conversions in Google Ads und das User-Tracking in GA4. Die Daten stehen nie im Quelltext deines Shops. Der Tag Manager holt sie im Hintergrund ab – und zwar nur, wenn der Besucher Google Ads zugestimmt hat. Gehasht wird immer auf dem Server, Klartext verlässt deinen Shop nicht. Bei einer Bestellung steht user_data im dataLayer bereit, bevor das purchase-Event folgt.

boolean

Master-Schalter. Wenn aus, wird kein user_data gepusht.

boolean

Empfohlen. Die E-Mail ist das wichtigste Match-Signal für Enhanced Conversions.

boolean

Vorname, Nachname, Straße, PLZ, Ort, Land. Verbessert die Match-Quality, ist aber DSGVO-relevant. Telefon und Bundesland werden bewusst nicht übertragen.

boolean

Zusätzlich zur Bestellung wird user_data auf jeder Seite gepusht, sobald ein User eingeloggt ist. Verbessert das Cross-Device-Matching für GA4. Wenn aus, wird user_data nur bei der Bestellung gepusht.

GA4 vom Server (Measurement Protocol)

Dein Shop kann Käufe direkt vom Server an Google Analytics 4 melden. So kommen auch Käufe in GA4 an, die der Browser nicht übertragen kann – etwa weil ein Adblocker aktiv ist, Safari das Tracking einschränkt oder der Käufer nach einer externen Zahlung nicht in den Shop zurückkehrt.

Browser, Server oder beides

GA4 zählt einen Kauf doppelt, wenn er über den Tag Manager im Browser und vom Server ankommt. Anders als Meta und TikTok sortiert GA4 die beiden Meldungen nicht aus – auch nicht bei derselben Bestellnummer (transaction_id), demselben Nutzer und derselben Sitzung. Das haben wir in GA4 nachgemessen. Deshalb legst du unter GTM → Käufe an GA4 melden fest, auf welchem Weg GA4 den Kauf bekommt:

Einstellung	Kauf im Tag Manager (`purchase`)	Kauf vom Server an GA4	Wann sinnvoll
Browser (Standard)	ja	nein	wie bisher, ohne Server-Weg
Server	nein	ja	dein Container braucht den Kauf für nichts anderes als GA4
Beides	ja, mit Kennzeichen	ja	andere Tags im Container brauchen den Kauf (z. B. Google-Ads-Conversion), GA4 bekommt ihn nur vom Server

Server: Der Kauf fehlt dann im Tag Manager – für alle Tags. Die Google-Ads-Conversion, Luigi’s Box und weitere Tools, die auf purchase reagieren, bekommen ihn nicht mehr. Wähle „Server“ nur, wenn dein Container den Kauf ausschließlich für GA4 nutzt.

Beides: Der Kauf bleibt im Tag Manager und trägt das Kennzeichen dzm_ga4_server: true. Dein GA4-Tag darf ihn nicht an GA4 weitergeben, sonst zählt GA4 doppelt. In unserer GTM-Vorlage ist diese Ausnahme schon eingerichtet. Nutzt du einen eigenen Container, lege sie an wie unter Ausnahme im eigenen Container beschrieben.

Der Server meldet Käufe stündlich per Cronjob (siehe Versand und Kontrolle). Bei „Server“ und „Beides“ erscheint der Kauf in GA4 deshalb bis zu einer Stunde später. Läuft der Cronjob nicht, kommt bei diesen beiden Einstellungen kein Kauf bei GA4 an.

Solange der Server-Weg nicht läuft – das API-Secret fehlt oder ist nicht lesbar, die Mess-ID fehlt oder GA4 im Browser ist aus – und solange der Debug-Modus an ist, geht der Kauf wie bei „Browser“ über den Tag Manager an GA4, ohne Kennzeichen. So geht kein Kauf verloren. Das Backend nennt dir den Grund.

Voraussetzungen

Für „Server“ und „Beides“:

GA4 im Browser ist aktiv: Unter Allgemein ist der Google Tag Manager eingebunden und die ID eingetragen, unter Consent ist „Consent für GA4 einholen“ aktiv. Auch bei „Server“ braucht es GA4 im Browser – ohne GA4 im Browser gibt es kein _ga-Cookie und keinen Eintrag im Consent-Banner.
Einwilligung des Käufers: Gesendet wird nur, wenn der Käufer bei der Bestellung Google Analytics 4 im Consent-Banner zugestimmt hatte. Mehr dazu unter Server-Side und Einwilligung.
Cronjob von DZM Resources: Die Käufe werden stündlich über die Aufgabe „DZM Resources: Server-Side-Tracking senden“ verschickt. Sie wird bei der Installation bzw. beim Update von DZM Resources automatisch angelegt.

Einrichtung

Weg wählen

Wähle im NIU-Plus-Backend unter GTM in der Box Käufe an GA4 melden „Server“ oder „Beides“. Danach erscheinen die weiteren Felder.

Bei „Beides“: Ausnahme im Container

Mit unserer GTM-Vorlage ist nichts zu tun. Bei einem eigenen Container lege die Ausnahme an und veröffentliche den Container.

Mess-ID eintragen

Trage im Feld „GA4-Mess-ID“ die Mess-ID deines GA4-Datenstreams ein, z. B. G-ABC123XYZ. Du findest sie in GA4 unter Verwaltung → Datenstreams beim Web-Datenstream deines Shops.

API-Secret in GA4 anlegen

Öffne in GA4 Verwaltung → Datenstreams, wähle den Web-Datenstream deines Shops und öffne Measurement Protocol API-Secrets. Lege dort ein neues Secret an, z. B. mit dem Namen „JTL-Shop“, und kopiere den Wert.

API-Secret speichern

Füge den Wert im Feld „API-Secret (Measurement Protocol)“ ein und klicke direkt neben dem Feld auf Speichern. Das Feld speichert sofort, unabhängig vom Speichern-Button der Seite. Das Secret wird verschlüsselt abgelegt und danach nie wieder angezeigt – das Feld zeigt nur noch den Zustand Gespeichert.

Einstellungen speichern

Lege fest, ob Stornos gesendet werden (siehe unten), und speichere die Seite.

Ersten Kauf prüfen

Prüfe nach dem ersten echten Kauf in DZM Resources unter Tracking, ob er als „gesendet“ markiert ist, und danach in GA4, dass er einmal ankommt. Bei „Beides“ zeigt die Vorschau des Tag Managers: Der GA4-Tag für E-Commerce-Ereignisse löst beim purchase nicht aus, die Google-Ads-Conversion schon.

Ausnahme im eigenen Container

Nur nötig bei Beides und einem Container, der nicht auf unserer Vorlage beruht. So nimmt der GA4-Tag den Kauf aus, alle anderen Tags bekommen ihn weiter:

Variable anlegen

Variablen → Neu → Datenschichtvariable, Name der Datenschichtvariable dzm_ga4_server, Version 2. Speichere sie z. B. als dl_dzm_ga4_server.

Trigger anlegen

Trigger → Neu → Benutzerdefiniertes Ereignis, Ereignisname purchase, Auslösen bei Einige benutzerdefinierte Ereignisse: dl_dzm_ga4_server ist gleich true. Speichere ihn z. B. als „purchase vom Server (Ausnahme GA4)“.

Als Ausnahme anhängen

Öffne den GA4-Ereignis-Tag, der deine E-Commerce-Ereignisse an GA4 sendet, und füge den Trigger unter Ausnahmen hinzu. Hänge ihn nicht an Google-Ads-Tags – die brauchen den Kauf weiter.

Testen und veröffentlichen

Prüfe in der Vorschau einen Testkauf: Beim purchase steht der GA4-Tag unter „Nicht ausgelöste Tags“. Veröffentliche den Container danach.

Einstellungen

Browser | Server | Beides

Auf welchem Weg GA4 den Kauf bekommt, siehe Browser, Server oder beides. Standard: Browser. Hattest du vor diesem Update „Käufe zusätzlich vom Server an GA4 melden“ eingeschaltet, steht die Einstellung nach dem Update auf Beides – prüfe dann deinen Container auf die Ausnahme.

string

Die Mess-ID deines GA4-Datenstreams im Format G-….

string

Das API-Secret aus deinem GA4-Datenstream. Der Zustand wird als Kennzeichen angezeigt:

Nicht gesetzt – es ist noch kein Secret hinterlegt.
Gespeichert – ein Secret ist hinterlegt. Trägst du einen neuen Wert ein, ersetzt er den alten. Mit Entfernen löschst du das Secret; danach geht der Kauf wieder wie bei „Browser“ über den Tag Manager an GA4, bis du ein neues einträgst.
Per Konstante gesetzt – das Secret kommt aus der config.JTL-Shop.ini.php (siehe unten), das Feld ist dann gesperrt.
Nicht lesbar – bitte neu eintragen – das gespeicherte Secret lässt sich nicht mehr entschlüsseln, z. B. nach einem Wechsel des Verschlüsselungsschlüssels im Shop. Trage es neu ein.

boolean

Wird eine Bestellung in der JTL-Wawi vollständig storniert, meldet der Shop ein refund an GA4. Nur bei „Server“ und „Beides“ und nur für Käufe, die vorher vom Server gemeldet wurden.

boolean

Sendet an den Prüf-Endpunkt von GA4: Google prüft das Format, zeichnet aber nichts auf. Ergebnis und Meldungen stehen in DZM Resources unter Tracking. Solange der Debug-Modus an ist, geht der Kauf wie bei „Browser“ über den Tag Manager an GA4 – sonst käme er nirgends an.

Der Prüf-Endpunkt prüft Mess-ID und API-Secret nicht – ein falsches API-Secret meldet Google dort nicht. Schalte den Debug-Modus nach dem Test wieder aus und prüfe nach dem ersten echten Kauf in GA4, ob der Kauf ankommt. Ein im Debug-Modus gemeldeter Kauf zählt in GA4 nicht; zu ihm wird deshalb auch kein refund gesendet.

Was übertragen wird

Kauf: Bestellnummer, Währung, Wert, Steuer, Versandkosten, Gutschein und Artikel – dieselben Werte wie das purchase-Event im Browser. Dazu die GA4-Kennungen aus den Cookies _ga und _ga_… (damit GA4 den Kauf der richtigen Sitzung zuordnet), IP-Adresse und Browserkennung des Käufers sowie der Bestellzeitpunkt.
Storno: Bestellnummer, Währung und Wert, ohne Artikel, ohne IP-Adresse und Browserkennung.
Google-Ads-Einwilligung: GA4 bekommt mit, ob der Käufer Google Ads zugestimmt hatte (ad_user_data, ad_personalization).

GA4 nimmt Ereignisse nur bis 72 Stunden nach dem Kauf an. Läuft der Cronjob länger nicht, werden ältere Käufe deshalb nicht mehr gesendet. Hatte der Käufer bei der Bestellung noch kein _ga-Cookie, kann GA4 den Kauf keiner Sitzung zuordnen – er wird dann nicht vom Server gesendet. Bei „Server“ fehlt er in GA4 dann ganz.

Zugangsdaten per Konstante

Statt das API-Secret im Backend einzutragen, kannst du es als Konstante in der config.JTL-Shop.ini.php deines Shops hinterlegen. Die Konstante hat Vorrang vor einem im Backend gespeicherten Wert.

config.JTL-Shop.ini.php

define('DZM_TRACKING_GA4_API_SECRET', 'dein-api-secret');

Versand und Kontrolle

Bei der Bestellung legt der Shop den Kauf nur in einer Warteschlange ab – der Checkout wird dadurch nicht langsamer. Der Cronjob „DZM Resources: Server-Side-Tracking senden“ verschickt die Käufe stündlich. Kann ein Kauf nicht zugestellt werden, versucht der Shop es erneut, mit wachsendem Abstand und insgesamt bis zu fünfmal. Alle Versände mit Status und Meldung siehst du in DZM Resources → Tracking in der Box „Server-Side-Tracking: Versände“. Details unter Tracking in DZM Resources.

Quickstart

Updates & Changelog

Aktuelles

Setup