Safari Tracking und ITP: was mit deinen Cookies passiert

Safari schränkt Tracking über Intelligent Tracking Prevention ein, kurz ITP. Die wichtigsten Folgen: Cookies von Drittanbietern blockiert Safari vollständig, und eigene Cookies, die per JavaScript gesetzt werden, leben höchstens sieben Tage. Kommt ein Besucher über einen Link mit Tracking-Merkmalen von einer Domain, die Safari als Tracker einstuft, kann die Grenze auf 24 Stunden sinken. Zusätzlich entfernt Link Tracking Protection in bestimmten Situationen Klick-IDs aus Links, etwa in Mail, Nachrichten und beim privaten Surfen. Für dich heißt das: Wiederkehrende Besucher werden seltener erkannt, und Conversions, die erst Tage nach dem Anzeigenklick passieren, lassen sich schwerer zuordnen. Ganz verhindern kannst du das nicht, aber du kannst die Lücken deutlich verkleinern.

Was macht Safari ITP mit Cookies?

Apple hat Intelligent Tracking Prevention in die Browser-Engine WebKit eingebaut und seit der ersten Version schrittweise verschärft. Der Mechanismus unterscheidet zwischen Cookies von Drittanbietern, also von fremden Domains, die in deine Seite eingebettet sind, und eigenen Cookies deiner Domain. Drittanbieter-Cookies sind in Safari komplett blockiert. Für Werbeplattformen bedeutet das: Sie können Nutzer nicht mehr über ein eigenes Cookie auf deiner Seite wiedererkennen.

Bei eigenen Cookies kommt es darauf an, wie sie gesetzt werden. Ein Cookie, das ein Skript im Browser über document.cookie schreibt, bekommt in Safari eine Laufzeit von höchstens sieben Tagen, egal was im Code steht. Genau so setzen die meisten Tracking-Werkzeuge ihre Cookies, auch der Google Tag für Google Analytics 4 (GA4) und Google Ads und der Meta Pixel. Besucht jemand deine Seite innerhalb dieser sieben Tage erneut, wird das Cookie erneuert. Kommt er erst nach acht Tagen wieder, ist es weg.

Strenger wird es bei sogenannter Link-Dekoration. Kommt ein Besucher von einer Domain, die Safari als Tracker mit Fähigkeiten über mehrere Websites einstuft, und enthält die Zieladresse Parameter, begrenzt Safari per JavaScript gesetzte Cookies auf deiner Seite auf 24 Stunden. Welche Domains Safari so einstuft, entscheidet der Browser anhand des Verhaltens, nicht anhand einer festen Liste, die du einsehen kannst. Außerdem löscht Safari Speicher, den Skripte geschrieben haben, etwa localStorage, wenn jemand Safari sieben Tage lang benutzt hat, ohne mit deiner Seite zu interagieren.

Link Tracking Protection: wenn Klick-IDs verschwinden

Mit Link Tracking Protection geht Apple einen Schritt weiter. Safari entfernt dabei bekannte Parameter, die einzelne Nutzer kennzeichnen, direkt aus der Adresse, bevor die Seite geladen wird. Das betrifft vor allem Klick-IDs, die Werbeplattformen an ihre Links hängen. Nach bisherigem Stand greift der Schutz in bestimmten Situationen: bei Links, die in Mail und Nachrichten geöffnet werden, und beim privaten Surfen in Safari. Apple hat die Schutzfunktionen in neueren Versionen weiter ausgebaut, deshalb lohnt es sich, die Entwicklung im Blick zu behalten.

Fehlt die Klick-ID, kann die Plattform den Besuch nicht mehr eindeutig dem Anzeigenklick zuordnen. In GA4 erscheint ein solcher Besuch dann womöglich nicht unter der richtigen Kampagne, und die spätere Conversion fehlt in Google Ads oder bei Meta, sofern die Plattform sie nicht über andere Signale zuordnen oder modellieren kann. UTM-Parameter sind nach bisherigem Stand nicht betroffen, weil sie Kampagnen beschreiben und keine Personen. Sie sind deshalb eine gute Ergänzung zu den automatischen Klick-IDs.

Passend dazu: Cross-Domain-Tracking in GA4 richtig einrichten

Folgen für Wiedererkennung und Zuordnung

Die Begrenzung der Cookie-Laufzeit zeigt sich in mehreren Kennzahlen. Diese Effekte solltest du kennen, bevor du Zahlen aus Safari mit anderen Browsern vergleichst:

