Wat Zaraz feitelijk doet aan de edge

Zaraz is een server-side tagbeheerder die uitvoert binnen Cloudflare Workers. Wanneer een bezoeker een pagina laadt, bevat de HTML van de uitgever een klein Zaraz-initialisatiescript — doorgaans een paar kilobytes — dat een gestructureerde eventpayload verzamelt van de browser (pageview, klik, aangepaste gebeurtenis) en deze naar een Cloudflare-eindpunt op het eigen domein van de uitgever POST. De Worker ontvangt die payload en voert de geconfigureerde Zaraz-tools hierop uit: een Google Analytics 4-integratie stuurt een Measurement Protocol-hit, een Meta Pixel-integratie stuurt een Conversions API-event, een Mixpanel-integratie stuurt een HTTP API-aanroep. De derde-partij-JavaScript van de leverancier wordt nooit in de browser geladen, de cookies van de leverancier worden ofwel helemaal niet ingesteld of worden via het first-party domein van Cloudflare via de Worker geschreven, en de leverancier ontvangt alleen de gegevens die de Zaraz-configuratie van de uitgever expliciet doorstuurt.

Dat is de architecturale waardepropositie. Het is ook de reden waarom het toestemmingsplaatje anders is dan bij elke client-side tagbeheerder. Met een traditionele opstelling is de toestemmingsvraag of de leveranciers-JavaScript laadt of niet laadt. Met Zaraz wordt de JavaScript in beide gevallen nooit geladen — de vraag wordt of de server-side payload wordt verzonden of onderdrukt, en of de payload de identifiers bevat die de leverancier nodig heeft om de gebruiker te volgen. Beide vragen hebben welomschreven antwoorden in de Zaraz Consent API; de taak van de uitgever is om ze correct te mappen.

De Zaraz Consent API en hoe die verschilt van client-side CMPs

Zaraz wordt geleverd met een ingebouwde toestemmingsmodule — Zaraz Consent Tools — die een per-bezoeker toestemmingsstatus bijhoudt en bepaalt welke geconfigureerde tools worden geactiveerd. De status is beschikbaar via een kleine JavaScript-API: zaraz.consent.set({ analytics: true, marketing: false }) om de keuze van een gebruiker vast te leggen, zaraz.consent.get('analytics') om deze te lezen, zaraz.consent.getAll() voor de volledige map, zaraz.consent.modal() om de toestemmings-UI te openen, en event-listeners op zaraz.consent.onModalShown en gerelateerde events voor aangepast UI-gedrag. Elke Zaraz-tool in het dashboard is geconfigureerd met een of meer doel-IDs, en de Worker voert een tool alleen uit wanneer de relevante doelen zijn verleend in de toestemmingsstatus van de bezoeker.

De integratiekeuze is of u de ingebouwde toestemmingsmodal van Zaraz gebruikt of Zaraz koppelt aan een externe CMP. De ingebouwde modal is het eenvoudigste pad: schakel Consent Tools in, definieer de doelen, configureer elke tool met het juiste doel en ship. Het externe-CMP-pad is de juiste keuze voor organisaties die al standaardiseren op Cookiebot, OneTrust, Usercentrics of een aangepaste CMP — Zaraz werkt dan downstream van de CMP, waarbij de CMP zaraz.consent.set() aanroept terwijl de gebruiker door de banner navigeert. Beide paden eindigen op hetzelfde handhavingspunt: de Worker controleert de toestemmingsstatus vóór elke tooluitvoering, en tools waarvan de doelen niet zijn verleend, worden eenvoudigweg niet uitgevoerd.

IAB TCF-ondersteuning en de regionale regimes

Zaraz voegde IAB TCF v2-ondersteuning toe in 2023 en heeft het framework sindsdien bijgehouden. Voor uitgevers die actief zijn in de EEA en het UK onder TCF-gebaseerde advertentiepartnerschappen vertaalt de integratie de TCF-toestemmingsstring automatisch naar de Zaraz-doelstatus wanneer de uitgever ervoor kiest. Voor niet-TCF-regio's mapt de uitgever aangepaste doelen — doorgaans analytics, marketing, personalization, functional — direct naar de relevante Zaraz-tools. Dezelfde Worker handhaaft beide, wat betekent dat één Zaraz-configuratie zowel een EEA-bezoeker via TCF als een Californische bezoeker via een aangepaste marketingdoelpoort kan bedienen zonder twee parallelle pipelines.

Waarom Zaraz het GDPR- en ePrivacy-plaatje verandert

De juridische positie onder GDPR, ePrivacy en de CCPA wordt niet vrijgesteld door server-side uitvoering — de rechtsgrondslag volgt de data, niet het transport — maar het praktische nalevingsoppervlak verandert wel. Drie verschuivingen zijn van belang.

