Cloudflare Zaraz Consent Integration Guide: Server-Side Tag Management at the Edge for 2026
Cloudflare Zaraz is unlike most of the tag-management products that came before it. The premise is structural rather than incremental: instead of loading Google Analytics, Meta Pixel, Hotjar, Mixpanel, LinkedIn Insight, and every other vendor's JavaScript into the visitor's browser, Zaraz executes those integrations inside Cloudflare Workers running at the edge, in front of the publisher's origin. The browser sees a single small Zaraz runtime; the vendor tools run server-side. That architectural choice has compounding consequences for consent. The cookie surface shrinks dramatically because most vendor cookies never get set in the first place. The fingerprinting surface shrinks because most vendor JavaScript never executes in the browser context. And the consent enforcement point moves from a JavaScript banner gating a pile of <script> tags into a server-side decision that determines which Zaraz integrations fire and what payload they receive. The publisher that wires Zaraz into a CMP correctly ends up with a smaller compliance surface, faster pages, and a clearer audit trail. The publisher that treats Zaraz like a faster Google Tag Manager and skips the consent wiring ends up with a regulatory exposure that is harder to spot because so much of the activity is invisible to standard browser-based audits.
What Zaraz actually does at the edge
Zaraz is a server-side tag manager that executes inside Cloudflare Workers. When a visitor loads a page, the publisher's HTML includes a small Zaraz initialisation script — typically a few kilobytes — that gathers a structured event payload from the browser (pageview, click, custom event) and POSTs it to a Cloudflare endpoint on the publisher's own domain. The Worker receives that payload and runs the configured Zaraz tools against it: a Google Analytics 4 integration sends a Measurement Protocol hit, a Meta Pixel integration sends a Conversions API event, a Mixpanel integration sends an HTTP API call. The vendor's third-party JavaScript never loads in the browser, the vendor's cookies are either not set at all or are written through Cloudflare's first-party domain via the Worker, and the vendor receives only the data the publisher's Zaraz configuration explicitly forwards.
That is the architectural value proposition. It is also why the consent picture is different from any client-side tag manager. With a traditional setup the consent question is whether the vendor JavaScript loads or does not load. With Zaraz, the JavaScript never loads in either case — the question becomes whether the server-side payload is sent or suppressed, and whether the payload contains the identifiers the vendor needs to track the user. Both questions have well-defined answers in the Zaraz Consent API; the publisher's job is to map them correctly.
The Zaraz Consent API and how it differs from client-side CMPs
Zaraz ships with a built-in consent module — Zaraz Consent Tools — that maintains a per-visitor consent state and gates which configured tools fire. The state is exposed through a small JavaScript API: zaraz.consent.set({ analytics: true, marketing: false }) to record a user's choice, zaraz.consent.get('analytics') to read it, zaraz.consent.getAll() for the full map, zaraz.consent.modal() to open the consent UI, and event listeners on zaraz.consent.onModalShown and related events for custom UI behaviour. Each Zaraz tool in the dashboard is configured with one or more purpose IDs, and the Worker only executes a tool when the relevant purposes are granted in the visitor's consent state.
The integration choice is whether to use Zaraz's built-in consent modal or to bind Zaraz to an external CMP. The built-in modal is the simplest path: enable Consent Tools, define the purposes, configure each tool with the right purpose, and ship. The external-CMP path is the right choice for organisations that already standardise on Cookiebot, OneTrust, Usercentrics, or a custom CMP — Zaraz then operates downstream of the CMP, with the CMP calling zaraz.consent.set() as the user moves through the banner. Either path lands at the same enforcement point: the Worker checks the consent state before each tool executes, and tools whose purposes are not granted simply do not run.
IAB TCF support and the regional regimes
Zaraz added IAB TCF v2 support in 2023 and has tracked the framework forward since. For publishers operating in the EEA and the UK under TCF-based ad partnerships the integration translates the TCF consent string into Zaraz purpose state automatically when the publisher opts in. For non-TCF regions the publisher maps custom purposes — typically analytics, marketing, personalization, functional — to the relevant Zaraz tools directly. The same Worker enforces both, which means a single Zaraz configuration can serve both an EEA visitor through TCF and a Californian visitor through a custom marketing-purpose gate without two parallel pipelines.
Why Zaraz changes the GDPR and ePrivacy picture
The legal posture under GDPR, ePrivacy, and the CCPA is not exempted by server-side execution — the legal basis follows the data, not the transport — but the practical compliance surface changes. Three shifts matter.
- The cookie surface shrinks. Most vendor cookies never get written because the vendor JavaScript never runs in the browser. The cookies that remain are typically Zaraz's own session identifier and any first-party identifiers the publisher has deliberately propagated. The non-essential-cookie surface that the banner must gate is therefore dramatically smaller — sometimes just one or two cookies versus the dozen-plus a typical client-side stack produces.
- The third-party-transfer disclosure changes. Because the Worker is sending data to the vendors via server-to-server calls, the data path from the visitor's browser is to Cloudflare's edge and from there to the configured vendors. The privacy notice must reflect this — Cloudflare is a processor and each Zaraz tool is a downstream recipient — but the disclosure is in many ways cleaner than the equivalent client-side path because the publisher has full control over what gets forwarded.
- The audit trail is more centralised. Because every vendor event passes through the Worker, the publisher has a single point at which consent state, event payload, and downstream recipient can be logged. Regulators expecting a queryable consent log have a clearer answer with Zaraz than with a sprawl of client-side tags.
The integration pattern that works
The reference deployment has four moving parts. The first is the Zaraz initialisation in the page, loaded from the publisher's domain via Cloudflare's proxy. The second is either the built-in Consent Tools modal or an external CMP that calls zaraz.consent.set() as the user makes choices. The third is the Zaraz dashboard configuration mapping each tool to the right purposes — analytics tools to the analytics purpose, advertising tools to the marketing purpose, session-replay tools to a stricter functional or research purpose, and any third-party-transfer-dependent tool to the cross-border-transfer purpose if the publisher's privacy notice exposes that as a separate choice. The fourth is a server-side log — either Cloudflare Analytics, Logpush to a publisher's data lake, or a custom Worker that writes consent decisions to a queryable store — so that the consent record can be produced on regulator request.
The validation step is the same four-check sequence that applies to any consent integration but with a Zaraz-specific twist. A clean browser session with the banner shown but no choice made should produce zero requests from the visitor's browser to any vendor domain and zero non-essential cookies — both of which are easier to confirm with Zaraz than with a client-side stack because the absence of third-party requests is the default rather than a configured exception. A reject visit should keep that state. An accept visit should produce the Zaraz endpoint POSTs that carry only the events the user consented to, and the Worker logs should show the downstream tool fires. A withdrawal should immediately stop further Worker tool executions, expire any Zaraz-set cookies, and trigger the appropriate deletion or opt-out signals to the configured downstream vendors.
Where Zaraz still requires careful handling
Zaraz is not a consent-by-architecture solution that removes the need to think. Three areas require deliberate handling. Click-to-load embeds — YouTube, Twitter, Instagram, TikTok video — still need the same placeholder pattern that any consent-first deployment uses, because Zaraz does not currently proxy embedded video iframes. Client-side identifiers that the publisher chooses to set in the browser for first-party purposes — a logged-in user ID, a session token, an A/B test bucket — remain on the publisher's side of the consent boundary and need their own gating logic. And the privacy notice must accurately describe the server-side transfer model, including Cloudflare's role as a processor and the geographic location of the Workers handling the data, because the Cloudflare edge runs in multiple regions and the visitor's traffic may be processed in a region that is not their own. With those handled, a Zaraz deployment in 2026 turns from a tag-management product into one of the cleanest consent architectures a publisher can run: smaller cookie surface, fewer third-party requests, centralised enforcement, and an audit trail that a regulator can actually read.