• Mehr neue Nutzer: Wer nach mehr als sieben Tagen wiederkommt, zählt in GA4 oft als neuer Nutzer.
• Kürzere Customer Journeys: Lange Entscheidungswege werden in Einzelstücke zerlegt, weil der frühere Besuch nicht mehr verknüpft ist.
• Fehlende Conversions bei langen Entscheidungen: Kauft jemand erst zwei Wochen nach dem Anzeigenklick, ist das Cookie mit der Klick-ID meist abgelaufen.
• Kleinere Zielgruppen für Remarketing: Besucher fallen früher aus Listen heraus, weil sie nicht mehr erkannt werden.
• Unterschiede zwischen Geräten: Auf iPhones ist der Effekt besonders sichtbar, weil dort Safari verbreitet ist und auch andere Browser in der Regel WebKit nutzen.

Wie stark dich das betrifft, hängt von deinem Publikum und deinem Geschäft ab. Ein Shop mit spontanen Käufen am selben Tag merkt wenig. Ein B2B-Dienstleister, dessen Kunden drei Wochen vergleichen, verliert viel Zuordnung. Schau in GA4 nach, welcher Anteil deiner Besuche aus Safari und von iOS-Geräten kommt, und vergleiche die Zahl der Conversions je Nutzer zwischen den Browsern.

Was hilft gegen Datenverlust durch ITP?

Zuerst die Grundlage: Einwilligung. Viele Lücken entstehen nicht durch ITP, sondern dadurch, dass Tags ohne Zustimmung gar nicht feuern. Ein sauber eingerichtetes Cookie-Banner mit Google Consent Mode v2 sorgt dafür, dass bei Zustimmung alles gemessen wird und bei Ablehnung Google zumindest Signale ohne Cookies für die Modellierung bekommt. ITP lässt sich damit nicht umgehen, und das ist auch nicht das Ziel. Dieser Artikel ist keine Rechtsberatung.

Zweitens: sauber gesetzte Cookies. Die Grenze von sieben Tagen gilt für Cookies, die per JavaScript gesetzt werden. Cookies, die dein eigener Webserver mit der Antwort auf eine Seitenanfrage setzt, behandelt Safari anders, solange der Server wirklich zu deiner Website gehört. Safari prüft dabei auch, ob die Antwort von derselben Infrastruktur kommt. Erkennt ITP, dass ein fremder Dienst nur per CNAME-Eintrag oder über eine fremde IP-Adresse unter deiner Subdomain erscheint, begrenzt es auch diese Cookies laut WebKit auf sieben Tage. Ein solcher Umbau ist technisch aufwendig und braucht eine klare Einwilligungslogik.

Drittens, und für viele Firmen am wirksamsten: Herkunft und Klick-ID zum richtigen Zeitpunkt festhalten. Wenn jemand ein Formular abschickt, sind UTM-Parameter und Klick-ID meist noch vorhanden. Speichere sie in diesem Moment mit der Anfrage, im Postfach oder im CRM. Wird aus der Anfrage Wochen später ein Auftrag, meldest du ihn als Offline-Conversion an Google Ads oder Meta zurück. Die Zuordnung hängt dann nicht mehr davon ab, ob ein Cookie im Browser überlebt hat.

Passend dazu: Consent Mode: Warum nach der Zustimmung Daten fehlen

Beispiel: kleiner Onlineshop mit vielen iPhone-Kunden

Ein Shop für Fahrradzubehör bekommt den größten Teil seiner Besuche von iPhones, viele davon über Instagram und Newsletter. In GA4 fällt auf, dass die Zahl neuer Nutzer kaum unter der Zahl aller Nutzer liegt, obwohl der Shop viele Stammkunden hat. Gleichzeitig meldet Meta weniger Käufe, als der Shop aus Kampagnen erwartet. Die Analyse zeigt: Stammkunden kaufen im Schnitt alle paar Wochen, ihre Cookies sind dann längst abgelaufen. Im Newsletter fehlen UTM-Parameter, und viele Links werden in der Mail-App geöffnet. Der Shop hängt jetzt an jeden Newsletter-Link UTM-Parameter an, prüft, dass Banner und Consent Mode sauber zusammenarbeiten, und sendet Käufe zusätzlich über die Meta Conversions API mit Einwilligung an Meta. Die Zahlen sind danach nicht perfekt, aber deutlich näher an den echten Bestellungen.

Safari-Lücken mit Trackum verkleinern

Trackum richtet Google Tag Manager, GA4 und Consent Mode v2 so ein, dass bei Zustimmung vollständig gemessen wird, für 150 € zzgl. MwSt. Mit dem Extra Kampagnen-Daten in Formularen für 50 € bleiben UTM-Parameter und Klick-IDs beim Weiterklicken erhalten und stehen in jeder Anfrage. Und mit dem Extra Verkäufe zurück an Google Ads und Meta meldet Trackum Aufträge aus deinem CRM als Offline-Conversions, unabhängig von der Laufzeit eines Cookies in Safari.