Herausforderungen des Trackings ohne Consent

Alle Entwicklungen im Datenschutz seit 2018 haben inzwischen ziemlich klar gemacht, dass dem optimistischen “Opt-Out Ansatz” für die meisten Trackingszenarien die Luft ausgegangen ist. Nervige Cookie-Info-Banner wurden von nervigen Consent Managern abgelöst. Unter der Haube schlummert trotzdem eine dramatische Änderung: bis zur Erteilung der Zustimmung durch den Besucher der Website darf nicht "einfach so getracked” werden. Das gilt jedenfalls für die meisten Tracking Tools wie Google Analytics und andere. Und wenn es nach Meinung von Herstellern alternativer Lösungen doch geht, dann in einem anderen und reduzierten Umfang.

Daher soll sich dieser Beitrag vor allem mit den Voraussetzungen, Einschränkungen und allgemeinen Problemen für ein alternatives Tracking auseinandersetzen; vor allem der Verwaltung von Identität. Er ist der erste Teil einer dreiteiligen Serie über “Ersatztracking” für den Fall, dass keine Zustimmung zum Tracking besteht oder das “Tracking von der Stange” z. B. vom Browser verhindert wird. In den weiteren Teilen geht es um cookieloses Tracking und serverseitiges Tracking. Nicht nur, aber auch mit Google Analytics. Wobei das nicht bedeutet, dass das eine oder andere eine wirklich valide Ersatzmethode bei fehlendem Consent ist. Gegen ITP und ETP hingegen kann man sich damit durchaus rüsten, solange man sich an die Vorgaben des Datenschutzes hält.

Cookie-Consent oder Tracking-Consent?

Die Probleme fangen in Hinblick auf DSGVO und TDDDG schon beim Einholen der Zustimmung an. Viele Consent Management Plattformen ("CMP"), die im Einsatz sind, managen “Tracking Consent”. Sie steuern also i. d. R. das Ausspielen von bestimmten Trackingcodes / Tags. Natürlich sind die Cookies, um die es primär geht, i. d. R. ein Teil der Funktionalität dieser Tags und werden ggf. ohne “Tracking Consent” auch nicht gesetzt, aber es gibt subtile Unterschiede. So ist in vielen Consent Management Systemen vorgesehen, detaillierte Angaben zu Cookies zu machen, die für die Erfüllung der rechtlichen Anforderungen notwendig sind. Aber “Tracking Consent” ist nicht nur “Cookie Consent”!

Ein typisches Cookie Consent Management wie die derzeit beliebten Tools von Borlabs, Cookiebot etc. haben Cookies (zumeist auch hier in Gruppen zusammengefasst) im Fokus und erlauben gezielt die Steuerung der Zustimmung zu deren Nutzung. Natürlich werden auch hier anhand dieser Zustimmung dann die entsprechenden Tags ausgespielt oder nicht, aber es ist dennoch etwas anderes, bestimmten Cookies zuzustimmen oder bestimmte Verfahren zu blockieren. Nicht falsch verstehen: Gemeint sind natürlich auch localStorage und andere Speicherung im Browser, nur klingt "Cookiebot" einfach besser als "LocalStoragebot".

Was tun ohne Consent?

Angesichts des für viele Websites leider real geringen Anteils aktiver Zustimmung zum “normalen” Tracking mit Google Analytics, Google Ads & Co. stellt sich die Frage, was man im Nicht-Consent-Fall tun kann. Gar nichts?

Oder geht es nicht “nur” vielmehr darum, dass man dem blockierten Tracking-Anbieter (also Google in diesem Fall) verweigern will, den Besucher über die dann verwendeten Cookies selbst zu identifizieren und mit dieser Identität - oder meinethalben auch schon allein durch die beim Abruf des Trackingcodes gewonnenen Daten - ein Profil bilden kann, welches dann Zwecken zugeführt wird, die über die reine Vermessung der Website hinaus gehen. “Man” meint hier gar nicht primär den Besucher, sondern auch den Gesetzgeber.

