Cookieloses Tracking mit Google Analytics

Nachdem der Sinn und Unsinn sowie die Herausforderungen von cookielosem Tracking im ersten Teil der Serie behandelt wurden, wird es Zeit für einen Praxisfall anhand von Google Analytics. Wie auch andere Webanalysesysteme kann nämlich auch Google Analytics auf die Verwendung von Cookies verzichten. Und wie alle anderen ist dann das heikle Thema der Identität nicht mehr in der Hand von Cookies, sondern muss an anderer Stelle verwaltet werden. Während das eine oder andere System dann von selbst oder per Option steuerbar auf andere Wege wie localStorage oder Fingerprinting ausweicht (oder Cookies damit gegen Trackingschutz und Cookielöschung ergänzt), liegt im Fall von Google Analytics die Verantwortung zu 100% beim Websitebetreiber. Aber fangen wir ganz vorn an...

TL;DR

Man konnte Universal Analytics ohne (analytics-eigene) Cookies betreiben. Das ist aber spätestens mit Google Analytics nicht mehr so einfach geworden, weil hier der Browser auch Kontrolle über die Session und den "Status" eines Besuchers hat. Ist schon eine Session aktiv? Die wievielte dieses Browsers ist es? All das beantwortet GA4 im Browser selbst - im Gegensatz zum Vorgänger oder wie es bei vielen anderen Tools noch üblich ist: Dort hat der Empfänger  diese Kontrolle, nicht der Sender. Spätestens wenn das Thema Datenschutz dazu kommt, ist ein Einsatz von Google Analytics "ohne Cookies" durch den "erweiterten Zustimmungsmodus" zwar technisch möglich, aber es ist aus Sicht des Datenschutzes hochgradig fraglich, ob das wirklich eine Lösung ist. Google Analytics wird allein wegen des Google im Namen stets eine Sonderstellung haben und ein Einsatz ohne Zustimmung (nicht ohne Cookies) ist entweder ein Risiko oder muss durch so viele Maßnahmen laufen, dass der Betrieb keinen Wert mehr für Marketing oder Attribution hat. Damit wird das ganze nicht zum technischen, sondern regulatorischen Problem.

Hier wird dennoch beschrieben, wie das technisch geht - um die Einschränkungen zu demonstrieren. Es ist allerdings nicht zu erwarten, dass mit dem Verzicht auf Cookies Consent-Problemen aus dem Weg gegangen werden kann. Gleiches gilt übrigens für den o. a. Consent Mode, der in GA4 oder auch von Google Ads Tags genutzt werden kann. Nur das Weglassen von Cookies unter ansonsten vollständigem Erhalt des Trackings ist keine Option, die hinsichtlich Datenschutz große Unterschiede ergibt. Bestenfalls aus dem ePrivacy-/TDDDG Dilemma mag es ein Ausweg sein.

Das wollte es gleich am Anfang loswerden. Gegen ITP hilft es aber je nach Gestaltung des eigenen Weges zur Verwaltung einer Client ID in einem Cookie oder anderswo durchaus. Zu 100%. Wer jetzt immer noch wissen will, wie es geht (und welchen Unterschied es ausmacht), darf gern weiterlesen 😉

Google Analytics ohne Cookies

Seit ITP angefangen hat, auch First-Party-Cookies zu attackieren, erfreuen sich alternative Wege zur Verwaltung und Übergabe einer clientId an den Google Analytics Trackingcode steigender Beliebtheit. Für Google Analytics ist aber seit GA4 kein solcher Weg mehr "einfach" zu begehen. Die damals noch existierenden Optionen zur Übergabe der clientId oder um Cookie Updates zu unterbinden, sind nicht mehr da. Allen noch verbeibenden Lösungen gemeinsam ist daher, dass Client ID und Session ID, Session Nummer und andere Dinge "irgendwo anders" herkommen müssen. Während man sich vorher alternative Identifier aus dem dataLayer oder direkt am Server "halten" konnte, muss ein Ersatz nun auf anderem Weg hergestellt werden.

Problemfeld Client ID und Session Info

Das ist genau die Kernfrage, der wir uns im ersten Teil gewidmet haben. Gehen wir also die dort genannten Optionen durch. Offensichtliche Alternativen wie localStorage oder andere Browserspeicher sind dabei zwar einsetzbar, aber kein wirklicher Ausweg aus der "Cookie-Falle". Weil sie weder das Consent- noch das Trackingschutzproblem lösen. Den Anfang machen die ggf. bestehenden oder selbstverwalteten Cookies.

