Markus Baersch

Alle Browserhersteller (selbst in gewissem Umfang Chrome) erschweren das Tracking von Besuchern auf die eine oder andere Weise. Wenngleich das keine neue Entwicklung ist, hat das Thema mit ITP in Safari, ETP in Firefox und der neuen Beta von Edge jüngst einiges an Fahrt aufgenommen. Daher soll dieser Beitrag einen Über- und Ausblick geben, in welchem Maß und Umfang verschiedene Trackingmechanismen beeinflusst werden und welche Herausforderungen sich Anbietern und Nutzern von Tools im Trackingumfeld stellen - und stellen werden. Dabei geht es nicht nur, aber auch um Google Analytics und den Tag Manager.

Ausnahmsweise wird dies kein "Nerdbeitrag" und der Tech-Part bleibt auf ein notwendiges Minimum beschränkt. Davon habe ich schon einige geschrieben und es folgen auch weitere. Links zu passenden Beiträgen werden für den technisch Interessierten enthalten, aber nicht zum Verständnis erforderlich sein. Wer nach diesem Disclaimer noch Bock hat, darf gern weiterlesen 😉

Warum dieser Beitrag?

Ich habe in den letzten Wochen und Monaten in verschiedenen Phasen der sich aktuell zuspitzenden Situation zwischen Browsern und Tracking viele Gespräche und Diskussionen geführt, Dinge erprobt und über meine Ergebnisse in verschiedenen Vorträgen Auskunft geben dürfen. Was hoffentlich ebenso informierend wie unterhaltsam war, denn beides liegt mir am Herzen.

Sowohl in den der Tonspur beraubten Folien auf Slideshare, als auch in der beschränkten Zeit der Slots bei Netzwerktreffen und Barcamps bleibt der Blick in die mittelfristige Zukunft und das "Big Picture" aber stets zu kurz. So schön es ist, Probleme auf technischer und taktischer Ebene zu lösen oder zumindest Zwischenlösungen zu erarbeiten - die aktuelle Entwicklung von ITP und ETP (dazu gleich ein kleiner Überblick) zeigen eine klare Richtung auf und dienen einem konkreten Ziel. Und genau dazu soll hier meine Einschätzung etwas mehr Raum bekommen.

"Trackingschutz": Warum wird blockiert?

Vor der "Was-Frage" muss geklärt werden, warum überhaupt "irgendwas" blockiert wird. Das übergreifende Thema aller Mechanismen kann man m. E. so zusammenfassen:

Besucher von Websites sollen davor geschützt werden, website- und / oder geräteübergreifend vermessen zu werden, um dadurch ein Profil zu bilden.

Diese Profilbildung kann unterschiedlicher Natur sein. Kategorien sind z. B. "allgemeine" Webnutzung, Bewegung in einem bestimmten Netzwerk, besuchte Websites und deren Themen, Interessen, Kaufverhalten... die Liste ist offen und die Nutzung der Profile vielfältig. Genutzt werden diese Daten hauptsächlich zu Werbezwecken.

Erhoben werden sie aber auf durchaus unterschiedliche Weise. Im Fokus stehen sowohl Marketing-Plattform-Technologien und deren Techniken zur Besucheridentifizierung als auch Anbieter von Trackingtechnologien - vor allem, wenn diese auch etwas mit dem Ausspielen von Werbung zu tun haben. Ja, ich meine Google und Facebook etc. Technisch hier setzt an dieser Stelle reichlich Komplexität ein, die sich aber generell auf zwei Klassen von browserseitigem Trackingschutz herunterbrechen lässt:

1. Verhindern der Identifizierung eines Besuchers jenseits des gerade genutzten Browsers und / oder über den "Datenhoheitsbereich" einer besuchten Website hinaus
2. Blockieren externer Ressourcen, die als Trackingmechanismen eingestuft werden ("Trackingpixel", "Trackingcodes" - i. d. R. JavaScript-Code von Trackingsystemen)

Meint: Es geht den Herstellern nicht um die reine Erhebung von anonymen Daten zur Auswertung der Performance der eigenen Website durch den Betreiber. Was aber nicht bedeutet, dass sich diesen dennoch Herausforderungen stellen, die durch diese Schutzmaßnahmen entstehen. Klares Ziel ist aber die Werbeindustrie und dort sind Disziplinen wie Affiliate-Marketing, Retargeting und viele andere Facetten des Display Advertising bzw. Programmatic Advertising auch z. T. bereits deutlich betroffen.

