ITP und Tracking-Prevention: was Safari blockiert

Worum es geht, und was ITP ist

Die meisten Tracking-Probleme, über die Shops klagen, fangen nicht in der Werbeplattform an, sondern im Browser des Nutzers. ITP, Intelligent Tracking Prevention, ist die Funktion in Safari, die genau dort ansetzt. Apple hat sie 2017 eingeführt und seitdem in mehreren Schritten verschärft. Ihr erklärtes Ziel ist, das Wiedererkennen von Nutzern über verschiedene Seiten hinweg zu erschweren. Sie tut das, indem sie Cookies in ihrer Lebensdauer begrenzt und Cross-Site-Tracking weitgehend unterbindet, und zwar bevor irgendein Tag, irgendeine Plattform oder irgendein Server deine Daten zu Gesicht bekommt.

Wichtig ist die Ebene, auf der das passiert. Consent-Banner, Plattform-Einstellungen und serverseitige Logik kommen alle erst danach. ITP wirkt eine Stufe früher, im Browser selbst, und entzieht sich damit dem Zugriff der üblichen Tracking-Schicht. Ob ein Nutzer eingewilligt hat oder nicht, ändert an dieser technischen Begrenzung zunächst nichts: ITP kürzt Cookies unabhängig vom Consent. Das macht es zu einem eigenen Problem neben dem fehlenden Einverständnis, nicht zu einem Teil davon.

Firefox verfolgt mit Enhanced Tracking Protection, kurz ETP, dieselbe Stoßrichtung mit anderen Mitteln. Beide zusammen decken einen Teil des DACH-Traffics ab, der zu groß ist, um ihn als Rundungsfehler zu behandeln. Wer Safari- und Firefox-Nutzer einfach unterzählt, verzerrt jede Auswertung, die auf vollständiger Wiedererkennung beruht. Dieser Artikel konzentriert sich auf den Browser-Mechanismus selbst, also darauf, wie ITP technisch funktioniert. Die App-Seite von Apples Tracking-Restriktionen, etwa die App-Tracking- Transparency, ist ein anderes Thema und hat einen eigenen Artikel.

Zurück zum Überblick: Cookieless Tracking, der Leitfaden. Im Glossar: ITP, Third-Party-Cookie. Die App-Seite getrennt davon: iOS-Tracking-Restriktionen.

Wie ITP technisch wirkt

ITP ist kein einzelner Schalter, sondern ein Bündel von Regeln, das über die Jahre gewachsen ist. Drei davon bestimmen, was für deine Messung übrig bleibt: das Aus für Drittanbieter-Cookies, die harte Kürzung clientseitig gesetzter First-Party-Cookies und das Beschneiden bestimmter URL-Parameter.

Drittanbieter-Cookies werden blockiert

Cookies, die unter einer anderen Domain als der besuchten gesetzt werden, akzeptiert Safari unter ITP gar nicht mehr. Das betrifft den klassischen Werbe-Pixel, der per eingebettetem Skript einer Drittanbieter-Domain eine wiedererkennbare ID hinterlegt. Ohne diesen Topf gibt es kein seitenübergreifendes Wiedererkennen über den klassischen Weg. Genau das war die Absicht, und genau das ist auch der Mechanismus, den Chrome mit der Abschaffung der Third-Party-Cookies nachzieht. Safari war hier nur Jahre früher dran.

First-Party-Cookies aus dem Skript werden gekürzt

Der folgenreichste Teil betrifft First-Party-Cookies, also Cookies der besuchten Domain selbst. Entscheidend ist, wie sie gesetzt werden. Setzt ein JavaScript im Browser das Cookie, etwa über document.cookie, begrenzt Safari dessen Lebensdauer auf wenige Tage, in der schärfsten Ausprägung auf sieben Tage, unter bestimmten Bedingungen auf einen Tag. Das ursprünglich vom Skript vorgesehene Ablaufdatum, oft viele Monate, wird dabei ignoriert. Da viele Analytics- und Werbe-Tags ihre Wiedererkennungs-ID genau so setzen, verfällt diese ID nach wenigen Tagen, obwohl sie als First-Party gilt.

Cookies, die der Server selbst per HTTP-Header setzt, fallen nicht unter diese kurze Skript-Grenze. Das ist die Bruchlinie, an der später das Gegensteuern ansetzt: nicht First- gegen Third-Party allein, sondern serverseitig gegen clientseitig gesetzt.