Blickt man über den Google Analytics Tellerrand und diskutiert über “Ersatztracking”, kommen zwei Ansätze immer wieder ins Gespräch: cookieloses Tracking und serverseitiges Tracking. Für beides gibt es Lösungen, die im schlimmsten Fall bis zum “Sammeln platter Hits in einer eigenen Datenbank” oder der reinen Logfileanalyse reduziert werden können.

Ein Ersatz muss aber leider immer irgendwo reduziert sein. Ansätze anderer Anbieter wie Piwik PRO und Matomo (dazu später mehr) zeigen, dass auch ohne Cookies - oder ohne Consent - ein gewisser Trackingumfang machbar ist. Zumindest technisch und unter den aktuellen Bedingungen hinsichtlich Datenschutz & Co. Bevor in den folgenden Teilen gezeigt wird, wie cookielos und / oder serverseitig auch mit Google Analytics gemessen wird, sollten zunächst die Herausforderungen betrachtet werden, die sich bei allen Ersatztrackingszenarien stellen.

Das Hauptproblem: Identität

Reglementierung von Tracking und Cookies und Trackingschutz wie ITP und ETP in Browsern haben einen wesentlichen Punkt gemein: Es geht eigentlich nicht darum, den einzelnen Webmaster vom Tracking auf seiner eigenen Domain abzuhalten, sondern darum, dass am Tracking beteiligte Systeme Profile von Besuchern bilden können, die der domainübergreifenden Datensammlung und Anreicherung - natürlich vor allem für Werbezwecke - dienen.

Dazu liegt es im Bestreben der Betreiber von Trackingdiensten, einen Besucher (oder besser: einen Browser) über eine möglichst lange Zeit wiederzuerkennen. Die dazu dienenden Cookies oder anderer Browserspeicher stehen daher (zurecht) an zentraler Stelle, wenn es um Consent oder Trackingschutz geht. Nicht umsonst sind Werbeindustrie und andere "Betroffene" daher an Ersatzstandards interessiert, die die gebeutelten Cookies ablösen sollen. Auf anderen Plattformen wie Android und iOS stellt sich aus gleichem Grund diese Frage für Apps erst gar nicht, weil dort eine Identifizierung im System "eingebaut" und (zumindest noch) nicht Gegenstand aktueller Reglementierungsbestrebungen ist, allerdings unterliegen auch diese IDs den gleichen Regulierungen und so hat längst auch bei Apps das Thema "Zustimmungsdialoge" eine zentrale Lösung gefunden - in Android und iOS selbst.

Befreit man den Nutzen der Kennzeichnung eines bestimmten Browsers / Geräts von allen Nebenzwecken wie Profilbildung, Cookie Synching und den vielen anderen Dingen, die aus nachvollziehbaren Gründen vielleicht unerwünscht sind, bleiben zwei Mindestanforderungen, die aus Sicht eines “reinen Website Trackings” übrig bleiben: Die Sitzung und der Besucher. Beide Faktoren bedeuten “Identität”.

Hits zu Sitzungen zusammenfassen

Die Kennzeichnung einer Sitzung als kleinere Einheit kann dabei für die Dauer der Sitzung auch den Besucher / Browser identifizierbar machen (aber nicht darüber hinaus). Damit ist eine Sitzung die “kleinstmögliche Klammer” die man um eine Abfolge von Hits wie Seitenaufrufen, Events oder anderen Messpunkten ziehen kann.

Besucher wiedererkennen

Im “schlimmsten” Fall braucht man also eine Sitzungskennung, um daraus etwas für die Webanalyse “direkt Verwertbares” generieren zu können. Der Besucher gilt bei jedem Besuch anhand der verwendeten Sitzungskennung in einem solchen Fall stets als neuer Besucher. Will man auch in einer späteren Sitzung anhand eines Merkmals den Besucher bzw. Browser wiedererkennen, ist also ein Merkmal erforderlich, das über die Sitzung hinaus “lebensfähig” ist. Daher ist eine Browserkennung auch auf einem abstrakten Level sicher “datenschutzrelevanter” als nur eine Sitzungskennung.

Wenn es keine Wiedererkennung gibt

