Was das Safari 7-Tage-Cookie-Limit wirklich einschränkt

Was ist das Safari 7-Tage-Cookie-Limit?

Apples Intelligent Tracking Prevention setzt das Safari 7-Tage-Cookie-Limit durch, indem sie die Ablaufzeit jedes per JavaScript gesetzten Cookies auf sieben Tage ab der Erstellung begrenzt, unabhängig von der vom Skript angeforderten Ablaufzeit. Ein Skript, das document.cookie aufruft und eine Ablaufzeit von einem Jahr verlangt, bekommt stattdessen sieben Tage; Safari schreibt die Ablaufzeit still um und gibt der Seite, die den Cookie gesetzt hat, keinen Fehler zurück. Die Grenze gilt für die Speicherung des Cookies auf dem Gerät, nicht dafür, ob die Seite einen Besucher weiterhin zur erneuten Authentifizierung auffordern kann.

Warum hat Apple Intelligent Tracking Prevention eingeführt?

Apple hat Intelligent Tracking Prevention in WebKit eingebaut, um zu verhindern, dass Tracker langlebige, per Skript gesetzte Cookies als dauerhaften Identifikator nutzen, nachdem der Cross-Site-Zugriff auf Cookies eingeschränkt wurde. Frühere ITP-Versionen blockierten Third-Party-Cookies, die einen Besucher über nicht verwandte Seiten hinweg verfolgten; Tracker reagierten darauf, indem sie ihren Identifikator stattdessen per JavaScript in einen First-Party-Cookie auf jeder Seite schrieben, was weiterhin funktionierte, weil First-Party-Cookies nie blockiert wurden. Das 7-Tage-Limit schloss diese Lücke, indem es jeden clientseitigen Cookie, ob First-Party oder nicht, auf eine kurze Frist ablaufen lässt.

Wann sinkt die Grenze auf 24 Stunden statt 7 Tage?

WebKit verkürzt die Grenze auf 24 Stunden, wenn ein Cookie per JavaScript unmittelbar nach einer Cross-Site-Navigation gesetzt wird, deren URL eine Link-Dekoration trägt, etwa einen Query-Parameter, der eine Klick- oder Kampagnen-ID überträgt, und die verweisende Domain vom On-Device-Klassifikator von WebKit als Cross-Site-Tracking-fähig markiert wurde. Diese Regel zielt genau auf das Muster, das ein Anzeigenklick erzeugt: Ein Besucher klickt auf eine Anzeige, landet über eine Weiterleitung mit einem Tracking-Parameter, und die Landingpage schreibt diesen Parameter sofort in einen Cookie. Ohne die kürzere Grenze hätte dieser Ablauf die vollen 7 Tage behalten.

Was übersteht das Safari 7-Tage-Cookie-Limit?

Cookies, die der Server direkt über einen Set-Cookie-Response-Header setzt, überstehen das Safari 7-Tage-Cookie-Limit unangetastet, da die Grenze nur die Ablaufzeit von Cookies umschreibt, die eine Seite clientseitig per JavaScript setzt. Ein Session-Cookie ohne Expires- oder Max-Age-Attribut übersteht die Grenze in der Praxis ebenfalls, da er ohnehin endet, wenn die Browser-Sitzung geschlossen wird, bei den meisten Besuchern früher als nach sieben Tagen. Was nicht übersteht, ist jeder Identifikator, auf den ein Tracking-Skript angewiesen ist, um über document.cookie länger als eine Woche zu bestehen, ohne dass der Besucher direkt auf die Seite zurückkehrt.

Werden auch serverseitig gesetzte HttpOnly-Cookies begrenzt?

Nein. Ein HttpOnly-Cookie kann nur über einen Set-Cookie-Response-Header vom Server erstellt und gelesen werden, da HttpOnly genau dafür existiert, JavaScript den Zugriff auf den Cookie vollständig zu verwehren, und Safaris Grenze für Skript-Cookies nur für Cookies gilt, die JavaScript geschrieben hat. Ein Login-Session-Cookie, ein CSRF-Token oder jeder andere Cookie, den Ihr Backend setzt und als HttpOnly markiert, behält die vom Server zugewiesene Ablaufzeit, ohne dass ITP sie auf sieben Tage oder 24 Stunden umschreibt.

Was bricht das Safari 7-Tage-Cookie-Limit bei der Attribution?

