De limiet van 7 dagen voor cookies in Safari: hoe ‘same-origin tracking’ de volledige levensduur van cookies herstelt

Een Safari-bezoeker vindt je via een advertentie, bekijkt een paar producten en vertrekt weer. Acht dagen later komt diezelfde gebruiker terug en koopt iets. Je analytics registreert dit als een nieuwe gebruiker in plaats van beide bezoeken aan elkaar te koppelen.

De bezoeker is niet van apparaat gewisseld en heeft zijn cookies niet gewist. Een identificatiecode in Safari is gewoon verlopen.

Server-side tracking maakt het verzamelen van gegevens minder afhankelijk van directe verzoeken aan analyse- en advertentieplatforms. Het kan ook gebruikmaken van cookies die via een HTTP-respons worden geplaatst, die anders worden behandeld dan cookies die door JavaScript worden aangemaakt.

Maar tracking aan de server-side alleen is geen garantie voor een lange levensduur van de cookie. Het openbare eindpunt dat de browser gebruikt, blijft belangrijk. In Safari kan een subdomein voor tracking binnen dezelfde site te maken krijgen met een cookie-limiet van zeven dagen als WebKit merkt dat er CNAME- of IP-adressen worden verborgen.

Tracking binnen dezelfde oorsprong helpt dat specifieke probleem te voorkomen.

Server-side tracking sluit de browser niet uit van de meting

In een typische client-side opzet sturen tags in de browser events rechtstreeks naar analyse- en advertentieplatforms. Server-side tagging verandert die route. Code aan de browserzijde stuurt geselecteerde events eerst naar een servercontainer. Die container verwerkt de gegevens en stuurt ze door naar de juiste bestemmingen. Hierdoor heeft de website meer controle over wat er wordt verzameld en gedeeld. Het vermindert ook de afhankelijkheid van browserverzoeken van derden die mogelijk worden geblokkeerd.

Het herkennen van anonieme bezoekers hangt nog steeds vaak af van een identificatiecode die in de browser is opgeslagen. GA4 gebruikt bijvoorbeeld vaak een client-ID die in een first-party cookie is opgeslagen om dezelfde browser bij verschillende bezoeken te herkennen. Een cookie identificeert een browsersessie, niet per se een persoon. Een gebruikers-ID van een ingelogde gebruiker, gemodelleerde gegevens en andere identiteitsmethoden kunnen ook helpen om activiteiten aan elkaar te koppelen.

'Same-site' en 'same-origin' zijn niet hetzelfde

De twee termen worden door elkaar gebruikt, maar voor een browser betekenen ze iets anders.

'Same-site' betekent hetzelfde registreerbare domein. 'Same-origin' is strenger: het schema, de host en de poort moeten allemaal overeenkomen. Een tracking-subdomein voldoet aan de eerste voorwaarde, maar niet aan de tweede.

Neem bijvoorbeeld de website https://yourdomain.com. Het tracking-eindpunt daarvan draait misschien op https://sst.yourdomain.com. Beide maken gebruik van HTTPS en delen het registreerbare domein yourdomain.com, dus volgens de moderne definitie behoren ze tot dezelfde site, maar het zijn nog steeds verschillende origins, omdat de host verschilt.

Verplaats het eindpunt naar een pad op de eigen host van de site, zoals https://yourdomain.com/metrics, en de pagina en het tracking-eindpunt delen eindelijk hetzelfde schema, dezelfde host en dezelfde poort. Nu zijn ze van dezelfde oorsprong.

	Subdomein op dezelfde site	Pad van dezelfde oorsprong
Voorbeeld	sst.jouwdomein.com	yourdomain.com/metrics
De browser ziet	Een aparte host	Je eigen site
Hetzelfde schema + host + poort als jouw site	Nee	Ja
Safari-cloakinglimiet	Kan worden toegepast	Gaat niet op

Tracking binnen dezelfde site biedt al een first-party-context. Dat kan voor veel toepassingen al voldoende zijn. Maar het delen van hetzelfde registreerbare domein garandeert niet dat Safari elke door de server geplaatste cookie met rust laat.

Waarom Safari door de server geplaatste cookies kan beperken

De regel in eenvoudige bewoordingen is: als de server die je cookie plaatst, op een netwerkadres staat dat geen verband houdt met dat van je hoofdsite, beschouwt Safari dit als verkapte tracking en beperkt het de geldigheidsduur van die cookie tot zeven dagen, zelfs als de cookie server-side via een HTTP-respons is geplaatst.

