Geschrieben von

Intelligent Tracking Prevention (ITP)

Analytics

Apple rüstet seinen Safari-Browser mit einem Feature namens Intelligent Tracking Prevention (ITP) auf. Bei diesem Feature handelt es sich um eine WebKit-Funktion, die seitenübergreifendes Tracking verhindern soll.

Das Wichtigste zuerst: Cookies

Um zu verstehen, wieso Apple seitenübergreifendes Tracking mit ITP verhindern will, muss zunächst das Konzept von Cookies verstanden werden. Insbesondere wichtig ist das Verständnis für:

  • Cookies Allgemein
  • First-Party-Cookies
  • Third-Party-Cookies

Cookies Allgemein

In meinem Artikel „Wie Webseiten geladen werden“ bin ich auf das HTTP-Protokoll kurz eingegangen. Dort beschrieb ich unter anderem:

Beim HTTP-Protokoll ist es noch wichtig zu wissen, dass dieses zustandlos ist. Heißt konkret: Mehrere Anfragen von einem Nutzer werden unabhängig voneinander betrachtet. Besucht ein Nutzer eine Webseite und bekommt vom Server eine Antwort, hat der Server den Nutzer bei der nächste Anfrage wieder „vergessen“. Es werden also keine Informationen abgespeichert, damit z.B. der Browser weiß, dass der Nutzer bestimmte Einstellungen auf der Webseite vorgenommen hat (z.B. Login-Status). Diese Aufgabe übernehmen Cookies.

Was ist also ein Cookie? Ein Cookie speichert Informationen über Nutzer in eine separate Textdatei. In der Regel werden diese Dateien in einem Ordner des Browsers gespeichert (Client-seitig). Cookies können aus unterschiedlichen Gründen notwendig sein:

  • Funktionsweise bzw. UX von Webseiten sicherstellen: Loggt man sich auf einer Webseite ein und verlässt diese, stellen Cookies beim nächsten Besuch sicher, dass man weiter eingeloggt bleibt. Oder im E-Commerce: Innerhalb einer Sitzung sorgen Cookies dafür, dass in den Warenkorb abgelegte Produkte erhalten bleiben, solange man auf der Webseite surft.
  • Tracking: Google Analytics und andere Webanalyse-Dienste benutzen ebenfalls Cookies, um das Nutzerverhalten zu analysieren.
  • Werbung: Im Werbebereich werden Cookies eingesetzt, um den Nutzer über mehrere Webseiten hinweg zu „verfolgen“ und dadurch personalisierte Werbung (z.B. Banner) auszuspielen.

Wie man sieht kann man Cookies anhand der Anwendungsgebiete unterteilen. Cookies können jedoch auch nach ihrer Zeitdauer (Persistent- und Permanent-Cookies) oder nach der zugeordneten Domain unterschieden werden: First- und Third-Party-Cookie. „Party“ bezieht sich dabei auf die Domain, die den Cookie setzt.

First-Party-Cookies

Hierbei handelt es sich um Cookies, die durch die Webseite gesetzt werden, auf die der Nutzer gerade surft. Der Nutzer kann hier nur von der Webseite erkannt werden, von der aus der Cookie gesetzt worden ist. Die oben 2 genannten Cookie-Arten „Funktionsweise bzw. UX von Webseiten sicherstellen“ und „Tracking“ sind z.B. First-Party-Cookies. Google Analytics setzt First-Party-Cookies ein (dazu später mehr). Standardmäßig blockieren Browser keine First-Party-Cookies. Nutzer können jedoch diese Cookies selbstständig löschen.

Third-Party-Cookies

Hierbei handelt es sich um Cookies, die nicht durch die Webseite gesetzt werden, auf die der Nutzer gerade surft. Diese kommen bei Werbenetzwerken meist zum Einsatz. Besucht der Nutzer eine Webseite mit Werbung werden im Hintergrund Ressourcen (HTTP-Anfragen) des Ad-Servers geladen und dabei ein Cookie gesetzt. Besucht der Nutzer eine andere Webseite, wo der selbe Werbetreibende Werbung schaltet und Cookies setzt, kann dieser den Nutzer wiedererkennen (obwohl der Nutzer die Domain des Ad-Servers nie besucht hat). Durch das Verfolgen des Nutzers über mehrere Domains hinweg, kann ein Interessensprofil des Nutzers erstellt werden. Auf dieser Basis kann dann wiederum gezielt Werbung ausgespielt und für Retaregting und Remarketing genutzt werden. Diese Technik nennt sich auch Cross-Site-Tracking. Das Google Ads Conversion Tracking, Criteo und Doubleclick setzen bspw. Third-Party-Cookies ein (dazu später mehr).