URL-Parameter werden teils beschnitten

Als Reaktion auf Versuche, die Cookie-Kürzung über IDs im Link zu umgehen, geht ITP auch gegen bestimmte Tracking-Parameter in URLs vor. Decoration-Parameter, mit denen eine ID von einer Seite zur nächsten gereicht wird, können entfernt oder entwertet werden. Für die Praxis heißt das: Workarounds, die eine Kennung einfach an den Link hängen, sind keine verlässliche Brücke, weil Safari diesen Weg ebenfalls im Blick hat.

Die Summe dieser Regeln trifft vor allem die Attributionsfenster. Ein Wiederkehr-Fenster von 30 oder 60 Tagen setzt voraus, dass die Kennung des Nutzers so lange überlebt. Wenn das tragende Cookie nach sieben Tagen verfällt, kann ein Fenster, das länger ist, technisch gar nicht mehr greifen. Die nominale Einstellung im Werbekonto bleibt stehen, die tatsächlich messbare Spanne unter Safari schrumpft auf die Cookie-Lebensdauer.

Im Glossar: Server-Side Tracking, Third-Party-Cookie. Der Unterschied im Detail: First-Party- vs. Third-Party-Cookies.

Was das fürs Tracking kostet

Auf dem Papier klingt eine Cookie-Lebensdauer von sieben Tagen harmlos. In der Auswertung richtet sie konkreten Schaden an, und zwar an mehreren Stellen gleichzeitig. Der gemeinsame Nenner: Sobald die Wiedererkennung früher abreißt als die echte Customer Journey dauert, zerfällt die Messung in Bruchstücke.

Am offensichtlichsten brechen längere Journeys auseinander. Klickt jemand am Montag über eine Anzeige, recherchiert eine Woche und kauft am Dienstag darauf, ist das tragende Cookie unter Umständen schon verfallen. Der Kauf wird dann nicht mehr dem ursprünglichen Klick zugeordnet, sondern erscheint als direkter, herkunftsloser Besuch. Die Anzeige, die den Kauf angestoßen hat, sieht im Report schlechter aus, als sie war.

Eng damit verbunden ist ein zweiter Effekt: Wiederkehrende Nutzer sehen aus wie neue. Ist die Kennung weg, erkennt das Tracking den Nutzer beim nächsten Besuch nicht wieder und legt ihn als neuen Besucher an. Das bläht die Zahl der vermeintlichen Neukunden auf, verfälscht die Wiederkehr-Raten und macht jede Aussage über Kundenbindung unsicher, weil dieselbe Person mehrfach als verschiedene Personen zählt.

Drittens kollabieren die Attributionsfenster, wie im letzten Abschnitt beschrieben. Ein im Werbekonto eingestelltes 30-Tage-Fenster ist für Safari-Nutzer effektiv ein Sieben-Tage-Fenster, ohne dass das irgendwo angezeigt würde. Kanäle, die typischerweise früh in der Journey wirken und deren Wirkung sich erst Wochen später im Kauf zeigt, werden dadurch systematisch unterbewertet.

Der vierte Punkt ist der unangenehmste, weil er die Verzerrung schief macht: Safari-lastige Zielgruppen werden untermessen. Apple-Geräte verteilen sich nicht gleichmäßig über alle Zielgruppen. Bestimmte Segmente, oft kaufkräftigere oder mobil-affine, nutzen Safari überdurchschnittlich. Wer deren Conversions schlechter misst, unterschätzt nicht nur den Gesamtwert, sondern verschiebt die Bewertung zwischen Kampagnen und Zielgruppen. Eine Kampagne, die zufällig viele Safari-Nutzer erreicht, sieht schwächer aus, als sie ist, und bekommt zu wenig Budget. Das ist kein gleichmäßiges Rauschen, das sich herausmittelt, es ist eine Verzerrung mit Richtung.

Woher Datenverlust insgesamt kommt und wie du ihn schließt: Datenverlust im Tracking. Im Glossar: ITP.

Gegensteuern: First-Party und Server-Side

Die gute Nachricht ist, dass der größte Hebel kein Trick ist, sondern eine saubere Architektur. ITP kürzt Skript-Cookies, nicht serverseitig gesetzte Cookies. Genau diese Lücke nutzt man, indem man die Wiedererkennung dorthin verlagert, wo sie länger überlebt.

Cookies serverseitig per HTTP-Header setzen