• Het cookieoppervlak krimpt. De meeste leverancierscookies worden nooit geschreven omdat de leveranciers-JavaScript nooit in de browser wordt uitgevoerd. De cookies die overblijven, zijn doorgaans de eigen sessie-identifier van Zaraz en eventuele first-party identifiers die de uitgever bewust heeft verspreid. Het niet-essentiële cookieoppervlak dat de banner moet beheren, is daardoor dramatisch kleiner — soms slechts één of twee cookies versus de twaalf of meer die een typische client-side stack produceert.
• De disclosure van derde-partij-overdracht verandert. Omdat de Worker data naar leveranciers stuurt via server-naar-server-aanroepen, loopt het datapad van de browser van de bezoeker naar de edge van Cloudflare en van daaruit naar de geconfigureerde leveranciers. De privacyverklaring moet dit weerspiegelen — Cloudflare is een verwerker en elke Zaraz-tool is een downstream ontvanger — maar de disclosure is op veel manieren schoner dan het equivalente client-side pad omdat de uitgever volledige controle heeft over wat er wordt doorgestuurd.
• Het audittrail is meer gecentraliseerd. Omdat elke leveranciersgebeurtenis door de Worker gaat, heeft de uitgever één punt waar toestemmingsstatus, eventpayload en downstream ontvanger kunnen worden gelogd. Toezichthouders die een opvraagbaar toestemmingslogboek verwachten, hebben een duidelijker antwoord met Zaraz dan met een wirwar van client-side tags.

Het integratiepatroon dat werkt

De referentieimplementatie heeft vier bewegende onderdelen. Het eerste is de Zaraz-initialisatie op de pagina, geladen vanuit het domein van de uitgever via de proxy van Cloudflare. Het tweede is ofwel de ingebouwde Consent Tools-modal of een externe CMP die zaraz.consent.set() aanroept terwijl de gebruiker keuzes maakt. Het derde is de Zaraz-dashboardconfiguratie die elke tool aan de juiste doelen koppelt — analysetools aan het analysedoel, advertentietools aan het marketingdoel, sessiereplay-tools aan een strenger functioneel of onderzoeksdoel, en elk grensoverschrijdend overdrachtsafhankelijk tool aan het grensoverschrijdend overdrachts doel als de privacyverklaring van de uitgever dat als een aparte keuze blootstelt. Het vierde is een server-side logboek — ofwel Cloudflare Analytics, Logpush naar het datalake van de uitgever, of een aangepaste Worker die toestemmingsbeslissingen schrijft naar een opvraagbare opslag — zodat het toestemmingsrecord op verzoek van de toezichthouder kan worden geproduceerd.

De validatiestap is dezelfde vier-controlereeks die van toepassing is op elke toestemmingsintegratie maar met een Zaraz-specifieke twist. Een schone browsersessie met de banner getoond maar geen keuze gemaakt zou nul verzoeken moeten produceren van de browser van de bezoeker naar enig leveranciersdomein en nul niet-essentiële cookies — beide zijn gemakkelijker te bevestigen met Zaraz dan met een client-side stack omdat de afwezigheid van derde-partij-verzoeken de standaard is in plaats van een geconfigureerde uitzondering. Een afwijzingsbezoek zou die staat moeten behouden. Een acceptatiebezoek zou de Zaraz-eindpunt-POSTs moeten produceren die alleen de events bevatten waarvoor de gebruiker toestemming heeft gegeven, en de Worker-logs zouden de activering van downstream tools moeten tonen. Een intrekking zou onmiddellijk verdere Worker-tooluitvoeringen moeten stoppen, eventuele door Zaraz ingestelde cookies laten verlopen, en de juiste verwijderings- of opt-outsignalen naar de geconfigureerde downstream leveranciers activeren.

Waar Zaraz nog zorgvuldige behandeling vereist

Zaraz is geen toestemming-door-architectuuroplossing die de noodzaak om na te denken wegneemt. Drie gebieden vereisen doelbewuste behandeling. Click-to-load-embeds — YouTube, Twitter, Instagram, TikTok-video — hebben nog steeds hetzelfde placeholderpatroon nodig dat elke toestemming-eerst-implementatie gebruikt, omdat Zaraz momenteel geen ingesloten video-iframes proxyt. Client-side identifiers die de uitgever kiest om in de browser in te stellen voor first-party doeleinden — een ingelogde gebruikers-ID, een sessietoken, een A/B-testgroep — blijven aan de kant van de uitgever van de toestemmingsgrens en hebben hun eigen gate-logica nodig. En de privacyverklaring moet het server-side overdrachtsmodel nauwkeurig beschrijven, inclusief de rol van Cloudflare als verwerker en de geografische locatie van de Workers die de data verwerken, omdat de Cloudflare-edge in meerdere regio's actief is en het verkeer van de bezoeker mogelijk wordt verwerkt in een regio die niet die van henzelf is. Met die zaken afgehandeld, verandert een Zaraz-implementatie in 2026 van een tagbeheerproduct in een van de schoonste toestemmingsarchitecturen die een uitgever kan draaien: kleiner cookieoppervlak, minder derde-partij-verzoeken, gecentraliseerde handhaving, en een audittrail dat een toezichthouder daadwerkelijk kan lezen.