Safaris 7-Tage-Cookie-Begrenzung: Wie „Same-Origin-Tracking“ die volle Lebensdauer von Cookies wiederherstellt

Ein Safari-Besucher findet dich über eine Anzeige, schaut sich ein paar Produkte an und verlässt die Seite wieder. Acht Tage später kehrt derselbe Browser zurück und kauft etwas. Deine Analyse erfasst einen neuen Nutzer, anstatt beide Besuche miteinander zu verknüpfen.

Der Besucher hat weder das Gerät gewechselt noch seine Cookies gelöscht. Eine Kennung in Safari ist einfach abgelaufen.

Server-side Tracking macht die Datenerfassung weniger abhängig von direkten Anfragen an Analyse- und Werbeplattformen. Es kann auch Cookies nutzen, die über eine HTTP-Antwort gesetzt werden und anders behandelt werden als Cookies, die per JavaScript erstellt werden.

Aber server-side Tracking allein garantiert noch keine lange Cookie-Lebensdauer. Der vom Browser verwendete öffentliche Endpunkt spielt nach wie vor eine Rolle. In Safari kann für eine Subdomain für Same-Origin-Tracking eine Cookie-Obergrenze von sieben Tagen gelten, wenn WebKit eine CNAME- oder IP-Adressverschleierung erkennt.

„Same-Origin-Tracking“ hilft, genau dieses Problem zu vermeiden.

Server-side Tracking schließt den Browser nicht aus der Messung aus

In einer typischen clientseitigen Konfiguration senden Tags im Browser Events direkt an Analyse- und Werbeplattformen. Server-side Tagging ändert diesen Weg. Der Code auf der Browserseite sendet ausgewählte Events zunächst an einen Server-Container. Dieser Container verarbeitet die Daten und leitet sie an die gewünschten Ziele weiter. Dadurch hat die Website mehr Kontrolle darüber, welche Daten erfasst und weitergegeben werden. Außerdem verringert sich dadurch die Abhängigkeit von Browser-Anfragen von Drittanbietern, die möglicherweise blockiert werden.

Die Erkennung anonymer Besucher hängt oft noch von einem im Browser gespeicherten Identifikator ab. GA4 nutzt zum Beispiel häufig eine Client-ID, die in einem First-Party-Cookie gespeichert ist, um denselben Browser über mehrere Besuche hinweg zu erkennen. Ein Cookie identifiziert eine Browser-Instanz, nicht unbedingt eine Person. Eine angemeldete Benutzer-ID, modellierte Daten und andere Identifizierungsmethoden können ebenfalls dabei helfen, Aktivitäten miteinander zu verknüpfen.

„Same-Site“ und „Same-Origin“ sind nicht dasselbe

Die beiden Begriffe werden oft synonym verwendet, haben für einen Browser aber unterschiedliche Bedeutungen.

„Same-Site“ bedeutet dieselbe registrierbare Domain. „Same-Origin“ ist strenger: Schema, Host und Port müssen alle übereinstimmen. Eine Tracking-Subdomain erfüllt die erste Bedingung, scheitert aber an der zweiten.

Nehmen wir mal die Website unter https://yourdomain.com. Ihr Tracking-Endpunkt läuft vielleicht unter https://sst.yourdomain.com. Beide nutzen HTTPS und teilen sich die registrierbare Domain „yourdomain.com“ – nach der modernen Definition gehören sie also zur selben Website, sind aber dennoch unterschiedliche Ursprünge, da der Host unterschiedlich ist.

Verschiebe den Endpunkt auf einen Pfad auf dem eigenen Host der Website, zum Beispiel https://yourdomain.com/metrics, und die Seite sowie der Tracking-Endpunkt haben schließlich dasselbe Schema, denselben Host und denselben Port. Jetzt gehören sie zum selben Ursprung.

	Subdomain auf derselben Website	Pfad auf derselben Herkunftsseite
