Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » Analytics / Trackingschutz

03.03.2019

ITP ist ein Problem für Analytics

ITP ("Intelligent Tracking Prevention") als Schutz vor Tracking durch Drittparteien und domainübergreifende Profilbildung in Safari Browsern ist prinzipiell eine gute Idee. Das sage ich selbst als jemand, der in der Rolle eines Marketers bei Google Ads & Co. auf so erhobene Daten in gewisser Weise angewiesen ist. Aber was Safari mit der neuen Version 2.1 von ITP einführen wird, geht deutlich über diese ursprüngliche Intention hinaus. Im Kern werden dabei First Party Cookies, wie sie für die Webanalyse (und deren Opt Out! - siehe unten), Testing, Personalisierung und viele andere Funktionen jenseits von Tracking durch Dritte oder Profilbildung genutzt werden, auf eine Lebensdauer von 7 Tagen begrenzt. Mit Folgen für alle o. a. Systeme. Das ist nicht gut. Was alles betroffen ist und was man tun kann, um die Effekte abzumildern, zeigt dieser Beitrag.

ITP in Safari

Trackingschutz-Mechanismen wird es in absehbarer Zeit in allen Browsern geben (siehe Ausblick unten). Safari gehört aber zu den ersten Kandidaten, die mit einer eigens zum Schutz vor potentiell "unerwünschtem" Tracking entwickelten Technologie ausgestattet wurden, welche ihren Dienst per Default - also ohne die Notwendigkeit des Einschaltens durch den Benutzer - versehen. Damit sind potentiell alle Nutzer der jeweiligen Safari Version betroffen. Dieser Beitrag wird schon lang genug, also wird die Historie, die Technik und die Auswirkungen von ITP an dieser Stelle nicht im Detail besprochen. Ersatzweise findet man alle Infos bis zur Version 2.0 von ITP im Beitrag im Piwik PRO Blog.

Was ändert sich mit ITP 2.1 und warum ist das ein Problem?

In der Ankündigung der Version 2.1 ist zu lesen, welche Änderungen zu erwarten sind. Wesentlich hierbei ist die Kappung der Laufzeit von First Party Cookies auf 7 Tage, wenn diese clientseitig durch JavaScript (via document.cookie) gesetzt wurden. Es betrifft also nicht alle Cookies, sondern nur diejenigen, die im Browser gesetzt werden. Das sind aber dummerweise genau die Cookies, die wir heute typischerweise zum Zweck der Webanalyse und für viele andere Dinge nutzen, um Besucher wiederzuerkennen oder zu markieren und anhand dieser Markierung z. B. die Ausgabe von Inhalten steuern (Personalisierung, Testing).

Der Hintergrund ist die Tatsache, dass inzwischen viele Drittanbieter-Tools, deren primärer oder sekundärer Zweck die domainübergreifende Profilbildung ist, heute auf First Party Cookies setzen, weil das Leben für Drittanbieter Cookies immer schwieriger wird. Nicht erst seit ITP 1.0. Der Umstellungs-Druck hat so z. B. auch Facebook zum Wechsel von Drittanbieter- auf First Party Cookies gezwungen. Alle Analytics Anwender kennen die Auswirkung dieser Umstellung in Form der "fbclid", die nun an allen URLs hängt, wenn diese einen Klick via Facebook-Link erhalten.

Entwicklung ITP

Dass durch die "Cookie-Kastration" auch Systeme betroffen sind, die nichts mit der Art von Datenerhebung zu tun haben, gegen die sich ITP eigentlich richtet, scheint bei Safari billigend in Kauf genommen zu werden. Der beim ITP-Post von Simo Ahava zitierte Austausch mit dem Lead Developer für ITP via Twitter spricht eine deutliche Sprache.

Leidtragende dieser Kollateralschäden sind also alle Funktionen und Scripts, die auf Cookies angewiesen sind, die per JavaScript gesetzt werden. Mit unterschiedlichen Folgen:

Auswirkungen des "First Party Cookie Cap"

Prinzipiell haben Cookies eine definierte Laufzeit. Je nach deren Einsatzzweck können dies ein paar Stunden, Tage, Monate oder auch Jahre sein. So lebt z. B. der "_ga"-Cookie von Google Analytics, der zur Wiedererkennung eines Besuchers dient, normalerweise zwei Jahre nach dem letzten Besuch. Solange er nicht gelöscht wurde, kann Google Analytics den Besucher anhand der dort gespeicherten Client ID eindeutig wiedererkennen. Das schlägt sich auf Berichte nieder, in denen zwischen neuen und wiederkehrenden Besuchern unterschieden wird. Auch Auswertungen, die nicht primär an eine Session gebunden, sondern "user-zentriert" sind (wie z. B. der Nutzerexplorer oder die Reports zum Customer Lifetime Value sowie der Multi-Channel-Trichter), sind auf diese Cookies angewiesen.

Um es klarzustellen: ITP 2.1 betrifft "nur" Nutzer der (zum Stand der Erstellung dieses Beitrags noch kommenden) Safari Version. Aber bei denen ist die Laufzeit dieses Cookies nun auf 7 Tage nach dem letzten Besuch begrenzt. Hier sieht man ein Beispiel aus der Vorabversion von Safari 2.2 mit ITP 2.1: Besucht man die Seite am 7.3., wird ein Cookie erzeugt, dessen Laufzeit nur bis zum 14.3. andauert.

