In diesem Artikel beschreibe ich eine Alternative zu der standardmäßigen Sitzungskontrolle von GA4, die für einige Tracking-Setups wie Cross-Domain oder Measurement-Protocol-basierte Ansätze besser funktioniert. Sie basiert auf einer serverseitigen Verarbeitung von Trackingdaten und setzt somit einen eigenen Trackingserver voraus.

Als Sitzung wird im Kontext der Webanalyse in der Regel eine zeitlich zusammenhängende Folge von Interaktionen durch einen Nutzer beschrieben. Auch wenn dieses Modell angesichts parallelisierter und fragmentierter Verhaltungsweisen beim Surfen heute nur noch eingeschränkt anwendbar ist, bleibt es nach wie vor eine beliebte Heuristik, um Erkenntnisse aus der Interaktion mit Web-Inhalten abzuleiten.

Warum die client-seitige Sitzungskontrolle nicht immer funktioniert

Mit GA4, der neuen Version von Google Analytics, wurde eine neue Form der client-seitigen Sitzungsverwaltung eingeführt, die sich grundsätzlich von der ihres Vorgängers Universal Analytics unterscheidet. Universal Analytics kalkulierte die einer Sitzung zugehörigen Events noch im Rahmen seiner datenbankseitigen Nachverarbeitung der Trackingdaten. Es war also relativ einfach möglich, Events über verschiedene Geräte und Browser hinweg zu einer Sitzung zu konsolidieren, sofern sie einem Nutzer zuzuordnen waren.

In seiner neuen Version des beliebten Trackingtools GA4 geht Google einen neuen Weg: Um verschiedene Events miteinander zu verknüpfen wird nun die Session ID benötigt, ein eigener Parameter im Datenschema. Dieser wird standardmäßig von der GA4-Library auf Basis eigener Logiken im jeweiligen Gerät oder Browser generiert. Will man übergreifende Sitzungen zusammenführen, muss entweder dieser Parameter also erst zwischen Client synchronisiert werden oder ein eigenes Sitzungsmodell bei der Auswertung der Daten erstellt werden.

Bei einem Cross-Domain-Setup wird beispielsweise zwar die Nutzeridentität von einer Domain zur nächsten übertragen – die Sitzung wird auf der neuen Domain aber neu gestartet. Dies macht eine zusammenhängende Analyse anschließend schwieriger und bläht die Summer der Sitzungen unnötig auf.

Wie Sitzungen stattdessen serverseitig verwaltet werden können

In einem früheren Artikel habe ich bereits beschrieben, was – am Beispiel des GTMs – die zahlreichen Vorteile eines serverseitigen Trackings sind. Ein großer Pluspunkt ist die Möglichkeit, die Trackingdaten serverseitig um zusätzliche Informationen anzureichern. Es ist darüber hinaus jedoch auch möglich, auf dem Server Daten abzugleichen und bspw. zu bestimmen, ob ein Event noch zu einer Sitzung gehören soll oder nicht.

Daten können serverseitig über verschiedene Events hinaus erhalten bleiben, indem sie im Firestore gespeichert werden. Dieser verursacht für Lese- oder Schreibvorgänge ab 50.000 bzw. 20.000 Zugriffen Kosten, die zwar mit 0,06$ bzw. 0,18$ pro 100.000 Vorgängen überschaubar sind.

Zusätzlich nutzt dieser Ansatz daher die API templateDataStorage, die es ermöglicht, Datensätze im Zwischenspeicher des jeweiligen Templates abzulegen. Da dieser Speicher lokal ist, gibt es keine Garantie, dass er auf der jeweiligen Serverinstanz, die die Anfrage bearbeitet, auch vorhanden ist. Daher wird immer erst geprüft, ob im Firestore bereits eine Sitzung vorhanden ist. Falls die Sitzung bereits im lokalen Speicher existiert, wird zusätzlich geprüft, wie alt diese ist und – falls eine bestimmte Ablauffrist erreicht ist – ebenfalls der Firestore nach neuen Sitzungsdaten abgefragt.