Das Safari 7-Tage-Cookie-Limit bricht jedes Attributionsmodell, das auf einen clientseitigen Cookie angewiesen ist, um einen Anzeigenklick mehr als eine Woche später mit einer Conversion zu verbinden, und verkürzt dieses Fenster auf einen einzigen Tag, wenn der Klick eine dekorierte Tracking-URL trug. Ein B2B-Verkauf mit einem dreiwöchigen Sales Cycle, eine Affiliate-Provision, die bei einem Rückbesuch zehn Tage nach dem ersten Klick beansprucht wird, oder eine Remarketing-Kampagne, die ein zweiwöchiges Attributionsfenster misst, verlieren auf Safari alle den clientseitigen Cookie, der den ursprünglichen Klick mit der späteren Conversion verbunden hätte, und das lange bevor die Conversion überhaupt stattfindet. Der Besucher geht der Seite nicht verloren; nur der per JavaScript gesetzte Cookie, der zwei getrennte Besuche verbunden hätte, ist weg.

Wie umgehen Teams das Safari 7-Tage-Cookie-Limit?

Teams umgehen das Safari 7-Tage-Cookie-Limit, indem sie das Setzen des Cookies von clientseitigem JavaScript auf den Server verlagern, da ein Set-Cookie-Response-Header von der eigenen First-Party-Domain keiner der beiden ITP-Grenzen unterliegt. Server-seitiges Tracking setzt den Identifikator-Cookie als Teil der HTTP-Antwort statt über einen Skriptaufruf, und die Markierung als HttpOnly entfernt ihn vollständig aus dem Geltungsbereich von ITP und verhindert zugleich, dass ein clientseitiges Skript ihn lesen oder manipulieren kann. Zu prüfen, welche Ihrer First-Party- und Third-Party-Cookies noch per JavaScript gesetzt werden, ist der erste Schritt, um jeden Identifikator zu finden, den diese Grenze still verfallen lassen kann.

Der andere Weg besteht darin, für die Attribution ganz auf Cookies zu verzichten. Flowsery liefert cookiefreie Analytics mit EU-Hosting, die Sitzungen ohne einen einzigen Identifikator-Cookie mit Umsatz verbindet, sodass die Safari-Einstellungen eines Besuchers und Apples Ablaufregeln von vornherein nichts zum Verfallen haben.

Häufig gestellte Fragen

Gilt das Safari 7-Tage-Cookie-Limit auch für Chrome oder Firefox?

Nein. Die 7-Tage- und 24-Stunden-Grenzen stammen von WebKits Intelligent Tracking Prevention, die in Safari und jedem auf WebKit basierenden Browser läuft, einschließlich Safari auf iOS und iPadOS. Chrome und Firefox betreiben ihre eigenen, separaten Systeme zur Tracking-Prävention mit anderen Regeln und anderen Grenzwerten.

Kann eine Seite die 7-Tage-Cookie-Uhr zurücksetzen?

Nur wenn der Cookie vom Server über einen Set-Cookie-Header neu geschrieben wird, oder wenn der Besucher direkt zur Seite zurückkehrt und deren Skript den Cookie erneut setzt, bevor die sieben Tage ablaufen; beide Wege starten ein neues Sieben-Tage-Fenster. Ein Cookie, der vor dem siebten Tag nie erneuert wird, läuft ab und ist weg, und der Besucher muss neu identifiziert werden, als hätte der Cookie nie existiert.

Blockiert das Safari 7-Tage-Cookie-Limit auch Third-Party-Cookies?

Third-Party-Cookies werden von Safari unter einer separaten ITP-Regel von vornherein komplett blockiert und erreichen die Sieben-Tage-Frage gar nicht erst. Das 7-Tage-Cookie-Limit zielt gezielt auf First-Party-Cookies, die JavaScript setzt, also genau die Ausweichlösung, zu der Tracker griffen, nachdem Third-Party-Cookies nicht mehr funktionierten.

Setzt das Löschen der Safari-Website-Daten die Cookie-Grenze zurück?

Das Löschen der Website-Daten entfernt den Cookie sofort, statt seine Grenze zurückzusetzen, sodass die Seite beim nächsten Besuch bei null anfängt, genau als wären bereits sieben Tage vergangen. Die Grenze regelt, wie lange ein bestehender Cookie leben darf, nicht wie sich der Cookie verhält, nachdem er manuell entfernt wurde.

