Hvad Zaraz faktisk gør på kanten

Zaraz er en server-side tag manager, der eksekveres inde i Cloudflare Workers. Når en besøgende indlæser en side, inkluderer udgiverens HTML et lille Zaraz-initialiseringsscript — typisk et par kilobytes — der samler en struktureret hændelses-payload fra browseren (sidevisning, klik, tilpasset hændelse) og POSTer den til et Cloudflare-endepunkt på udgiverens eget domæne. Workeren modtager den payload og kører de konfigurerede Zaraz-værktøjer mod den: en Google Analytics 4-integration sender et Measurement Protocol-hit, en Meta Pixel-integration sender en Conversions API-hændelse, en Mixpanel-integration sender et HTTP API-kald. Leverandørens tredjeparts JavaScript indlæses aldrig i browseren, leverandørens cookies sættes enten slet ikke eller skrives via Cloudflares førstepartsdomæne via Workeren, og leverandøren modtager kun de data, som udgiverens Zaraz-konfiguration eksplicit videresender.

Det er det arkitektoniske værdiforslag. Det er også grunden til, at samtykkebilledet er anderledes end med nogen klientside tag manager. Med en traditionel opsætning er samtykkespørgsmålet, om leverandørens JavaScript indlæses eller ej. Med Zaraz indlæses JavaScript aldrig i noget tilfælde — spørgsmålet bliver, om server-side payloaden sendes eller undertrykkes, og om payloaden indeholder de identifikatorer, leverandøren har brug for at spore brugeren. Begge spørgsmål har veldefinerede svar i Zaraz Consent API; udgiverens opgave er at kortlægge dem korrekt.

Zaraz Consent API og hvordan det adskiller sig fra klientside CMP'er

Zaraz leveres med et indbygget samtykke-modul — Zaraz Consent Tools — der opretholder en samtykkestatus per besøgende og styrer, hvilke konfigurerede værktøjer der aktiveres. Statusen eksponeres via en lille JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) for at registrere en brugers valg, zaraz.consent.get('analytics') for at læse det, zaraz.consent.getAll() for det fulde kort, zaraz.consent.modal() for at åbne samtykke-UI'en og hændelseslyttere på zaraz.consent.onModalShown og relaterede hændelser for tilpasset UI-adfærd. Hvert Zaraz-værktøj i dashboardet konfigureres med et eller flere formåls-ID'er, og Workeren eksekverer kun et værktøj, når de relevante formål er givet i besøgerens samtykkestatus.

Integrationsvalget er, om man bruger Zaraz's indbyggede samtykke-modal eller forbinder Zaraz til en ekstern CMP. Den indbyggede modal er den enkleste vej: aktiver Consent Tools, definer formålene, konfigurer hvert værktøj med det rigtige formål og udgiv. Den externe CMP-vej er det rigtige valg for organisationer, der allerede standardiserer på Cookiebot, OneTrust, Usercentrics eller en tilpasset CMP — Zaraz opererer så downstream fra CMP'en, med CMP'en der kalder zaraz.consent.set(), når brugeren bevæger sig gennem banneret. Begge veje lander ved det samme håndhævelsespunkt: Workeren kontrollerer samtykkestatussen, før hvert værktøj eksekveres, og værktøjer, hvis formål ikke er givet, kører simpelthen ikke.

IAB TCF-understøttelse og de regionale regimer

Zaraz tilføjede IAB TCF v2-understøttelse i 2023 og har fulgt rammen siden. For udgivere, der opererer i EEA og UK under TCF-baserede reklamepartnerskaber, oversætter integrationen automatisk TCF-samtykkestrengen til Zaraz-formålsstatus, når udgiveren tilmelder sig. For ikke-TCF-regioner kortlægger udgiveren brugerdefinerede formål — typisk analytics, marketing, personalization, functional — direkte til de relevante Zaraz-værktøjer. Den samme Worker håndhæver begge dele, hvilket betyder, at en enkelt Zaraz-konfiguration kan betjene en EEA-besøgende via TCF og en californisk besøgende via en brugerdefineret marketingformålsport uden to parallelle pipelines.

Hvorfor Zaraz ændrer GDPR- og ePrivacy-billedet

Den juridiske stilling under GDPR, ePrivacy og CCPA er ikke undtaget af server-side eksekvering — det juridiske grundlag følger dataene, ikke transporten — men den praktiske overholdelsesoverflade ændres. Tre ændringer er vigtige.

