Markus Baersch

Bei der Implementierung von parallelem Facebook Tracking via Pixel und CAPI über den Google Tag Manager bin ich vor ein paar Tagen auf ein eigenartiges Problem gestoßen: Die Event IDs der Ereignisse aus dem Browser und vom Server stimmten nicht überein, obschon sowohl das GA4 Tag, das durch den server-side GTM läuft als auch das Facebook Pixel Tag im Browser zur gleichen Zeit ausgelöst wurden. Nur hat das GA4 Tag für page_view, view_item, purchase und einige andere stets Event IDs späterer Events verwendet.

TL;DR: Wer nur die Lösung braucht: Es liegt am Tag Sequencing, das bei älteren client-side Tag Manager Containern die beste Option war, um wirklich alle Events durch den eigenen Server laufen zu lassen. Wer mehr wissen will, findet im Folgenden mehr Details zum Problem und zur Korrektur, die ich nur dank Denis von Stape kenne, obschon das Phänomen offenbar schon älter ist.

Event IDs für Meta CAPI

Das Problem liegt darin, dass zur Deduplizierung von Ereignissen aus dem Browser und via CAPI idealerweise eine gemeinsame "event_id" gesendet werden sollte, die Meta zur Deduplizierung von allen Ereignissen verwendet, die auf beiden Wegen dort ankommen. Dabei ist die Event ID nicht das einzige Mittel und sie nutzt nur in Kombination mit anderen Merkmalen. Die folgenden Bedingungen sorgen für saubere Deduplizierung bei Meta für alle Events, die den gleichen event_name Parameter enthalten, von beiden Quellen gesendet wurden und in einem der folgenden weiteren Merkmalen übereinstimmt:

• event_id
• external_ID
  
• fbp

Das bedeutet, dass Deduplizierung trotz falscher Event ID funktionieren kann. Dieser Zustand ist aber sicher nicht ideal und sollte daher korrigiert werden.

Falsche Event IDs bei GA4 Ereignissen

Alle Ereignisse, die "früh" beim Laden einer Seite ausgelöst werden, sind theoretisch von dem hier beschriebenen Problem betroffen, denn wie schon verraten ist die Ursache die Verbindung von Ereignis-Tag und dem Google Tag. Damit sind neben einem separat als Tag definierten Seitenaufruf auch alle Events betroffen, die beim Laden bestimmter Seitentypen stattfinden. Conversions, die auf URL Basis definiert sind zum Beispiel - oder viele Standard E-Commerce Ereignisse. Diese Verbindung zwischen Ereignis- und Google Tag und stammt üblicherweise aus der Zeit vor dem Google Tag, als es noch Tags vom Typ GA4 Konfiguration gab. Wer hier generelle Ereignisparameter für alles definiert hat, was nach dem Laden der Seite passiert ist, wollte speziell für die o. a. Ereignisse sicherstellen, dass diese Parameter gesetzt sind, bevor das Tag feuert. Das gilt vor allem (wenngleich nicht nur) für eine server_container_url, über die definiert wird, wohin das Tag die Daten senden soll.

Leidet das eigene Setup an diesem Problem, zeigt es sich wie folgt:

Im dataLayer finden sich zum Zeitpunkt des Auslösens der Tags (hier "consent_status" von Usercentrics) folgende Werte für eine Event ID:

• die Variable "0Event ID" basiert auf meinem Variablen-Template "Event ID",
• "0gtm.uniqueEventId" zeigt die uniqueEventId, wie sie vom GTM im dataLayer angelegt ist und die den hinteren Teil der Event ID bildet und
• "0Unique Event ID" ist mittels des "Unique Event ID" Templates von Stape generiert, wo ebenfalls am Ende die uniqueEventId aus dem dataLayer zu finden ist

Feuert man nun aber zu diesem Zeitpunkt ein GA4 Tag wie z. B. einen Seitenaufruf, bei dem diese Variablenwerte als event_id bzw. unique_event_id übergeben werden, findet man für beide Event Varianten einen abweichenden Wert - ebenso wie für die ebenfalls zu Demozwecken als gtm_event_id übergebene uniqueEventId aus dem dataLayer.

