Hva Zaraz faktisk gjør ved kanten

Zaraz er en server-side tag-håndterer som kjøres inne i Cloudflare Workers. Når en besøkende laster en side, inkluderer utgiverens HTML et lite Zaraz-initialiseringsskript — vanligvis noen kilobytes — som samler en strukturert hendelsesnyttelast fra nettleseren (sidevisning, klikk, tilpasset hendelse) og POST-er den til et Cloudflare-endepunkt på utgiverens eget domene. Workeren mottar den nyttelasten og kjører de konfigurerte Zaraz-verktøyene mot den: en Google Analytics 4-integrasjon sender et Measurement Protocol-treff, en Meta Pixel-integrasjon sender en Conversions API-hendelse, en Mixpanel-integrasjon sender et HTTP API-kall. Leverandørens tredjeparts-JavaScript lastes aldri inn i nettleseren, leverandørkapslene settes enten ikke i det hele tatt eller skrives gjennom Cloudflares førsteparts-domene via Workeren, og leverandøren mottar kun dataene som utgiverens Zaraz-konfigurasjon eksplisitt videresender.

Det er det arkitekturale verdiforslaget. Det er også grunnen til at samtykkebildet er annerledes enn hos enhver klientsides tag-håndterer. Med et tradisjonelt oppsett er samtykkespørsmålet om leverandørens JavaScript lastes eller ikke lastes. Med Zaraz lastes JavaScript aldri inn i begge tilfeller — spørsmålet blir om server-side nyttelasten sendes eller undertrykkes, og om nyttelasten inneholder identifikatorene leverandøren trenger for å spore brukeren. Begge spørsmål har veldefinerte svar i Zaraz Consent API; utgiverens jobb er å kartlegge dem riktig.

Zaraz Consent API og hvordan den skiller seg fra klientside-CMP-er

Zaraz leveres med en innebygd samtykkemodul — Zaraz Consent Tools — som opprettholder en per-besøker samtykkestatus og portvoker hvilke konfigurerte verktøy som utløses. Statusen eksponeres gjennom et lite JavaScript-API: zaraz.consent.set({ analytics: true, marketing: false }) for å registrere en brukers valg, zaraz.consent.get('analytics') for å lese det, zaraz.consent.getAll() for hele kartet, zaraz.consent.modal() for å åpne samtykke-UI-en, og hendelses-lyttere på zaraz.consent.onModalShown og relaterte hendelser for tilpasset UI-atferd. Hvert Zaraz-verktøy i dashbordet er konfigurert med én eller flere formåls-IDer, og Workeren kjører bare et verktøy når de relevante formålene er innvilget i besøkerens samtykkestatus.

Integrasjonsvalget er om du bruker Zaraz sin innebygde samtykkedialog eller binder Zaraz til en ekstern CMP. Den innebygde dialogen er den enkleste veien: aktiver Consent Tools, definer formålene, konfigurer hvert verktøy med riktig formål, og ship. Ekstern-CMP-veien er det riktige valget for organisasjoner som allerede standardiserer på Cookiebot, OneTrust, Usercentrics eller en tilpasset CMP — Zaraz opererer da nedstrøms for CMP, med CMP-en som kaller zaraz.consent.set() ettersom brukeren går gjennom banneret. Begge veier lander på samme håndhevingspunkt: Workeren sjekker samtykkestatus før hvert verktøy kjøres, og verktøy hvis formål ikke er innvilget kjøres rett og slett ikke.

IAB TCF-støtte og de regionale regimene

Zaraz la til IAB TCF v2-støtte i 2023 og har fulgt rammeverket fremover siden. For utgivere som opererer i EEA og UK under TCF-baserte annonseringspartnerskap oversetter integrasjonen TCF-samtykkestrengen til Zaraz-formålsstatus automatisk når utgiveren velger det. For ikke-TCF-regioner kartlegger utgiveren tilpassede formål — typisk analytics, marketing, personalization, functional — direkte til de relevante Zaraz-verktøyene. Den samme Workeren håndhever begge, noe som betyr at én Zaraz-konfigurasjon kan betjene både en EEA-besøkende gjennom TCF og en Californisk besøkende gjennom en tilpasset markedsføringformåls-port uten to parallelle pipelines.

Hvorfor Zaraz endrer GDPR- og ePrivacy-bildet

Den juridiske posisjonen under GDPR, ePrivacy og CCPA er ikke fritatt av server-side-kjøring — det juridiske grunnlaget følger dataene, ikke transporten — men den praktiske samsvaroverflaten endres. Tre skift er viktige.

