Safari ITP und Ad-Tracking: Was noch funktioniert

Die Intelligent Tracking Prevention (ITP) von Safari begrenzt, wie lange eine Website einen wiederkehrenden Besucher erkennen kann. Sie blockiert alle Drittanbieter-Cookies und begrenzt per JavaScript gesetzte Cookies auf 7 Tage, nach manchen Anzeigenklicks auf 24 Stunden. Käufe, die serverseitig aus deinen Bestelldaten gesendet werden, Click-IDs, die beim Landen des Käufers gespeichert werden, und gehashte Kundendaten funktionieren weiterhin.

Dieser Leitfaden erklärt jede ITP-Regel so, wie WebKit sie dokumentiert, was die Regeln für Attributionsfenster und Remarketing bedeuten und welche Tracking-Methoden für einen Webshop weiterhin funktionieren. Am Ende steht eine Möglichkeit, zu prüfen, wie stark Safari deinen eigenen Shop betrifft.

Was ist Safari ITP?

Intelligent Tracking Prevention ist eine Sammlung von Datenschutzmaßnahmen in WebKit, der Browser-Engine hinter Safari auf Mac, iPhone und iPad. WebKit hat sie viele Male erweitert und dokumentiert die aktuellen Regeln auf seiner Seite Tracking Prevention.

Einige ITP-Regeln gelten für jede Website. Andere gelten nur für Domains, die ITP als fähig zum websiteübergreifenden Tracking eingestuft hat, basierend darauf, wie sich diese Domains auf den Websites verhalten, die eine Person besucht. ITP ist standardmäßig aktiv und betrifft daher jeden Safari-Besucher deines Shops, nicht nur datenschutzbewusste.

Welche Cookie-Grenzen gelten in Safari ITP?

Die 7-Tage-Grenze für Skript-Cookies

Die meisten Pixel und Analyse-Tools schreiben ihre eigenen First-Party-Cookies mit JavaScript. Das Meta-Pixel speichert zum Beispiel eine Browser-ID in einem Cookie namens _fbp. In Safari löscht ITP per JavaScript erzeugte Cookies und anderen Speicher nach 7 Tagen ohne Nutzerinteraktion auf deiner Website. WebKit definiert Nutzerinteraktion als Klick, Tippen oder Tastendruck. Scrollen zählt nicht.

In der Praxis behält ein Käufer, der innerhalb von 7 Tagen zurückkommt und deine Website nutzt, das Cookie in der Regel. Ein Käufer, der länger als 7 Tage wegbleibt, kommt ohne das Cookie zurück und wirkt wie ein neuer Besucher.

Die 24-Stunden-Grenze nach einem Link mit angehängten Parametern

Werbeplattformen hängen Click-IDs an die Links in ihren Anzeigen an. WebKit nennt das Link Decoration. Schickt eine Domain, die ITP als Tracker eingestuft hat, den Besucher auf deine Seite, und die endgültige URL hat einen Query-String oder ein Fragment, sind Cookies, die JavaScript auf dieser Landingpage schreibt, auf 24 Stunden begrenzt. Die Grenze gilt für die Seite, die über diese Navigation erreicht wurde, nicht für die gesamte Website.

Drittanbieter-Cookies

Safari blockiert standardmäßig alle Drittanbieter-Cookies, und laut WebKit gibt es bei dieser Blockierung keine Ausnahmen. Ein Drittanbieter kann Zugriff nur über Mechanismen wie die Storage Access API anfragen. Eine Werbeplattform kann ihr eigenes Cookie daher nicht innerhalb deiner Seiten lesen. Sie ist auf die First-Party-Cookies angewiesen, die ihr Pixel schreibt, und für die gelten die 7-Tage- und die 24-Stunden-Regel.

CNAME- und IP-Adress-Cloaking

Ein verbreiteter Workaround ist eine Tracking-Subdomain wie t.yourstore.com, die auf einen Tracking-Server zeigt. Cookies dieser Subdomain werden in der HTTP-Antwort gesetzt, sind also keine Skript-Cookies. WebKit behandelt die Subdomain als getarnt, wenn sie per CNAME auf eine andere Domain zeigt. Seit Safari 17 behandelt es die Subdomain auch dann als getarnt, wenn ihre IP-Adresse nach einer anderen Partei als deine Website aussieht, zum Beispiel wenn die beiden Adressen in deutlich unterschiedlichen Netzwerkbereichen liegen. In beiden Fällen begrenzt ITP die in der Antwort gesetzten Cookies auf 7 Tage. Wem der Server gehört, spielt für diese Regeln keine Rolle.

Wie geht Safari mit Click-IDs in Links um?

