Web Analytics · Server-Side & First-Party

Consent Mode v2 & CMP Integration

A consent choice is only real when storage, requests, and server routes all change with it.

A consent banner can look compliant while the tags behind it ignore the selected choice. We connect the CMP signals to Consent Mode v2 and inspect storage, requests, and server routes after acceptance, rejection, and withdrawal.

Consent choices that provably change what gets collected and forwarded, tested across accept, reject, and withdrawal.

Plan consent implementationAll Server-Side Tracking & First-Party Measurement tasks
A Zeo specialist at a consent gate routing allowed and blocked signal lanes

Some of the 500+ brands we've worked with

See all references
  • LC Waikiki
  • Lexus
  • Abdi İbrahim
  • Milliyet
  • Tosla
  • Koleksiyon Mobilya
  • Neova Sigorta

How we run it

From approved policy to a signed test report

We verify the behavior behind every consent choice, going beyond what the banner merely displays. Four steps that end with proof instead of an assumption.

How we hold ourselves to it

  • Default and update signals, wired correctly — The default command must fire before any measurement command reaches the page, and the update command must fire when someone changes their choice. We wire both for ad_storage, analytics_storage, ad_user_data, and ad_personalization.
  • What actually happens when someone says no — For acceptance, rejection, and partial consent, we inspect real browser storage and network requests rather than relying on the banner UI's reported state.
  • Server-side routes, held to the same standard — If you route data through a server container, we confirm the same consent state carries through there too, matching what happens in the browser.
  • EEA defaults and what a withdrawal actually changes — We test EEA versus non-EEA defaults and confirm that updating or withdrawing consent actually changes behavior going forward. A changed value sitting in the banner isn't enough on its own.

  1. Confirm the approved policy

    We start with the consent categories and regional rules approved by your privacy or legal team. We do not set the policy ourselves.

    Policy confirmation

    AI assist
    Audits script firing logs to detect cookies set prior to CMP user interaction.
    Human gate
    Legal/Privacy counsel approves default consent states and regional geo-targeting rules.
    Owners
    Privacy Owner, Legal Reviewer
    Illustrated figure holding up a signed agreement page

  2. Configure Consent Mode v2

    We wire the CMP's signal into GTM and configure default and update behavior for each affected tag.

    Configuration record

    AI assist
    Drafts default and update signals for each tag.
    Human gate
    Your privacy owner approves the consent-state mapping.
    Owners
    Consent Engineer, GTM Admin
    Two illustrated figures carrying an oversized key together

  3. Test every state

    We test accept, reject, partial consent, and withdrawal, checking actual storage and network requests in each case.

    Test matrix results

    AI assist
    Runs the test matrix across every consent state.
    Human gate
    Legal reviews the storage and request test results.
    Owners
    Consent Engineer, Legal Reviewer
    Illustrated figure reading an oversized measurement dial

  4. Document and hand over

    We leave a record of what was tested and what to re-check after a policy or vendor change.

    Consent test report

    AI assist
    Drafts the re-test checklist for future changes.
    Human gate
    Your privacy owner signs off before we hand over.
    Owners
    Consent Engineer, Privacy Owner
    One illustrated figure passing a relay baton to another

We test what accept, reject, and withdrawal actually do

Automation audits firing logs for cookies set before the banner is answered, drafts the default and update signals per tag, and runs the full state matrix. The approvals are human by design: privacy owns the consent-state mapping, legal reviews the storage and request results, and nothing ships without that sign-off.

What you get

Evidence that consent choices change real behavior

You receive proof from storage, requests, and tag behavior. Confirmation that the banner is merely live isn't the same thing.

  • Reference document

    Consent-state matrix

    One reference document showing storage, requests, and tag behavior for every consent state.

    Accepted when

    Every consent state in the matrix has an observed row, not an expected one.

    Cadence: Re-observed after each CMP change

  • QA evidence

    Test evidence

    What we tested for accept, reject, partial consent, and withdrawal, with the actual browser and network results.

    Accepted when

    Each result is backed by a browser storage and network capture taken under that state.

    Cadence: Captured per consent state

  • Runbook

    Maintenance notes

    What to re-test after a CMP update, a new tag, or a policy change.

    Accepted when

    The notes name the exact checks to rerun after a CMP update, a new tag, or a policy change.

    Cadence: Reread before any policy change

We call it done when: accept, reject, partial consent, and withdrawal have each been tested with browser and network evidence, and the same state is enforced on any server route.

Fit and readiness

A compliant-looking banner proves nothing about the tags

The three signals below are what usually mean a consent audit is overdue.

A good fit when

  • Your CMP is live but nobody has verified that a "reject" choice actually stops what it's supposed to stop.
  • You're implementing Consent Mode v2 for the first time and need it actually wired and tested, beyond just switching it on.
  • You have both browser and server-side tracking and need consent to propagate correctly across both.

Better handled as other work when

  • You still need to decide the consent categories, regional rules, or retention policy. Your privacy or legal team owns that call, and we implement what they approve.
  • You need general server infrastructure rather than consent behavior verification. That is Server-Side GTM & Cloud Setup.

If one of these is closer to your situation, start here instead: All Server-Side Tracking & First-Party Measurement tasks

We call it done when: your privacy or legal reviewer has approved the default consent states and the regional rules, so the configuration has a policy to implement.

People who build your measurement system

Zeo designs measurement systems that connect a business decision to governed collection and reporting you can check. The people shown here work on the part of that system this page covers.

Tools we use

Tools behind this work

  • Google Tag Manager

    where every tag's consent gating actually gets configured against the CMP's signal

  • Cookiebot

    the CMP whose accept, reject, and withdrawal states this page connects directly to Consent Mode

  • Google Tag Assistant

    shows the consent state each tag actually fired under, tested after every choice

Next step

Prove that consent choices change behavior

Bring us your CMP and approved policy. We will connect Consent Mode v2 and test what happens when someone declines.
Plan consent implementation

Before we start

Questions teams ask before booking

No single technical setting does that. Consent Mode can correctly implement an approved policy's technical behavior, but whether the policy itself is sufficient is a legal question for your own counsel.