Google Analytics: Auswirkungen von Tracking Prevention Mechanismen auf die Nutzererkennung
Management Summary
In den herkömmlichen Implementierungen von Google Analytics über einen clientseitigen Google Tag Manager wird das _ga Cookie verwendet, um eine ClientId zu speichern und für zukünftige Besuche des Nutzers vorzuhalten. Dieses First-Party Cookie kommt mit einer Speicherzeit von 2 Jahren und ermöglicht somit eine Wiedererkennung des Nutzers über einen langen Zeitraum. Das Ablaufdatum des Cookies wird beim erneuten Besuch des Nutzers automatisch verlängert.
Einschränkungen bei der Nutzererkennung
Doch was passiert, wenn der _ga Cookie bei einem erneuten Besuch der Website nicht mehr vorhanden ist? In diesem Fall wird ein neuer _ga Cookie mit einer neuen ClientId generiert, wodurch in Google Analytics ein neuer Nutzer verzeichnet wird. Neben den bereits bekannten Einflüssen, wie Cross Device Nutzern, oder der Verwendung unterschiedlicher Browser auf einem Endgerät gibt es mittlerweile auch innerhalb verschiedener Browser Schutzmechanismen, welche die Nutzererkennung deutlich schwieriger machen. Das prominenteste Beispiel hierfür ist die Intelligent Tracking Prevention (ITP) von Safari, welche die Lebensdauer von Firstparty Cookies, die über JavaScript geschrieben werden, auf 7 Tage limitiert.
Aber auch weitere Browser wie Firefox nutzen Mechanismen wie die Enhanced Tracking Prevention (ETP), die die Cookie Lebensdauer bei Firefox auf 1 Tag reduziert.
Auswirkungen in der Praxis
Doch was bedeutet das in der Praxis? Wie stark verzerren diese Schutzmechanismen bereits jetzt die Nutzerzahlen in einem Google Analytics Setup? Um zumindest ein repräsentatives Beispiel zu betrachten, darf ich Ihnen heute echte Daten aus der Praxis vorstellen.
Bevor wir uns die Ergebnisse anschauen, hier noch ein Überblick über die Testweise, bzw. unser Testsetup.
Testsetup
Bei einer großen E-Commerce-Website nutzen wir einen serverseitigen Google Tag Manager, welcher eine gehashte Version der ClientId aus dem _ga Cookie erstellt und diese in einem HTTP Only Cookie FPID speichert. Das HTTP Only Flag sorgt dafür, dass browserseitiges JavaScript keinen Zugriff auf die so markierten Cookies hat. Dadurch sind diese Cookies nicht von Maßnahmen wie ITP und ETP betroffen.Beispiel ClientId _ga: GA1.2.1476844631.1648732442
Beispiel gehaschte ClientId FPID: FPID2.2.RQb894iKE7ebjaQVIYEpZSQhd1L+hvCUrhTmtUC4eno=.1649247034
Zusätzlich wurde im Google Analytics Client auf dem serverseitigen Google Tag Manager die Option “Migrate vom JavaScript” aktiviert, was dazu führt, dass die ClientId aus dem _ga Cookie so lange verwendet wird, bis die gehaschte Version der ClientId nicht mehr mit der ursprünglichen ClientId übereinstimmt.
Das heißt, wenn bei wiederkehrenden Nutzern ein _ga Cookie verloren geht, wird ab diesem Zeitpunkt die gehaschte ClientId genutzt. Solange der _ga aber existiert wird die ClientId aus dieser Quelle vorgezogen.
Diese gehaschten ClientIds sind leicht von den ursprünglichen ClientIds zu unterscheiden, denn sie bestehen nicht nur aus einer Zahlenfolge, die durch einen Punkt getrennt wird, sondern enthalten zusätzlich am Anfang eine Buchstabenfolge, welche mit =. Von der darauffolgenden Zahlenfolge abgetrennt werden.
Durch diese Charakteristik lässt sich der Anteil dieser ClientIds, welche bei Verlust des _ga Cookies genutzt werden, einfach ermitteln.
Im Folgenden sehen Sie unsere Ergebnisse dieser Auswertung:
Auswertung
In dieser Grafik sehen Sie die gesamten Anteile der _ga ClientIds (client) und FPID ClientIds (server). Wie schnell zu erkennen ist, bewegt sich der Anteil (±6%) der serverseitigen ClientIds in sehr niedrigem Bereich, wenn wir die gesamte Datenbasis betrachten. Zusätzlich ist ein Anstieg der serverseitigen ClientIds über unseren Betrachtungszeitraum erkennbar.
Für eine Einordnung dieser Zahlen müssen wir berücksichtigen, dass es einen nicht zu vernachlässigenden Anteil von Nutzern gibt, welche in unserem Betrachtungszeitraum nur einen Besuch auf der Website durchführen. Weiterhin ist wichtig zu wissen, dass Browser wie Chrome noch keine Mechanismen wie ITP oder ETP nutzen.
Deshalb ist für ein genaueres Bild die Segmentierung der Daten nach Browser unabdingbar. In folgender Grafik sehen Sie die Daten nach Browser, sortiert absteigend nach Anteil des Browsers von der Gesamtanzahl ClientIds.
Wie erwartet verzeichnet der Chrome, der Browser mit dem größten Anteil, einen sehr geringen Anteil von nur 1,45 % an serverseitigen ClientIds.
Auffällig in dieser Betrachtung sind sofort Safari, Safari (in-app) und Mozilla Compatible Agent. Diese verzeichnen deutlich höhere Anteile von serverseitigen ClientIds, als andere Browsern unter den Top Ten. Somit ist deutlich erkennbar, dass ITP und ETP bereits erhebliche Einflüsse auf die Datenqualität haben können.
Wie groß dieser Anteil ist, hängt hauptsächlich von zwei Faktoren ab:
- Anteil von Browsern wie Safari und Firefox, welche bereits Maßnahmen wie ITP und ETP einsetzen
- Anteil der wiederkehrenden Nutzer auf Ihrer Website.
Fazit
Obwohl der gesamte Anteil der serverseitigen ClientIds “nur” ca. 6% ausmacht, wird bei einer detaillierten Betrachtung klar, dass bereits jetzt erhebliche Einflüsse bei gewissen Browserversionen wie Safari (18 %) vorliegen. Besonders bei Webseiten mit höherem Safari Anteil dürfte dieser Einfluss noch deutlich höher ausfallen.
Da eine Umstellung auf serverseitige ClientIds bei der Verwendung vom serverseitigem Google Tag Manager ein einfacher Schritt ist, empfiehlt sich aus hier Businesssicht klar ein Wechsel, wenn die Möglichkeit besteht. Denn häufig dienen Websysteme wie Google Analytics als Herzstück für Aussteuerung und Auswertung von verschiedenen Marketingkanälen.
Zusätzlich ist anzunehmen, dass in Zukunft weitere Maßnahmen zum Schutz der Privatsphäre etabliert werden.
Mit einer serverseitigen Lösung, wie dem serverseitigen Google Tag Manager, haben Sie mehr Kontrolle über die Weitergabe von Daten an andere Plattformen wie Facebook, oder auch Google.