Eine Click-ID wie fbclid oder gclid ist Teil der URL der Landingpage. Beim normalen Surfen lädt Safari die URL mit ihren Parametern, sodass ein Skript auf der Landingpage die Click-ID lesen kann. Die 24-Stunden-Grenze oben begrenzt, wie lange ein auf dieser Seite geschriebenes Cookie hält. Sie entfernt die Click-ID nicht aus der URL.

Das private Surfen geht weiter. Seit Safari 17 greift die Link Tracking Protection, wenn der Besucher von einer Website zu einer anderen navigiert, etwa von einer Anzeige zu deinem Shop. Safari entfernt eine Reihe von Query-Parametern, die WebKit als genutzt für das websiteübergreifende Tracking von Nutzern oder Klicks identifiziert hat. Die Ankündigung von WebKit listet die Parameter nicht auf. Ihr Beispiel entfernt einen Tracking-Parameter und behält einen Kampagnenparameter. Auf der Landingpage erhalten auch Drittanbieter-Skripte, die die URL lesen, sie ohne Query-String. Dieselben Schutzmaßnahmen sind beim normalen Surfen für Personen verfügbar, die den erweiterten Schutz vor Tracking und Fingerprinting für alle Websites aktivieren.

Was ist mit Private Relay und IP-Adressen?

Laut WebKit verbirgt Safari seit Safari 15 standardmäßig IP-Adressen vor bekannten Trackern. Wer für iCloud+ bezahlt, kann zusätzlich iCloud Private Relay aktivieren. Es leitet den Safari-Datenverkehr über zwei getrennte Relays unterschiedlicher Betreiber, sodass Websites eine Relay-IP-Adresse statt der eigenen des Besuchers sehen. Apple sagt, dass die Relay-Adresse den groben Standort des Besuchers auf Stadtebene behält und dass sich mehrere Nutzer in derselben Gegend eine Adresse teilen können.

Das schwächt Tracking, das auf der IP-Adresse beruht, etwa den Abgleich eines Besuchers über IP-Adresse und Browser. Click-IDs, gehashte E-Mail-Adressen und Bestelldaten sind nicht betroffen. ROASaurus nutzt einen IP-Abgleich nur als letzten Ausweg, und nur wenn genau ein kürzlicher Besucher mit dieser IP-Adresse und diesem Browser passt. Eine geteilte Relay-Adresse führt dann meist zu keinem Treffer.

Was bedeutet ITP für Attributionsfenster?

Ein Attributionsfenster ist die Anzahl der Tage nach einem Klick, in denen ein Kauf diesem Klick noch zugeschrieben werden kann. In ROASaurus wählst du ein Lookback-Fenster von 1 bis 90 Tagen, standardmäßig 7 Tage. Werbeplattformen haben eigene Einstellungen. In Safari kann ein Setup, das sich nur auf Browser-Cookies stützt, einen Kauf nur so lange mit einem Klick verbinden, wie das Cookie besteht.

Der Effekt wächst mit der Länge des Fensters. Ein Fenster von 1 oder 7 Tagen ist nicht länger als die 7-tägige Lebensdauer eines Skript-Cookies, außer die 24-Stunden-Grenze greift. Bei einem Fenster von 28 Tagen sind Käufe ab Tag 8 von Käufern, die zwischendurch nicht zurückgekehrt sind, auf andere Daten angewiesen.

So schätzt du das Ausmaß für einen Shop ab. Die Zahlen sind ein Beispiel; nimm deine eigenen.

Was bedeutet ITP für Remarketing?

Remarketing-Zielgruppen werden aus Browser-Events aufgebaut, etwa von Personen, die ein Produkt angesehen oder in den Warenkorb gelegt haben. In Safari kann die Plattform ihre Drittanbieter-Cookies nicht nutzen, und das First-Party-Cookie des Pixels wird nach 7 Tagen ohne Besuch gelöscht. Ein Safari-Besucher, der nach 8 Tagen zurückkehrt, wirkt für das Pixel wie neu. Seine früheren Produktansichten sind ihm im Browser nicht mehr zugeordnet.

Daraus ergeben sich zwei Effekte. Zielgruppen mit langer Dauer, etwa 30 oder 180 Tage, behalten weniger Safari-Besucher, als die Dauer vermuten lässt. Außerdem zeigen deine Analysen mehr neue und weniger wiederkehrende Besucher, als du tatsächlich hast. Kundenlisten-Zielgruppen, die aus gehashten E-Mail-Adressen in deinem Shop oder E-Mail-Tool aufgebaut werden, hängen nicht von Cookies ab und sind daher nicht auf dieselbe Weise betroffen.

Was funktioniert in Safari weiterhin?

Serverseitige Events aus Bestellungen

