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. 

  1. Den Nutzer nicht (erneut) auf die Thankyou Seite leiten
  2. Das Tracking serverseitig unterbinden, was sie trotz IT Aufwand als beste Lösung bezeichnet. 
  3. Beim Reload der Seite den DataLayer Push/ das Tracking unterbinden
  4. 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.

Optimierung von Gebotsstrategien in Search Ads 360 mit der Hilfe von Wetterdaten der METEONOMIQS-API

Server Side Consent Mode für mehr Datenschutz und besseres Reporting in Google Analytics

Der Google Consent Mode ist ein wesentlicher Baustein im Google Ökosystem um Cookieless Tracking zu ermöglichen. Er bildet die Grundlage für die Modellierung von Daten um Messlücken durch fehlenden Consent und Browser Restriktionen wie Safari ITP zu schließen. Aktuell bestehen allerdings noch 2 wesentliche Problem, die den sinnvollen Einsatz des Consent in der Regel verhindern:

  1. Im Fall des Cookieless Trackings mittels “Pings” wird die IP Adresse des Nutzers an Google übertragen
  2. Die Daten des Consent Modes werden zwar für die Modellierung genutzt, erweitern aber die Daten in Google Analytics nicht

Wie beide Probleme mit dem Server Side Consent Mode und den Rohdaten aus BigQuery gelöst werden können zeigen wir in diesem Artikel.

Was ist der Google Consent Mode?

Wichtig zu wissen: Der Google Consent Mode übernimmt nicht die Funktion einer Consent Management Platform (CMP), sondern kümmert sich darum, dass die Tags von Google (Google Analytics, Google Ads, Floodlight) den Consent-Status des Nutzers berücksichtigen. So kann sichergestellt werden, dass ohne Consent keine Cookies gesetzt werden – stattdessen werden lediglich “Pings” an Google gesendet die keinen Bezug haben zu einem spezifischen Nutzer. Diese “Pings” werden anschließend dafür genutzt Daten in z.B. Google Analytics zu modellieren, also die Datenqualität zu verbessern, die durch nicht vorhandenen Consent oder Browser Restriktionen wie Safari ITP eingeschränkt ist. 

Probleme des Consent Mode

Die Idee hinter dem Consent Mode ist grundsätzliche eine feine Sache: ist keine Zustimmung zum Tracking vorhanden werden nur Signale verwendet die ohne Bezug zum Nutzer auskommen und mit diesen Signalen wiederum werden die Daten, welche mit Zustimmung erhoben wurden, verbessert. Wer den Consent Mode einsetzt wird allerdings auf folgende Probleme stoßen:

Übertragung der IP Adresse

Beim Einsatz des Consent Mode wird – auch wenn keine Zustimmung zum Tracking gegeben wurde – die IP Adresse des Nutzers an Google Server übertragen. Google gibt zwar an, die IP Adresse nicht zu speichern, dennoch wird diese als Teil der normalen Funktionalität des Internets zuvor an Google übertragen. 

Blackbox Conversion Modelling

Für das Reporting in Google Analytics verspricht der Consent Mode eine verbesserte Datenqualität in dem die Zuweisung der Marketingkanäle für die gemessenen Conversions auf Basis der Informationen des Consent Mode verbessert wird. Das bedeutet allerdings nicht dass dadurch mehr Conversions für die Analyse zur Verfügung stehen, sondern es wird ledigliche die Zuweisung der mit vorhandenen Consent messbaren Conversions angepasst. Dadurch entsteht eine Blackbox wie genau die entsprechenden Zuweisungen zustande kommen.

Conversion Modelling in Action

Wir haben das Conversion Modelling in einer “Laborsituation” getestet und in unserem Testshop User simuliert, die Conversions erzeugen um das Verhalten genau nachvollziehen zu können. Anschließend wurden dieser User einmal mit und einmal ohne Consent Mode in zwei unterschiedlichen GA4 Properties gemessen.

Hier das Ergebnis des Tests 

Ohne Consent Mode:

Mit Consent Mode:

Die Unterschiede in einer Tabelle:

QuelleConversions ohne Consent ModeConversions mit Consent ModeDifferenz
not set10981-28
facebook1425+11
banner814+6
affilliate611+5
bing510+5
direct01+1
SUMME1421420

Wir sehen also: Die Gesamtzahl an Conversions in Google Analytics 4 ändert sich durch den Consent Mode und das Conversion Modelling nicht – lediglich die Zuweisung der Kanäle zu den Conversions ändert sich.

Leider können wir hier nicht sehen was im Hintergrund genau passiert ist und welche Conversions genau Teil des Conversion Modellings von Google sind. 

Der grundsätzliche Ansatz lässt sich aber bereits aus obiger Tabelle ablesen: 28 Conversions für welche die Quelle ohne Consent Mode und Conversion Modelling unbekannt war, konnten Marketing Kanälen zugewiesen werden. Conversion Modelling sorgt daher dafür dass wir mehr Conversions zu Marketing Kanälen zuweisen können und damit ein besseres Bild über den Impact unserer Marketing Aktivitäten bekommen. 