Über Tags, Cookies und "Browserspeicher"

Um zu verstehen, was blockiert wird, muss hier das angedrohte Minimum an Tech-Zeugs zur Definition der im Schach zwischen Browsern und Trackern bewegten Figuren folgen. Sorry.

Cookies kennt vermutlich jeder und viele wissen, dass es "Third Party Cookies" und "First Party Cookies" gibt. Die Unterscheidung liegt im Kern darin, wer dadurch Informationen im Browser speichert: Die besuchte Website / Domain als "First Party" oder andere Domains, deren Ressourcen ebenfalls im Browser geladen wurden und die in diesem Kontext als "Drittpartei" gelten.

Solche externen Ressourcen anderer beteiligter Websites sind nicht nur, aber oft JavaScript-Code, die wir gern auch einfach "Tags" nennen. Sie laden Funktionalität oder Inhalt von einem anderen Server, der ebenfalls Cookies speichern kann. Und eben auch lesen. Folgerichtig sind Third Party Cookies auch am stärksten davon betroffen, was Browserhersteller sich an Trackingschutz bisher haben einfallen lassen.

Verkompliziert wird die Situation dadurch, dass Tags (also im Kern: Betreiber externer Domains) auch unter bestimmten Bedingungen Inhalte aus First Party Cookies lesen und nutzen können. Die Gründe sind technisch, aber für das Verständnis einer wichtigen Sache irrelevant: Dadurch werden auch First Party Cookies in zwei Klassen aufgeteilt, von denen eine nur von der besuchten Domain genutzt und nicht per Javascript im Browser von Tags genutzt werden kann und die andere eben nicht.

Nach den First Party Cookies ist es dieser zweiten Klasse von Cookies ebenfalls an den Kragen gegangen. Nennen wir sie hier vereinfachend, aber ausreichend prägnant "JavaScript Cookie" und die anderen "HTTP Cookies".

Diese JavaScript Cookies werden in Safari durch die "Intelligent Tracking Prevention" (ITP, gleich mehr dazu) in der Laufzeit z. T. deutlich beschränkt. Das hat dazu geführt, dass sich "Tracker" auch anderen Speichermöglichkeiten im Browser zugewendet haben: localStorage und IndexedDB. Das sind zwar keine Cookies, können aber in gewisser Weise (eingeschränkt) deren Aufgaben übernehmen. Diese Ausweichoptionen fassen wir hier zur Vereinfachung unter "Browserspeicher" zusammen.

Vor allem zur Behandlung zunehmender Blockierung von Third Party Cookies durch die Browser sind zudem auch Parameter ein Thema. Sie können zum Beispiel in einer URL enthalten sein, über die man nach dem Klick auf ein Werbemittel oder einen Link auf eine Seite gelangt. Auch Parameter können von Tags gelesen und weitergegeben werden, um damit die Identifizierung des Besuchers innerhalb eines Netzwerks oder "Datenpools" zu ermöglichen bzw. die Zuordnung zu einer bestimmten Quelle zu ermöglichen. Daher wird auch der Zugriff auf diese Informationen oder deren Weitergabe als Parameter von Aufrufen durch Tags unter bestimmten Umständen durch die Browser verhindert (oder zumindest erschwert).

Der Vollständigkeit halber: Fingerprinting umfasst wiederum andere Techniken, die im Prinzip darauf basieren, dass jeder Browser im Zusammenspiel mit dem System, auf dem er installiert ist und dem Verhalten des Nutzers genug Merkmale aufweist, um daraus einen ausreichend eindeutigen Marker zu generieren. Diesen nennt man dann je nach Technik Fingerabdruck, Fußabdruck oder sonstwie. Das ist gruselig und klingt nach nichts, was man als Website-Besucher haben möchte.

Überblick: Wer blockiert was?