Warum muss man denn einen Besucher überhaupt unbedingt wiedererkennen? Aus Sicht der Webanalyse geht es dabei nicht nur um die Verteilung von wiederkehrenden vs. neuen Besuchern, sondern vor allem um Attribution. Das Zusammenspiel von mehreren Trafficquellen und Kanälen kann nicht betrachtet werden, wenn man den Besucher nicht wiedererkennt. Damit stehen und fallen also viele Analysemöglichkeiten, die vor allem den Besucher und nicht die Sitzung in den Vordergrund stellen.

(Technisch) nutzbare Identitätsquellen

Sowohl ein vollständiges Tracking als auch Ersatztechnologien benötigen auf die eine oder andere Weise also Identität, um über die Sammlung von Hits hinaus funktionieren zu können. Um es (nochmal) klar zu formulieren: Hier geht es nicht um die Einschätzung von Nutzbarkeit aus Sicht des Datenschutzes, sondern um das, was technisch möglich (und - auch heute noch - zum Teil im Einsatz) ist.

Erstaunlicherweise kann dabei niemand wirklich zaubern, sondern muss sich auf eine von zwei Klassen von Optionen zurückziehen:

1. Speichern von Merkmalen im Browser. Das kann in einem Cookie, localStorage, IndexedDB oder sonstwo (ich kenne nun sogar ein Beispiel, das den HTTP Cache nutzt ;)) geschehen - die Unterschiede sind rein technischer Natur.
2. Erkennung anhand von bestehenden Merkmalen. Also Dingen, die technisch notwendig sind oder bereits existieren, ohne explizit vom Trackingdienst gespeichert werden zu müssen. Damit sind Fingerprints, Footprints, Checksummen, Session Hashs oder wie auch immer sie heißen mögen gemeint. Sie können serverseitig oder clientseitig erhoben werden und mal mehr und mal weniger “eindeutig” sein.

Einen dritten Weg, der aus der Weitergabe einer (serverseitig verwalteten) Id als Parameter an allen URLs einer Sitzung besteht, ordnen wir der Einfachheit halber dem ersten Fall zu, denn es ist streng genommen nur eine Spielart eines Session-Cookies.

Speichern von Merkmalen

Schmeißen wir Cookies und alles andere einfach in einen Topf - die Gesetzgebung macht es auch so, also ist ein “Rückzug” auf localStorage keine Lösung (auch schon rein technisch nicht, wenn es z. B. um ITP und localStorage geht). Im einfachsten Fall nehmen wir also dem Trackingdienst per Consent Manager das Recht, Cookies zu setzen und schon existieren keine Cookies mehr, die den User identifizierbar machen.

Stimmt das denn wirklich? Wenn wir für ein Ersatztracking Identität brauchen und z. B. nur Tracking-Cookies von Google Analytics und seine Freunde verzichten müssen, weil Consent fehlt; finden wir dann wirklich nirgends eine Alternative? Vermutlich (natürlich!) doch.

Denn auf vielen Systemen werden z. B. bestimmte Cookies erforderlich sein, um die Funktion der Website zu gewährleisten oder um z. B. die Wahl von Besuchern im Zustimmungsdialog zu speichern. Im einfachsten Fall gibt es zudem eine Session ID der einen oder anderen Art, die (hoffentlich nicht in den URLs, sondern) in einem Cookie zu finden ist. Auch ohne Tracking finden sich z. B. auf vielen Websites Cookies mit wohlklingenden Namen wie CAKEPHP, PHPSESSID und ähnliche. Die darin verwaltete Session kann technisch gesehen auch bei einem Ersatztracking genutzt werden; entweder direkt im Browser durch Auslesen des Cookiewertes oder serverseitiges Auslesen und ggf. Weitergabe an den Client per dataLayer, globaler Variable o. Ä. Der nächste Beitrag wird hierzu ein paar konkrete Beispiele zeigen, aber allen Lösungen ist eines gemein: Verwendung eines Cookies jenseits seines Zwecks (zu dem ggf. zugestimmt wurde) zu Trackingzwecken ist kein Ausweg aus datenschutzrechtlichen Anforderungen!

Selbst (und exklusiv) verwaltete Identität

