Integrationsguide för Cloudflare Zaraz Consent: Serverbaserad tagghantering vid kanten för 2026
Cloudflare Zaraz skiljer sig från de flesta tagghanteringsprodukter som kom före det. Premissen är strukturell snarare än inkrementell: istället för att läsa in Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight och varje annan leverantörs JavaScript i besökarens webbläsare exekverar Zaraz dessa integrationer inuti Cloudflare Workers som körs vid kanten, framför utgivarens ursprungsserver. Webbläsaren ser ett enda litet Zaraz-runtime; leverantörens verktyg körs på serversidan. Det arkitekturiska valet har sammansatta konsekvenser för samtycke. Cookie-ytan krymper dramatiskt eftersom de flesta leverantörscookies aldrig sätts över huvud taget. Fingeravtrycksytan krymper eftersom de flesta leverantörers JavaScript aldrig körs i webbläsarens kontext. Och samtyckets verkställighetspunkt förflyttas från en JavaScript-banderoll som kontrollerar en hög med <script>-taggar till ett serversidigt beslut som avgör vilka Zaraz-integrationer som aktiveras och vilken nyttolast de tar emot. Utgivaren som kopplar Zaraz till ett CMP korrekt får en mindre efterlevnadsyta, snabbare sidor och ett tydligare revisionslog. Utgivaren som behandlar Zaraz som ett snabbare Google Tag Manager och hoppar över samtyckeskopplingen slutar med en regelverksmässig exponering som är svårare att identifiera eftersom så mycket av aktiviteten är osynlig för standardbaserade webbläsarrevisioner.
Vad Zaraz faktiskt gör vid kanten
Zaraz är en serverbaserad tagghanterare som körs inuti Cloudflare Workers. När en besökare laddar en sida innehåller utgivarens HTML ett litet Zaraz-initialiseringsskript — vanligtvis några kilobyte — som samlar en strukturerad händelsenyttolast från webbläsaren (sidvisning, klick, anpassad händelse) och POST:ar den till en Cloudflare-slutpunkt på utgivarens eget domän. Worker tar emot nyttolasten och kör de konfigurerade Zaraz-verktygen mot den: en Google Analytics 4-integration skickar ett Measurement Protocol-träff, en Meta Pixel-integration skickar en Conversions API-händelse, en Mixpanel-integration skickar ett HTTP API-anrop. Leverantörens tredjepartsJavaScript laddas aldrig i webbläsaren, leverantörscookies sätts antingen inte alls eller skrivs via Cloudflares förstapartsdomän genom Worker, och leverantören tar emot bara de uppgifter som utgivarens Zaraz-konfiguration uttryckligen vidarebefordrar.
Det är det arkitekturiska värdeerbjudandet. Det är också varför samtyckesbilden skiljer sig från alla klientsidiga tagghanterare. Med en traditionell inställning är samtycksfrågan om leverantörens JavaScript laddas eller inte. Med Zaraz laddas JavaScript aldrig i något fall — frågan blir om serverns nyttolast skickas eller undertrycks, och om nyttolasten innehåller de identifierare som leverantören behöver för att spåra användaren. Båda frågorna har väldefinierade svar i Zaraz Consent API; utgivarens uppgift är att mappa dem korrekt.
Zaraz Consent API och hur det skiljer sig från klientsidiga CMP:er
Zaraz levereras med en inbyggd samtyckesmodul — Zaraz Consent Tools — som upprätthåller ett per-besökare samtyckestillstånd och kontrollerar vilka konfigurerade verktyg som aktiveras. Tillståndet exponeras via ett litet JavaScript-API: zaraz.consent.set({ analytics: true, marketing: false }) för att registrera en användares val, zaraz.consent.get('analytics') för att läsa det, zaraz.consent.getAll() för hela kartan, zaraz.consent.modal() för att öppna samtyckesUI, och händelseavlyssnare på zaraz.consent.onModalShown och relaterade händelser för anpassat UI-beteende. Varje Zaraz-verktyg i instrumentpanelen konfigureras med ett eller flera ändamåls-ID:n, och Worker kör bara ett verktyg när de relevanta ändamålen är beviljade i besökarens samtyckestillstånd.
Integrationsvalet är om man ska använda Zaraz inbyggda samtyckesmodal eller binda Zaraz till ett externt CMP. Den inbyggda modalen är den enklaste vägen: aktivera Consent Tools, definiera ändamålen, konfigurera varje verktyg med rätt ändamål och leverera. Vägen med externt CMP är rätt val för organisationer som redan standardiserar på Cookiebot, OneTrust, Usercentrics eller ett anpassat CMP — Zaraz verkar sedan nedströms om CMP:et, med CMP:et som anropar zaraz.consent.set() när användaren navigerar genom banderollen. Båda vägarna leder till samma verkställighetspunkt: Worker kontrollerar samtyckestillståndet innan varje verktyg körs, och verktyg vars ändamål inte är beviljade körs helt enkelt inte.
IAB TCF-stöd och regionala regimer
Zaraz lade till IAB TCF v2-stöd 2023 och har spårat ramverket framåt sedan dess. För utgivare som verkar i EEA och UK under TCF-baserade annonspartnerskap översätter integrationen TCF-samtyckssträngen till Zaraz-ändamålstillstånd automatiskt när utgivaren väljer att delta. För icke-TCF-regioner mappar utgivaren anpassade ändamål — vanligtvis analytics, marketing, personalization, functional — direkt till de relevanta Zaraz-verktygen. Samma Worker tillämpar båda, vilket innebär att en enda Zaraz-konfiguration kan betjäna både en EEA-besökare via TCF och en kalifornisk besökare via en anpassad marknadsföringsändamålsgrind utan två parallella pipelines.
Varför Zaraz förändrar GDPR- och ePrivacy-bilden
Den rättsliga ställningen under GDPR, ePrivacy och CCPA är inte undantagen av serversidig exekvering — den rättsliga grunden följer uppgifterna, inte transporten — men den praktiska efterlevnadsytan förändras. Tre förändringar är viktiga.
- Cookie-ytan krymper. De flesta leverantörscookies skrivs aldrig eftersom leverantörens JavaScript aldrig körs i webbläsaren. De cookies som finns kvar är vanligtvis Zaraz egna sessionsidentifierare och eventuella förstapartsidentifierare som utgivaren medvetet har spridit. Den icke-nödvändiga cookie-ytan som banderollen måste kontrollera är därför dramatiskt mindre — ibland bara en eller två cookies mot dussinet-plus som en typisk klientsidigs stack producerar.
- Tredjepartsöverföringens offentliggörande förändras. Eftersom Worker skickar data till leverantörerna via server-till-server-anrop är datasökvägen från besökarens webbläsare till Cloudflares kant och därifrån till de konfigurerade leverantörerna. Integritetspolicyn måste återspegla detta — Cloudflare är en personuppgiftsbiträde och varje Zaraz-verktyg är en nedströms mottagare — men offentliggörandet är på många sätt tydligare än den motsvarande klientsidiga vägen eftersom utgivaren har full kontroll över vad som vidarebefordras.
- Revisionsloggen är mer centraliserad. Eftersom varje leverantörshändelse passerar genom Worker har utgivaren en enda punkt vid vilken samtyckestillståndet, händelsens nyttolast och nedströms mottagare kan loggas. Tillsynsmyndigheter som förväntar sig en sökbar samtyckesblogg har ett tydligare svar med Zaraz än med en spridning av klientsidiga taggar.
Integrationsmönstret som fungerar
Referensimplementationen har fyra rörliga delar. Den första är Zaraz-initieringen på sidan, laddad från utgivarens domän via Cloudflares proxy. Den andra är antingen den inbyggda Consent Tools-modalen eller ett externt CMP som anropar zaraz.consent.set() när användaren gör val. Den tredje är Zaraz instrumentpanelskonfigurationen som mappar varje verktyg till rätt ändamål — analysverktyg till analysändamålet, annonseringsverktyg till marknadsföringsändamålet, sessionsuppspelningsverktyg till ett striktare funktionellt eller forskningsändamål, och alla verktyg beroende av tredjepartsöverföring till gränsöverskridande överföringsändamålet om utgivarens integritetspolicy exponerar det som ett separat val. Den fjärde är en serversidig logg — antingen Cloudflare Analytics, Logpush till utgivarens datasjö, eller en anpassad Worker som skriver samtycksbeslut till ett sökbart arkiv — så att samtycksposten kan produceras på regleringsmyndighetens begäran.
Valideringssteget är samma fyra-kontroll-sekvens som gäller för alla samtyckesintegrationer men med en Zaraz-specifik twist. En ren webbläsarsession med banderollen visad men inget val gjort bör producera noll förfrågningar från besökarens webbläsare till något leverantörsdomän och noll icke-nödvändiga cookies — båda är lättare att bekräfta med Zaraz än med en klientsidigs stack eftersom frånvaron av tredjepartsförfrågningar är standardvärdet snarare än ett konfigurerat undantag. En avslagsbesök bör behålla det tillståndet. En acceptbesök bör producera Zaraz-slutpunkts-POST:arna som bär bara de händelser som användaren samtyckte till, och Worker-loggarna bör visa att det nedströms verktyget aktiveras. Ett återkallande bör omedelbart stoppa ytterligare Worker-verktygsexekveringar, låta Zaraz-satta cookies gå ut och utlösa lämpliga borttagnings- eller avanmälningssignaler till de konfigurerade nedströms leverantörerna.
Var Zaraz fortfarande kräver noggrann hantering
Zaraz är inte en samtyckeslösning per arkitektur som eliminerar behovet av att tänka. Tre områden kräver avsiktlig hantering. Klicka-för-att-ladda-inbäddningar — YouTube, Twitter, Instagram, TikTok-video — behöver fortfarande samma platshållarmönster som varje samtycke-först-driftsättning använder, eftersom Zaraz för närvarande inte proxyar inbäddade video-iframes. Klientsidiga identifierare som utgivaren väljer att ange i webbläsaren för förstapartsändamål — ett inloggat användar-ID, en sessionstoken, en A/B-testbucket — förblir på utgivarens sida av samtycksgränsen och behöver sin egen styrlogik. Och integritetspolicyn måste korrekt beskriva serversidig överföringsmodell, inklusive Cloudflares roll som personuppgiftsbiträde och den geografiska platsen för de Workers som hanterar data, eftersom Cloudflare-kanten körs i flera regioner och besökarens trafik kan behandlas i en region som inte är deras egna. Med dessa hanterade förvandlas en Zaraz-driftsättning 2026 från en tagghanteringsprodukt till en av de renaste samtyckesarkitekturerna en utgivare kan köra: mindre cookie-yta, färre tredjepartsförfrågningar, centraliserat verkställande och en revisionslogg som en regleringsmyndighet faktiskt kan läsa.