Zwei Jahre beantragt, sieben Tage bekommen

Ein Cookie-Header ist eine Bitte und keine Anweisung. Max-Age=63072000 bittet um zwei Jahre, und was der Browser gewährt, hängt an etwas, das im Header gar nicht vorkommt: daran, wie das Cookie zustande kam. Dieselbe Zeile ergibt im einen Fall zwei Jahre und im anderen sieben Tage, und nichts in der Antwort sagt, welcher Fall vorliegt.

Der Unterschied reicht über Ordnungsliebe hinaus. Ein wiederkehrender Besucher kehrt nur so lange wieder, wie das Cookie besteht, das ihn erkennt; ist es weg, zählt der Besucher als neu, und jedes Fenster, das länger ist als die Lebensdauer des Cookies, rechnet mit Daten, die es nicht mehr gibt.

Die drei Kappungen

Safari kürzt jeden über document.cookie geschriebenen Cookie auf sieben Tage. Das ist die Regel mit der größten praktischen Wirkung, denn die meisten Mess-Cookies entstehen genau so – durch ein Tag, das in der Seite läuft.

Dieselben sieben Tage wendet Safari auf Cookies an, die in einer HTTP-Antwort von einem Host kommen, der über einen CNAME anderswo auflöst. Gemeint ist damit die Anordnung, bei der eine Subdomain der Seite auf einen Messdienstleister zeigt; die Wirkung ist, dass ein korrekt gesetztes Erstanbieter-Cookie wie eines von Dritten behandelt wird.

Chrome und Firefox kappen bei 400 Tagen. Diese Zahl tut selten weh – sie liegt über jedem vernünftigen Messfenster – beendet aber stillschweigend das Zwei-Jahres-Cookie, das seit 2018 in der Tag-Vorlage steht.

Warum der Weg entscheidet und nicht das Attribut

Zwei Cookies mit gleichen Attributen können verschiedene Laufzeiten haben, und der einzige Unterschied ist, wer sie geschrieben hat. Ein Cookie, das ein Skript in der Seite setzt, wird gekürzt; dasselbe Cookie in der Antwort des eigenen Servers nicht.

Deshalb ist es die wirksamste einzelne Änderung, das Cookie in die Antwort zu verlegen: sie kostet einen Endpunkt auf der eigenen Domain und macht den Unterschied zwischen einer Woche Wiedererkennung und einem Jahr. Das Tag liest das Cookie dann, statt ihn zu schreiben.

Der Umzug hat eine zweite Wirkung, die der Erwähnung wert ist: ein in der Antwort geschriebenes Cookie kann HttpOnly tragen, und ein Cookie mit HttpOnly liest kein Skript der Seite – auch keines, das dort niemand absichtlich eingebaut hat.

Was ein CNAME daran ändert

Eine Subdomain, die auf einen Dienstleister zeigt, sieht in der Adresszeile nach Erstanbieter aus und ist für den Browser durchsichtig: die Auflösungskette liegt offen, und der Browser sieht, dass der Host anderswo endet. Genau daran setzt die Abwehr an.

Die Folge gehört eingeplant statt entdeckt: eine Anordnung, die gebaut wurde, um Drittanbieter-Beschränkungen zu entgehen, erbt in Safari die Kappung auf sieben Tage und gewinnt dafür eine Subdomain, deren Ausfall die ganze Messung mitnimmt. Läuft der Endpunkt auf eigener Infrastruktur, trifft weder das eine noch das andere zu.

Die Attribute, an denen ein Cookie scheitert

Alle scheitern auf dieselbe Weise: die Antwort ist in Ordnung, das Cookie ist hinterher schlicht nicht da. Die einzige verlässliche Prüfung ist der Blick auf das, was der Browser gespeichert hat, und nicht auf das, was gesendet wurde.

Was daraus für die Messung folgt

Ein Sieben-Tage-Cookie macht aus einem Besucher, der nach acht Tagen wiederkommt, einen neuen. Im Bericht zeigt sich das als Anteil wiederkehrender Besucher, der unter Safari niedriger liegt als überall sonst, und als Conversion-Pfade, die kürzer sind als der Verkaufszyklus – nicht weil die Reise kurz war, sondern weil ihr früherer Teil nicht mehr daran hängt.

Wo sich das Cookie nicht verlängern lässt, ist die ehrliche Antwort, das Fenster zu verkürzen, statt weiter eines auszuweisen, das die Daten nicht tragen. Ein dreißigtägiges Attributionsfenster über einem Sieben-Tage-Cookie beschreibt einen Zeitraum, an den der Browser keine Erinnerung hat, und jede daraus abgeleitete Zahl erbt diese Lücke.