Vergessen wir für einen Moment das Thema Cookie-Consent und konzentrieren uns auf die Probleme, die durch Trackingschutz im Browser entstehen. Maßnahmen wie ITP und ETP machen den per Javascript generierten und von jedem im passenden Kontext ausgeführten Script lesbaren Cookies das Leben schwer. Und Kurz. Selbst localStorage ist keine Ausnahme mehr. Als Lösung dieses Problems ist auch eine vom eigenen Server verwaltete ID denkbar. Diese ist auch dann noch nutzbar, wenn es sich um ein servergeneriertes und auch nur serverseitig lesbares sicheres Cookie handelt. Solche ID-Cookies erhalten im Gegensatz zu einer Session ID eigentlich alle Stärken der Webanalyse, ohne dabei auf die Angreifbarkeit des Analytics-eigenen Cookies setzen zu müssen. Aus ITP Sicht ist man damit also aus dem Schneider und auch Cookie-Synching und andere Kritikpunkte prallen an dieser für den Browser und andere Scripts nicht lesbaren Id ab. Löst man dann individuell und nur für die eigene Webanalyse den Zugriff auf diese Id, kann man diese ohne Sorge um vom Browser gelöschte oder blockierte Cookies weiter betreiben. Genau das macht die "Server-Managed" ID im GA4 Client beim serverseitigen Google Tag Manager. Zusammen mit einem technisch sauberen "Same Origin" Setup lässt sich etwas gegen Trackingschutz ausrichten. Das ist sinnvoll, solange man sich an Zustimmung hält und so nur den Browser dann aushebelt, wenn dem Tracking zugestimmt wurde. "Gegen" Datenschutzanforderungen kann und sollte ein solches Setup aber nicht gewählt werden, denn es ergibt keinen Unterschied (zumindest ohne weitere Maßnahmen, dazu mehr im zweiten Teil).

Wenigstens die Sitzung?

Kann aber ggf. zumindest ein Session-Cookie selbst erzeugt und als Identitätsmerkmal (für die Dauer der Sitzung) genutzt werden? Das kann direkt per Javascript im Browser geschehen. Oder auch serverseitig; z. B. durch Erzwingen einer PHP-Session, die dann ein PHPSESSID Cookie erzeugt. Das oben schon angeführte Argument der Zweckentfremdung beantwortet diese Frage bereits. Auch Lösungen, die vor ein paar Jahren noch in Piwik PRO betrieben wurden und mit kurzlebigen Cookies arbeiteten, sind inzwischen als nicht mehr haltbar dort verschwunden.

Fingerprinting zur Identifizierung

Die zweite der beiden Möglichkeiten zur “Generierung” einer Identität basiert auf Merkmalen, die es schon gibt. Fingerprinting bedient sich daher oft solcher Dinge wie dem User Agent, den jeder Browser zur Identifizierung von System, Version etc. bei Anfragen an den Server übermittelt und der auch clientseitig ausgelesen werden kann.

Andere Merkmale können installierte Plugins oder Eigenschaften des Browsers sein… oder bei serverseitiger Generierung auch die IP Adresse, die ebenso zwingender Bestandteil jeder Anfrage an den Server ist. Diese kann - idealerweise anonymisiert - und kombiniert mit den anderen o. a. Merkmalen dazu verwendet werden, um eine “ausreichend eindeutige” Kennung zu erzeugen. Macht man es dabei “richtig”, sind weder die IP Adresse noch andere Merkmale aus dieser Kennung zurückgewinnbar.

So “richtig eindeutig” muss eine solche Kennung allerdings nicht sein, denn mehrere Clients können z. B. den gleichen Browser, Plugins, System und IP Adresse haben. Gerade in größeren Unternehmen ist das nicht unwahrscheinlich. Und auch eine IP ist nicht in Stein gemeißelt und ändert sich bei vielen Webnutzern mindestens einmal täglich. In Sinne einer möglichst guten Erkennung und Zusammenfassung von Hits ist ein solches Merkmal aber oft besser als nichts.