Schaut man dann die Liste der dataLayer Events "aufwärts" nach, findet man den Eintrag in einem späteren Event. Hier ist es "Window Loaded", es können aber auch beliebige andere später stattfindende Einträge sein.

Das GA4 Ereignis nimmt also die "uniqueEventId" eines späteren Events mit - und so auch die falsche Event ID für Meta auf Basis einer der beiden Variablen-Vorlagen, die sich beide dieser ID als Zähler für Events auf der gerade geladenen Seite bedienen.

Ergebnisse im Meta Events Manager

Sendet man nun mittels des Facebook Pixels die zum dataLayer Event passende ID (endend auf 442 im obigen Beispiel) und enthält der GA4 Request, der durch den eigenen server-side GTM läuft und dort vom CAPI Tag an Meta gesendet wird, eine andere ID (endet auf 553 im Beispiel), ist Deduplizierung zwar wegen der oben genannten alternativen Wege nicht völlig verloren, aber das Ergebnis im Events Manager sieht vermutlich so aus:

Die oberen Ereignisse sind dabei die angesprochenen "frühen" Events, die aufgrund der unterschiedlichen IDs im Gegensatz zum "AddToCart" nicht gruppiert dargestellt sind. Denn während ein Hinzufügen zum Warenkorb erst nach einem Klick stattfindet und das Problem daher nicht auftritt, haben die anderen Ereignisse unterschiedliche IDs. Dass dennoch "Dedupliziert" bei den vom Server gesendeten Ereignissen zu lesen ist, ist den beiden anderen Wegen zu verdanken. Es ist aber kein idealer Zustand.

Lösung: Ereignisparameter statt Tag Sequencing

Zur Korrektur müssen alle Ereignis-Tags, die derzeit via Sequencing zuerst das üblicherweise auf "Einmal pro Seite" beschränkte Google Tag (ehedem "GA4 Konfiguration") auslösen, angepasst werden. Bei einer überschaubaren Anzahl an Tags ist das manuell zu erledigen; bei umfangreichen Containern lohnen sich JSON-Export, Anpassung und anschließender Import.

Entfernt werden also Referenzen zur Tag-Reihenfolge...

... und als Ersatz werden alle Ereignisparameter, die vorher vom Google Tag "geerbt" werden sollten, entweder bei allen Tags direkt hinterlegt oder - viel einfacher - in einer Variable für Ereignisparameter definiert und diese bei allen betroffenen Tags zugeordnet.

Mit dieser Umstellung können alle Events wieder feuern, ohne auf das Google Tag warten zu müssen, was vorher zur ungewollten Verwendung von Variablenwerten "aus der Zukunft" gesorgt hat.

Korrekte Deduplizierung

Schaut man sich nach der Korrektur das Ergebnis im Meta Events-Manager an, sollten nun auch Seitenaufrufe und andere Ereignisse sauber dedupliziert und durch die Verwendung einer gemeinsamen Event ID wie erwartet gruppiert werden.

Sollten dabei einzelne Ereignisse nicht in dieser Form dargestellt werden: Keine Sorge. Wer die Event IDs der Ereignisse kontrolliert, wird vermutlich eine Übereinstimmung feststellen. Die Darstellung auf dem "Events Testen"-Tab des Events-Managers ist nicht zwingend zuverlässig. Mittelfristig sollte sich der Erfolg allerdings hoffentlich in der Übersicht bei der Matching-Qualität (z. B. beim PageView) zu sehen sein. Sehen die Werte zum Beispiel so wie hier aus, könnte sich ein Blick lohnen, wenngleich "Keine Fehler erkannt" wurden.

Kein Problem bemerkt? Trotzdem besser nachsehen!

Wie gesagt: Das Problem ist offenbar schon älter und vermutlich bereits seit Wegfall des GA4 Konfigurationstags ein Thema. Mir war es dennoch nicht bewusst und alles ist für jeden beim ersten Mal neu. Wer kann schon bei den laufenden Änderungen bei GA4 selbst und dem GA4-Tagging den Überblick behalten? Da zudem die Deduplizierung dadurch nicht unbedingt gleich in den Keller geht, ist es eine gute Idee, den eigenen GTM auf Tag Sequencing und dem damit verbundenen Problem zu überprüfen und die o. a. Umstellung vorzunehmen.