Mit diesem Rüstzeug kann der Tech-Zug wieder abfahren. Es sollte nun klar geworden sein, dass Trackingschutz viele Facetten haben kann und vor allem eines ist: Ein Prozess. Browserhersteller setzen Maßnahmen um, die den beiden oben genannten Kernzielen dienen und die hier in einen Topf geworfenen "Tracker" ziehen auf die eine oder andere Weise nach. Eine Momentaufnahme mit Stand Ende September zeigt die folgenden unterschiedlichen Ansätze:

• Chrome konzentriert sich neben Maßnahmen gegen Fingerprinting (was mehr oder weniger auch alle anderen tun und daher hier nicht mehr erwähnt werden muss) sehr oberflächlich auf das Schließen der oben beschriebenen Lücke, die bei Cookies herrscht. Durch ein Attribut, dass von Browserherstellern und allen, die Cookies setzen unterstützt werden müsste, damit es etwas bringt. Mehr Wertung ist hier nicht nötig und die Kritik laut. Im Kern bleibt: Hier sind die Probleme klein, wenn es denn welche gibt. Natürlich tut man sich schwer, Maßnahmen zu finden, die das eigene System nicht gefährden, ohne es offenkundig zu bevorzugen (auch bekannt als die Quadratur des Kreises).
• Edge ist gerade in einer neuen Vorab-Fassung erschienen, in der je nach Einstellung des neuen Trackingschutzes unterschiedlich stark das Laden von Ressourcen aus bestimmten Quellen verhindert als auch der Zugriff auf Cookies und Browserspeicher eingeschränkt werden können. Der Trackingschutz in Edge betrifft also ggf. nicht nur die Identifizierung von Besuchern, sondern das Tracking durch entsprechende Tags wird ggf. komplett verhindert.
• Firefox hat jüngst durch neue Voreinstellungen des eigenen Trackingschutzes ETP ("Enhanced Tracking Protection") vor allem Third Party Cookies den Hahn faktisch ganz abgedreht. Das hat zu spürbaren Einbußen in bestimmten Sparten der Werbebranche geführt und verhindert faktisch viele Dinge wie Programmatic Advertising und das gezielte Ansprechen von ehemaligen Websitebesuchern; AKA Retargeting / Remarketing. Firefox blockiert aber nicht nur Cookies, sondern je nach Einstellung werden auch Tags gar nicht geladen. Wie bei Edge kann also durchaus das ganze Tracking ausfallen, wenn die Einstellungen stimmen oder der Hersteller irgendwann entscheidet, die Daumenschrauben enger zu ziehen. Dabei kann Firefox wie auch Edge theoretisch sehr selektiv und "willkürlich" vorgehen und einzelne Dienste oder Anbieter komplett aussperren. Der aktuelle Stand, dass Google Analytics derzeit jenseits der optionalen Werbefunktionen und Erhebung demografischer Daten nicht groß betroffen ist (Details dazu hier im Blog), kann sich also jederzeit ändern.
• Safari hat gerade erst begonnen, im Rahmen von ITP 2.3 ("Intelligent Tracking Prevention") auch Browserspeicher unter bestimmten Umständen mit dem gleichen vorzeitigen Ablaufdatum zu behandeln, mit dem zuvor schon JavaScript Cookies versehen wurden. Tags wird das Leben erschwert, indem z. B. Parameter aus den aufrufenden URLs einer Seite nicht mehr ausgelesen werden können. Generell konzentriert sich hier der Schutz aber vor allem auf das erste oben aufgeführte Thema: Die Identifizierung von Browser-Benutzern. Mehr Details zu ITP (bis 2.3) und auch möglichen Lösungen finden sich hier im Blog.

Das Problem für die Webanalyse und andere "Kollateralschäden"

All diese Maßnahmen erschweren nicht nur das "böse Tracking", sondern auch das "ganz normale Tracking". Wobei man über die Klassifizierung zwar trefflich diskutieren kann; ich möchte hier aber eine grobe und unscharfe Trennlinie ziehen, die sich am ersten obigen Punkt orientiert: Was der Profilbildung und ähnlicher Maßnahmen dient, die das Anreichern eines Browserbenutzers mit Informationen zu Werbezwecken dient, ist aus Sicht der Browserhersteller "böse". Bevor wir diese Trennlinie aus eher strategischer Sicht betrachten, soll es hier erst einmal um die praktischen Implikationen gehen, die vor allem mit der Identifizierung zu tun haben. Also alles rund um das Wiedererkennen eines Besuchers in Form von Cookies und Browserspeicher.