Die Hintergründe zur Intelligent Tracking Prevention

Da Third-Party-Cookies primär für Werbezwecke eingesetzt werden, blocken diese einige Browser standardmäßig. So hat Safari noch vor der Intelligent Tracking Prevention Third-Party-Cookies blockiert. First-Party-Cookies galten dabei als „sicher“. Das Problem, welches mittlerweile stattfindet: Auch First-Party-Cookies werden so eingesetzt , dass sie den Nutzer genauso tracken wie Third-Party-Cookies. Um zu verdeutlichen, wie das genau funktioniert schauen wir uns folgendes Szenario an:

  1. Nutzer besucht example.com und es wird ein Cookie von dieser Domain gesetzt (First-Party)
  2. Nutzer klickt auf einen Werbebanner
  3. Nutzer wird auf die Domain example-adserver.com des AdServers geleitet
  4. example-adserver.com setzt einen First-Party-Cookie
  5. Nutzer wird weiter auf die eigentliche Zielseite geleitet

Die Weiterleitung von example-adserver.com auf die eigentliche Zielseite des Werbebanners geschieht sehr schnell, sodass dies kaum gemerkt wird. Diese Zeit reicht jedoch aus, dass example-adserver.com einen First-Party-Cookie setzen kann. Wir erinnern uns: First-Party-Cookies sind Cookies, die durch die Webseite gesetzt werden, auf die der Nutzer gerade surft. Das heißt nun: Der Nutzer kann – trotz des Blockens von Third-Party-Cookies – auf anderen Internetseiten verfolgt werden, da First-Party-Cookies gesetzt werden, die der Browser ja nicht blockiert. Im Umkehrschluss bedeutet dies, dass First-Party-Cookies eingesetzt werden, sich jedoch eher wie Third-Party-Cookies verhalten. Und genau dagegen will Apple mit der Intelligent Tracking Prevention vorgehen. Ziel ist es domainübergreifendes Tracking zu unterbinden.

Im Folgenden benutze ich den Begriff „First-Party-Tracker“ für First-Party-Cookies, die den Nutzer wie Third-Party-Cookies „verfolgen“.

Wie funktioniert Intelligent Tracking Prevention (ITP) grundsätzlich?

ITP geht in 3 Phasen vor:

  1. Datensammlung: Zunächst werden Statistikdaten gesammelt, welche Ressourcen eine Webseite lädt und auch Nutzeraktivitäten wie das Aufrufen einer Seite oder das Anklicken auf bestimmte Webseiten-Elemente (passiert auf dem Endgerät des Nutzers).
  2. Machine Learning Classifier: Auf Basis der Statistikdaten ermittelt ein Maschinenlernmodell, welche Domains einen Nutzer seitenübergreifend verfolgen und damit tracken (passiert auf dem Endgerät des Nutzers).
  3. Tracking-Anpassung: Im letzten Schritt wird ermittelt, welches Tracking verwendet werden darf und es werden ggf. Cookies blockiert.

ITP-Versionen

Bisher wurden verschiedene Versionen von ITP veröffentlicht, die immer wieder weiterentwickelt worden sind. Von der Grundfunktionalität (siehe oben) hat sich nicht viel verändert. Es kamen jedoch Weiterentwicklungen hinzu. Nachfolgend gehe ich auf die verschiedenen Versionen und Updates ein:

Intelligent Tracking Prevention 1.0