• Cookie-overfladen skrumper. De fleste leverandørcookies skrives aldrig, fordi leverandørens JavaScript aldrig kører i browseren. De cookies, der forbliver, er typisk Zaraz's eget sessionsidentifikator og eventuelle førstepartsidentifikatorer, udgiveren bevidst har udbredt. Den ikke-essentielle cookie-overflade, som banneret skal styre, er derfor dramatisk mindre — nogle gange kun en eller to cookies versus de et dusin eller mere, en typisk klientside-stak producerer.
• Tredjeparts-overførselsafsløringen ændres. Fordi Workeren sender data til leverandørerne via server-til-server-kald, er datastien fra besøgerens browser til Cloudflares kant og derfra til de konfigurerede leverandører. Privatlivspolitikken skal afspejle dette — Cloudflare er en databehandler og hvert Zaraz-værktøj er en downstream-modtager — men afsløringen er på mange måder tydeligere end den tilsvarende klientside-vej, fordi udgiveren har fuld kontrol over, hvad der videresendes.
• Revisionssporet er mere centraliseret. Da enhver leverandørhændelse passerer gennem Workeren, har udgiveren et enkelt punkt, hvor samtykkestatus, hændelses-payload og downstream-modtager kan logges. Regulatorer, der forventer en forespørgbar samtykkelogfil, har et tydeligere svar med Zaraz end med en spredning af klientside-tags.

Det integrationsmønster, der virker

Referenceinstallationen har fire bevægelige dele. Den første er Zaraz-initialiseringen på siden, indlæst fra udgiverens domæne via Cloudflares proxy. Den anden er enten den indbyggede Consent Tools-modal eller en ekstern CMP, der kalder zaraz.consent.set(), når brugeren træffer valg. Den tredje er Zaraz-dashboard-konfigurationen, der kortlægger hvert værktøj til de rigtige formål — analyseværktøjer til analyseformålet, reklamevæktøjer til marketingformålet, session-replay-værktøjer til et strengere funktionelt eller forskningsformål og ethvert tredjeparts-overførselsafhængigt værktøj til formålet om grænseoverskridende overførsel, hvis udgiverens privatlivspolitik eksponerer dette som et separat valg. Den fjerde er en server-side log — enten Cloudflare Analytics, Logpush til en udgivers datasø eller en tilpasset Worker, der skriver samtykkebeslutninger til et forespørgbart lager — så samtykkeoptegnelsen kan fremvises på regulatorbegæring.

Valideringstrinnet er den samme fire-tjek-sekvens, der gælder for enhver samtykkeintegration, men med et Zaraz-specifikt twist. En ren browsersession med banneret vist men intet valg truffet bør producere nul forespørgsler fra besøgerens browser til ethvert leverandørdomæne og nul ikke-essentielle cookies — begge dele lettere at bekræfte med Zaraz end med en klientside-stak, fordi fraværet af tredjeparts-forespørgsler er standarden snarere end en konfigureret undtagelse. Et afvisningsbesøg bør bevare denne tilstand. Et acceptbesøg bør producere Zaraz-endpoint-POST'er, der kun bærer de hændelser, brugeren har samtykket til, og Worker-loggene bør vise downstream-værktøjsaktiveringer. En tilbagetrækning bør straks stoppe yderligere Worker-værktøjseksekvering, udløbe cookies sat af Zaraz og udløse de relevante sletnings- eller fravalgs-signaler til de konfigurerede downstream-leverandører.

Hvor Zaraz stadig kræver omhyggelig håndtering

Zaraz er ikke en samtykke-som-arkitektur-løsning, der fjerner behovet for at tænke. Tre områder kræver bevidst håndtering. Klik-for-at-indlæse-indlejringer — YouTube, Twitter, Instagram, TikTok-video — har stadig brug for det samme pladsholdemønster, som enhver samtykke-prioriteret installation bruger, fordi Zaraz i øjeblikket ikke proxer indlejrede video-iframes. Klientside-identifikatorer, som udgiveren vælger at sætte i browseren til førstepartsformål — et indlogget bruger-ID, et sessionstoken, en A/B-testspand — forbliver på udgiverens side af samtykkegrænsen og har brug for deres egen styrelogik. Og privatlivspolitikken skal nøjagtigt beskrive server-side-overførselsmodellen, herunder Cloudflares rolle som databehandler og den geografiske placering af de Workers, der håndterer dataene, fordi Cloudflares kant kører i flere regioner, og besøgerens trafik kan blive behandlet i en region, der ikke er deres egen. Med disse håndteret forvandler en Zaraz-installation i 2026 sig fra et tag-management-produkt til en af de reneste samtykkearkitekturer, en udgiver kan drive: mindre cookie-overflade, færre tredjeparts-forespørgsler, centraliseret håndhævelse og et revisionsspor, som en regulator faktisk kan læse.