Durch die Einschränkung des Zugriffs auf Cookies & Co. oder die Beschränkung der Lebensdauer dieser Informationen, wenn sie von Trackingsystemen genutzt werden sollen, ist die Wiedererkennung von Besuchern gefährdet. Ohne Trackingschutz kann man in der Webanalyse wiederkehrende Besucher ausreichend zuverlässig anhand von Cookies oder Browserspeicher erkennen. Unter der Prämisse, dass viele Benutzer Cookies nicht selbst löschen oder entsprechende Einstellungen nutzen, war diese Erkennungsrate bisher kein großes Thema. Das ändert sich nun nicht nur für Webanalyse-Systeme, sondern auch andere, "als externes Tag eingebundene" Tools zu Zwecken wie z. B. Testing oder Consent Management (AKA Cookie Banner).

Die gute Nachricht: Das Identifizierungsproblem ist lösbar

Es gibt zahlreiche Ansätze, um dem sterbenden Cookie neue Kraft einzuhauchen oder über Browserspeicher in Eigenregie Alternativen zu finden, um die Wiedererkennung aufrecht zu erhalten. Das ist nicht nur für Google Analytics eine Option, sondern auch für andere Trackingsysteme entstehen ständig neue Lösungen mit unterschiedlichen Chancen auf Dauerhaftigkeit. Selbst wenn man die Entwicklungslinie in diesem Bereich weiterzeichnet und ggf. der JavaScript-Zugriff auf Cookies im Browser vollständig zum Erliegen kommen sollte, gibt es immer mehr oder weniger komplexe Optionen, um dieser Herausforderung zu begegnen. Auch in Szenarien, in denen mehr als eine Website vermessen werden soll ("Cross Domain Tracking"), kann man technisch aufwändigere Workarounds verbauen, die heute noch funktionieren und ggf. auch morgen noch, wenn die Browserhersteller weitere Einschränkungen scharf schalten.

Als Machbarkeitsstudie wird z. B. auf gandke.de derzeit komplett auf das Handling der Identifizierung durch Google Analytics verzichtet und die Identifizierung mit einem eigenen HTTP Cookie gelöst, auf das Javascript Tags (also auch Analytics selbst) keinen Zugriff haben. Diese Lösung ist sowohl bei direkter Implementierung und auch der Verwendung des Google Tag Managers nutzbar und weitestgehend "ITP sicher". Das behandelt weder alle denkbaren Sonderfälle, noch ist es für jede Website auf einfache Weise umsetzbar, aber dennoch kann man für einen Großteil betroffener Websites mit solchen Lösungen theoretisch ITP als besiegt betrachten. Warum also nicht freuen und alles wie immer weitermachen?

Erstens: Das ist kein Sieg, sondern eine Lösung, die der Webanalyse die Identifizierung des Besuchers zurückgibt und gleichzeitig die Kernanforderung von ITP erfüllt. Denn es wird ein Cookie genutzt, dessen Wert für alle anderen und potentiell "bösen" Tags unsichtbar ist. Und es ist zweitens immer noch ein Cookie, was übermorgen dank ePrivacy wieder zum Thema werden kann. Drittens - und viel gewichtiger: Cookies & Co. sind wie eingangs beschrieben nicht das ganze / eigentliche Problem.

Ein "Ressourcenproblem" der ganz anderen Art

Die Zwischen-Überschrift lässt es erahnen: Der zweite Punkt aus der Liste der Trackingschutzmaßnahmen ist die eigentliche Herausforderung. Was ist, wenn wir das Identitätsproblem lösen, aber die Trackingtechnologie selbst geblockt wird? Die Zeichen sind unübersehbar und Edge und Firefox machen es vor. Hier gibt es - und das ist ein Punkt mit unterschiedlichen "politischen" Facetten - Listen von Diensten bzw. Domains, die bei bestimmten Stufen des Trackingschutzes nicht mehr in der Lage sind, ihre Tags überhaupt im Kontext einer im Browser betrachteten Seite zu laden und auszuführen. Es mag also ein Cookie oder sonstwas mit einer Id des Besuchers da sein, aber die Tags selbst werden blockiert und damit fällt das Tracking komplett aus.

