Cookieless GA4 mit Server-Side GTM & Firestore
Management Summary
1. Die Herausforderung von cookieless GA4
Die digitale Landschaft wandelt sich grundlegend in Richtung eines verstärkten Schutzes der Privatsphäre. Da Browser Cookies einschränken und sich rechtliche Rahmenbedingungen weiterentwickeln, stehen traditionelle Methoden der Webanalyse auf dem Prüfstand. Für Google Analytics 4 ist dies eine erhebliche Herausforderung, da die Fähigkeit, Nutzer*innen zu erkennen und deren Journey zu verfolgen, oft direkt von Browser-Cookies abhängt.
Einen cookielosen Status erzwingen
Um mit maximalem Respekt für die Privatsphäre zu agieren, können wir den Google Consent Mode nutzen. Dieser Mechanismus passt das Verhalten der Google Tags basierend auf der Zustimmung der Nutzer*innen an. Indem wir die Parameter analytics_storage und ad_storage standardmäßig auf “denied” setzen, weisen wir GA4 an, keine Analytics-Cookies zu schreiben oder zu lesen. Durch diese eine Maßnahme erreichen wir einen echt cookielosen Betrieb aus der Perspektive der User – was jedoch direkte technische Konsequenzen hat.
Daten, die verschwinden
Ohne Cookies ist GA4 effektiv “blind”. Jedes eingehende Event erscheint so, als käme es von einem brandneuen Gast. Wichtige Informationen, die die User Journey verknüpfen, gehen verloren oder werden bei jedem Seitenaufruf neu randomisiert. Dazu gehören kritische Parameter wie:
- Client ID (cid): Die eindeutige Kennung für den Browser des Users.
- Session ID (sid): Die Kennung für eine einzelne Nutzersitzung.
- Session Count (sct): Die Anzahl der Sitzungen dieses Users.
- First Visit (_fv) & Session Start (_ss): Flags, die diese Schlüsselereignisse markieren und zentrale Bestandteile der internen Nutzer- und Sitzungsverwaltung in GA4 sind.
Die Folge ist ein Zusammenbruch der Datenintegrität. Eine sinnvolle Analyse der Channel-Attribution, des Nutzerverhaltens und der Conversion-Funnels wird fast unmöglich. Wir sammeln zwar Zugriffe, verlieren aber die Geschichte, die sie eigentlich erzählen sollen.
2. Die Server-Side-Lösung
Ein Überblick
Angesichts der Datenlücken im cookielosen Browser besteht die Lösung nicht darin, den Browser zur Speicherung zu zwingen, sondern den Ort des “Gedächtnisses” zu verlagern. Wir übertragen die Verantwortung für die Identifizierung von Nutzer*innen und Sitzungen vom Client-Browser auf unseren eigenen Tracking-Server. Einfach gesagt: Wenn der Browser kein Gedächtnis in Form von Cookies haben kann, geben wir unserem Server eines in Form einer Datenbank.
Die Kombination aus serverseitigem GTM und einer Datenbank ermöglicht es uns, verlorene Informationen wiederherzustellen und den Nutzer- sowie Sitzungskontext neu aufzubauen. Aufgrund der nativen Anbindung von Firestore an den sGTM und der hohen Lese- und Schreibgeschwindigkeit ist dies die bevorzugte Wahl.
Die zwei Kernkomponenten dieses Setups sind:
- Server-Side Google Tag Manager (sGTM): Er fungiert als unser neuer Daten-Hub. Er empfängt die anonymen Rohdaten vom Browser; hier wird unsere Logik angewendet.
- Eine Datenbank (wie Firestore): Sie dient als persistentes Gedächtnis des Systems. Sie speichert die notwendigen Informationen, um wiederkehrende Nutzer*innen zu erkennen und deren Journey zusammenzuführen.
Durch die Kombination beider Systeme können wir die fehlenden Analyse-Parameter intelligent auf dem Server rekonstruieren, bevor wir die vollständigen, korrekten Daten an Google Analytics weiterleiten.
Die Architektur
Beide Systeme arbeiten nacheinander, um die Analysedaten zu verarbeiten und anzureichern. Der Datenfluss gestaltet sich wie folgt:
-
01
Der initiale Request
Eine Nutzeraktion auf der Website löst ein Standard-GA4-Event aus. Dieses wird an den Server gesendet, der den sGTM-Container hostet. Zu diesem Zeitpunkt fehlen dem Request stabile Nutzer- und Sitzungskennungen.
-
02
Abfangen durch den Custom Client
Im sGTM ist ein speziell entwickelter Client so konfiguriert, dass er alle eingehenden GA4-Anfragen beansprucht. Dieser Client fängt den Request ab und verhindert, dass der Standard-GA4-Client ihn sofort verarbeitet. Seine Aufgabe ist es, den Event-Fluss zu pausieren, um die Datenanreicherung zu ermöglichen.
-
03
Firestore-Datenbankabfrage
Der Custom Client nutzt Signale aus dem Request (wie IP-Adresse und User-Agent), um unsere Firestore-Datenbank abzufragen. Ziel ist es, einen passenden Datensatz zu finden. Jeder Datensatz in Firestore enthält die wesentlichen Sitzungs- und Nutzerinformationen, wie eine computed_client_id, die aktuelle session_id sowie den Zeitstempel des letzten Events (last_event_ts).
Diese Abfrage liefert den gesamten Kontext, der für das Verständnis des Nutzerstatus erforderlich ist. Der sGTM verfügt nun sowohl über die Rohdaten des Browsers als auch über den historischen Kontext aus Firestore.
3. Der Maschinenraum: Wiederaufbau der verlorenen GA4-Parameter
In diesem Kapitel wird die Logik beschrieben, die der Custom Client auf High-Level-Ebene ausführt. Hier wird die cookielose Roh-Anfrage in ein vollständiges Event transformiert.
Erstellung einer stabilen Nutzerkennung
Das wichtigste fehlende Puzzleteil ist die Client ID (cid). Um diese wiederherzustellen, generiert der Custom Client eine computed_client_id. Dies ist ein SHA256-Hash, der durch die Kombination der IP-Adresse, des User-Agents und eines eindeutigen, privaten “Salts” erzeugt wird. So entsteht eine konsistente, pseudonyme ID, die wiederkehrende Nutzer*innen ohne Cookies zuverlässig identifiziert.
Der Firestore-Nutzerdatensatz
Für jede eindeutige computed_client_id wird ein entsprechender Eintrag in unserer Firestore-Datenbank gespeichert. Dieser dient als persistentes Gedächtnis und enthält Felder wie die session_id, den session_number-Zähler sowie die session_sequence (Anzahl der Events innerhalb der aktuellen Sitzung).
Rekonstruktion des Sitzungskontexts
Sobald der User identifiziert ist, prüft der Client den Zeitstempel des letzten Ereignisses in Firestore. Eine neue Session ID (sid) wird generiert, wenn es sich um einen neuen User handelt oder das letzte Ereignis mehr als 30 Minuten zurückliegt. In diesem Fall wird auch der Session Count (sct) erhöht. Die GA4-Events werden durch Manipulation der Event-Daten im Custom Client mit diesen konstruierten Werten angereichert.
Überschreiben des Consents für die vollständige Verarbeitung
Dies ist der finale, entscheidende Schritt. Der ursprüngliche Request vom Browser kam mit dem Status “denied” an. Würden wir die Daten so an GA4 senden, würden sie lediglich als eingeschränkter “cookieloser Ping” behandelt oder je nach Standort des Users gar nicht erst angezeigt.
Um dies zu verhindern, überschreibt der Custom Client den Consent-Status auf dem Server auf “granted”. Dies stellt sicher, dass unsere rekonstruierten Daten tatsächlich genutzt werden und wir ein vollständiges und genaues Bild in GA4 erhalten.
Fazit
Indem wir die Nutzer- und Sitzungsidentifikation mit Hilfe von sGTM und Firestore vom Browser in eine Server-Side-Umgebung verlagern, lassen sich die durch den cookielosen Betrieb entstehenden Datenlücken effektiv schließen. Diese serverseitige Methodik stellt nicht nur die lebenswichtige Channel-Attribution wieder her, sondern bietet auch eine zukunftssichere Blaupause für datenschutzkonforme Analytics in einer Welt nach dem Cookie.
Die Implementierung einer Server-Side-Tracking-Architektur ist ein bedeutender und leistungsstarker Schritt zur Zukunftssicherung deiner Analytics. Wenn du bereit bist, die Datenintegrität in einer cookielosen Welt sicherzustellen, unterstützt dich unser Expert*innen-Team gerne dabei.