Bestehende oder eigene (Session-) Cookies

Der zweifelsfrei üblichste Weg zur Speicherung von Informationen zwischen zwei oder mehr Seitenaufrufen ist und bleibt ein Cookie. Wie jetzt? cookieloses Tracking und dann doch ein Cookie? Ja, vielleicht. Denn wie schon im ersten Beitrag beschrieben mag es Umstände geben, unter denen ein Cookie trotz fehlendem Consent nutzbar und / oder systembedingt unvermeidbar ist. Daher setzen einige Lösungen auf genau diesen Ansatz. Eine ID aus einem Session Cookie, dem Consent Cookie oder anderen haben aber ein großes Problem, wenn sie jenseits des eigentlichen (und ggf. tatsächlich notwendigen und damit existenzbegründenden) Zwecks für Tracking missbraucht werden. Regulierung ist hier ganz eindeutig und es gibt keinen Spielraum zur Diskussion oder Grauzonen, die Bewegung darin zulassen würden.

Zudem bleibt die Bildung von Session Informationen, die Google Analytics ebenfalls "von außen" bekommen muss, weiterhin offen. Eine ID mag technisch (nicht rechtlich) nutzbar sein, aber für einen Zeitstempel für den Start einer Session (und ja, es muss ein Zeitstempel sein und nichts anderes, wenn GA4 wirklich mit den Daten funktionieren soll - ich habe es erprobt!) und deren Zählung braucht es nun mal nicht irgendwelche Daten, sondern den genannten Zeitstempel und einen fortlaufenden Counter.

Wer hingegen hauptsächlich ITP aus dem Weg gehen will, setzt ein Cookie lieber serverseitig statt per JavaScript im Browser und muss zudem ein Setup haben, das für Apple "Same Origin" genug ist. Die dortige Definition ist derzeit sehr willkürlich und verlangt, dass der das Cookie erzeugende Server (wie ein serverside Google Tag Manager) und der Server der Website in der ersten Hälfte der IP nicht abweichen darf. Anderenfalls werden auch serverseitig erzeugte Cookies wie "gewöhnliche" JavaScript Cookies behandelt und unterliegen einer stark begrenzten Lebensdauer.

Warum nicht Google Consent Mode?

Analytics ohne Cookies kann nicht abgeschlossen werden, ohne vorher über den Google Consent Mode zu sprechen. Während der Einsatz der "Basic" Variante (also das Kommunizieren der Zustimmungslage mit jedem Request an GA4 oder Google Ads) für Werbetreibende schon lange zur Pflicht gehört, damit das Ads Konto nicht einschläft, ist der Einsatz der "Advanced" Variante nach wie vor kritisch zu betrachten. Denn es passieren all die Dinge, über die bisher nur theoretisch gesprochen wurde: Bei Ablehnung (und auch schon vor der Entscheidung in vielen Setups) werden vollwertige Requests an Google gesendet. Die einzige Einschränkung ist, dass es keine Cookies gibt, in der Client ID oder Session Daten gespeichert wären und so jeder Request nach dem Laden einer Seite technisch so aussieht, als sei es "der erste". Das ändert aber nichts daran, dass dennoch alle Daten an Google gesendet werden. Ob dahinter nun wirklich "nur" Modellierung stattfindet oder nicht, ist weder kontrollierbar, noch relevant aus Datenschutzperspektive. Solche Requests ohne Zustimmung und sogar trotz Ablehnung zu versenden, hat ungeachtet des freundlichen Namens und der verharmlosend "Pings" genannten Requests nichts an Brisanz verloren, nur weil keine Cookies im Spiel sind. Wer sich den sehr geringen Unterschied zwischen Zustimmung und Ablehnung im erweiterten Zustimmungsmodus ansehen will, findet dazu ein Video von mir auf Youtube.  Dass ich als Marketer kein Fan bin, sollte etwas aussagen. Was nicht bedeutet, dass ich den Einsatz nicht nachvollziehen kann, wenn das Volumen des eigenen Ads Kontos tatsächlich genug Daten generiert, dass ein erkennbarer Nutzen besteht.

Serverseitiger Ausweg?