Ein Kauf, der aus den Bestelldaten deines Shops gesendet wird, hängt von keinem Cookie in Safari ab. Der Shop erfasst die Bestellung, ein Server sendet sie an die API der Plattform, und die Plattform empfängt sie. Das Event enthält die gehashte E-Mail-Adresse und Telefonnummer aus der Bestellung. Die Plattform kann diese einem ihrer Nutzer zuordnen und ihre eigenen Aufzeichnungen zu Anzeigenklicks und -ansichten innerhalb ihres eigenen Attributionsfensters prüfen. Lies was Server-Side-Tracking ist, um den vollständigen Datenweg zu sehen.

Beim Landen erfasste Click-IDs

Die Click-ID steht in der URL der ersten Seite. Ein Skript kann sie dort lesen und an deinen Server senden, wo sie zusammen mit der Besucher-ID gespeichert wird. Die Kopie auf dem Server läuft nicht nach 7 Tagen ab. Ablaufen tut das Browser-Cookie, das einen wiederkehrenden Besuch mit diesem gespeicherten Besucher verbindet. Andere Daten können eine Bestellung trotzdem mit einem gespeicherten Klick verbinden, etwa eine E-Mail-Adresse, die der Käufer früher in einem Anmeldeformular angegeben hat, oder die Click-ID in der Landing-URL der Sitzung, in der die Bestellung aufgegeben wurde.

First-Party-Erfassung mit der 7-Tage-Grenze

Wenn du das Tracking-Skript und seine Anfragen von deiner eigenen Domain auslieferst, bleibt die Erfassung First-Party, was auch gegen Adblocker hilft. Cookies halten dadurch allein aber nicht länger. Eine Tracking-Subdomain, die per CNAME auf eine andere Domain zeigt oder die WebKit als Drittanbieter-IP-Adresse erkennt, fällt unter die 7-Tage-Grenze. Eine Tracking-Subdomain von ROASaurus stellt die Besucher-ID erneut als HTTP-Cookie aus, aber Safari kann dieses Cookie trotzdem auf 7 Tage begrenzen. Der App-Proxy von Shopify hält Anfragen auf deiner Shop-Domain, aber Shopify entfernt Cookies aus App-Proxy-Anfragen und -Antworten, daher wird die Besucher-ID dort per JavaScript geschrieben, und die 7-Tage-Regel gilt.

Was der Käufer dir sagt

Käufer können dir sagen, wie sie dich gefunden haben, und diese Antwort hängt nicht von Cookies ab. Eine Umfrage nach dem Kauf fragt nach dem Checkout. In ROASaurus kombiniert das Modell Total Impact die Antwort mit den Klickdaten und gibt der Umfrage 50% des Credits, wenn es auch Klicks gibt.

So prüfst du, wie stark Safari deinen Shop betrifft

1. Den Safari-Anteil deiner Bestellungen ermitteln

   Gruppiere in deinem Analyse-Tool die Käufe nach Browser. Zähle Safari auf Mac, iPhone und iPad.

2. Die Zeit vom Klick bis zum Kauf messen

   Finde heraus, wie viele Bestellungen mehr als 7 Tage nach dem Anzeigenklick eingehen. Vergleiche im ROASaurus-Attributionsbericht die Fenster von 7, 14 und 28 Tagen und sieh, wie viel Credit sich verschiebt.

3. Pixel-Käufe mit Bestellungen vergleichen

   Zähle die Purchase-Events, die dein Pixel gesendet hat, nach Browser aufgeteilt, falls deine Plattform das erlaubt, und vergleiche sie mit deinen Bestellungen im selben Zeitraum.

4. Server-Events prüfen

   Stelle sicher, dass jede bezahlte Bestellung serverseitig mit gehashter E-Mail-Adresse und Telefonnummer gesendet wird und dass die Browser- und die Server-Kopie dieselbe Event-ID teilen.

Wenn ein großer Teil deiner Bestellungen aus Safari kommt und viele davon mehr als 7 Tage nach dem Klick eingehen, erfassen Browser-Cookies allein deine Anzeigen zu niedrig. Käufe, die aus Bestelldaten mit gehashten Kundendaten gesendet werden, geben den Werbeplattformen eine weitere Möglichkeit, diese Bestellungen zuzuordnen. Wie ROASaurus das macht, siehst du auf der Seite zu Server-Side-Tracking, und wie es Klicks Credit zuweist, unter Attribution.

Quellen

1. WebKit: Tracking Prevention in WebKit
2. WebKit: Intelligent Tracking Prevention 2.2
3. WebKit: CNAME Cloaking and Bounce Tracking Defense
4. WebKit: Private Browsing 2.0
5. Apple Developer: Prepare your network or web server for iCloud Private Relay

In ROASaurus

• Server-Side-Tracking in ROASaurus
• Attribution in ROASaurus
• Funnels und verknüpfte Domains

Weiterlesen