In meinen eigenen Tests konnte ich durch diesen Mechanismus die Anzahl der Lese- oder Schreibvorgänge im Firestore auf eine minimale Summe begrenzen. Das Template kann jedoch auch so konfiguriert werden, dass immer der Firestore genutzt wird.

Das Template für eine einfache Implementierung der serverseitigen Sitzungsverwaltung

Um die Implementierung zu erleichtern, habe ich ein eigenes Variablen-Template erstellt, das die Aufgabe der Sitzungsverwaltung übernimmt. Es steht hier zum Download bereit. Über die Vorlagen-Funktion des serverseitigen Tag Managers kann es in den eigenen Container importiert werden.

Wie auf dem Bild zu sehen, setzt sich das Template aus zwei Einstellungsbereichen zusammen: Dem Zugang zum Firestore und der Definition der Sitzungsmodalitäten.

Eigene Einstellungen für eine serverseitige Sitzungsverwaltung wählen

In den weiteren Einstellungen wird zunächst die Sitzungslänge bestimmt. Standardmäßig sind es 30 Minuten.

Um die Sitzung einem Nutzer zuzuordnen, wir im nächsten Schritt die Inputvariable für Identität des Nutzers festgelegt. Im Normalfall kann dafür die Client ID verwendet werden, die im Event bereits enthalten sein sollte.

Anschließend kann der Output der Variable ausgewählt werden. Es ist möglich, neben der Session ID auch den Session Counter und die Engagement Time serverseitig zu erfassen. Letztere unterscheidet sich von der clientseitigen Engagement Time aber dadurch, dass sie bloß die Differenz zwischen dem Sitzungsbeginn und dem Zeitpunkt des Events erfasst und nicht die aktive Zeit auf der Seite.

Darüber hinaus kann bestimmt werden, in welchem Zeitfenster die Sitzung aktualisiert werden soll. Durch diesen Vorgang wird auch der Firestore aktualisiert, d.h. ein Schreibvorgang ausgeführt. Es empfiehlt sich daher, die mögliche Anzahl der Events hier zu berücksichtigen, um Kosten zu kontrollieren. Falls die Variable für mehrere Parameter genutzt wird, macht es Sinn, den Refresh nur für einen zu aktivieren.

Wenn nicht jedes Event eine Sitzung reaktivieren soll, können in der letzten Einstellung bestimmte Eventnamen einbezogen bzw. davon ausgenommen werden.

Die GA4-Events mit eigenen Sitzungsparameter ausstatten

Im nächsten Schritt können die Parameter nun dem GA4-Event (auf dem Server) hinzugefügt. Für jeden Parameter wird dafür eine Version der Variable mit dem jeweiligen Output-Wert (session_id, session_number oder engagement_time_msec) erstellt.

Im Bereich "Hinzuzufügende/zu bearbeitende Parameter" werden diese Variablen eingefügt:

Mit dieser Änderung werden die Parameter, sofern sie im ursprünglichen Event vorhanden sein sollten, mit den eigenen Werten überschrieben.

Vorteile der serverseitigen Sitzungsverwaltung

Mit diesem Setup wird die Sitzungsverwaltung vom Client auf den Server verlegt. Dieser Ansatz bietet insbesondere für Situationen Vorteile, in denen sich Sitzungen über mehrere Domains oder Geräte verteilen oder wenn das Measurement Protocol verwendet wird und Sitzungen selbst manuell verwaltet werden müssten. In Kombination mit dem serverseitigen Tag Manager kann hier ein großer Teil des Aufwands gespart werden.

Durch die Lösung auf Basis des Firestores wird eine Funktion verwendet, die nativ an den serverseitigen Tag Manager angebunden und einfach zu verwenden ist. Um dennoch nicht unzählige Lese- und Schreibvorgänge auszuführen, werden Sitzungsinformationen im templateDataStorage zwischengespeichert. Dieser greift, wenn eine aktuelle Sitzung als Datensatz im Speicher vorhanden ist. Andernfalls werden die Sitzungsinformationen über den Firestore synchronisiert.

Dank seiner serverseitigen Implementierung werden die Daten hier vollständig cookielos verarbeitet. Damit unterstützt dieser Ansatz auch die Möglichkeit, GA4 ohne diese berüchtigten Speicherbrösel zu nutzen.