Ernüchternd ist, dass wir nicht mehr Conversions sehen können, obwohl jene Conversions über die Conversion Pings des Consent Modes – auch bei nicht vorhandenem Consent – an Google geschickt werden.

Die Lösung: Server Side Implementierung & BigQuery

Um von den Vorteilen des Consent Mode profitieren zu können gilt es die beiden obigen Probleme zu lösen. Im Allgemeinen, und gerade wenn wir keinen Consent des Nutzers haben, wollen wir vermeiden dass die IP Adresse an Google übertragen wird und gleichzeitig ist es auch wünschenswert die Gesamtanzahl an Conversions ins Reporting zu bekommen.

Kontrolle über den Consent Mode: Übertragung der IP Adresse verhindern

Mit einer Server seitigen Anbindung des Consent Modes können wir die an die Google Server übertragenen Daten kontrollieren und Informationen verändern bevor diese an die Server von Google übertragen werden.

Hier am Beispiel der IP Adresse:

Unterbindung der Übertragung der IP Adresse beim Einsatz des Google Consent Mode mit Google Analytics 4

Damit können wir den Consent Mode vollständig an unsere Datenschutz-Bedürfnisse anpassen! Wie im obigen Beispiel dargestellt kann die IP Adresse gekürzt werden um keinen Bezug des Nutzers zur IP Adresse zu ermöglichen. Bei Bedarf können wir ebenso die Übertragung der IP Adresse vollständig unterbinden oder die Übertragung weiterer Informationen verhindern. Das ist ein wesentlicher Baustein um den Consent Mode den eigenen Datenschutz-Bedürfnissen entsprechend einzusetzen.

Volles Conversion und Pageview Reporting via BigQuery

Wie bereits gezeigt, sehen wir in Google Analytics 4 trotz Conversion Modelling nicht mehr Conversions. Natürlich wäre es aber höchst interessant zu wissen wie viele Conversions insgesamt passiert sind. Tatsächlich ermöglicht uns der Consent Mode das – und zwar mittels dem Rohdatenexport aus Google Analytics 4 nach BigQuery. Dort landen die mittels der Cookieless Pings übertragenen Ereignisse in Rohdatenform und lassen dementsprechend auch auswerten.

Verknüpfen wir Google Datastudio mit den Rohdaten aus Google Analytics 4, können wir zwischen den Ereignissen aus den Cookieless Pings und dem Cookie basierten Tracking mit User-Consent unterscheiden und die fehlenden Conversions reporten:

Reporting auf Basis der Rohdaten aus dem Google Consent Mode mit Google Datastudio, hier Verkäufe

So sehen wir, dass wir statt den 142 Käufen, welche wir in GA4 direkt gesehen haben tatsächlich 50 Käufe mehr, also insgesamt 192 Käufe hatten! Ebenso können wir den gesamt erzielten Umsatz ausweisen. Neben einem vollständigen Bild unserer Conversions können wir damit auch wertvolle Rückschlüsse darüber bilden wie sich das Consent Management auf die Conversion-Messung auswirkt – ein wesentliche Information wenn wir auf Basis der gemessenen Daten Hochrechnungen auf die Gesamtmenge anstellen möchten.

Darüber hinaus können wir nun den genutzten Content auf der Webseite wesentlich besser analysieren. So könnten wir uns etwa die Frage stellen wie viele Aufrufe unsere Jobangebote insgesamt bekommen haben, unabhängig davon ob uns Nutzer Consent gegeben haben oder nicht. Das ist ebenso problemlos möglich:

Reporting auf Basis der Rohdaten aus dem Google Consent Mode mit Google Datastudio, hier die Nutzung bestimmter Webseiten Bereiche

Ein Blick in Google Analytics hätte uns etwa 20.000 Aufrufe gezeigt – tatsächlich waren es aber um 6.700 Aufrufe mehr von Usern welche keine Zustimmung zum Tracking gegeben haben.

Die Nutzung der Rohdaten ermöglicht uns dabei keinen Rückschluss auf einzelne User – diese werden auch hier natürlich nicht erfasst, denn ohne Consent soll dieser auch nicht ermöglicht werden. Die Information darüber, wie viele Conversions insgesamt passiert sind und wie der Content auf der Webseite insgesamt genutzt wird bietet aber bereits wertvolle Rückschlüsse darüber wie viele Daten durch fehlenden Consent nicht gemessen wurde. Das wiederum bietet vielfältige Möglichkeiten die Daten für eine eigene Modellierung zu nutzen, die Hochrechnungen auf die Gesamtmenge ermöglicht.

Fazit

Der Google Consent Mode bietet einen spannenden Ansatz von Google Cookieless Tracking in Google Analytics 4 zu ermöglichen. Der Server Side Google Consent Mode erlaubt es das volle Potential zu enfalten. Die für den Datenschutz notwendige Kontrolle über die übertragenene Daten ist wesentlich für einen nachhaltigen und rechtskonformen Einsatz des Google Consent Mode. Die Möglichkeit mittels der Rohdaten aus BigQuery ein besseres Bild über die Gesamtanzahl an aufgerufenen Webseiten und Conversions zu bekommen sollte man darüber hinaus ebenso nicht ungenutzt lassen.