Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » Analytics / Datenschutz / Trackingschutz

12.10.2019

Spätestens seit dem jüngsten EuGH Urteil ist klar, dass auch in Deutschland dem optimistischen “Opt-Out Ansatz” für die meisten Trackingszenarien irgendwann die Luft ausgehen wird. Unter welchen genauen Bedingungen und Auflagen ist noch unklar, aber auch ohne unmittelbaren Handlungsbedarf vor einer Umsetzung des Urteils in deutsches Recht sind einige Folgen absehbar.

Nervige Cookie-Info-Banner werden dann z. B. vermutlich von nervigen Consent Managern abgelöst. Unter der Haube schlummert trotzdem eine dramatische Änderung: bis zur Erteilung der Zustimmung durch den Besucher der Website wird nicht mehr "einfach so getracked” werden dürfen. Vermutlich jedenfalls. Und wenn doch, 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 sein kann / wird. Gegen ITP und ETP hingegen kann man sich damit durchaus rüsten.

Cookie-Consent oder Tracking-Consent?

Die Probleme fangen in Hinblick auf das o. g. Urteil und auch die ausstehende ePrivacy-Verordnung schon beim Einholen der Zustimmung an. Viele Tools, die bereits im Einsatz sind (weil sie z. B. mit der DSGVO Umsetzung 2018 eingeführt wurden) managen “Tracking Consent”. Sie steuern also i. d. R. das Ausspielen von bestimmten Trackingcodes / Tags. Natürlich sind die Cookies, um die es nun bald 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 derzeit (noch) nicht vorgesehen, die detaillierten Angaben zu Cookies zu machen, die für die Erfüllung der vermutlich kommenden Anforderungen notwendig sind. Aus “Tracking Consent Managern” müssen nun also auch “Cookie Consent Manager” werden.

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. Darum soll es hier aber gar nicht gehen und am Ende wird der Unterschied vermutlich auch für die Rechtsprechung zu subtil sein, um sich darauf zurückzuziehen.

Was tun ohne Consent?

Angesichts der für viele Websites zu befürchtende geringe Anteil aktiver Zustimmung zum “normalen” Tracking mit Google Analytics (nennen wir das Beispiel hier einfach beim Namen) 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 (vermutlich / hoffentlich) nicht so 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. Ob diese Beispiele auch nach einem in Deutschland gültigen Urteil in dieser Form bestand haben können oder einer Anpassung (oder gar Einstellung) bedürfen, soll im Rahmen dieses Beitrags beiseite geschoben werden. Bleiben wir beim Status Quo der derzeit theoretisch wie praktisch bestehenden Ausweichoptionen.

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.

Befreit man den Nutzen der Kennzeichnung eines bestimmten Browsers 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 nach einem noch nicht gefällten Urteil, sondern um das, was möglich und auch wirklich 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 Trackingsdienst gespeichert werden zu müssen. Damit sind Fingerprints, Footprints, Checksummen 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 wird es vermutlich auch so machen, 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 auf das _ga-Cookie 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. Im einfachsten Fall gibt es z. B. 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 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. Wer es eilig hat, kann sich das derzeit verbaute Tracking auf gandke.de genauer ansehen, wo testweise ein selbst gesetzter Keks im Einsatz ist. Gute Überleitung zur nächsten Option:

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 diese ohne Sorge um vom Browser gelöschte oder blockierte Cookies weiter betreiben.

Muss man allerdings diese Id selbst erzeugen und ist sie nicht zwingend Bestandteil des eigenen Systems (CMS) bzw. anderer erforderlicher Komponenten, ist das freilich nach wie vor ein Consent Thema.

Wenigstens die Sitzung?

Alternativ 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. Über “funktionale Erforderlichkeit” eines solchen Cookies wollen wir hier nicht diskutieren… aber vielleicht zumindest anführen, dass auch ein Tracking ohne Consent, wie es von Piwik PRO betrieben wird, derzeit mit kurzlebigen Cookies arbeitet.

Auch Consent Manager brauchen (oft) Identität

Einen Ausweg aus der Misere könnten ironischerweise ausgerechnet die Consent Management Tools selbst sein. Vor allem, wenn diese eine serverseitige Komponente zur Speicherung und Dokumentation von Consent haben, ist eine sitzungsüberdauernde ID ein zwingendes Merkmal einer solchen Lösung. Und so hat Borlabs seine uid, man findet einen stamp bei Cookiebot und auch andere Anbieter haben oft ähnliches zu bieten.

Selbst Consent Manager, die “nur clientseitig” eingebunden sind und nichts auf dem Server des Betreibers oder eines Dienstanbieters zur Dokumentation speichern, halten oft eine ID vor, um diese z. B. zusammen mit den Infos zum Consent für einen bestimmten Dienst oder eine Gruppe weitergeben zu können. Das ist auch sinnvoll, wenn z. B. parallel zu den Hits auch der Consent weiterverarbeitet und / oder zur Referenzierung des erteilten Consents für einen Messpunkt diese ID mit übergeben werden soll.

Klingt kompliziert? Egal. Im Kern bedeutet es, dass auch Consent Manager oft eine ID mit möglichst langer Lebensdauer speichern. Und das natürlich in einem (funktional erforderlichen) Cookie. Auf diesen Wert kann man je nach Consent Manager mehr oder weniger einfach zugreifen, aber sowohl im Client als auch auf dem Server besteht so die Chance auf eine nutzbare ID, die für das eigene Tracking verwendet werden kann, wenn Consent für eine Identifizierung per Cookie durch das Trackingsystem selbst fehlt. Wohlgemerkt: Es geht um technische Machbarkeit, nicht die Einschätzung von Rechtskonformität.

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). Wir werden es sehen. Machbar ist es jedenfalls schon. Auch im Browser kann - dann ohne IP - eine ID als “Abdruck” des Systems berechnet und verwendet werden und dieser Technik bedienen sich viele Dienste. Auch solche, die z. B. der Erkennung von Klickbetrug etc. widmen, wären betroffen, wenn diese Option wegfallen würde.

Nutzung der Identitätsoptionen für alternatives Tracking

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 kann ich selbstredend nicht mitliefern. Aber zum Trost: Nach aktuellem Stand (zwischen EuGH Urteil und konkreter deutscher Umsetzung) geht das vermutlich ab einer bestimmten Belastbarkeitsstufe der Aussagen auch den meisten Anwälten und Datenschützern so. Gehen wir also davon aus, dass es a) noch funktional erforderliche oder datenschutztechnisch unkritische Cookies geben wird und b) “vollwertiges Tracking” irgendwann aktive Zustimmung erfordert.

Unter diesen Bedingungen mag also ein alternatives Tracking ohne Consent immer noch möglich sein. Unterstellen wir das und bleiben 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 Google Analytics. Beides erprobe ich nun schon seit einigen Wochen aktiv. Serverseitiges Tracking war auch 2015 schon mal in anderer Form hier ein Thema.

Im Vordergrund steht auch dabei die technische Umsetzung - die Problematik und Lösungsoptionen für die Identitätsfrage sind hiermit erst einmal abgeschlossen. Beide gezeigten alternativen Trackingoptionen (und alle anderen auch) drehen sich aber im Kern um genau dieses Problem der Identität… und die damit im konkreten Fall einhergehenden Vor- und Nachteile.

Hat Dir der Beitrag geholfen?

Dann freue ich mich, wenn Du ihn mit anderen teilst! Wenn Du magst, gib einen aus ;)

© 2001 - 2024 Markus Baersch