Kurzlebige GA Cookies in Safari 2.2

Mit der Folge, dass ein Besucher an Tag 8 oder später nicht mehr wiedererkannt und so als neuer Besucher eingestuft wird. Das ist vor allem bei Themen wie Attribution oder Conversiontracking (nicht nur für Google Ads), aber auch beim Testing mit Google Optimize und anderen Tools ein Problem. Für einige Systeme ist das auch genau die Absicht hinter ITP - aber eben nicht bei allen.

Potentiell betroffene Systeme und Funktionen

  • Webanalyse
  • Testing
  • Personalisierung
  • Profilbildung (nicht nur domainübergreifend)
  • Attribution
  • Werbung
  • Warenkörbe in Shops

Abhilfe für die Webanalyse am Beispiel Google Analytics

Man kann dieser verkürzten Laufzeit der Cookies, die für Google Analytics (und andere Webanalysesysteme) benötigt werden, durchaus begegnen. Viele Lösungen (auch die hier vorgestellten) basieren dabei auf dem Speicher moderner Browser, dem so genannten localStorage. Bevor wir uns darauf fokussieren, ist aber ein Blick auf die generell verfügbaren Optionen im Überblick fällig:

Optionen zur Behandlung des ITP-Problems

  • localStorage: Hierbei gibt es aber eine wichtige Einschränkung: Im localStorage abgelegte Informationen können nur dann ausgelesen werden, wenn der Hostname übereinstimmt ("same origin policy"). Damit sind alle Lösungen, die auf diesen Speicher setzen, nur für Tracking-Szenarien geeignet, bei denen nur ein einzelner Host wie www.markus-baersch.de getracked werden soll. Sind andere Subdomains wie blog.markus-baersch.de, app.markus-baersch.de etc. im Spiel oder ist das "www" in der Adresse nicht zwingend, scheitert diese Lösung und es entstehen drei unterschiedliche Nutzer, die beim Wechsel jeweils eine neue Session aufmachen und nicht in Verbindung gebracht werden können. Auch das Protokoll muss übereinstimmen, also darf es keine http- neben https-Adressen geben, sondern eine Fassung muss "durchgesetzt" werden, wenn es eine vergleichsweise "einfache" Lösung sein soll. Ansonsten bietet der Beitrag von Simo Ahava auch dafür Ansatzpunkte für die Nutzung von localStorage in solchen Szenarien (über iFrames und Messages, also kein triviales Zeugs).Cross-Domain Tracking (also z. B. domain.com und domain.de in einer Property) kann damit nur unter bestimmten Bedingungen bzw. auf Umwegen bedient werden. Während es für den GTM eine "fertige" Lösung gibt (siehe Beitrag von Simo Ahava unten), ist das Tracking und manuelle oder automatische Tagging der Links zwischen den Domains bei direkt implementiertem Code auf individuelle Anpassungen angewiesen (= potentiell viel Umsetzungs- und Testaufwand).
  • User ID: Wer den Luxus hat, zu einem großen Anteil von angemeldeten Benutzern besucht zu werden, die auf diese Weise systemseitig erkennbar sind, kann mit User ID arbeiten. Dabei würde zumindest der eingeloggte Anteil der Safari-Nutzer von diesem Problem befreit... aber eben nicht alle. Daher ist User ID bestenfalls eine Teillösung.
  • Serverseitige Cookies: In Fällen, in denen localStorage nicht genutzt werden kann. helfen ggf. andere Lösungen wie das "Aufwerten" des Cookies durch einen serverseitigen Cookie, der serverseitig gesetzt werden muss. Das ist je nach eingesetztem System unterschiedlich komplex. Für viele CMS wie z. B. WordPress sollte sich das relativ leicht mittels eines Plugins nachrüsten lassen, sobald das Problem Realität geworden und wahrgenommen wurde. Das Prinzip erklärt Simo Ahava im oben verlinkten Blogbeitrag zu ITP 2.1 im Abschnitt "Set-Cookie headers could work, for now".Hier sieht man - passend zum nur 7 Tage lebenden Beispiels eines GA-Cookies oben - das Ergebnis einer solchen serverseitigen Erneuerung des Cookies in Safari 2.2., wo die Laufzeit wieder bei 2 Jahren liegt.Serverseitige GA Cookies in Safari 2.2Für das unten beschriebene Opt-Out-Problem ist eine Umstellung weg vom "JavaScript Cookie" sogar vermutlich die einfachere Option.
  • "Upgrade" der Tracking - Cookies: Über einen per JavaScript aufgerufenen "Helper", der (in PHP oder anderen Sprachen realisiert) werden die per JS gesetzten Cookies von Analytics & Co ausgelesen und als serverseitig generierte Cookies neu erstellt. Eine entsprechende Lösung, die den Vorteil hat, dass dadurch im Idealfall wirklich nur das Löschen durch ITP verhindert wird, habe ich auf Github beschrieben und bereitgestellt. Dabei ist aber zu beachten, dass man die Anzahl der Aufrufe von URLs auf dem eigenen Server erhöht. Da es sich nicht um eine Ressource wie ein Bild handelt, welches nur einmal aufgerufen werden muss und dann im Browsercache lebt, sorgt jeder Aufruf einer Seite mit dem modifizierten Code einen weiteren Eintrag in den Logfiles des eigenen Servers, wenn der "Helper" aufgerufen wird. Das ist bei kleinen und mittelgroßen Websites (hinsichtlich der Besucher und Seitenaufrufe) sicher kein Beinbruch, aber speziell Sites mit mehr Traffic sollten dies bei der Entscheidungsfindung mit einbeziehen und sich einstweilen wie im Beispiel umgesetzt auf Safari Besucher beschränken... jedenfalls solange, bis auch Firefox und andere das Konzept übernehmen (siehe dazu auch Hinweise unter "Wie geht es weiter?"). Update Juni 2019: Wie Simo Ahava in seinem eigenen Beispiel mit einem Web Service zum Erneuern des Cookies über die Google Cloud Platform beschreibt, kann man die ständiger Erneuerung des Cookies durch den Trackingcode verhindern, so dass das serverseitige Erneuern des Cookies nur noch bei Bedarf erfolgen muss. Das macht diesen Ansatz nach akt. Stand m. E. zur besten Option für viele Websitebetreiber. Ich habe meine Beispiele auf Github entsprechend ergänzt und exemplarische Trackingcodes hinzugefügt, die genau nach diesem Prinzip arbeiten.
  • Nichts tun: Auch das kann eine Option sein, wie gleich in den Hinweisen zum unverzichtbaren Schritt der Analyse noch ausgeführt wird. Ist der zu erwartende Effekt marginal oder kann man bewusst mit dem (grob bezifferbaren) Verlust an Datenqualität durch ITP 2.1 leben, ist "Aussitzen" diejenige Variante, welche den geringsten Aufwand und das kleinste Risiko bedeutet. Vom Sonderfall Opt Out einmal abgesehen, aber das ist ein separat zu betrachtendes Thema, das unten vertieft wird.