Der wirksamste einzelne Schritt: Lass die Cookies, die deine Wiedererkennung tragen, nicht mehr von einem JavaScript im Browser setzen, sondern vom Server per HTTP-Header. Solche Cookies fallen nicht unter die kurze Sieben-Tage-Grenze, die ITP clientseitig gesetzten Cookies aufzwingt. Die Kennung überlebt dadurch unter Safari deutlich länger, und längere Journeys bleiben messbar. Das ist kein Umgehen der Regel, sondern eine andere, von Safari bewusst anders behandelte Setzmethode.

Eine eigene First-Party-Domain als Endpunkt

Damit die Daten als First-Party-Kontext gelten und nicht als Drittanbieter, läuft das Tracking über eine eigene Subdomain deiner Hauptdomain, etwa einen Endpunkt unter deiner Domain statt unter der eines Drittanbieters. Aus Sicht des Browsers ist der Datenfluss dann Teil derselben Seite, nicht ein fremder Tracker. In Verbindung mit dem serverseitig gesetzten Cookie ist das die Kombination, die unter ITP am verlässlichsten trägt.

Modellierte Conversions für den Rest

Ein Teil der Conversions fällt trotzdem aus der direkten Messung, etwa weil das echte Fenster länger ist als jede zumutbare Cookie-Lebensdauer oder weil gar keine Einwilligung vorlag. Für diesen Rest bleibt modellierte Ergänzung: Aus den gemessenen Fällen wird der nicht gemessene Anteil statistisch hochgerechnet. Das ist keine exakte Zuordnung, sondern eine begründete Schätzung, und sie ist nur so gut wie die Datenbasis, auf der sie aufsetzt.

Bei aller Wirkung gehört die ehrliche Einordnung dazu: First-Party und Server-Side reduzieren den ITP-Verlust deutlich, sie heben ihn nicht auf. Die Cross-Site-Beschränkungen selbst bleiben bestehen, und ohne Consent darfst du ohnehin nicht setzen. Wer dir verspricht, ITP komplett auszuhebeln, verkauft entweder eine Illusion oder etwas, das auf Dauer nicht regelkonform ist. Realistisch ist, den messbaren Anteil von einem schlechten auf ein gutes Niveau zu heben und den Rest sauber zu modellieren.

Wie das Fundament aussieht: Server-Side Tracking. Im Produkt: First-Party-Domain. Im Glossar: Server-Side Tracking.

ITP, ETP und die größere Cookieless-Bewegung

ITP wirkt wie ein Safari-Sonderfall, ist aber das frühe Glied einer Kette. Was Apple 2017 begonnen hat, zieht sich inzwischen durch alle großen Browser. Firefox unterbindet Cross-Site-Tracking mit Enhanced Tracking Protection, und auch Chrome bewegt sich, wenn auch langsamer und mit Umwegen, weg vom Drittanbieter-Cookie. Die Richtung ist dieselbe: weniger seitenübergreifende Wiedererkennung, mehr Kontrolle im Browser.

Firefox kommt dabei über einen anderen Weg ans gleiche Ziel. Statt primär an Cookie-Lebensdauern zu drehen, arbeitet ETP stark mit Blocklisten bekannter Tracker und mit einer Partitionierung des Speichers: Drittanbieter-Inhalte bekommen pro besuchter Seite einen eigenen, getrennten Cookie-Topf und können dadurch nicht mehr seitenübergreifend wiedererkennen. Der Mechanismus unterscheidet sich von ITP, die Wirkung auf deine Messung ist im Kern dieselbe. Für die Praxis bedeutet das: Du baust nicht gegen eine einzelne Browser-Eigenheit, sondern gegen einen breiten, dauerhaften Trend.

Daraus folgt die eigentliche Konsequenz. Es lohnt sich nicht, ITP als isoliertes Hindernis zu bekämpfen, das man mit dem nächsten Workaround wieder umgeht. Jeder Trick, der eine Browser-Schutzfunktion austrickst, wird im nächsten Update kassiert. Tragfähig ist nur, das Tracking von vornherein für eine Welt mit kurzen oder fehlenden Cookies zu bauen: auf First-Party-Daten, serverseitige Verarbeitung und einen ehrlichen Umgang mit Modellierung für das, was nicht direkt messbar ist. Das ist anstrengender als ein schneller Hack, aber es hält.

Die Grundlagen daneben: First-Party- vs. Third-Party-Cookies und Datenverlust im Tracking. Die App-Seite des Themas: iOS-Tracking-Restriktionen.