Zusammengefasst kam die erste Version mit folgenden Funktionen:

  • First-Party-Tracker wurden erlaubt solange der Nutzer die Webseite, die diesen Tracker-Cookie setzt, innerhalb von 24 Stunden aktiv nach dem Klick auf den Banner/die Werbung besucht. Dies ist jedoch sehr unwahrscheinlich, da die Domains von Ad-Servern von Nutzern kaum aktiv besucht werden. Ausnahmen sind Webseiten wie Google, Facebook, Amazon, etc. die grundsätzlich von Nutzern sehr häufig aufgerufen werden.
  • Besucht der Nutzer die Webseite des Ad-Server-Anbieters nach dem Klick auf den Banner nicht innerhalb von 24 Stunden, kann man den Nutzer mittels diesem Cookie nicht mehr tracken. Dadurch kann gezielte Werbung über mehrere Webseiten hinweg und Retargeting nicht mehr umgesetzt werden.
  • Besucht der Nutzer die Webseite des Ad-Server-Anbieters innerhalb von 30 Tagen nicht, wird der Cookie gelöscht.
  • Partitionierte Cookies: Wenn der Nutzer die Webseite in den letzten 30 Tagen – aber nicht in den letzten 24 Stunden – aufgerufen hat, werden die Cookies partitioniert, sprich in mehrere Dateien aufgeteilt. Diese können dann nicht mehr in einem Third-Party-Kontext genutzt werden. Dadurch wird sichergestellt, dass Nutzer, die eine Webseite nur selten besuchen weiterhin eingeloggt bleiben (durch die 1. Cookie-Partition = First-Party-Kontext), gleichzeitig aber die Tracking-Möglichkeiten eingeschränkt bleiben (durch die 2. Cookie-Partition = Third-Party-Kontext).

Da das Google Ads Conversion-Tracking mit Third-Party-Cookies arbeitet, ist es notwendig hier Gegenmaßnahmen zu ergreifen, damit die Conversion-Erfassung weiterhin läuft. Was kann man dagegen tun?:

  • Wenn Google Analytics und Google Ads miteinander verknüpft sind, muss nichts weiter getan werden. Wichtig ist nur, dass „Autotagging“ in Google Ads aktiviert ist. Da Google Analytics First-Party ist, werden hier die Daten mit Google Ads automatisch geteilt.
  • Wenn Google Tag Manager und das Google Ads Conversion-Tracking-Tag im Einsatz sind, dann muss noch das Conversion-Linker-Tag im Google Tag Manager aktiviert werden.

Wenn man nichts unternimmt, dann ist ein Conversion-Tracking mit Google Ads nur innerhalb des 24-Stunden-Zeitfensters möglich.

Storage Access API

Mit der ersten Version von ITP hatten vor allem Social Media Dienste zu kämpfen. Sind von einem Social Media Dienst Funktionen wie Liken, Sharen oder Kommentieren auf einer Webseite eingebettet, wurde von ITP erkannt, dass dies ein Cross-Site-Tracking ermöglicht. Dadurch wurde der Zugriff auf Cookies blockiert. Selbst wenn der Nutzer beim Social Media Dienst eingeloggt war, konnten die Funktionen wie Liken, Sharen und Kommentieren nicht auf den Webseiten direkt genutzt werden. Ausnahme: Der Nutzer hat in den letzten 24 Stunden aktiv mit der Social Media Webseite interagiert. Das Gleiche gilt für Zahlungsdienste und Video-Inhalte. ITP behandelt den Nutzer als Abgemeldet, obwohl dieser angemeldet ist.

Mit der Storage Access API geht ITP einen Kompromiss ein. Nutzer, die nicht in den letzten 24 Stunden mit der Social Media Webseite interagiert haben, können dennoch die Social Media Funktionen auf den betroffenen Webseiten nutzen bei gleichzeitigem Schutz der Privatsphäre. Die Cookies werden jedoch gelöscht, wenn der Nutzer mit dem Facebook-Widget oder mit facebook.com nicht innerhalb von 30 Tagen interagiert hat. Wie das technisch funktioniert, kann hier nachgelesen werden: https://webkit.org/blog/8124/introducing-storage-access-api/.

Technisch gesehen konnte man durch die Storage Access API auf den Teil der partitionierten Cookies zugreifen, die eigentlich in einem Third-Party-Kontext waren.

Intelligent Tracking Prevention 1.1