Keine Lösung ist perfekt. Man muss sich z. B. bewusst machen, dass die Speicherung der Client ID parallel zum verwendeten Cookie dessen Lebensdauer nicht nur in Safari und hinsichtlich ITP 2.1+ verlängert. Nutzt man diese Option für alle Besucher, führen gelöschte Cookies generell nicht mehr zu neuen Nutzern, sondern Besucher können durch die an anderer Stelle abgelegte "Sicherung" der ID jederzeit wiedererkannt werden. Es gibt demnach Auswirkungen jenseits von Safari - schließlich betrifft dies (wenn man nichts im Code speziell auf Safari Nutzer ausrichtet) alle Nutzer und alle Browser. Folgerichtig werden sich auch über alle Besucher die Verhältnisse von neuen zu wiederkehrenden Besuchern verändern. Möglicherweise sind diese Auswirkungen auf Nutzer anderer Browser so sogar gravierender, als die eigentliche "Zielgruppe" der Anpassung; den Safari-Benutzern. Daher vor einer Anpassung zunächst einmal:

Schritt 1: Analyse - wie groß ist das Problem überhaupt?

Bevor man sich mit den unten genannten Anleitungen ggf. wirklich an die Anpassung des Tag Managers oder des Trackingcodes macht, sollte man sich erst einmal einen Überblick verschaffen. Wie groß (oder klein) ist das zu erwartende Problem? Gerade angesichts der o. a. Nebenwirkungen durch bessere Wiedererkennung von Besuchern ist die bewusste Entscheidung gegen eine Anpassung möglicherweise die bessere Option. Selbst wenn man die Dunkelziffer der "Cookielöscher" jenseits von ITP nicht wirklich bestimmen kann.

Falscher Ansatz: "Fremde" Zahlen

Die falsche Methode wäre das Vertrauen auf Studien. Denn darin stecken Durchschnitte und die sind wertlos, wenn es um die Auswirkungen auf die eigene Website gibt. Zum Beweis hier der Durchschnitt von knapp 17 Millionen Besuchern zwischen August 2018 und Februar 2019 auf 200+ unterschiedlichen Properties, deren Verteilung ich nach Browser und Besuchertyp ausgewertet habe. Mit dem Ergebnis, dass irgendwelche Zahlen rauskommen, die zwar interessant sind, aber von den eigenen Zahlen mit absoluter Sicherheit vollkommen abweichen. Hilfreich bei der Bewertung des eigenen Problems sind die 5% aus dieser Verteilung daher nicht. Zur Unterhaltung bewegen sich die Zahlen aber wenigstens im folgenden Chart.

Verteilung nach Besuchertyp und Browser - schön, aber nicht hilfreich

Der richtige Weg: In die eigenen Daten sehen

Um den Effekt für die eigene Website einzuschätzen, sieht man sich am besten zuerst den Report unter "Zielgruppe - Technologie - Browser & Betriebssystem" an. Hier findet man die Anteile der Sitzungen und Nutzer nach Browser. Safari bringt dabei je nach Website unterschiedliche Anteile, ist aber inzwischen typischerweise in den Top 3 zu finden. Hier zwei Beispiele:

Statistik nach Browser - Beispiel 1

Die Sache erscheint auf den ersten Blick sonnenklar: Auf Platz 3 und fast so viele Besucher wie im Firefox. Da muss man ran. Oder nicht? Bedenke: Es geht ausschließlich darum, wiederkehrende Besucher auch nach 7 Tagen eindeutig zu erkennen. Die Differenz aus Nutzern und neuen Nutzern sagt uns also: Es sind gerade schlappe 29 Besucher, auf die das zutrifft. OK, das ist natürlich eine Milchmädchenrechnung, denn der Zeitraum bestimmt mit, ob ich ein neuer oder wiederkehrender Besucher bin... Aber im Kern stimmt die Aussage dennoch: Es sind erbärmlich wenig Besucher, auf die eine Anpassung Auswirkungen haben würde.