Wird lokaler Speicher genauso begrenzt wie Cookies?

Diese Seite behandelt nur die Cookie-Grenze, da genau diese Regel hier beschrieben wird. Clientseitige Speichermechanismen außer Cookies fallen unter andere Teile von Intelligent Tracking Prevention, mit eigenen Bedingungen dafür, wann die gespeicherten Daten einer Domain gelöscht werden, also behandeln Sie Cookie-Grenzen und andere Speichergrenzen als getrennte Regeln, statt anzunehmen, dass die eine die andere einschließt.

Warum funktioniert Attribution auf manchen Seiten in Safari trotzdem über 7 Tage hinaus?

Eine Seite funktioniert weiterhin über sieben Tage hinaus, wenn sie nie auf einen per JavaScript gesetzten Cookie für die Verbindung zwischen Klick und Conversion angewiesen war, weil sie den Identifikator-Cookie über den Server mit Set-Cookie setzt oder den Besucher stattdessen über einen Login statt über einen Cookie neu identifiziert. Seiten, die Conversions ganz ohne Cookie messen, über serverseitigen Session-Abgleich oder einen cookiefreien Analytics-Ansatz, unterliegen der Grenze nie, weil es keinen skriptschreibbaren Cookie gibt, den ITP verfallen lassen könnte.

Gilt das Safari 7-Tage-Cookie-Limit für Cookies, die JavaScript nur liest, oder nur für die, die es setzt?

Die Grenze gilt nur, wenn JavaScript ein Cookie über document.cookie schreibt, nicht wenn es eines liest. Ein vom Server gesetztes Cookie, das ein Skript nur ausliest, behält die Ablaufzeit, die der Set-Cookie-Header festgelegt hat, denn nur Schreibzugriffe durch Skripte werden umgeschrieben. HttpOnly-Cookies entziehen sich sogar diesem Lesezugriff, aber die Regel für Schreibzugriffe deckt das Lesen bei jedem Cookie ohnehin schon ab, das JavaScript sonst sehen könnte.

Löst ein Affiliate-Link die 24-Stunden-Grenze statt der 7-Tage-Grenze aus?

Nur wenn der Affiliate-Link dekorierte Tracking-Parameter trägt, etwa eine Klick- oder Kampagnen-ID in der URL, und die verweisende Domain vom Klassifikator von WebKit als Cross-Site-Tracking-fähig eingestuft wurde. Ohne beide Bedingungen fällt ein Affiliate-Link weiterhin unter die normale 7-Tage-Grenze für jedes per JavaScript gesetzte Cookie. Das Affiliate-Beispiel in diesem Beitrag, eine Provision, die zehn Tage nach dem ersten Klick beansprucht wird, verpasst schon das 7-Tage-Fenster, sodass die kürzere Grenze diese Lücke nur vergrößern würde.

Gilt das Safari 7-Tage-Cookie-Limit auch für Third-Party-Analyse-Skripte?

Ja, wenn das Skript sein Cookie über document.cookie auf der Domain der Seite selbst schreibt, denn die 7-Tage-Grenze gilt für jedes clientseitig gesetzte Cookie, First-Party oder nicht. Für ITP zählt, wie das Cookie gesetzt wurde, nicht welche Firma das Skript geschrieben hat. Ein Third-Party-Analyse-Tag, das für seine Kennung weiterhin auf document.cookie setzt, verliert diese Kennung nach sieben Tagen genauso wie ein First-Party-Tracking-Skript.

Kann die 24-Stunden-Grenze ein Cookie verkürzen, das schon vor dem Anzeigenklick existierte?

Die 24-Stunden-Grenze greift nur bei einem Cookie, das unmittelbar nach dem dekorierten Cross-Site-Klick selbst gesetzt wird; sie wirkt nicht rückwirkend auf ein Cookie, das schon vorher auf dem Gerät existierte. Ein Cookie, das JavaScript vor dem Klick auf die Anzeige geschrieben hat, läuft weiter unter der Grenze, die bei seiner Erstellung galt, meist die normale 7-Tage-Grenze. Der Klick kann ein neues, stärker begrenztes Cookie starten, greift aber nicht rückwirkend in eines ein, dessen Uhr schon läuft.