Beispiel	sst.deinedomain.com	yourdomain.com/metrics
Der Browser sieht	einen separaten Host	Deine eigene Website
Gleiches Schema + Host + Port wie deine Website	Nein	Ja
Safari-Cloaking-Limit	Kann angewendet werden	Trifft nicht zu

Das Tracking innerhalb derselben Website bietet bereits einen First-Party-Kontext. Das kann für viele Implementierungen ausreichen. Die gemeinsame Nutzung der registrierbaren Domain garantiert jedoch nicht, dass Safari jedes vom Server gesetzte Cookie unangetastet lässt.

Warum Safari vom Server gesetzte Cookies begrenzen kann

Einfach ausgedrückt lautet die Regel: Wenn der Server, der dein Cookie setzt, eine Netzwerkadresse hat, die nichts mit der deiner Haupt-Website zu tun hat, behandelt Safari dies als getarnte Nachverfolgung und begrenzt die Gültigkeit dieses Cookies auf sieben Tage – selbst wenn das Cookie server-side über eine HTTP-Antwort gesetzt wurde.

Von JavaScript gesetzte Cookies waren in Safari bereits auf sieben Tage begrenzt, in einigen Fällen der Link-Gestaltung sogar auf 24 Stunden. Durch das server-side Setzen von Cookies über eine HTTP-Antwort konnte diese Begrenzung bisher umgangen werden. Seit Safari 16.4 (27. März 2023) ist das nicht mehr garantiert: Wenn Safari feststellt, dass das Cookie von einem Server stammt, der nicht zu deiner Hauptwebsite gehört – etwa durch CNAME- oder IP-Adress-Verschleierung –, wendet es dieselbe Sieben-Tage-Beschränkung an.

WebKit entscheidet das, indem es die Netzwerkadresse hinter der Tracking-Antwort mit derjenigen vergleicht, die deine Hauptwebsite verwendet. Es behandelt sie als zu unterschiedlichen Parteien gehörend, wenn eine Adresse IPv4 und die andere IPv6 ist, wenn zwei IPv4-Adressen weniger als 16 führende Bits gemeinsam haben oder wenn zwei IPv6-Adressen weniger als 64 führende Bits gemeinsam haben. WebKit bezeichnet dies als Heuristik, daher kann sich das genaue Verhalten in zukünftigen Browser-Versionen ändern.

Eine gängige Konfiguration für server-side Tracking löst genau das aus. Deine Hauptwebsite läuft hinter Cloudflare, während sst.deinedomain.com auf einen Tracking-Anbieter in einem anderen Netzwerk verweist. Die Namen stammen zwar von derselben Website, ihre Netzwerkadressen stehen jedoch in keinem Zusammenhang, sodass die in der Tracking-Antwort gesetzten Cookies auf sieben Tage begrenzt sind.

Eines muss klar sein: Es handelt sich hierbei nicht um eine siebentägige Begrenzung für jedes vom Server gesetzte First-Party-Cookie. Sie gilt nur, wenn Safari genau diesen bestimmten Cloaking-Fall erkennt. Ein normales Same-Origin-Cookie ist davon nicht betroffen – und genau darauf baut die unten beschriebene Lösung auf.

Was passiert, wenn die Kennung abläuft?

Bei der Messung fallen die Auswirkungen vielleicht nicht auf, können aber letztendlich teuer werden. Wiederkehrende Safari-Besucher werden als neue Besucher gezählt, die Zahlen der neuen Nutzer werden aufgebläht, und die Klicks aus Kampagnen lassen sich nicht mehr mit den darauf folgenden Conversions in Verbindung bringen.