Ein tieferer Blick per Klick auf den Safari - Eintrag kann, gepaart mit der Auswahl einer anderen Dimension wie "Nutzertyp" statt der Browserversion, weitere Einblicke in den potentiellen Impact einer Änderung liefern. Außerdem sollte man sich vor allem neben der Anzahl von Nutzern, Sitzungen und Seitenaufrufen Kennzahlen wie die Zielerreichung und Transaktionen ansehen.

Meint: Ohne Berücksichtigung der tatsächlichen Auswirkungen sollte man keine Entscheidung treffen und nicht nur auf die Anzahl der Nutzer blicken. Machen wir das daher für ein zweites Beispiel:

Statistik nach Browser - Beispiel 2

Hier kann man - neben dem offenkundig höheren Anteil an den Nutzern - allein an den beiden abgebildeten Kennzahlen einen wesentlichen Unterschied zum vorherigen Beispiel ablesen: Der Anteil der wiederkehrenden Besucher ist deutlich höher. Außerdem zählen in einem solchen Szenario eben auch die "absoluten Zahlen". Denn jeder Besucher, der hinter den Zahlen steckt, beeinflusst auch die anderen o. a. Kennzahlen wie Conversions und Umsätze. Unter diesen Gesichtspunkten werden also wieder zuerst die wiederkehrenden vs. neuen Besucher segmentiert betrachtet. Immer dran denken: Es geht primär um die Wiedererkennung, es steht nicht "der ganze Safari Traffic auf der Kippe".

"ITP Impact Analyse" - Berichtsvorlage

Für eine schnelle "ITP Impact Analyse" kann auch ein entsprechender Benutzerdefinierter Bericht verwendet werden, der sich auf die Safari Besucher konzentriert und diese im ersten Schritt gleich nach Neu vs. Wiederkehrend als Dimension segmentiert. Per Klick auf diesen Link kann ein solcher Bericht als Vorlage importiert werden. Darin sieht man (ungeachtet der Angabe "Alle Nutzer") nur die Safari Benutzer, denn der Bericht ist bereits gefiltert.

ITP Impact Analyse

  • Unter (1) kann zwischen verschiedenen Kennzahlen gewechselt werden, wobei der Tab "Ziele" i. d. R. individuell an die bestehenden Ziele angepasst werden sollte. Er enthält daher in der Vorlage nur die Gesamtzahlen.
  • Alle Berichte enthalten als primäre Kennzahl die Nutzer, also ist es sinnvoll, bei einer Betrachtung der eigenen Zahlen auf den jeweiligen Tabs unter (2) die Kennzahlen auch im Zeitverlauf zu betrachten.
  • Unter (3) sind - wie in allen Berichten - sekundäre Dimensionen eine große Hilfe bei der Suche nach Antworten. So zeigt die Browserversion z. B. an, wie hoch die Rate der Nutzer ist, die die aktuelle Version nehmen. Dieses Detail sieht man übrigens auch per Klick auf einen der Einträge beim Nutzertyp (4). Wie bei allen bisher untersuchten Properties sollte der Anteil der aktuellen Version aber sehr hoch sein, so dass ITP vermutlich auch einen Löwenanteil der Besucher betrifft, sobald Safari 12.1 erscheint.

Wie dieses Beispiel zeigt, entfällt hier ein guter Teil des Umsatzes auf die wiederkehrenden Besucher. Die Anzahl der Sitzungen pro Benutzer (aus diesem Report auf dem Reiter "Besucher") und die durchschnittliche Dauer bis zum Kauf sind weitere Bausteine einer informierten Entscheidung.

Der Bericht zum Zeitintervall beim Multi-Channel-Trichter gibt beim Blick auf die Conversions in diesem Zusammenhang weiter Aufschluss darüber, wie groß der Anteil der betroffenen vorbereiteten Conversions wäre, wenn das Tracking nach 7 Tagen einen neuen Nutzer messen würde. Das kann und sollte sowohl für alle Besucher als auch gezielt für das "Safari-Segment" betrachtet werden.

Sollte man die Analyse ausweiten?

Da auch Firefox früher oder später nachziehen wird und sich schon erste Anzeichen zeigen (siehe Link unter "Wie geht es weiter?"), ist es für eine mittel- statt kurzfristige Betrachtung denkbar, den Vorgang zu wiederholen und diesmal einen Blick auf alle Firefox-Besucher zu werfen. Zumindest der Anteil, der auf einer ansatzweise aktuellen Browserversion unterwegs ist, wird sich nach der Umsetzung auch in Richtung ITP 2.1 aufmachen. Für viele Websites bedeutet dies etwa eine "Verdopplung des Problems", da die Anteile von Safari und Firefox dort ähnlich sind. Wie aber schon oben erwähnt: Durchschnitte verschiedener Sites helfen hier nicht weiter. Daher lieber in die eigenen Daten sehen.

Zum Blick auf das, was in Zukunft noch kommen wird, kann man zwar unter der Annahme, dass früher oder später alle Browser betroffen sein werden, auch den ganzen Traffic nach diesem Vorbild untersuchen, aber spätestens dann muss die Zeit von Workarounds und Flickwerk vorbei sein. Hier sind die Anbieter in der Pflicht, Lösungen zu ermöglichen oder selbst herbeizuführen. Langfristig ist man also gut beraten, wenn man den ganzen wiederkehrenden Traffic nicht als potentiell gefährdet betrachtet.

