Cloudflare als proxy voor sGTM: zo omzeil je WebKit's CNAME Cloaking-beperking
Door je server-side GTM-subdomein via Cloudflare te proxyen in plaats van direct naar Google Cloud Platform te laten wijzen, krijgen beide domeinen hetzelfde IP-subnet. WebKit (Safari, iOS-browsers) beschouwt ze dan als first-party aan elkaar, waardoor HTTP-response cookies langer dan 7 dagen mogen leven. De ingreep is klein, maar het effect op cookie-levensduur is direct meetbaar in GA4 en andere tracking-oplossingen.
Waarom WebKit server-side GTM-cookies afkapt op 7 dagen
WebKit bevat een mechanisme dat CNAME Cloaking tegengaat. Wanneer een browser een verzoek doet naar een subdomein, vergelijkt WebKit de DNS-records van het hoofddomein en het subdomein. Wijzen die naar significant verschillende IP-subnetten, dan beperkt WebKit de levensduur van cookies die via een HTTP-response worden gezet tot maximaal 7 dagen. Concreet: stel dat je website www.site.example via Cloudflare loopt en daarmee uitkomt op het 188.114.X.X-subnet. Je sGTM-container draait op Google Cloud Platform en is bereikbaar via sst.site.example, dat resolvet naar de 216.239.X.X-reeks. Hoewel beide technisch subdomein zijn van hetzelfde naaktdomein, ziet WebKit de eerste twee octetten als te verschillend en behandelt het sGTM-subdomein als third-party. Resultaat: alle cookies die sGTM via HTTP-responses probeert te zetten, worden afgekapt op 7 dagen, ongeacht de ingestelde vervaldatum.
De oplossing: proxy het sGTM-subdomein via Cloudflare
Als je DNS al bij Cloudflare is ondergebracht, is de aanpassing minimaal. Ga in het Cloudflare-dashboard naar DNS → Records en zoek alle A/AAAA-records op voor je sGTM-subdomein. Zet de Proxy status per record om van 'DNS only' naar 'Proxied'. Na deze wijziging lopen verzoeken naar het sGTM-subdomein via Cloudflare's eigen netwerk, waardoor het IP-subnet overeenkomt met dat van je hoofddomein. Controleer het resultaat via een DNS-lookuptool: de eerste twee octetten van beide domeinen moeten nu overeenkomen.
Verplichte stap: schakel caching uit voor het sGTM-subdomein
Cloudflare cachet standaard responses op geproxyde domeinen. Voor sGTM is dat problematisch: bepaalde interne processen, waaronder de Preview-modus van GTM, werken niet correct als responses worden gecachet. Maak daarom een Cache Rule aan onder Caching → Cache Rules in het Cloudflare-dashboard en stel een 'Bypass cache'-regel in die van toepassing is op je sGTM-subdomein. Zonder deze stap riskeer je onvoorspelbaar gedrag in je server-container.
Wat dit betekent voor je sGTM- en GA4-setup
Na de wijziging kunnen first-party cookies die via je server-container worden gezet, een langere levensduur krijgen dan 7 dagen in Safari en iOS-browsers. Dat is relevant voor sessie-identificatie, gebruikersherkenning en attributie in GA4, maar ook voor signalen die via Meta CAPI worden doorgestuurd op basis van cookie-waarden zoals _fbp of _fbc. Controleer na de DNS-wijziging de volgende zaken: komen verzoeken naar je sGTM-endpoint nog steeds correct binnen in de server-container (check de preview-logs), worden tags correct gefired, en zijn er geen afwijkingen in de data layer of consent-instellingen door onverwachte caching? Test ook of de Preview-modus in GTM nog functioneert, want dat is het eerste dat breekt bij een onjuiste cache-configuratie.
Nuancering: hoeveel is dit waard?
De meerwaarde van deze aanpak hangt sterk af van je huidige DNS-situatie. Gebruik je Cloudflare al voor je hoofddomein, dan is de extra inspanning klein en zijn er mogelijk aanvullende voordelen, zoals toegang tot Cloudflare Workers, Firewall-regels en Bot Management voor je sGTM-endpoint. Migreer je je volledige domeinarchitectuur uitsluitend om cookie-levensduur te verlengen, dan is de investering waarschijnlijk niet proportioneel. WebKit beweegt richting een model waarbij alle first-party opslag standaard beperkt is tenzij de gebruiker expliciet toestemming geeft voor langere opslag. Op dat punt biedt geen enkele serverconfiguratiewijziging meer uitkomst. Behandel deze proxy-aanpak daarom als een zinvolle optimalisatie binnen een bestaande Cloudflare-omgeving, niet als structurele oplossing voor tracking-duurzaamheid op de lange termijn.