Die Hauptänderung von ITP 1.1 bezog sich auf die Nutzung der Storage Access API. Die partitionierten Cookies, die zur Aufrechterhaltung des Login-Status benutzt wurden, wurden zu Session Cookies. Sobald das Browserfenster geschlossen wurde, wurden auch die Cookies gelöscht.

Intelligent Tracking Prevention 2.0

Version 2.0 hatte folgende Funktionen und Updates:

  • Das 24-Stunden-Zeitfenster wurde abgeschafft.
  • Nutzer können nur noch getrackt werden, wenn diese über die Storage Access API eine Einwilligung (durch ein Consent-Popup, welches aufpoppt) geben.
  • Das Löschen von Cookies wird von der Storage Access API gesteuert, die 30-Tage-Frist gilt aber weiterhin.
  • Version 2.0 erkennt Webseiten, die nur weiterleiten und dazu gedacht sind First-Party-Tracker zu setzen. Diese werden dann blockiert.

Intelligent Tracking Prevention 2.1

Mit Version 2.1 geht ITP nicht nur gegen First-Party-Tracker im Third-Party-Kontext vor, sondern auch gegen First-Party-Cookies, die Client-seitig per JavaScript gesetzt werden (mit document.cookie). In Zukunft erlaubt Safari eine Cookie-Laufzeit von nur 7 Tagen bei document.write gesetzten Cookies. Google Analytics nutzt document.write, um ein Cookie im Browser zu setzen.

Standardmäßig läuft das _ga-Cookie (Google Analytics Cookie) 2 Jahre. Mit Safari 12.1 werden Nutzer, die die Seite nicht innerhalb von 7 Tagen wieder besuchen, nicht mehr wiedererkannt. Für diese Nutzer vergibt Google Analytics eine neue Client-ID. Die Nutzer werden dadurch als neue Nutzer – und nicht wie bisher als wiederkehrende Nutzer – behandelt. Das betrifft nicht nur Google Analytics, sondern alle Webanalyse-Tools, die Cookies mit document.cookie setzen. Hintergrund ist, dass seit der Einführung von ITP viele Drittanbieter auf First-Party-Cookies gewechselt haben.

Link Click Analytics and Privacy

Unter dem Titel „Link Click Analytics and Privacy“ veröffentlichte Apple den Umgang mit dem Tracken von Link-Klicks. Im Beitrag wird erklärt, dass Link-Klick-Analysen grundsätzlich wie folgt möglich seien:

  • Synchrones XHR (XMLHttpRequest)
  • Asynchrones XHR oder Abrufen mit Verzögerung
  • First-Party-Bounce-Tracking
  • Beacon-API
  • Ping-Attribut

ITP unterscheidet hier zwischen Link-Klick-Tracking im Allgemeinen und Link-Klick-Tracking von Drittanbietern. Letztere werden blockiert. Dabei werden Referrer-Header herabgestuft, sofern die Anfragen an eine Drittanbieter-Domainer geht (inkl. Cross-Domain-Tracking-Charakter). Apple nennt auch, dass Nutzer „Content-Blocker“ installieren können, die ebenfalls Link-Klick-Tracker blockieren. Dies kann jedoch dazu führen, dass auf besuchten Websites Anzeigen oder Widgets (von Drittanbietern) nicht angezeigt werden.

Intelligent Tracking Prevention 2.2

ITP 2.2 verkürzt das 7-Tage-Fenster auf 24 Stunden. Betroffen sind persistente First Party-Cookies, die mittels Link-Dekoration als Workaround arbeiten, um den Nutzer zu tracken. Bei Link-Dekoration kann man Informationen an die URL dranhängen, um diese dann der Zielseite weiterzugeben. Beispiel: UTM-Parameter. Dadurch könnten Unternehmen Informationen an andere Webseiten weitergeben, was Apple unterbinden möchte.

Privacy Preserving Ad Click Attribution For the Web