Schritt 2: Bewertung

Zieht man eine Anpassung des Trackings in Betracht - und ist localStorage eine valide Option (siehe Hinweis oben) -, gibt es je nach Art der Implementierung verschiedene Lösungsansätze. Bevor man sich an eine Umsetzung begibt, sollte man folgende Dinge einschätzen und bewerten und erst dann eine Entscheidung treffen:

  1. Es handelt sich um einen nennenswerten Eingriff in das Tracking. Durch die o. a. Auswirkungen sind nicht nur Safari-Nutzer betroffen, sondern alle Besucher der Website. Da am Trackingcode auch Dinge wie E-Commerce-Tracking und die Qualität (und Kontinuität / Vergleichbarkeit) vieler Reports hängen, spricht man eine Anpassung idealerweise mit anderen Beteiligten ab, wenn man keine Einmann-Bude mit voller Entscheidungsgewalt bei einer Person ist.
  2. Nicht jeder Trackingcode ist "Standard" und kann einfach 1:1 gegen die hier vorgestellten Alternativen ausgetauscht werden. Daher ist der richtige Ansprechpartner für eine Anpassung nicht nur darüber informiert, wo der Code zu finden ist, sondern auch im Bilde über bestehende Modifikationen, so dass diese in einer geänderten Fassung nicht verloren gehen. Meint: Ohne HTML- und JavaScript-Kenntnisse sollte man sich nicht selbst an den Austausch machen! Ohne Tests der einwandfreien Funktion der Website kann und sollte ein solcher Eingriff ebenso nicht stattfinden. Es entstehen auf jeden Fall Kosten und Aufwand, der über "Copy, Paste, Fertig" hinausgeht.
  3. Es mag eine gute Option sein, das Problem erst einmal entstehen zu lassen und zu beobachten, statt "vorab" bereits in eine Lösung zu investieren. In diesem Sinne verstehen sich die unten vorgestellten Ansätze eher als Denkanstoß und kommen definitiv ohne direkte Implementierungsempfehlung daher!
  4. Es ist auch eine valide Option, die Speicherung im localStorage nicht für alle Besucher zu nutzen, sondern nur Nutzer von Safari. So lassen sich die oben benannten Nebeneffekte minimieren, wenn die Sorge besteht, dass alle Reports für alle Nutzer potentiell "irgendwie anders" ausfallen.

So, das wäre geklärt. Immer noch anpassen? OK, dann so:

Schritt 3: Anpassung des Trackingcodes bzw. Tag Managers

Generell arbeiten alle Varianten nach dem gleichen Prinzip (wobei je nach Option die Teilschritte abweichen oder an unterschiedlicher Stelle verarbeitet werden).

  1. Es wird im localStorage nach einer bestehenden ID gesucht (und je nach Variante ggf. schon hier erzeugt, wenn nicht vorhanden)
  2. Ist eine ID vorhanden, wird sie der Initialisierung des Trackers zugeführt
  3. Der Tracker nutzt entweder die übergebene ID oder ansonsten die aus einem bestehenden Cookie. Wenn keine vorhanden oder generiert wurde, wird ein neuer Nutzer (Cookie) erstellt
  4. Es wird getracked. Entweder direkt dabei oder spätestens im nächsten Schritt wird die ID im localStorage gespeichert
  5. Ggf. Speicherung der ID (wenn nicht schon im vorherigen Schritt)

Tracking mit ID aus localStorage

Bei Nutzung des Tag Managers

Wird für das Ausspielen des Google Analytics Trackingcodes der Google Tag Manager genutzt, kann man die Aufgabe wie in diesem Blogpost (ebenso von Simo Ahava) beschrieben mit Hilfe einer JavaScript-Variable zum Lesen der Client ID aus dem localStorage sowie einem customTask zum Schreiben der ID in den Speicher erledigen. Beide werden als Feld beim Analytics-Tag hinterlegt. Für die korrekte Funktion ist es wesentlich, dass wirklich alle Analytics-Tags damit ausgestattet werden - gut also, wenn man mit einer globalen Einstellungsvariable im GTM arbeitet, so dass man diese Anpassung an zentraler Stelle vornehmen kann.

Alternativ kann auch das nachträgliche Upgrade der Cookies (siehe Beschreibung zur "Upgrade"-Lösung oben) über den Tag Manager genutzt werden. Der AJAX-Aufruf des dazu erforderlichen serverseitigen Scripts kann in z. B. einem hitCallback, einem customTask oder Cleanup-Tag untergebracht werden.

Bei direkt implementiertem Code

Hat man den Analytics-Code direkt in das Template seines CMS implementiert, sodass er auf allen Seiten direkt ausgespielt wird, muss dieser angepasst werden, um auf ähnlichem Weg die gleichen Ergebnisse zu erzielen. Dazu kann wiederum z. B. entweder das "Upgrade" der Cookies per PHP Script (siehe oben) oder die localStorage Variante gewählt werden.

Google selbst gibt in der Hilfe für Universal Analytics einen Weg zur Nutzung von localStorage vor. Dieser verzichtet allerdings komplett auf die ansonsten eingesetzten Cookies und arbeitet zudem mit einer Client ID, die kein Verfallsdatum hat. Da dies deutlich "drastischer" ist als die bisherige Cookie-Lösung, habe ich aus den dort vorgestellten Ansatz mit der sinnvollen Ergänzung einer Laufzeit aus Simos Lösung für den GTM vereint. Daraus sind entsprechende Pendants für direkt implementierten Code entstanden.

