Was ist ITP?

ITP ist eine Funktion von WebKit, der Engine hinter Safari auf Mac, iPhone und iPad. Sie erschien 2017 mit einem anderen Ansatz als Sperrlisten. Statt einen Katalog verbotener Domains zu pflegen, beobachtet der Browser das Verhalten jeder Domain und entscheidet selbst, welche einer Person websiteübergreifend folgen können. Die Einstufung nutzt ein statistisches Modell, das unter anderem darauf schaut, unter wie vielen verschiedenen Domains eine Ressource als Subressource auftaucht, unter wie vielen sie in einem Frame erscheint und auf wie viele verschiedene Domains sie weiterleitet. Die gesamte Berechnung läuft auf dem Gerät des Nutzers.

Daher rühren die beiden teuersten Verwechslungen. Erstens: ITP ist kein Werbeblocker. Anzeigen werden weiterhin ausgeliefert und Seiten laden weiterhin; gekürzt wird die Lebensdauer des Speichers, mit dem sich dieselbe Person bei getrennten Besuchen wiedererkennen ließe. Zweitens: ITP fragt nicht nach der Einwilligung. Es ist eine Entscheidung des Browsers, sie greift bei erteilter Erlaubnis genauso und folgt der Datenschutzrichtlinie von WebKit, nicht dem Cookie-Hinweis der Website. Wer im Banner alles akzeptiert, hat in Safari exakt dieselben Ablauffristen wie jemand, der ablehnt.

Die erste Fassung arbeitete mit zwei Zeitfenstern. Hatte der Nutzer in den letzten vierundzwanzig Stunden mit einer eingestuften Domain interagiert, blieben deren Cookies verfügbar, wenn sie als Drittanbieter auftrat. Nach dreißig Tagen ohne Interaktion wurden ihre Daten und Cookies gelöscht.

ITP 2.0 strich das Fenster von vierundzwanzig Stunden und partitionierte sofort. Hinzu kamen die Storage Access API für legitime eingebettete Sitzungen, die Erkennung von Umleitungen über Zwischendomains und die Kürzung des Referrers. ITP 2.1 begrenzte die Lebensdauer jedes über document.cookie geschriebenen persistenten Cookies auf sieben Tage und schaffte partitionierte Cookies ab. ITP 2.2 senkte diese Grenze auf einen Tag, wenn der Nutzer von einer eingestuften Domain kommt und die Zieladresse angehängte Parameter mitbringt. ITP 2.3 dehnte die Kürzung auf den übrigen per Skript beschreibbaren Speicher aus und stufte document.referrer auf die Domain der obersten Ebene plus eins herab.

2020 kamen die beiden Änderungen, die das Bild schließen. Safari blockiert standardmäßig die Cookies von Ressourcen anderer Websites, nun ohne Ausnahmen, und löscht den gesamten per Skript beschreibbaren Speicher einer Website nach sieben Tagen Browsernutzung ohne Interaktion des Nutzers auf dieser Website. Kurz darauf begann ITP, Anfragen zu erkennen, die einen Dritten über CNAME-Einträge hinter einer eigenen Subdomain verbergen, und die in diesen Antworten gesetzten Cookies auf sieben Tage zu begrenzen. WebKit fügt an dieser Stelle einen Sicherheitshinweis an: Wer eine solche Konstruktion aufsetzt, riskiert die Übernahme der Website und den Diebstahl der Cookies seiner Kunden.

Die praktische Folge ist eine einzige, und sie gehört ohne Schnörkel gesagt. In Safari bricht die Wiedererkennung über längere Zeiträume weg. Ein eigenes Cookie, das auf ein Jahr eingestellt ist, kann sieben Tage leben. Lange Kaufzyklen, Trichter mit mehreren Besuchen und Kundenwertanalysen über zwölf Monate sehen einen Abschnitt des Wegs und schreiben den Rest einem Direktbesuch oder dem zuletzt sichtbaren Kanal zu.

Dann kommt immer dieselbe Frage: Repariert serverseitiges Tracking das? Es hilft in seinem eigenen Zuständigkeitsbereich. Es gibt Kontrolle darüber, welche Daten das Haus verlassen, senkt die Abhängigkeit von Drittanbieterskripten auf der Seite und hält Netzwerkblockern besser stand. Was es nicht leistet, ist die Rückkehr der langfristigen Wiedererkennung, denn die Kürzung der Lebensdauer erfasst sowohl die aus dem Browser geschriebenen Cookies als auch jene, die über Wege kommen, deren tatsächlicher Empfänger ein Dritter ist. Eine Serverinfrastruktur als Gegenmittel zu ITP zu verkaufen verspricht genau das, was die Funktion verhindern soll.

Was die Messung tatsächlich trägt, ist etwas anderes: kürzere Auswertungsfenster, freiwillige Identifikation über eine Anmeldung mit Erlaubnis, aggregierte oder modellierte Berichte dort, wo vorher Einzelzählungen standen, und nach Browser angepasste Erwartungen an die Attribution.

• Messen Sie in kurzen Fenstern und vergleichen Sie gleichwertige Zeiträume, statt Kohorten über zwölf Monate mitzuschleppen, die in Safari nie vollständig sein werden.
• Trennen Sie die Berichte nach Browser, bevor Sie Schlüsse ziehen. Safari mit Chrome zu mischen verdeckt den Effekt und lässt ihn wie ein Kampagnenproblem aussehen.
• Geben Sie einen echten Grund für eine Anmeldung. Die freiwillige Identifikation mit Erlaubnis ist die einzige langfristig stabile Wiedererkennung.
• Nutzen Sie die Storage Access API, wenn ein eingebetteter Inhalt die Sitzung des Nutzers wirklich braucht, statt nach Speicherersatz zu suchen.
• Prüfen Sie, welche Entscheidungen an der Attribution auf den letzten Klick hängen und welche sich auf aggregierte Messung oder Experimente stützen lassen.
• Halten Sie den erwarteten Verlust je Browser fest und teilen Sie ihn mit denen, die die Berichte lesen, damit der Rückgang nicht als Implementierungsfehler gelesen wird.

• ITP als Einwilligungsthema behandeln und von der CMP eine Lösung erwarten.
• Die Leistung von Safari mit der von Chrome vergleichen, ohne den Messunterschied zu korrigieren, und dann Budget im falschen Kanal kürzen.
• Serverseitiges Tracking in der Erwartung beauftragen, es stelle die langfristige Wiedererkennung wieder her.
• Voraussetzen, dass ein eigenes Cookie so lange lebt, wie sein Ablaufdatum angibt.
• Beim Lesen eines Rückgangs Werbeblockierung mit Tracking-Prävention verwechseln.