Wir konzentrieren uns auf das Debuggen unseres TAGGRS Demoshops, eines einfachen E-Commerce-Webshops. Zum Testen richten wir verschiedene Komponenten ein, um eine Tracking-Umgebung zu schaffen:
Der Debugging-Prozess im Server-Container unterscheidet sich von dem im Web-Container dahingehend, dass Sie den Vorschaumodus sowohl für Web- als auch für Server-Container aktivieren müssen.
Sehen Sie sich das Video unten an, um den Prozess Schritt für Schritt nachzuvollziehen.
Beim Öffnen des Vorschaumodus in GTM werden Unterschiede zwischen den Web- und Server-Containern deutlich. Der Server-Container führt neue Tabs ein, die speziell auf seine Funktionalität zugeschnitten sind.
Im Web-Container auf der linken Seite sehen wir unter der Zusammenfassung:
Im Server Container sehen wir:
Im Bereich „Summary“ des Server-Containers werden spezifische Ereignisse durch den Parameter collect?=v dargestellt, der den Typ des verarbeiteten Ereignisses angibt, zum Beispiel ein GA4-Ereignis. Unter „collect“ befindet sich das Ereignis, das in diesem Fall page_view ist.js?id=G-XXXXXXXX = Anfrage von der Google Tag JavaScript-Bibliothekcollect?v=2 = GA4-Anfragen
Um zu überprüfen, ob Daten korrekt im Server-Container ankommen, prüfen wir zunächst, ob der Server-Container Daten vom Web-Container empfangen hat. Dies tun wir über den Bereich 'Request' in GTM. Hier sehen Sie, welcher Client die eingehenden Anfragen verarbeitet hat, welche Anfragen eingehen und welche ausgehen.
Nachdem die Daten erfolgreich vom Web-Container an den Server-Container und dann an Google Analytics übermittelt wurden, ist es an der Zeit zu testen, ob unsere eingerichteten Tags korrekt funktionieren. Wir konzentrieren uns darauf, ein View-Item-Ereignis in unserem TAGGRS Demo Webshop zu testen.
Im Web-Container sehen wir, dass zwei Tags aktiviert werden: unser GA4-Ereignis und der TAGGRS-Server-Tag. Dies ist der Zeitpunkt, um zu überprüfen, ob alle notwendigen Tags wie beabsichtigt ausgelöst werden. Wenn dies der Fall ist, bestätigt es, dass die Trigger korrekt eingestellt sind und die Daten ordnungsgemäß an den Server weitergeleitet werden.
Nachdem die notwendigen Tags korrekt aktiviert wurden, ist es wichtig zu überprüfen, welche spezifischen Daten diese Tags mitsenden. Dies kann im Bereich der Ereignisdaten innerhalb des Server-Containers eingesehen werden. Hier finden Sie alle Daten, die vom Web-Container an den Server-Container übergeben wurden. Für ein 'view item'-Ereignis in unserem Demo-Shop möchten wir beispielsweise, dass Informationen wie der Preis, der Name und eventuell eine ID des Produkts weitergeleitet werden. Dieser Abschnitt ermöglicht es Ihnen zu überprüfen, ob die erstellten Variablen korrekt übergeben werden.
Man arbeitet nicht direkt im Server-Container mit der Data-Layer-Struktur, sondern mit den Namen der Parameter, die man übergibt.
Nach der Aktivierung der entsprechenden Tags ist der nächste Schritt zu überprüfen, ob die Daten in der entsprechenden Plattform korrekt verarbeitet wurden. Dies können Sie über die Debug-Modi der Plattformen selbst beurteilen oder mithilfe verschiedener Debug Chrome-Erweiterungen.
Im TAGGRS Server-side Analytics Dashboard können Sie Folgendes überprüfen:
Der Web-Container kann Fehler anzeigen, ähnlich denen, die Sie in der Konsole sehen würden, während der Server-Container über einen speziellen Konsolen-Tab verfügt.
Dieser Debug-Tab kann nützliche zusätzliche Informationen zur Fehlerbehebung liefern.
Wenn Sie Berechtigungs- (Consent-) Einstellungen konfiguriert haben, zum Beispiel mit Consent Mode V2, zeigt dieser Tab an, welche Consent-Status gesetzt und ausgelöst wurden, was besonders nützlich für das Debugging von Consent Mode V2 und auch für die Überprüfung der Standardeinstellungen ist.
Im Web-Container-Vorschaumodus bietet der Tab „Data Layer“ wesentliche Informationen über die Struktur und die vom Webauftritt für Tracking-Zwecke gesendeten Daten. Dies ist eine wichtige Informationsquelle für alle Tags, die für ihre Funktion auf den Data Layer angewiesen sind.
Der Tab „Variablen“ listet alle verfügbaren Variablen innerhalb des Containers auf, die zum Festlegen von Triggern oder zum Definieren von Tag-Konfigurationen verwendet werden können. Dieser Tab ist wichtig, um zu verstehen, welche Daten für die Verwendung in Tags und Triggern verfügbar sind.
Sobald verifiziert, veröffentlichen Sie den aktualisierten Server-Container, um die Transformation live zu schalten.
Die Einrichtung von serverseitigem Tracking erfordert die Koordination vieler Komponenten über Web- und Server-Container hinweg. Selbst bei einer sorgfältigen manuellen Einrichtung sind Fehlkonfigurationen häufig und schwer zu erkennen, und wenn das Tracking aufgrund eines Einrichtungsfehlers nicht die gewünschte Leistung erbringt, verliert man leicht das Vertrauen in die Daten.
Das Tracking Audit Tool beseitigt diese Unsicherheit. Sobald Ihr Setup live ist, nutzen Sie es, um Ihre gesamte GTM-Infrastruktur – sowohl Web- als auch Server-Container – direkt von Ihrem TAGGRS-Dashboard aus automatisch zu scannen. Es prüft in Sekundenschnelle die häufigsten Tracking-Fallstricke und erspart Ihnen so Stunden manuellen Debuggings im GTM-Vorschaumodus.
So greifen Sie darauf zu: Gehen Sie zu Ihrem TAGGRS-Dashboard → Übersicht → Tracking-Einrichtung optimieren (Schritt 7).
Im Folgenden finden Sie die häufigsten Probleme, die verhindern, dass die Tags ausgelöst werden, praktische Lösungen und zwei spezifische Situationen, die einen gezielteren Ansatz zur Problembehandlung erfordern.
Die allgemeinen Gründe, warum ein Tag nicht ausgelöst wird, sind:
gtm.blocklist und gtm.allowlistDie allgemeinen Gründe, warum ein Tag nicht ausgelöst wird, sind:
Prüfen Sie im Vorschaumodus, ob das GA4-Tag ausgelöst wird. Wenn es im Web-Container ausgelöst wird, aber nicht im Server-Container, überprüfen Sie, ob die Measurement-ID (Web Container) und die Tag-ID (Server Container) in den GA4-Konfigurations-Tags übereinstimmen.
Für die Diagnose und Behebung des Problems ist es von entscheidender Bedeutung, die Nuancen zu verstehen, warum ein Tag möglicherweise nicht ausgelöst wird.
Folgen Sie den oben beschriebenen Schritten, um häufig auftretende Probleme beim Auslösen von Tags in Google Tag Manager zu beheben. Denken Sie daran, dass detaillierte Tests und Überprüfungen entscheidend sind, um sicherzustellen, dass Ihr Tracking-Setup wie vorgesehen funktioniert.
In Situationen, in denen der Debug-Modus von Google Tag Manager zwar Seitenaufrufe anzeigt, E-Commerce-Ereignisse jedoch nicht registriert, liegt das Problem häufig in der Abstimmung zwischen der Mess-ID des Google-Tags und der E-Commerce-Konfiguration. Es ist wichtig sicherzustellen, dass die in Ihrem Google-Tag-Setup verwendete Mess-ID genau mit der für das E-Commerce-Tracking konfigurierten ID übereinstimmt. Abweichungen zwischen diesen IDs können dazu führen, dass Seitenaufrufe korrekt verfolgt werden, während E-Commerce-Ereignisse verpasst werden. Überprüfe diese Konfigurationen noch einmal, um die Konsistenz und die korrekte Verfolgung aller gewünschten Aktionen auf deiner Website sicherzustellen.
Stellen Sie außerdem sicher, dass Sie kein doppeltes Tracking-Skript im Code haben. In einigen Fällen stellen wir fest, dass das Google Tag Manager-Skript auf verschiedene Arten in den Code geladen wird, häufig durch manuelles Platzieren + über ein Plugin. Dies kann in einigen Fällen das Tracking stören.
Prüfen Sie also immer, ob der Code einen Tracking-Code (pro Container) enthält. In der Abbildung unten können Sie sehen, dass das Tracking an mehrere Quellen gesendet wird. Idealerweise möchten Sie, dass hier nur serverseitige Domains aufgeführt werden, an die Sie die Daten senden. Andernfalls können Ereignisse von den anderen missbraucht werden.
Nach der Implementierung von serverseitigem Tracking über TAGGRS erhalten Sie beim Öffnen der Konsole im Browser Fehler. Oft sind diese Fehler harmlos oder lassen sich leicht beheben. Hier sind alle Situationen und Lösungen für Konsolenfehler nach der Implementierung unserer Software aufgeführt.
Wenn in der Konsole der Fehler ERR_BLOCKED_BY_ORB 200 angezeigt wird, bedeutet dies, dass unser TAGGRS-Tracking-Tags-Pixel durch Tracking-Verhinderung blockiert ist (siehe zum Beispiel Aktualisierungen von Safari 26) aufgrund von Browserpräventionen und -vorschriften. Wenn TAGGRS aufgrund des serverseitigen Trackings zusätzliche Daten grafisch darstellt, wird ein Pixel über den Web-Container verwendet. Wenn Sie ERR_BLOCKED_BY_ORB 200 sehen, bedeutet das, dass es (teilweise) blockiert wird. Das hat keine Auswirkungen auf dein Tracking, das ist nur das zusätzliche Datengraph!
Sollten Sie bei der Integration des GTM-Codes auf einen der unten aufgeführten Fehler stoßen, können Sie sicher sein: Der Code bleibt funktionsfähig.
Wenn in der Konsole ein 400-Fehler angezeigt wird, deutet dies in der Regel darauf hin, dass bei der Einrichtung der Client-Erstellung im Servercontainer ein verpasster Schritt versäumt wurde. Dies ist eine wichtige Phase bei der Konfiguration des Enhanced Tracking Script.
Bei der Verwendung des Enhanced Tracking-Skript, es ist nicht erforderlich, einen veralteten Google Tag Manager-Code zu pflegen. Das liegt daran, dass dann zwei verschiedene Tag-Manager (der alte und das Enhanced Tracking Script) gleichzeitig geladen werden. Um dieses Problem zu lösen, sollte der ursprüngliche GTM-Code nach der Aktivierung des Enhanced Tracking Script entfernt werden. Nur der GTM-Code des Enhanced Tracking Script bleibt erhalten.
Das Erreichen des Anforderungslimits (TAGGRS Dashboard) kann dazu führen, dass Tag Manager pausiert und das Tracking gestoppt wird. Es ist wichtig zu verstehen, dass nach der Implementierung des Enhanced Tracking Script das Überschreiten des Anforderungslimits die Tracking-Funktionalität unterbricht. Die Überwachung und Verwaltung des Anforderungslimits ist daher von entscheidender Bedeutung, um eine kontinuierliche Nachverfolgung zu gewährleisten.
Treten in Ihrem Magento 2-Servercontainer keine Anfragen für Server Side Tracking auf? Dies ist häufig auf die CORS-Regeln von Magento zurückzuführen, die ausgehende Anfragen aus Sicherheitsgründen blockieren sollen. Um das Problem zu beheben, passen Sie Ihr .htaccess mit Header an und fügen Sie Access-Control-Allow-Origin "https://*.yourdomain.com" hinzu und ersetzen Sie "https://*.yourdomain.com" durch Ihre Subdomain, um sicherzustellen, dass Ihre Anfragen zulässig sind. Überprüfe unsere Magento 2 Artikel ohne Anfrage.
Parameter zulassenParameter ausschließenBereicherung von Veranstaltungen