Arbeitet man mit Universal Analytics (Nutzt im Code die Funktion ga()) oder die neuere Fassung von gtag.js (Funktion gtag() wird genutzt), kann man den Trackingcode bei Wahl dieser Variante anhand der Beispiele anpassen, die ich bei Github abgelegt habe.

Extrawurst gtag.js

Im Fall von gtag.js ist aber zu beachten, dass die unter dem Github-Link vorgestellte Lösung in gewisser Weise ein "Provisorium mit Verfallsdatum" darstellt und damit keine bevorzugte Lösung sein kann. Das liegt daran, dass gtag.js derzeit hinsichtlich Google Analytics intern nichts anderes ist als Universal Analytics. Die verlinkte Lösung muss daher über den Umweg des intern genutzten "ga-Trackers" dafür sorgen, dass die bestehende Client ID (entweder vorher ausgelesen oder aus dem neuen Cookie) per Callback ausgelesen und in den localStorage geschrieben wird. Das ist in dieser Form nur funktionsfähig, solange im Innern von gtag.js immer noch Universal Analytics steckt. Generell ist es also nicht empfehlenswert, dauerhaft auf diese Lösung zu setzen. Besser ist es, nach wie vor die Universal-Syntax zu verwenden - oder gleich auf den Google Tag Manager umzustellen.

Besonders ärgerlich: Opt Out per Cookie funktioniert nicht mehr in Safari!

Ein Punkt, an den bei der Konzeption von ITP 2.1 ganz sicher nicht gedacht wurde, sind die üblichen cookiebasierten Opt Out Lösungen für Google Analytics und den Tag Manager, die nicht erst seit der DSGVO auf vielen Websites angeboten werden. Dies sind Alternativen für die Plugins, die Google für viele Browser bereitstellt und die allein schon wegen der steigenden Dominanz mobiler Browser erforderlich wurden, um wirklich allen Besuchern eine Wahl zu lassen, durch die Webanalyse erfasst zu werden oder nicht. Dazu finden sich in vielen Datenschutzhinweisen im Abschnitt zu Google Analytics Links, mit denen der Besucher seinen Opt-Out-Wunsch per Klick kundtun kann. Solche Lösungen, die in verschiedenen Varianten im Web zu finden sind (als Beispiel hier mein eigener Beitrag zum Opt Out bei gandke.de) und auch in Diensten wie der automatisch generierten Datenschutzerklärung von Avalex verbaut wurden, basieren alle in der einen oder anderen Form auf dem folgenden Ablauf:

  • Beim Klick wird ein (ja, First Party) Cookie mit langer Laufzeit gesetzt (Ja, per JavaScript), der diesen Wunsch über den Aufruf der aktuellen Seite hinaus speichert. Er "gehört" also der Domain und beinhaltet normalerweise auch die Property ID, für die das Tracking deaktiviert werden soll.
  • Ggf. wird schon jetzt eine Eigenschaft des window-Objekts gesetzt, die alle weiteren Tracking Aufrufe durch Analytics blockiert. Das ist eine "eingebaute" Eigenschaft des Analytics Tracking-Scripts. Spätestens aber passiert das beim nächsten Aufruf einer Seite:
  • Durch Modifikation des Trackingcodes oder entsprechende Konfiguration im Tag Manager wird vor dem Ausführen / Laden des Trackingcodes nachgesehen, ob es ein Cookie mit Opt Out Wunsch gibt. Falls ja, wird die in Punkt 2 genannte Eigenschaft des window-Objektes gesetzt, sodass der danach ausgeführte Trackingcode angewiesen wird, keine Hits an Analytics rauszusenden.

Kommt nun künftig ein Besucher mit Safari und ITP 2.1 daher und klickt auf diesen Link - oder hat dies bereits in der Vergangenheit getan -, geht er davon aus, dass dieser Wunsch dauerhaft gespeichert und respektiert wird. Durch das per ITP verkürzte Zeitfenster scheitert diese Lösung aber ab Tag 8 in Safari nach dem Klick auf den Opt Out Link. Das Tracking läuft (stillschweigend) wieder an, wenn der Besucher nach dem durch den Browser erzwungenen vorzeitigen Verfall des Cookies zurückkommt.

Das ist besonders ärgerlich, weil der Besucher dies i. d. R. nicht einmal erkennt, wenn er die Datenschutzhinweise (vor allem ab Tag 8) erneut besucht. In den meisten Fällen passiert nach einem Klick auf den Opt Out Link aus Sicht des Besuchers nichts... oder es wird bestenfalls eine Meldung ausgegeben, dass man nun aus dem Tracking ausgestiegen ist. Eine "Statuskontrolle" ist aber üblicherweise nicht vorhanden.

Ist das ein DSGVO-Verstoß?

Keine Ahnung. Ich bin kein Anwalt. So oder so wird aber vermutlich ein (Opt Out-) Versprechen im begleitenden Text des Links gegeben, das für einen Teil der Besucher nicht eingelöst werden kann. Wer also einen Opt Out Link anbietet und nicht handelt, sollte sich dieser Lücke zumindest bewusst sein. Und vermutlich auch versuchen, sie zu schließen.