Angenommen, eine Browser-ID ist auf eine Laufzeit von einem Jahr konfiguriert, Safari verkürzt diese jedoch auf sieben Tage. Der Browser kann diese ID während des siebentägigen Zeitraums weiterhin senden. Kehrt der Browser nach Ablauf der Gültigkeit zurück, erstellt das Tracking-System möglicherweise eine neue ID. GA4 oder eine andere Analyseplattform kann dann beide Besuche unter separaten Browser-Identitäten erfassen. Die Zahl der neuen Nutzer könnte steigen, während die Erkennung wiederkehrender Nutzer unvollständiger wird.

Andere Identitätsmerkmale können das Ergebnis beeinflussen. Eine angemeldete Benutzer-ID könnte die Besuche wieder miteinander verknüpfen. Analysesysteme nutzen möglicherweise auch modellierte Daten. Das Ablaufen von Cookies kann daher zu fragmentierten Customer Journeys führen, anstatt zu gewährleisten, dass jeder wiederkehrende Besucher als neuer Besucher gezählt wird – was ein Grund dafür ist, warum deine Meta-, GA4- und Google Ads-Conversions nicht übereinstimmen

Auch bei der Attribution gibt es eine ähnliche Einschränkung. Wenn ein früherer Kampagnenbesuch und eine spätere Conversion keine gemeinsame, verwertbare Kennung mehr haben, kann es für die Messplattform schwierig sein, beide miteinander zu verknüpfen – und so gelangen schwächere Conversion-Daten in das Smart Bidding.

Das konfigurierte Attributionsfenster bleibt eine eigenständige Regel. Ein Cookie mit längerer Lebensdauer verwandelt ein siebentägiges Werbe-Attributionsfenster nicht in ein 30-Tage-Fenster. Es hilft dabei, ein Browsersignal zu erhalten, das für berechtigte Conversions innerhalb des bestehenden Zeitfensters der Plattform genutzt werden kann.

Remarketing funktioniert im Grunde genauso. Stabilere Identifikatoren und zuverlässiger übermittelte Events können die Daten verbessern, die zum Erstellen oder Aktualisieren von Zielgruppen verwendet werden. Die Dauer der Zielgruppenzugehörigkeit, die Einwilligung, Mindestlistengrößen und die Plattformrichtlinien gelten weiterhin.

Wie Same-Origin-Tracking das Szenario mit getrennten Hosts vermeidet

Beim Same-Origin-Tracking sendet der Browser Tracking-Anfragen an einen Pfad auf dem primären Host der Website:

https://yourdomain.com/metrics

Ein Reverse-Proxy empfängt Anfragen unter diesem Pfad und leitet sie an den server-side Tracking-Container weiter. Ein Cloudflare Worker kann dieses Routing am Edge übernehmen.

Bei diesen Aufrufen kommuniziert der Browser mit yourdomain.com und nicht mit einer separaten Tracking-Subdomain. Das Szenario mit separatem Host-CNAME und IP-Cloaking trifft nicht mehr zu. Der Worker sendet die Anfrage an den bestehenden Tracking-Host und leitet dessen Antwort an den Browser weiter. Alle „Set-Cookie“-Header müssen korrekt weitergeleitet werden.

Cookies sind in der Regel nicht auf eine bestimmte Herkunft beschränkt. Ihre Verfügbarkeit hängt von Attributen wie „Domain“, „Path“, „Secure“, „HttpOnly“ und „SameSite“ ab. Der Proxy muss diese Attribute beibehalten oder korrekt konfigurieren.

Das „Same-Origin“-Routing umgeht diese spezielle Sieben-Tage-Beschränkung für das Cloaking. Es macht Cookies jedoch nicht dauerhaft und garantiert auch nicht, dass Safari sie für den gesamten konfigurierten Zeitraum aufbewahrt.

Browser können weitere Einschränkungen vornehmen. Für dauerhafte Cookies gilt zudem häufig eine allgemeine maximale Speicherdauer von etwa 400 Tagen. Nutzer können gespeicherte Daten löschen, ihre Einwilligung ändern oder den Inkognito-Modus nutzen.

Same-Origin-Tracking und Werbeblocker