Platt ausgedrückt: "Der ganze ITP - Cookiekram ist nicht so schlimm. ETP bzw. die Blockierung von Tags ist das Problem"

Ein wesentlicher Punkt in diesem Spiel ist - zumindest derzeit - die Herkunft der Ressourcen bzw. Tags. Alle Trackingsysteme, die auf der eigenen Domain betrieben werden können bzw. die es ermöglichen, zumindest aus technischer Sicht hierüber ausgeliefert zu werden (technische Begriffe, die in diesem Zusammenhang fallen, sind z. B. Subdomain als Trackingdomain, CNAME und DNS Weiterleitung) sind da anderen gegenüber klar im Vorteil. Wer also entweder ein Trackingsystem selbst betreibt oder einen Anbieter nutzt, der die technischen Voraussetzungen für diese "Eingliederung" in die eigene Domain mitbringt, wird perspektivisch auch den nächsten Schritten der Browserhersteller relativ entspannt entgegen sehen können, wenn dies auch eine Lösung des Identifizierungsproblems darstellt oder ermöglicht (was oft der Fall ist).

Spätestens jetzt lohnt es sich aber, die Google Analytics Brille aufzusetzen. Wie wahrscheinlich ist es, dass das Script von Google Analytics gar nicht geladen werden kann - sei es bei direktem Einbau oder über den Google Tag Manager oder einen anderen Tag Manager, der ggf. das Script nicht nachladen kann oder dessen Code selbst schon blockiert wird? Hier genau steckt die Gefahr, die sich auf technischer Ebene schwierig behandeln lässt. Denn das Blockieren von Tracking-Tags dient nicht nur dem Blockieren von Tracking, Was erst einmal unlogisch klingen mag, ist leichter zu verstehen, wenn man sich an die Vorbereitungszeit der DSGVO zurück erinnert. Da wurden Reihenweise Dinge aus Website ausgebaut, die nicht dem Tracking dienten. Google Webfonts sind ein gutes Beispiel. Denn hier - wie bei allen anderen externen Ressourcen - birgt ein Aufruf aus dem Kontext einer einbindenden Website dem ausliefernden Server der Ressource immer die Möglichkeit, diese Anfragen auch zu protokollieren. Und diesen Anfragen kann man auch eine ganze Menge an Informationen über das System entlocken. Mit Aluhut würde hier nun wieder "Fingerprinting" stehen. Aber auch ohne Verschwörungstheorien muss man sich bei allen Ressourcen, die man von Google als Anbieter in die eigene Website einbindet, über diese Möglichkeit im Klaren sein. Begünstigt durch die Tatsache, dass Google sich trotz aller bestehenden Aussagen in Nutzungsbedingungen etc. nicht gerade um den Transparenzpreis bemüht, wenn es um die konkrete Nutzung oder Zusammenführung von Daten geht, ist das Risiko also bei Google Analytics und dem Google Tag Manager durchaus gegeben, dass die Browserhersteller hier irgendwann "per Default" keine solchen Tags mehr laden. Um ein "Tracking vor dem Tracking" nur durch den Abruf der Ressourcen zu verhindern.

Die Macht der Liste... und Google

Welche Tags oder auch Cookies von welchen Domains blockiert werden, liegt in der Hand der Browserhersteller. Firefox setzt auf eine Liste, die man zumindest in Auszügen einsehen kann. Darauf befinden sich mehr oder weniger alle Google Dienste. Was nicht bedeutet, dass heute bereits alle Google Dienste komplett ausgesperrt werden. Bei Safari zeigt der ITP-Debugger an, wessen Cookies blockiert werden und auch hier findet man Google Dienste, die über Analytics und den Tag Manager hinaus gehen. Aber sie sind freilich auch dabei.

Der Umfang dessen, was hinsichtlich der Blockierung passiert, kann schon jetzt vom Benutzer des Browsers angepasst werden. Und die Gefahr, dass sich die Vorgaben verschärfen, ist real. Ob es auch realistisch ist, dass Google Analytics per Default blockiert wird - oder gar der Google Tag Manager, so dass er nicht mehr in der Lage ist, die gewünschten Tags nachzuladen? Für viele ist das längst keine Ja/Nein-Frage mehr, sondern eine Wann-Frage. Marktanteil und Misstrauen gegenüber Google sprechen zumindest dafür... und das sind nur die "M"s.