Was tun? Optionen zur Korrektur des Opt Out

Wird der Link durch einen Dienst oder ein WordPress-Plugin o. Ä. erzeugt, so dass man selbst keinen Einfluss auf die Funktion und Methode des Opt Out hat, sollte man sich beim jeweiligen Hersteller nach Updates mit evtl. Lösungen erkundigen. Hat man die Gestaltung des Opt Out selbst in der Hand, kann und sollte man auch aktiv eine Lösung erarbeiten.

Wie auch für das eigentliche Tracking und die Rettung der Client ID kann unter den schon genannten Bedingungen (wie z. B. nur ein Host und Protokoll) das Ausweichen auf localStorage ein Weg sein. Im einem Zusatz zum oben exemplarisch verlinkten Beitrags werden die Unterschiede zur reinen Cookie-Lösung aufgezeigt. Passend zur bestehenden Anleitung wird das erweiterte Prinzip in einem Updateartikel zum Opt Out gezeigt.

Oder man setzt auf serverseitig erzeugte Cookies, für die dieses 7 Tage Fenster nicht gilt, wie es im Prinzip auch die "Upgrade"-Variante für Analytics selbst praktiziert. Dazu passt man den Opt Out Link so an, dass er nicht mehr ein JavaScript zum Setzen des Cookies ausführt, sondern eine Seite aufruft, die sich um das Setzen des Cookies kümmert. Danach kann die Datenschutzseite einfach erneut aufgerufen werden oder die Seite gibt selbst eine Bestätigung / Rückmeldung aus. Das kann mit wenigen Zeilen in PHP - oder was auch immer zum eigenen Server passt - erledigt werden. Als ganz einfaches Beispiel reicht im Prinzip dieser Code, der als PHP-Datei auf dem eigenen Server abgelegt und per Opt Out Link aufgerufen werden kann:

<?php
$property = "UA-xxxxxx-y"; //eigene ID hier eintragen
$domain = ""; //leer lassen oder z. B. mit ".domainname.de" belegen, wenn mehrere Hosts / Subdomains im Spiel sind
setcookie("ga-disable-$property", "true", time()+60*60*24*365*100, "/", $domain);
echo "Opt Out Cookie wurde gesetzt";
?>

Wird ein Cookie auf diese Weise serverseitig generiert (bzw. erneuert) wird er nicht von ITP 2.1 betroffen. Peter Nikolow hat dies ausführlich getestet in einem Blogpost protokolliert.

Tipp: Wer ohnehin für Analytics auf das "Upgrade" der Cookies setzt und einen entsprechenden Helper auf dem eigenen Server bereitstellt, der bei jedem Seitenaufruf genutzt wird, der kann auch gleich den Opt Out Cookie "mitbehandeln". So muss man keine weiteren Schritte durchführen, solange sicher gestellt ist, dass nach dem Setzen eines Opt Out Cookies direkt dieser (oder ein für diesen Keks separat erstellter) Helper aufgerufen wird. Vorteil: Alles andere kann bleiben, wie es ist, der Cookie-Wert ist gegen ITP 2.1 durch das unmittelbare Upgrade des Cookies geschützt.

Während eine serverseitige Lösung für das Tracking einer kompletten Website per CMS oder Anpassung der Serverkonfiguration ggf. eine Herausforderung in der Implementierung darstellt, ist der Aufwand im Fall des Opt Out durchaus überschaubar, so dass diese Lösung in vielen Fällen sogar zu bevorzugen ist, selbst wenn localStorage nutzbar ist. Gestaltet man die Rückmeldung etwas ansprechender oder verzichtet man auf das Laden der Seite und gibt eine eigene Meldung aus (was auch per JavaScript problemlos umsetzbar ist), ist damit alles erledigt und bestehende Mechanismen, die auf dem Cookie basieren, können weiter verwendet werden.

Wer keine Möglichkeit hat, die eine oder andere Variante umzusetzen, sollte vielleicht zumindest die Texte in den Datenschutzhinweisen beim Opt Out Link anpassen und auf das Problem für Safari Nutzer aufmerksam machen. Zumindest die Logik empfiehlt diesen Schritt, der für mehr Transparenz sorgt. Ob ein Anwalt das auch so sieht oder sich dadurch die Angriffsfläche für Abmahnungen ändert, sei dahingestellt (ich versuche eine Einschätzung gerade aus einigen Anwälten herauszukitzeln ;)).

Was kann man in den anderen von ITP betroffenen Systemen tun?

Je nachdem, wozu ein Cookie dient und wann darauf erstmals zugegriffen wird, kann man prinzipiell die beiden oben skizzierten Lösungswege nehmen und entweder auf serverseitige Cookies, das "Aufwerten" - und damit gegen ITP "Härten" - der Cookies oder das Speichern der Informationen an anderer Stelle wie dem localStorage zurückgreifen. Dazu muss man aber selbst aktiv werden bzw. auf Lösungen der Hersteller des eingesetzten Tools oder Systems hoffen. Nicht in allen Systemen kann man selbst Hand anlegen, wenngleich vielleicht ausreichende Kenntnisse über Funktion des Systems und dessen technologischer Basis vorhanden sind.

