← Alle resources Gids

Waarom Safari je cookies nog steeds na 7 dagen weggooit, ook met server-side tagging

Overstappen op server-side tagging wordt vaak verkocht als de oplossing voor de cookielimiet van 7 dagen in Safari. Voor de meeste setups is het dat niet meer. Sinds Safari 16.4 beslist niet wie de cookie zet, maar waar de server draait die hem zet, en voor bijna elke gehoste taggingserver is dat ergens anders dan je website.

Wat Safari beperkt

Safari's Intelligent Tracking Prevention (ITP) beperkt cookies die JavaScript schrijft, zoals de cookie _ga die de Google-tag in de browser zet, tot 7 dagen. Komt een bezoeker binnen via een link met trackingparameters vanaf een bekend trackingdomein, dan is het 24 uur. Een bezoeker die na een week terugkomt, is voor je analytics een nieuwe gebruiker.

Cookies die een server in een HTTP-response zet, waren de manier om dit te omzeilen: Safari behandelde ze als echte first-party cookies en liet ze hun volledige levensduur leven. Daar is server-side cookieverlenging, ook onze Cookie Keeper, op gebouwd.

De wijziging in Safari 16.4

Sinds maart 2023 beperkt Safari ook door een server gezette cookies tot 7 dagen als de server eruitziet als een vermomde derde partij. Het controleert twee dingen:

Een tagging-subdomein zoals mbase.yourshop.com wijst naar de server van je tagging-aanbieder, niet naar die van je website. Safari ziet het andere adres en beperkt elke cookie die dat subdomein zet tot 7 dagen, door de server gezet of niet.

Wie het raakt

Vrijwel elke setup waarin de taggingserver op een apart subdomein draait, welke aanbieder hem ook host. Onze tracking-audit vindt het op meer dan de helft van de domeinen die hij controleert. Wie eraan ontsnapt, draait website en taggingserver op hetzelfde netwerk, en dat is zeldzaam.

Wat het kost: terugkerende Safari- en iPhone-bezoekers tellen na een week als nieuw, conversies die langer duren verliezen hun oorspronkelijke bron, en remarketingdoelgroepen die op terugkerende bezoekers zijn gebouwd, krimpen. Op veel Nederlandse sites is Safari een derde of meer van al het verkeer.

Zo controleer je je eigen setup

De tracking-audit van Measurebase controleert het elke nacht en zegt het zonder omwegen: "Safari beperkt de cookies die je tagging-subdomein zet tot 7 dagen: het draait op een andere server dan je website." Met de hand controleer je het door het IP-adres van je website en van je tagging-subdomein op te zoeken (bijvoorbeeld met dig of een online DNS-lookup) en de eerste twee getallen te vergelijken.

De oplossing: tracking vanaf je eigen domein

Safari kijkt alleen naar de server die antwoordt. Serveer je tagging vanaf een pad op je eigen website, zoals https://www.jouwshop.nl/mb, en dan beantwoordt het adres van je eigen website de requests. Je hosting of CDN stuurt dat pad op de achtergrond door naar de taggingserver, en Safari behandelt de cookies weer als die van jezelf.

In Measurebase doet de power-up Same-Origin Tracking dit. Je krijgt een kant-en-klare doorstuurregel voor Vercel, Next.js, Cloudflare, Netlify, nginx en Apache, en de WordPress- en Shopware-plugins sturen zelf door. Een live check bevestigt dat het pad je taggingserver bereikt, het IP-adres van de bezoeker doorgeeft en cookies terugstuurt. Daarna genereer je je script opnieuw en laadt het vanaf je eigen domein.

Twee dingen om te weten:

Veelgestelde vragen

Helpt een CNAME naar de taggingserver?

Nee. Safari herkent CNAME-cloaking ook, en beperkt die cookies op dezelfde manier.

Doen Chrome en Firefox hetzelfde?

Nee. Zij doen deze controle niet. Chrome beperkt elke cookie tot hoogstens 400 dagen, wie hem ook zet.

Houden mijn bestaande bezoekers hun geschiedenis?

Bezoekers van wie de cookie nog geldig is, houden die. Vanaf de overstap worden hun cookies vanaf je eigen domein gezet en houden ze hun volledige levensduur.

Verder lezen

Klaar om je tagging naar Nederland te verhuizen?

Gratis starten, geen creditcard nodig. Binnen een kwartier live.

Gratis starten