Cookies die door JavaScript worden geplaatst, hadden in Safari al een maximale geldigheidsduur van zeven dagen, en in sommige gevallen van linkversiering van 24 uur. Door cookies server-side in te stellen via een HTTP-respons kon je die limiet vroeger omzeilen. Sinds Safari 16.4 (27 maart 2023) is dat niet meer gegarandeerd: als Safari detecteert dat de cookie afkomstig is van een server die geen verband houdt met je hoofdsite, via CNAME- of IP-adresmaskering, past het dezelfde limiet van zeven dagen toe.

WebKit bepaalt dit door het netwerkadres achter het tracking-antwoord te vergelijken met het adres dat je hoofdwebsite gebruikt. Het beschouwt ze als behorend tot verschillende partijen wanneer het ene adres IPv4 is en het andere IPv6, wanneer twee IPv4-adressen minder dan 16 voorloopbits gemeen hebben, of wanneer twee IPv6-adressen minder dan 64 voorloopbits gemeen hebben. WebKit noemt dit een heuristiek, dus het exacte gedrag kan in toekomstige browserversies veranderen.

Een veelvoorkomende opzet voor tracking aan de server-side zorgt precies hiervoor. Je hoofdwebsite draait via Cloudflare, terwijl sst.jouwdomein.com doorverwijst naar een trackingprovider op een ander netwerk. De domeinnamen behoren tot dezelfde site, maar hun netwerkadressen staan los van elkaar, waardoor cookies die in het trackingantwoord worden geplaatst, na zeven dagen verlopen.

Eén ding moet even duidelijk zijn: dit is geen limiet van zeven dagen voor elke first-party cookie die door de server wordt geplaatst. Het geldt alleen wanneer Safari die specifieke cloaking-situatie detecteert. Een gewone same-origin cookie wordt hierdoor niet beïnvloed, en daar is de onderstaande oplossing precies op gebaseerd.

Wat gebeurt er als de identificatiecode verloopt?

Bij het meten vallen de gevolgen misschien niet meteen op, maar ze kunnen uiteindelijk wel in de papieren lopen. Terugkerende Safari-bezoekers worden als nieuwe bezoekers geteld, waardoor het aantal nieuwe gebruikers opblaast en de klikken op campagnes niet meer gekoppeld worden aan de conversies die daarop volgen.

Stel dat een browser-ID is ingesteld op een geldigheidsduur van één jaar, maar dat Safari die terugbrengt naar zeven dagen. De browser kan die ID gedurende die periode van zeven dagen blijven versturen. Als de browser terugkomt nadat de ID is verlopen, kan het tracking-systeem een nieuwe ID aanmaken. GA4 of een ander analyseplatform kan dan beide bezoeken onder aparte browser-ID’s meten. Het aantal nieuwe gebruikers kan stijgen, terwijl terugkerende gebruikers minder goed worden herkend.

Andere identiteitssignalen kunnen de uitkomst beïnvloeden. Een aangemelde gebruikers-ID kan de bezoeken weer aan elkaar koppelen. Analysesystemen kunnen ook gebruikmaken van gemodelleerde gegevens. Het verlopen van cookies kan dus leiden tot gefragmenteerde trajecten, in plaats van te garanderen dat elke terugkerende bezoeker als nieuwe bezoeker wordt geteld. Dat is een van de redenen waarom je conversies in Meta, GA4 en Google Ads niet met elkaar overeenkomen

Attributie heeft te maken met een soortgelijke beperking. Als een eerder campagnebezoek en een latere conversie geen bruikbare identificatiecode meer gemeen hebben, kan het meetplatform moeite hebben om ze aan elkaar te koppelen, waardoor er zwakkere conversiegegevens bij Smart Bidding terechtkomen.

Het ingestelde attributievenster blijft een aparte regel. Een cookie met een langere levensduur verandert een advertentie-attributievenster van zeven dagen niet in een venster van 30 dagen. Het helpt om een browsersignaal te behouden dat kan worden gebruikt voor in aanmerking komende conversies binnen het bestaande venster van het platform.

Remarketing werkt op vrijwel dezelfde manier. Stabilere identificatiecodes en betrouwbaarder geleverde events kunnen de gegevens verbeteren die worden gebruikt om doelgroepen samen te stellen of bij te werken. De duur van het lidmaatschap van een doelgroep, toestemming, minimale lijstgroottes en platformbeleidsregels blijven van toepassing.

