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. You end up with consent choices that provably change what gets collected and forwarded, tested across accept, reject, and withdrawal.
Some of the 500+ brands we've worked with
See all references
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.
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. The legal/Privacy counsel approves default consent states and regional geo-targeting rules.
Policy confirmation
Configure Consent Mode v2
We wire the CMP's signal into GTM and configure default and update behavior for each affected tag. Your privacy owner approves the consent-state mapping.
Configuration record
Test every state
We test accept, reject, partial consent, and withdrawal, checking actual storage and network requests in each case. Legal reviews the storage and request test results.
Test matrix results
Document and hand over
We leave a record of what was tested and what to re-check after a policy or vendor change. Your privacy owner signs off before we hand over.
Consent test report
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.
QA evidence
Test evidence
What we tested for accept, reject, partial consent, and withdrawal, with the actual browser and network results.
Runbook
Maintenance notes
What to re-test after a CMP update, a new tag, or a 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.
Abdullah Tanıdır
Performance Marketing Team Lead
Sevda Yurtvermez
Performance Marketing Team Lead
Serap Yurtvermez
Performance Marketing Team Lead
İlker Emir
Senior Performance Marketing Executive
İpek Ezer
Performance Marketing Executive
Deniz Çağın Demirci
Frontend Developer
Onur Durdağı
Performance Marketing Executive
Didem Himmetli
Marketing Executive
Mirzamin Aghazada
UI/UX Designer
Yağmur Bayram
Sr. SEO Analyst
Gülşah Şahin Özkan
Senior SEO Analyst
Tools we use
Tools behind this work
Google Tag Managerwhere every tag's consent gating actually gets configured against the CMP's signal
Cookiebotthe CMP whose accept, reject, and withdrawal states this page connects directly to Consent Mode
Google Tag Assistantshows the consent state each tag actually fired under, tested after every choice
Where this fits
Keep going
Same capability
Server-Side GTM & Cloud Setup
The cross-boundary check only exists if there is a server route to check; this builds that container, its clients, and the domain it answers on.
Same capability
First-Party Tracking Architecture
Wiring the default and update signals presumes someone already decided which signals travel first-party and how long each one is kept.
Same capability
Server-Side Monitoring & Reliability
A consent state passes the test matrix once; a wrong state later produces no error at all, which is exactly what these silent-failure checks watch for.
Next step
Prove that consent choices change behavior
Before we start
Questions teams ask before booking
Does Consent Mode make us compliant?
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.
Do you test anything beyond the banner?
Yes. Displaying the right options does not prove that downstream systems respect them. We inspect storage, network requests, and server behavior for every consent state.
What if we also have a server-side container?
We check that the consent state reaching your server routes matches what the browser captured, since a mismatch there is a common and hard-to-notice gap.
Who needs to sign off before we start?
Your approved consent policy (categories, regions, defaults) from your privacy or legal team, plus access to your CMP, GTM, and any server container involved.