Ein separater Hostname für das Tracking gibt Blockern ein klares Signal, nach dem sie suchen können. Wenn das Tracking auf einen Pfad auf dem Hauptserver der Website verlagert wird, entfällt dieses Hostname-Signal.

Das kann Blockierungen reduzieren, die durch Hostnamen- und CNAME-Regeln verursacht werden. Eine Zustellung kann dadurch jedoch nicht garantiert werden.

Browser-Erweiterungen können zudem URL-Pfade, Anfragemuster oder webspezifische Regeln abgleichen. Offensichtliche Pfade wie /analytics, /track oder /collect können dennoch von Filtern erfasst werden.

Das „Same-Origin“-Routing sollte daher als Möglichkeit betrachtet werden, bestimmte Blockierungssignale zu reduzieren, und nicht als Methode, die jeden Werbeblocker umgeht.

Was Marketingfachleute davon haben

Same-Origin-Tracking kann die Kontinuität der Cookie-basierten Messung in Safari verbessern. Browser, die nach mehr als einer Woche zurückkehren, erhalten mit geringerer Wahrscheinlichkeit eine neue Kennung, nur weil WebKit einen separaten Tracking-Host als „cloaked“ eingestuft hat.

Eine zuverlässigere Browsererkennung kann Analysetools dabei helfen, längere Kundenreisen miteinander zu verknüpfen. Außerdem können so nützliche Signale für die Attribution und die Zielgruppenverarbeitung erhalten bleiben – im Rahmen der von den jeweiligen Plattformen festgelegten Regeln.

Die Verbesserung betrifft die Messgenauigkeit. Sie sorgt nicht für mehr Besucher oder Conversions. Möglicherweise werden weniger bestehende Nutzerpfade auf mehrere Browser-Identifikatoren aufgeteilt, was bedeutet, dass ein geringerer Teil deiner Auswertungen auf modellierten Conversions basiert.

Die geltenden Datenschutz- und Speichervorschriften gelten weiterhin. Wo eine Einwilligung erforderlich ist, ersetzt die Verlängerung der Lebensdauer eines Cookies diese Einwilligung nicht. Zweck, Dauer und Verwendung der Kennung müssen weiterhin ordnungsgemäß offengelegt werden. Bei korrekter Umsetzung ist das „Same-Origin-Tracking“ ein Teil eines umfassenderen Wandels hin zum First-Party-Daten-Marketing – also einer Messung, die auf Daten basiert, die dir gehören und für die du Rechenschaft ablegen kannst.

Wo TAGGRS passt

TAGGRS unterstützt die Bereitstellung aus derselben Quelle über einen Cloudflare Worker. Bei dieser Implementierung bleiben die bestehende Produkt-ID und der Server-Container erhalten, während die für den Browser sichtbare Route geändert wird.

Das Tracking-Skript und die Erfassungsaufrufe werden über einen Pfad auf dem eigenen Host der Website geladen. Der Worker entfernt dieses Pfadpräfix und leitet jede Anfrage an den bestehenden TAGGRS-Tracking-Host weiter.

Bei dieser speziellen Implementierung muss der Hostname der Website, der die Worker-Route enthält, über Cloudflare weitergeleitet werden. Der Worker ist nur an den ausgewählten Tracking-Pfad gebunden, läuft also nicht bei jeder Website-Anfrage.

Das Standard-TAGGRS-Snippet bleibt bestehen, wobei die URLs für „script“ und „noscript“ so angepasst wurden, dass sie den Same-Origin-Pfad verwenden. Falls Cloudflare den GTM-Preview-Traffic blockiert, solltest du die Sicherheitsevents überprüfen, bevor du eine eng gefasste Ausnahme hinzufügst.

Die vollständige Anleitung findest du in unserer Dokumentation: Same-Origin-Tracking mit einem Cloudflare Worker.

Fazit