Hoe 'same-origin tracking' het scenario met afzonderlijke hosts voorkomt

Bij ‘same-origin tracking’ stuurt de browser trackingverzoeken naar een pad op de primaire host van de website:

https://yourdomain.com/metrics

Een reverse proxy ontvangt verzoeken onder dat pad en stuurt ze door naar de server-side Tracking-container. Een Cloudflare Worker kan deze routering aan de rand uitvoeren.

Bij deze verzoeken communiceert de browser met yourdomain.com, niet met een apart tracking-subdomein. Het scenario met een aparte host via CNAME en IP-cloaking is niet langer van toepassing. De Worker stuurt het verzoek naar de bestaande tracking-host en stuurt het antwoord daarvan terug naar de browser. Eventuele Set-Cookie-headers moeten correct worden doorgestuurd.

Cookies zijn over het algemeen niet beperkt tot één oorsprong. Of ze beschikbaar zijn, hangt af van eigenschappen zoals Domain, Path, Secure, HttpOnly en SameSite. De proxy moet die eigenschappen behouden of correct instellen.

Met ‘same-origin routing’ omzeil je deze specifieke limiet van zeven dagen voor het verbergen van cookies. Het maakt cookies niet permanent en garandeert ook niet dat Safari ze de volledige ingestelde periode bewaart.

Browsers kunnen nog andere beperkingen opleggen. Voor permanente cookies geldt meestal ook een algemene maximale bewaartermijn van zo’n 400 dagen. Je kunt je opgeslagen gegevens verwijderen, je toestemming aanpassen of in de incognitomodus browsen.

Tracking binnen dezelfde oorsprong en advertentieblokkers

Een aparte hostnaam voor tracking geeft blokkers een duidelijk signaal om op te reageren. Door de tracking te verplaatsen naar een pad op de hoofdhost van de website verdwijnt dat signaal van de hostnaam.

Dat kan blokkades door hostnaam- en CNAME-regels verminderen. Het is echter geen garantie dat de gegevens ook daadwerkelijk worden afgeleverd.

Browser-extensies kunnen ook URL-paden, verzoekpatronen of sitespecifieke regels herkennen. Voor de hand liggende paden zoals /analytics, /track of /collect kunnen nog steeds door filters worden tegengehouden.

Routing vanuit dezelfde oorsprong moet daarom worden gezien als een manier om specifieke blokkeringssignalen te verminderen, niet als een methode die elke adblocker omzeilt.

Wat marketeers hieraan hebben

Tracking van dezelfde oorsprong kan de continuïteit van op cookies gebaseerde metingen in Safari verbeteren. Browsers die na meer dan een week terugkomen, krijgen minder snel een nieuwe identificatiecode, alleen maar omdat WebKit een aparte trackinghost als ‘verborgen’ heeft aangemerkt.

Een duurzamere browserherkenning kan analytics helpen om langere klanttrajecten in kaart te brengen. Het kan ook nuttige signalen bewaren voor attributie en doelgroepanalyse, binnen de regels die door elk platform zijn vastgesteld.

De verbetering heeft betrekking op de meetnauwkeurigheid. Het zorgt niet voor meer bezoekers of conversies. Er zullen wellicht minder bestaande trajecten over meerdere browser-ID’s worden verdeeld, wat betekent dat je rapportages minder op gemodelleerde conversies zijn gebaseerd.

De geldende regels voor privacy en opslag op apparaten blijven van kracht. Als er toestemming nodig is, vervangt het verlengen van de levensduur van een cookie die toestemming niet. Het doel, de duur en het gebruik van de identificatiecode moeten duidelijk worden vermeld. Als je het goed aanpakt, is ‘same-origin tracking’ een onderdeel van een bredere verschuiving naar first-party datamarketing — metingen op basis van gegevens die je zelf bezit en waarover je verantwoording kunt afleggen.

Waar TAGGRS past

TAGGRS ondersteunt ‘same-origin serving’ via een Cloudflare Worker. Bij deze implementatie blijven de bestaande product-ID en servercontainer behouden, terwijl de route naar de browser wordt aangepast.