Nach diesem Ansatz arbeitet z. B. das vielgelobte cookielose Tracking von Matomo (siehe Matomo FAQ). Hier wird aus den o. a. Merkmalen ein Fingerabdruck erzeugt, der dann bei der Zusammenstellung der Hits zu Sessions (und auch sitzungsübergreifend auf einen Nutzer bezogen) verwendet werden. Ist das erlaubt? Heute offenbar schon, morgen ggf. nicht mehr (ohne Consent). Wer auf diese Lösung setzt, sollte aber auf jeden Fall darauf achten, dass Matomo Konfigurationsoptionen hat, die das Verwenden von Plugins im Browser, das Auslesen der Sprache und andere Dinge unterbindet, denn neben den Anforderungen der DSGVO gilt auch das, was die ePrivacy von uns verlangt und das untersagt (in Form des TDDDG) klar den Zugriff auf solche Geräteinformationen ohne Zustimmung.

Dass ggf. auch im Browser - dann ohne IP - eine ID als “Abdruck” des Systems berechnet und verwendet werden darf, wenn keine Zustimmung besteht, macht die Lage nicht einfacher. Für Tracking gibt es solche Ausnahmen allerdings nicht. Typischerweise finden solche Maßnahmen unter der Rechtfertigung der Notwendigkeit nur dann statt, wenn das Tool nicht dem Tracking, sondern z. B. der Erkennung von technischen Attacken oder Klickbetrug dient.

Nutzung und Nutzen von alternativen Trackinglösungen

Können wir in Zukunft also ggf. bei Fehlen von Consent für bestimmte Cookies oder das Laden einzelner Tags dennoch “irgendwas” tracken; zumindest aus technischer Sicht? Eine rechtliche Einschätzung oder gar Verbindliches kann ich selbstredend nicht liefern. Aber zum Trost: Auch Anwälte und Datenschützer haben oft sehr unterschiedliche Meinungen, was noch okay ist und was nicht. Man darf davon ausgehen, dass Tools wie Piwik PRO, Matomo, Plausible und andere deutlich einfacher ohne Zustimmung zu betreiben sind als Google Analytics. Das liegt nicht nur daran, dass dort nicht nur eine ID aus einem Cookie einen Ersatz benötigt, sondern vor allem an der Tatsache, dass es ein Tool ist, dessen vermutlicher Hauptzweck aus Sicht des Anbieters im Marketing liegt.

Wer also eine technisch umsetzbare und rechtlich belastbare Lösung gefunden hat, um Daten auch ohne Zustimmung zu sammeln, der wird eine Einschränkung nicht umgehen können: Alle Daten, die auf diese Weise gesammelt werden, können nicht aktiv in Marketingsysteme zurückgespielt werden! Conversions in Google Ads auf Basis von "unconsented data" einzuspielen, erfordert das Überspringen einer Hürde, die allein ethisch unübersehbar ist: Man müsste lügen! Die erforderlichen Consent Mode Signale für eine Verarbeitung von Conversions oder Bildung von Zielgruppen sind nur durch Lügen in die Daten zu bekommen, wenn diese ohne Zustimmung erhoben wurden. Bei allem Bewegungsspielraum, den man also zum Einsatz alternativer Webanalyse und Reichweitenmessung haben mag: Aktivierung für Marketing ohne Zustimmung ist nicht möglich. Und auch nicht sinnvoll. Wer will schon dabei erwischt werden, die Besuchenden seiner Website in Remarketinglisten gesteckt zu haben, ohne dass dazu eine Zustimmung bestand?

Unter diesen Bedingungen und mit dieser großen Einschränkung ist ein alternatives Tracking ohne Consent immer noch möglich. Bleiben wir also bei der Machbarkeit und konkreten Umsetzung. Genau das ist das Thema der nächsten beiden Teile. Diese zeigen vor allem das Prinzip des cookielosen Trackings bzw. einer serverseitigen Nutzung des Trackings - mit und ohne Google Analytics.

Im Vordergrund steht auch dabei die technische Umsetzung - die Problematik und Lösungsoptionen für die Identitätsfrage sind hiermit erst einmal abgeschlossen. Alle alternativen Trackingoptionen drehen sich aber im Kern um genau dieses Problem der "Identität" oder zumindestens der "Session" als Klammer um ansonsten unzusammenhängende Signale, die aus Seitenaufrufen und Ereignissen bestehen.