Wo immer ein Cookie "ersatzlos" im Browser gestrichen ist, aber dennoch ein vollwertiges Tracking für Google Analytics stattfinden soll - unterstellen wir hier zunächst, dass dies nur bei Zustimmung geschieht -, müssen die o. a. Infos zu Session und Client auch serverseitig gespeichert werden. Existierende Lösungen orientieren sich dabei an dem Grundsatz, dass IP Adresse und User Agent keine Informationen sind, die aktiv aus dem Gerät ausgelesen werden, sondern als Teil der Kommunikation mit dem Server ohnehin anfallen. Mit der Einschränkung, dass diese Daten also "okay" sind, kann ein Server damit eine Tabelle verwalten, in der die Kombination aus UA und IP als Schlüssel verwendet wird, um dazu gespeicherte Informationen zur aktiven Session, den vorherigen Sessions und eine Client ID abzurufen. Bei der Client ID kann man sogar auf das Speichern verzichten und diese aus IP und UA bilden. Dazu weiter unten mehr. Ob man dies aber nun einen Session Hash oder einen Fingerprint nennt: Die meisten Methoden leben mit einer gewissen Unschärfe, denn weder IP-Adresse noch User Agent sind eindeutig genug, um einzelne Browser zu identifizieren - dazu gleich mehr.

Dazu kommt, dass bei dieser rein serverseitigen Speicherung dann auch eine serverseitige Versorgung von Google Analytics mit Daten erforderlich ist. Diese Informationen wieder in den Client zu tragen, würde nicht helfen, denn dort existiert ja keine Möglichkeit, die entsprechenden Daten (wie früher bei Universal Analytics) in die Konfiguration zu bekommen. Will man dabei weder das (im Alleinbetrieb sehr verlustreiche) Measurement Protocol einsetzen, noch selbst die ausgehenden Requests zusammenbauen, ist ein server-side Google Tag Manager mit den dortigen Optionen zur Transformation von Ereignisdaten die meistgewählte Option. Kommt man damit aber aus der Datenschutzfalle? Ohne starke Reduktion der an GA fließenden Daten ist das eher unwahrscheinlich. Wie schwierig es sein kann, den Standardbetrieb von Google Analytics ohne den Einsatz von gtag.js als Trackingscript im Browser selbst bei Verwendung eines serverside Google Tag Managers sein kann, zeigt mein Experiment mit walker.js.

100% cookieloser "Session Hash" (AKA Fingerprinting)

Bevor wir über Ethik und Grenzen von Fingerprinting, Datenschutz oder andere Aspekte diskutieren: Wir folgen in diesem Gedankenexperiment exemplarisch dem Beispiel von Matomo und nutzen anonymisierte IP, den User Agent. Die Sprache des Browsers können wir nicht verwenden, weil dies wiederum nicht zu unserem Server gelangt, sondern aktiv im Browser ausgelesen werden müsste. Auf Plugins verzichten wir aus gleichem Grund. Es geht zudem um das Prinzip und mehr Signale senken nur die Wahrscheinlichkeit von Gleichheit bei mehreren Clients, aber eliminiert sie nicht. Das ist allein deshalb unvermeidlich, weil mehrere Besucher mit der gleichen anonymisierten IP in der Realität vorkommen können. Nutzen diese auch noch (weil z. B. im selben Unternehmen) Systeme und Browser, die zu übereinstimmenden User Agents führen, wird der gleiche Abdruck entstehen. Um eine Wiedererkennung absichtlich zu vermeiden und damit Datenschutzanforderungen zu genügen, fügen viele Lösungen zudem vor der Bildung des Hash einen "Salt" hinzu, der aus einer zufälligen Kombination von Zeichen besteht, die eine begrenzte Lebensdauer hat. Wird dieser Zusatz z. B. stets um Mitternacht gewechselt, kann man auch bei konstanter IP und UA Kombination in den Daten nicht länger als einen Tag wiedererkannt werden. Das reicht für Sessions, nicht für Langzeitbetrachtung.

Generell kann man mit der gewählten Methode und den genutzten Merkmalen vielleicht die Nutzbarkeit hinsichtlich Datenschutz beeinflussen... oder auch nicht. Wir werden es sehen. Eine beispielhafte Umsetzung findet sich als Funktion get_fingerprint im Logger-Script zum folgenden Beitrag der Serie. Darin stecken auch ein paar Hinweise zum Verfahren der Generierung eines Schlüssels (in diesem Fall ein Hash) und dem daraus resultierenden Schutz der zur dessen Bildung verwendeten Informationen. Ganz ehrlich: ob ein Hash nun die dadurch repräsentierten Daten ausreichend schützt oder ob es reicht, "nur" die anonymisierte IP zu verwenden, ist bestimmt strittig. Vor allem, wenn man es mit den "billigen" Mitteln des Beispielcodes versucht. Matomo macht es zum Glück etwas anders und sicherer. Mir ging es primär darum, das Prinzip zu verdeutlichen. Ob das so aber im Licht einer angepassten Rechtslage Bestand haben wird, werden wir am Beispiel von Matomo viel besser beobachten können.