Da am Ende des Tages die Zusammenstellung der Listen oder dadurch gesteuerten Maßnahmen durch den jeweiligen Browser einem "irgendwie demokratischen" Prozess unterworfen sind, kann man auch keinen Einfluss auf das nehmen, was der Browser  für seinen Nutzer je nach Einstellung "Hoch, Mittel, Niedrig" entscheidet. Da die Listen nicht für jedermann einfach und vollständig einsehbar sind, herrscht auch nur geringe Transparenz über die betroffenen Domains und Dienste. Wenn man nicht gerade beim Besuch einer bestimmten Website nachschaut, was an blockierten Ressourcen und Cookies im Browser ausgewiesen wird, merkt man als Nutzer schlussendlich nichts davon, solange die Funktionalität der Website nicht beeinträchtigt wird.

Kann man das nicht auch technisch lösen?

Natürlich. Man kann in meiner Welt fast jedes Problem irgendwie technisch lösen, wenn es selbst technischer Natur ist. Dummerweise aber sind viele theoretische Lösungswege vorhanden, deren praktische Nutzbarkeit (langfristig) unwahrscheinlich ist. Weil man diese nicht allein umsetzen kann, sondern auf Anpassungen von zwei Seiten angewiesen sind. Können wir Google Analytics nicht einfach auch über technische Mittel in den Kontext der eigenen Website bringen und damit das Blockieren verhindern? Möglicherweise. Aber ist das eine Lösung für einen Großteil der Anwender? Und wie sieht es mit dem Tag Manager aus, statt "nur" Analytics? Auch der Einsatz von Google Analytics über das Measurement Protocol zum Aufbau einer "serverseitigen Trackingvariante" hat gewisse Nachteile und bringt Einschränkungen gegenüber der üblichen Nutzung. Aus diesem Grund habe ich mich auch vorerst dagegen entschieden, das Blockierungsproblem ebenso wie das Identitätsproblem zu behandeln und nach technischen Auswegen zu suchen. Was nicht bedeutet, dass ich keine Tests in dieser Richtung durchführen werde.

Denn ich habe zeitgleich wenig Hoffnung, dass uns eine von Google propagierte, bevorzugte und vor allem sicher unterstützte Alternative in den Schoß fallen wird. Im Gegensatz zu Adobe und anderen ggf. kleineren Anbietern, deren Lösungen weder "massenhaft verbaut" noch in der Breite "kostenlos" nutzbar sind, wie es bei Google Analytics und dem Tag Manager der Fall ist, muss eine solche Lösung immer noch genug Wert für den Anbieter haben, um den Aufwand und Betrieb zu rechtfertigen. Wenn kein Analytics 360 gegen Geld im Einsatz ist und Analytics in Folge einer Lösung ggf. als Mittel ausfällt, um Zielgruppen für Werbung zu befüllen oder andere Werbefunktionen zu befruchten, wo bleibt dann der Anreiz für den Anbieter? Ich habe keine Antwort auf diese Frage.

Wie sich die Bedingungen für das Tracking mit Google Analytics - oder z. B. das Facebook Tracking Pixel verschärfen, werden wir eher früher als später sehen. Auf jeden Fall bleibt bei allen Lösungen für die schon bestehenden Probleme eine Ungewissheit für die mittel- und langfristige Zukunft, über die man sich als Anwender von Trackingsystemen bewusst sein sollte. Wer sich bis hier durch den Beitrag gekämpft hat, kennt nun zumindest die Rahmenbedingungen, Bedrohungen und deren Ursachen. Ich werde diesen Beitrag vermutlich genau wie die oben verlinkten Artikel zu ITP und ETP noch mehrmals in Zukunft aktualisieren (müssen). Wenn Du mit Ergänzungen, eigenen Tests, anderen Meinungen oder alternativen Lösungen daran teilhaben willst: Gern stelle ich mich der Diskussion per Mail oder wenn wir uns auf Konferenzen oder Events begegnen sollten!