Server-side Tracking verbessert die Kontrolle über die Datenerfassung, aber der browserseitige Endpunkt beeinflusst weiterhin, wie lange manche Identifikatoren bestehen bleiben. Eine Subdomain derselben Website kann weiterhin den CNAME- oder IP-Cloaking-Prüfungen von Safari unterliegen. Wenn das Tracking über einen Pfad auf dem exakten Ursprung der Website erfolgt, lässt sich dieses Szenario mit separatem Host vermeiden.

Die Änderung kann die Erkennung wiederkehrender Browser verbessern und für mehr Kontinuität bei der Messung sorgen. Sie erweitert jedoch weder die Attributions-Einstellungen einer Werbeplattform, noch garantiert sie die Speicherung von Cookies, noch macht sie das Tracking immun gegen Werbeblocker.

Bist du bereit, es einzurichten? Folge unserer Schritt-für-Schritt-Anleitung zum Same-Origin-Tracking mit einem Cloudflare Worker oder starte kostenlos mit TAGGRS und bringe zunächst den Server-Container zum Laufen.

FAQ

Ist „Same-Site“-Tracking dasselbe wie „Same-Origin“-Tracking?

Nein. URLs derselben Website haben dasselbe Schema und dieselbe registrierbare Domain, daher können verschiedene Subdomains zur selben Website gehören. „Gleicher Ursprung“ ist strenger: Schema, Host und Port müssen übereinstimmen. https://yourdomain.com und https://sst.yourdomain.com gehören zwar zur selben Website, sind aber unterschiedlicher Herkunft.

Begrenzt Safari die Gültigkeitsdauer jedes First-Party-Cookies auf sieben Tage?

Nein. Permanente Cookies, die über JavaScript erstellt werden, unterliegen den Beschränkungen von WebKit für den durch Skripte beschreibbaren Speicher. Cookies, die über eine HTTP-Antwort gesetzt werden, können ebenfalls eine Begrenzung auf sieben Tage erhalten, wenn WebKit eine Verschleierung von CNAME-Einträgen oder IP-Adressen durch Dritte feststellt. Gewöhnliche, vom Server gesetzte Cookies derselben Herkunft unterliegen dieser speziellen Verschleierungsbeschränkung nicht.

Garantiert das „Same-Origin“-Tracking eine Cookie-Lebensdauer von 400 Tagen?

Nein. Dadurch wird die spezifische Sieben-Tage-Obergrenze umgangen, die mit einer getarnten Tracking-Subdomain verbunden ist. Die konfigurierten Cookie-Attribute, andere Browser-Richtlinien, der private Modus, das Löschen durch den Nutzer und Änderungen der Einwilligungserklärungen können die Speicherdauer dennoch verkürzen oder verhindern. Browser können zudem eine allgemeine maximale Lebensdauer für dauerhafte Cookies festlegen.

Wird das „Same-Origin“-Tracking die Attributions- oder Remarketing-Fenster verlängern?

Nein. Diese Fenster werden von jeder Werbeplattform separat verwaltet. Eine dauerhaftere Browser-Kennung kann zwar dabei helfen, relevante Aktivitäten innerhalb eines bestehenden Fensters miteinander zu verknüpfen, ändert aber weder das Fenster selbst noch die konfigurierte Mitgliedschaftsdauer einer Zielgruppe.

Umgeht das Same-Origin-Tracking alle Werbeblocker?

Nein. Es entfernt den separaten Tracking-Hostnamen, den manche Blockierungsregeln verwenden. Erweiterungen können Anfragen weiterhin anhand von Pfaden, Verhaltensweisen oder webortspezifischen Regeln blockieren. Das Same-Origin-Routing reduziert bestimmte Blockierungssignale, ohne jedoch zu garantieren, dass jede Anfrage zugestellt wird. Für einen umfassenderen Schutz vor Werbeblocker-Techniken kombiniere das Same-Origin-Routing mit Enhanced Tracking Script (ETS v3).