In anderen Fällen mag das Problem auf den zweiten Blick (einstweilen) nicht so groß sein, dass sich eine Anpassung wirklich lohnt. Am Beispiel eines A/B-Tests hat man so z. B. mehrere Optionen, wenn nicht bereits der Anbieter des Testing Tools eine "ITP-sichere" Lösung bereitstellt. Läuft ein Test nicht wesentlich länger als 7 Tage, ist das Problem, das durch unkontrolliertes Ausspielen einer anderen Version bei Safari Benutzern verursacht wird, vermutlich zu vernachlässigen. Oder man kann Safari Nutzer vom Test oder der Auswertung der Daten (oder beidem) ausschließen.

I. d. R. sollte man "selbstgestrickte" Lösungen aber generell vermeiden, denn mit jeder Anpassung wird auch eine ganze Menge an Testing in verschiedensten Browsern erforderlich. Betrifft die Anpassung wichtige Funktionen wie einen Warenkorb, spielt man bei Experimenten ggf. sogar mit dem Kern der Website. Von verlorener Updatefähigkeit der ggf eingekauften und aus gutem Grund laufend extern gepflegten Scripts und Plugins ganz abgesehen. Folgerichtig ist nach einer Analyse des Impact von ITP 2.1 stets der Kontakt zum Hersteller der richtige erste Schritt und alle Workarounds wie diejenigen, die oben für Analytics vorgestellt wurden, können immer nur ein letzter Ausweg sein.

Hängt die Funktion - wie im Fall von Conversion-Tracking für Google Ads, Google Optimize oder in Zukunft auch anderer Dienste - an einer Variante von Googles gtag.js, kann die oben für Analytics vorgestellte Lösung ggf. adaptiert werden. Allerdings wird dies nur im Zusammenspiel mit Analytics via gtag,js funktionieren, denn der vorgestellte Code kann nicht beliebig "umgestellt" werden, ohne z. B, die Funktion zum Speichern der Client ID im localStorage zu verlieren. Es kann also sein, dass hier jeweils individuelle Alternativen erarbeitet werden müssen. Sorry! Glücklicherweise ist zu erwarten, dass das Interesse der Anbieter wie Google, Bing & Co. so groß ist, dass es entsprechende Lösungsansätze von dort geben wird. Der Conversion-Linker, der im Google Tag Manager hinzugekommen ist, ist ein gutes Beispiel, das schon durch frühere ITP-Versionen erforderlich wurde.
Wie geht es weiter?

So oder so wird uns ITP weiterhin beschäftigen und der jetzt erreichte Stand ist noch nicht das Ende der Fahnenstange. Worauf müssen wir uns vorbereiten?

  • 2.1 ist nicht die letzte Versionsnummer. Von 1.0 bis 2.1 hat sich die Schlinge stets enger gezogen. Zeitfenster sind kleiner und Funktionalität aggressiver geworden. Dieser Trend wird weitergehen. Daher sind auch die o. a. Lösungswege nicht für die Ewigkeit gedacht - im Fall der gtag.js Lösung ist die Lebensfähigkeit sogar an die Entwicklung des dahinter liegenden Trackings gebunden (siehe Hinweise zu den Scripts oben).
  • Nicht nur Safari. Auch Firefox zieht im Herbst mit einer eigenen Lösung nach, die (erst einmal) nur auf Drittpartei Cookies abzielt. Möglicherweise wird man sich aber an Safari orientieren und ebenso clientseitige First Party Cookies auf 7 Tage beschränken. Das ist aber bestimmt auch dort nicht der letzte Schritt... und nicht der letzte betroffene Browser. Selbst wenn Chrome vielleicht der letzte sein wird: "Trackingschutz" wird kurz oder lang zum Standardfeature werden.
  • Jeder Browser macht potentiell andere Dinge oder die gleichen Dinge auf anderem Weg. Allen Hindernissen mit eigenen Mitteln entgegenwirken zu wollen, bedeutet daher auch, laufend auf der eigenen Seite nachzubessern, wenn die Hersteller vorlegen. Das ist ein Kampf, den man nicht unbedingt gewinnen - oder unter wirtschaftlichen Aspekten betrachtet lange führen - kann.
  • Anbieter werden reagieren. Spätestens, wenn das potentielle Problem groß genug ist. Wie oben schon erwähnt, ist das Conversion-Linker Tag aus dem GTM ein gutes Beispiel. Andere Anbieter und Lösungen müssen entsprechend folgen.
  • Im Zweifelsfall erscheint das hausgemachte Upgrade von Cookies auf serverseitg erzeugte Varianten derzeit die vielseitigste Option. Wenn man aber viele Cookies damit beglücken muss, wird auch das irgendwann eine komplexe Aufgabe.
  • Die ePrivacy-Verordnung wird uns auch noch einmal dazu zwingen, alles zu überdenken und ggf. zu ersetzen, was jetzt mit Cookies zu tun hat - wer weiß?

Der Krieg zwischen Browsern und Tracking aller Art hat schon lange begonnen... mit ITP 2.1 trifft es nun erstmals auch Opfer, die vermutlich nicht das Ziel des Angriffs waren. Krieg ist halt scheiße. Leidtragende sind die vielen Systeme, die nichts mit domainübergreifender Profilbildung zu tun haben und bisher gut mit First Party Cookies leben konnten. Diese Zeiten werden nicht mehr zurückkommen - halten wir also weiter die Augen offen und passen uns an neue Rahmenbedingungen an. Im Grunde auch nichts Neues, nur eine weitere Baustelle, die nie fertig werden wird. Das kennen wir schon. Also: bleibt BER-eit 😉

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