Am 22. Mai 2019 kamen unter dem Namen „Privacy Preserving Ad Click Attribution For the Web“ weitere Updates:

  • Der Anzeigenklick eines Nutzer sollte nicht mehr mit der Conversion zugeordnet werden können. Mit ITP werden nur noch max. 64 Werbekampagnen pro Website geladen werden können.
  • Drittanbieter sollen keine Informationen zu Anzeigenklicks und Conversions mehr erhalten.
  • Browser-Anbieter sollen keine Informationen zu Anzeigenklicks und Conversions mehr erhalten.
  • Der Browser soll zudem für mehr Privatsphäre garantieren (Übermittlung von Attributions-Reports nur noch über „Private Browsing Mode“, Übermittlung von Daten soll verzögert werden, etc.).

WebKit Tracking Prevention Policy

In der Richtlinie zur Webkit-Tracking-Prevention werden Arten des Trackings sowie was davon WebKit unterbinden möchte vorgestellt. Unter anderem wird genannt, dass WebKit alles unternehmen wird, verdeckte und standortübergreifendes Tracking zu unterbinden. Wenn eine Tracking-Variante nicht vollständig blockiert werden kann, so versucht WebKit dies zumindest einzuschränken. Zudem wird erwähnt, dass es keine Ausnahmen für bestimmte Parteien geben wird. Unter „Unintended Impact“ wird zudem erklärt, dass dem WebKit-Team durchaus bewusst ist, dass auch unbeabsichtigte Auswirkungen zu erwarten sind. Das vollständige Statement ist hier zu lesen.

Intelligent Tracking Prevention 2.3

In der Meldung zu ITP 2.3 folgende folgende Themen genannt:

  • Die Maßnahmen gegen Tracking mittels Link-Dekoration wurden verbessert (LocalStorage und Link-Decoration mittels Referrer-URL im Visier).
  • Aktualisierungen der Storage Access-API.
  • Der ITP-Debug-Mode wurde vorgestellt.

Alternative Lösungen

Um das 7-Tage-Zeitfenster (bzw. auch 24-Stunden-Fenster) zu umgehen, werden aktuell verschiedene Möglichkeiten diskutiert. Simo Ahava hat in seinem Blog diverse Alternativen vorgestellt.

  • localStorage: Bei gleichem Hostnamen kann localStorage eingesetzt werden, da hier Informationen nur dann ausgelesen werden können, wenn der Hostname übereinstimmt. Das ist durch die Same-Origin-Policy geregelt. Wenn z.B. nur www.demirjasarevic.com getrackt werden soll, kann localStorage eingesetzt werden. Bei Subdomains geht das nicht mehr, da hier beim Domainwechsel ein Nutzer nicht eindeutig verfolgt werden kann.
  • Server-seitige Cookies: Um die document.cookie-Einschränkung zu umgehen, kann man – wenn z.B. node.js auf dem Server läuft – ein Server-seitiges Cookies setzen.
  • Einsatz von Cloudflare Workers siehe hier: https://omr.ruhr/google-analytics-itp-2-1-prevention-http-set-cookie-snippet-182092779d40.
  • Einsatz eines Reverse Proxy
  • Server-seitiges Google Analytics

Muss man überhaupt was tun?

Eine berechtigte Frage ist, ob sich der gesamte Aufwand für eine Umstellung auf eine Alternativlösung überhaupt lohnt? Hierzu wirft man am besten einen Blick in die Google Analytics Daten, um sich einen Überblick zu verschaffen.
Google Analytics Browserbericht
Im Bericht „Browser & Betriebssystem“ unter „Zielgruppe“ -> „Technologie“ lässt sich nachvollziehen, wie viele Nutzer mit Safari auf die Webseite zugreifen. Bei den meisten Webseiten wird dies sicherlich einen großen Teil ausmachen, da die mobile Nutzung von Webseiten in den letzten Jahren deutlich zugenommen haben. Stichwort „Mobile First“.

Bei der Bewertung, ob sich eine Umstellung lohnt, muss auch bedacht werden, dass es hier darum geht, ob man Nutzer außerhalb des 7-Tage-Zeitfensters wiedererkennen will oder nicht. ITP heißt nicht, dass Safari-Nutzer durch Google Analytics nicht mehr getrackt werden.

Zudem kann es sein, dass Anbieter von Analyse-Tools wie Google, Facebook und Co. nachziehen und Lösungen liefern, sodass individuelle Anpassungen nicht notwendig sind.

Last modified: 15. Oktober 2019