GA4: Transaktionen deduplizieren mit Serverside GTM & Firestore
Ein Klassiker der Probleme in der Datenqualität hat mit GA4 neuen Wind bekommen. Doppeltes Transaktion Tracking tritt in Google Analytics 4 häufiger auf als in Universal Analytics. In Universal Analytics ist eine Mechanik aktiv, die automatisch Transaktionen mit gleicher ID in der gleichen Session herausfiltert. Diesen Filter gibt es in Google Analytics 4 derzeit nicht.
Das macht den Einbau eines Filtersystems für fast jeden Onlineshop zu einem essentiellen Bestandteil des GA4 Setups.
Wie kommt es zu doppeltem Tracking?
Je nach Trackingsetup und Websitearchitektur gibt es verschiedene Ursachen für doppelte Transaktionen. Die häufigste Variante ist, dass beim Aufruf der “Thankyou” Seite des Shops die Transaktion via DataLayer Push und GTM an Analytics gesendet wird. Wenn diese Seite erneut geladen wird, wird auch der DataLayer Push erneut ausgeführt.
Das Reloading ist bei Desktop Nutzern wahrscheinlich ein selteneres Phänomen. Auf dem Smartphone tritt es jedoch viel häufiger auf. Wenn ein Nutzer nach dem Kauf das Handy einfach weglegt und später wieder den (Chrome-) Browser öffnet, dann laden sich die letzten Seiten erneut. Dies kann dann auch die “Thankyou” Seite sein.
Bisherige Methoden zur Deduplizierung von Transaktionen
Michaela Linhart hat in Ihrem Beitrag zu diesem Thema 4 Lösungswege aufgezeigt.
- Den Nutzer nicht (erneut) auf die Thankyou Seite leiten
- Das Tracking serverseitig unterbinden, was sie trotz IT Aufwand als beste Lösung bezeichnet.
- Beim Reload der Seite den DataLayer Push/ das Tracking unterbinden
- Das Tracking via GTM Clientseitig über ein Cookie/localStorage verhindern.
Da für die Lösungen 1, 2 und 3 in irgendeiner Form IT Ressourcen benötigt werden und Lösung 4 ohne IT-Support auskommt, ist dieser Weg der wahrscheinlich am häufigsten verwendete.
Nach dem Tracking der Transaktion wird hier ein Cookie/localstorage mit der Transaktionsnummer gesetzt. Beim Tracking kann dieses Cookie überprüft werden und geblockt werden, wenn die Nummer gefunden wird.
Das Cookie oder den Local Storage kann man über ein extra Tag direkt nach dem Purchase Tag auslösen. Für Universal Analytics gibt es von Simo Ahava ein Custom Task Script, das das übernimmt
Die beste Lösung wäre aber immernoch, das Tracking serverseitig zu unterbinden, da hierfür keine neuen Cookies/Storage Einträge auf den Geräten der Nutzer gespeichert werden müssen. Hier gibt es für Serverside GTM mit Einführung von Firestore jetzt eine Möglichkeit, die beste Lösung ohne IT Ressourcen aufzusetzen.
Deduplizierung mit serverside GTM & Firestore
Mit der Möglichkeit, mit dem Serverside Tag Manager von Firestore zu Lesen und zu Schreiben, können wir uns eine sehr schnelle NoSQL Datenbank der Transaktionsnummern aufbauen und bei für Nummer speichern, in welche Systeme sie schon getrackt wurde.
Wenn dann eine neue Transaktion eingeht, wird die Variable aus Firestore abgefragt. Ist sie gesetzt, wird die Transaktion geblockt. Wenn sie nicht vorhanden ist, wird die Transaktion getrackt und die Variable in Firestore geschrieben.
In Firestore sieht das dann so aus, dass wir für jede Transaktionsnummer ein Dokument sehen, was verschiedene Variablen haben kann. In diesem Fall gibt es nur die Variable “trakkedga4”, die immer auf “true” steht.
Vorbereitung in Firestore
Sind Serverside GTM und Firestore in verschiedenen Google Cloud Projekten aufgehangen, sollte zuerst eine Verbindung via Service Account hergestellt werden. Dazu muss ein Service Account des GTM Projekts als Cloud Data Store Nutzer hinzugefügt werden.
Soll der Firestore des serverside GTM Projekts verwendet werden, ist dieser Schritt nicht nötig. In einigen GCP Projekten ist Firestore unter Umständen nicht verfügbar.
In Firestore sollte dann eine neue Sammlung für transactions erstellt werden. Hier reicht es aus, lediglich den Namen zu definieren.
Variable “Read from Firestore / Write to Firestore”
Für die Deduplizierung musste ein neues Variablen Template geschrieben werden. Die Firestore Lookup Variable reicht nicht aus, weil wir auch zu Firestore schreiben müssen. Das Template kann hier heruntergeladen werden:
>> Variablen Template „Read from Firestore / Write to Firestore“ herunterladen <<
In der Variable gibt es 4 Felder:
- Firestore Document Path meint den Pfad zum Dokument in Firestore. Dieser besteht in diesem Fall aus der angelegten Sammlung “transactions” und der Transaktionsnummer. Die Transaktionsnummer kann im Falle von GA4 über eine Variable mit dem Query Parameter “ep.transaction_id”
- Die Projekt ID des Firestore Projektes
- Der Variablen Name
- Der Wert, der bei Nichtvorhandensein der Variable gesetzt werden soll.
Blocking Trigger für GA4 Tags
Mit dieser Variable können wir jetzt einen Blocking Trigger für unser GA4 Tag erstellen. Dieser kann entweder nur auch “purchase” Events oder auf alle Events “.*” feuern. Als Bedingung muss der Wert der Variable auf “true” gesetzt werden (bzw. Auf den Wert, der bei “Write value if not found” eingetragen wurde).
Kontrolle im Debug View
Im Debug View können wir dann bei den Outgoing Requests bei einer neuen Transaktion 3 Requests sehen. Einmal der Firestore Read Request, der einen 404 zurückspielt; daneben der Write Request an Firestore und als drittes den GA4 Request.
Wird dieselbe Transaktion noch einmal geschickt, sehen wir nur den Read Request. Der GA4 Hit wird geblockt.
Bei einem Pageview ohne Transaktion gibt es keine Kommunikation mit Firestore und der GA4 Tag löst normal aus.
Optionaler Schritt für viele Clients
Wenn auch andere Requests an den ss GTM einlaufen, die den gleichen Parameternamen für die Transaktion wie GA4 benutzen, kann über eine Lookup Tabelle abgesichert werden, dass die Variable ausschließlich bei Requests mit GA4 Client mit Firestore kommuniziert.
Erwartete Kosten
Das freie Kontingent von Firestore sind 50.000 Lesevorgänge und 20.000 Schreibvorgänge pro Tag. Außerhalb des freien Kontingents sind je 100.000 Requests 18 Cent für Schreiben und 6 Cent für Lesen angegeben.
Bei einem Projekt mit 1000 Transaktionen pro Tag, die in GA4 und Universal getrackt werden sollen, sind 2000 Write Requests und entsprechend etwas mehr Read Requests (~ 2500) pro Tag zu erwarten. Die Kosten sollten also keine Relevanz haben.
Fazit: Best Practice jetzt ohne IT
Ein Schutz gegen doppeltes Transaktionstracking ist bei GA4 Ecommerce Setups obligatorisch. Die Verbindung von Firestore und serverside GTM ermöglicht Webanalysten jetzt die bestmögliche Handhabung der Deduplizierung komplett ohne zusätzliche IT Ressourcen.