Het trackingscript en de verzamelverzoeken worden geladen via een pad op de eigen host van de website. De Worker verwijdert dat padvoorvoegsel en stuurt elk verzoek door naar de bestaande TAGGRS-trackinghost.

Voor deze specifieke implementatie moet de hostnaam van de website met de Worker-route via Cloudflare worden doorgestuurd. De Worker is alleen gekoppeld aan het geselecteerde trackingpad, dus hij wordt niet bij elk verzoek aan de website uitgevoerd.

Het standaard TAGGRS-fragment blijft intact, waarbij de script- en noscript-URL’s zijn aangepast om het same-origin-pad te gebruiken. Als Cloudflare het verkeer van GTM Preview blokkeert, moet je eerst de beveiligingsevents controleren voordat je een uitzondering met een beperkte reikwijdte toevoegt.

Je vindt de volledige handleiding in onze documentatie: Tracking met dezelfde oorsprong met een Cloudflare Worker.

Conclusie

Tracking aan de server-side geeft je meer controle over het verzamelen van gegevens, maar het eindpunt aan de browserzijde heeft nog steeds invloed op hoe lang sommige identificatiecodes blijven bestaan. Een subdomein op dezelfde site kan nog steeds onderworpen zijn aan de CNAME- of IP-cloaking-controles van Safari. Door tracking via een pad op de exacte oorsprong van de website te laten lopen, voorkom je dat scenario met een aparte host.

Deze aanpassing kan de herkenning van terugkerende browsers verbeteren en zorgt voor meer continuïteit in de metingen. Het breidt de attributie-instellingen van een advertentieplatform niet uit, garandeert geen opslag van cookies en maakt tracking niet immuun voor adblockers.

Klaar om het in te stellen? Volg onze stapsgewijze handleiding over Same-origin tracking met een Cloudflare Worker, of begin gratis met TAGGRS en zet eerst de servercontainer aan de praat.

Veelgestelde vragen

Is tracking binnen dezelfde site hetzelfde als tracking binnen dezelfde oorsprong?

Nee. URL’s van dezelfde site hebben hetzelfde schema en hetzelfde registreerbare domein, dus verschillende subdomeinen kunnen tot dezelfde site behoren. ‘Zelfde oorsprong’ is strenger: het schema, de host en de poort moeten overeenkomen. https://yourdomain.com en https://sst.yourdomain.com zijn van dezelfde site, maar hebben een verschillende oorsprong.

Beperkt Safari de geldigheidsduur van elke first-party cookie tot zeven dagen?

Nee. Permanente cookies die via JavaScript worden aangemaakt, vallen onder de beperkingen van WebKit voor opslagruimte die door scripts kan worden geschreven. Cookies die via een HTTP-respons worden ingesteld, kunnen ook een limiet van zeven dagen krijgen als WebKit CNAME- of IP-adresmaskering door derden detecteert. Gewone, door de server ingestelde cookies van dezelfde oorsprong vallen niet onder die specifieke maskeringslimiet.

Garandeert ‘same-origin tracking’ een levensduur van 400 dagen voor cookies?

Nee. Het omzeilt de specifieke limiet van zeven dagen die geldt voor een verborgen tracking-subdomein. De ingestelde cookie-instellingen, andere browserbeleidsregels, privémodus, het verwijderen van gegevens door de gebruiker en wijzigingen in toestemming kunnen de opslagduur nog steeds verkorten of helemaal voorkomen. Browsers kunnen ook een algemene maximale levensduur toepassen op permanente cookies.

Zal tracking binnen dezelfde oorsprong de attributie- of remarketingperiodes verlengen?

Nee. Die vensters worden door elk advertentieplatform apart beheerd. Een duurzamere browser-ID kan helpen om in aanmerking komende activiteiten binnen een bestaand venster aan elkaar te koppelen, maar het verandert niets aan het venster zelf of aan de ingestelde lidmaatschapsduur van een doelgroep.

Omzeilt ‘same-origin tracking’ alle adblockers?

Nee. Het verwijdert de aparte tracking-hostnaam die sommige blokkeerregels gebruiken. Extensies kunnen verzoeken nog steeds blokkeren op basis van pad, gedrag of sitespecifieke regels. Same-origin routing vermindert bepaalde blokkeringssignalen, maar garandeert niet dat elk verzoek wordt afgeleverd. Voor bredere bescherming tegen advertentieblokkeringstechnieken kun je same-origin routing combineren met Enhanced Tracking Script (ETS v3).