Nutzbarkeit und Nutzen

Cookieloser Betrieb von Google Analytics ist also streng genommen technisch machbar. Die Komplexität kommt mit der Anforderung, neben einer Client ID für GA4 nun auch Sessions, deren Dauer und Anzahl zu verwalten und zu nutzen. Es ist aber strittig bzw. fraglich, ob man auf diese Weise auch nach wie vor einfach alle Daten wie Referrer, URLs mit allen Klick-Identifiern, vollständige Pfade zum tatsächlichen Zeitpunkt des Aufrufs, angereicherte Dimensionen, Transaktions IDs und alles andere  unverändert versenden darf, nur weil man im Browser auf Cookies verzichtet. Wenn die Französische Datenschutzaufsichtsbehörde CNIL - und nach ihr auch andere europäische Pendants - ganz klare Regelwerke zum Betrieb von Google Analytics über einen "Proxy" mit extremer Reduktion der Daten als einzigen Ausweg beschreiben, begibt man sich bei Beschreiten eines anderen Pfades mit mehr Daten für GA auf jeden Fall in den Bereich des Risikomanagements.

Schlussendlich sind neben dem Verzicht auf Cookies also weitere Anpassungen erforderlich, ohne die "cookielose" Verfahren ohne Consent nicht mehr betrieben werden können. Dennoch: Trotz aller regulatorischen Vorgaben und klaren Aussagen von Datenschützern ist das Thema nicht trennscharf und muss im Einzelfall entschieden werden, wenn es die Abhängigkeit von Daten gebietet. Trotzdem kann man über die "Cookiefrage" hinaus ein paar Stärken und Schwächen dieser Lösung ausmachen - unabhängig davon, dass sie ohne weitere Anpassungen als "Ersatztracking" ohne Consent eher nicht geeignet ist.

Vorteile

• Eigene Verwaltung des Clients schützt z. B. je nach Gestaltung wirksam vor Safaris Trackingschutz ITP
• Selbst mit einem eigenen Cookie ist der ominöse Nutzen für Google zu Werbezwecken etc. deutlich minimiert, weil die Identität für (andere) Scripts im Browser nicht greifbar ist.
• Rein technisch das Tracking und die Sammlung von Informationen / Dimensionen nicht eingeschränkt
• Damit einher geht die "volle Kompatibilität" zu anderen Systemen, die angebunden werden können und die Daten nutzen

Nachteile

• Bei serverseitig verwalteten und nicht in einem Cookie direkt im Browser verfügbaren IDs und Sessions muss auf den Server gesetzt werden - technischer Aufwand steigt enorm.
• Es ist unwahrscheinlich, dass das Eliminieren der Google Cookies wirklich etwas daran ändert, ob und wie ohne Consent noch ein Einsatz möglich ist
• ETP in Firefox oder der Trackingschutz in Edge sowie andere Blocker-Mechanismen können daher immer noch verhindern, dass Cookies so lange leben, wie man es geplant hat
• Wie alle Lösungen mit eigener Identität sinkt der Nutzen, wenn deren Lebensdauer - z. B. durch fehlende Berechtigungen - auf einen kleinen Zeitraum oder nur eine Sitzung eingeschränkt wird.

In Summe ist diese Option des Trackings mit Google Analytics aus rechtlicher Sicht vermutlich nicht oder nur geringfügig besser als bei normaler Installation. Aber es sollte zumindest klar sein, dass der Verzicht auf Cookies eigentlich kein Merkmal ist, das eine Lösung automatisch "datensicherer" macht. Es bleibt zu hoffen, dass der Unterschied zwischen Consent und kein Consent im Tracking am Ende darauf hinausläuft, wie und für wie lange dabei die gleiche "Identität" genutzt wird und wie sie ermittelt werden darf. Und natürlich mit welchen Mitteln, denn da hat Google Analytics sicherlich - und sei es auch nur in der Wahrnehmung im Umfeld des Datenschutzes - eine gewisse Sonderstellung.

Einen Schritt weiter geht dementsprechend der Rückzug des Trackings aus dem Browser; also serverseitigem Tracking. Das kann - in der einen oder anderen Weise - auch mit Google Analytics umgesetzt werden. Genau das ist Gegenstand des dritten Teils dieser Serie.