• Informasjonskapsel-overflaten krymper. De fleste leverandørkapsler skrives aldri fordi leverandørens JavaScript aldri kjøres i nettleseren. Kapslene som gjenstår er typisk Zaraz sin egen økt-identifikator og eventuelle førstepartsidentifikatorer som utgiveren bevisst har propagert. Den ikke-essensiell-kapsel-overflaten som banneret må portvokte er derfor dramatisk mindre — noen ganger bare én eller to kapsler versus dusinvis som en typisk klientside-stack produserer.
• Tredjepartsoverføringens opplysning endres. Fordi Workeren sender data til leverandørene via server-til-server-kall, er datastien fra besøkerens nettleser til Cloudflares kant og derfra til de konfigurerte leverandørene. Personvernerklæringen må gjenspeile dette — Cloudflare er en behandler og hvert Zaraz-verktøy er en nedstrøms mottaker — men opplysningen er på mange måter renere enn den tilsvarende klientsides stien fordi utgiveren har full kontroll over hva som videresendes.
• Revisjons-sporet er mer sentralisert. Fordi hver leverandørhendelse passerer gjennom Workeren, har utgiveren ett punkt der samtykkestatus, hendelsesnyttelast og nedstrøms mottaker kan logges. Regulatorer som forventer en søkbar samtykkelogg har et klarere svar med Zaraz enn med en spredning av klientside-tagger.

Integrasjonsmønsteret som fungerer

Referanseimplementeringen har fire bevegelige deler. Den første er Zaraz-initialiseringen på siden, lastet fra utgiverens domene via Cloudflares proxy. Den andre er enten den innebygde Consent Tools-dialogen eller en ekstern CMP som kaller zaraz.consent.set() ettersom brukeren gjør valg. Den tredje er Zaraz-dashbordkonfigurasjonen som kartlegger hvert verktøy til de riktige formålene — analyseverktøy til analyse-formålet, annonseringsverktøy til markedsføringsformålet, økt-replay-verktøy til et strengere funksjonelt eller forskningsformål, og ethvert grensekryssende overføringsvhengig verktøy til grensekryssende overføringsformålet hvis utgiverens personvernerklæring eksponerer det som et eget valg. Den fjerde er en server-side logg — enten Cloudflare Analytics, Logpush til en utgivers data-lake, eller en tilpasset Worker som skriver samtykkevedtak til en søkbar lagring — slik at samtykke-registreringen kan produseres på regulatorforespørsel.

Valideringstrinn er den samme fire-sjekks-sekvensen som gjelder for enhver samtykkeintegrasjon men med et Zaraz-spesifikt vri. En ren nettleserøkt med banneret vist men uten valg gjort bør produsere null forespørsler fra besøkerens nettleser til ethvert leverandørdomene og null ikke-essensielle kapsler — begge er lettere å bekrefte med Zaraz enn med en klientside-stack fordi fraværet av tredjepartsforespørsler er standard snarere enn et konfigurert unntak. Et avvisnings-besøk bør opprettholde den tilstanden. Et godkjennings-besøk bør produsere Zaraz-endepunkt-POST-ene som bærer bare hendelsene brukeren samtykket til, og Worker-loggene bør vise aktivering av nedstrøms verktøy. En tilbaketrekking bør umiddelbart stoppe ytterligere Worker-verktøy-kjøringer, utløpe eventuelle Zaraz-satte kapsler, og utløse de riktige slettings- eller opt-ut-signalene til de konfigurerte nedstrøms leverandørene.

Hvor Zaraz fortsatt krever forsiktig håndtering

Zaraz er ikke en samtykke-ved-arkitektur-løsning som fjerner behovet for å tenke. Tre områder krever bevisst håndtering. Klikk-for-å-laste-innebygg — YouTube, Twitter, Instagram, TikTok-video — trenger fortsatt det samme plassholter-mønsteret som enhver samtykke-først-implementering bruker, fordi Zaraz for øyeblikket ikke proxyer innebygde video-iframes. Klientside-identifikatorer som utgiveren velger å sette i nettleseren for førstepartsformål — en innlogget bruker-ID, et økt-token, et A/B-testbøtte — forblir på utgiverens side av samtykkegrensen og trenger sin egen port-logikk. Og personvernerklæringen må nøyaktig beskrive server-side overføringsmodellen, inkludert Cloudflares rolle som behandler og den geografiske plasseringen av Workerne som håndterer dataene, fordi Cloudflare-kanten opererer i flere regioner og besøkerens trafikk kan behandles i en region som ikke er deres egen. Med disse håndtert, forvandler en Zaraz-implementering i 2026 seg fra et tag-håndteringsprodukt til en av de reneste samtykke-arkitekturene en utgiver kan kjøre: mindre kapsel-overflate, færre tredjepartsforespørsler, sentralisert håndhevelse, og et revisjons-spor som en regulator faktisk kan lese.