Tracking & AnalyticsService
Consent Mode v2 Implementation — CMP Integration & QA
For stores with visitors in the EEA or UK: make your tags and server events actually follow the choice people make in your cookie banner, checked, documented and re-testable.
- Published
- Reviewed
Prefer email? next@taskfordaniel.com
The problem
Why does Consent Mode v2 fail even with a CMP installed?
Consent Mode v2 became effectively mandatory for advertisers serving the EEA and UK, and a lot of implementations technically exist without actually working.
A CMP banner is installed, a consent decision gets recorded — and then tags fire regardless of what the visitor chose, because nothing downstream is actually reading that decision. Or the opposite happens: consent gating is applied too broadly, and legitimate, consented traffic gets suppressed or misattributed, showing up as inflated “Unassigned” traffic in GA4.
Neither failure is visible from the CMP’s own dashboard, which only shows that a banner is running — not whether the tags behind it actually respect what visitors decided.
Scope
What I do
I audit and implement the technical layer that connects a consent decision to what tags and server events actually do:
-
Basic vs. advanced modereviewing which mode is currently configured (or missing) and whether it fits your traffic and measurement needs, since the two modes trade off exact measurement against modeled data differently.
-
CMP integrationconnecting your consent management platform’s decision to Google’s consent signals (and any other platform’s equivalent) so tags genuinely respond to what was chosen, not just what was recorded.
-
Region-aware gatingmaking sure consent requirements that apply in the EEA/UK are applied there specifically, without unnecessarily restricting measurement in regions where those requirements don’t apply.
-
Server propagationpassing the browser’s consent decision through to server-side tracking, so server events honor the same consent state as browser events instead of operating independently.
-
QA methoda documented, repeatable way to verify consent signals are firing correctly: what a tag should do when consent is denied, what it should do when granted, and how to check that in practice rather than trust the configuration screen.
The process
How it runs
-
Access and current-state audit
GTM/GA4 access, CMP configuration details, and a review of what’s actually firing before and after a consent decision is made, using a real test session — not just reading the configuration.
-
Gap identification
I document where tags fire regardless of consent state, where region-aware logic is missing or wrong, and whether server-side events (if any) are consent-aware at all.
-
Implementation
CMP signals are wired into Google’s consent API correctly, region logic is applied, and server propagation is built if server-side tracking is in scope.
-
QA
I test each consent state combination — granted, denied, undecided, per region — and confirm the expected tag behavior in each case, documenting the method so it can be re-run after future changes.
Handover
What you get
A Consent Mode v2 implementation that actually reflects visitor choices: correctly wired CMP integration, region-aware gating, server-side propagation where relevant, and a documented QA method you or a future developer can re-run whenever the site or the CMP changes.
You also get a plain description of which mode (basic or advanced) is in place and why it was chosen for your traffic.
Handover kit
- Consent Mode v2 audit — which signals are currently sent, basic or advanced mode, and where gaps exist
- CMP (consent management platform) integration or repair
- Region-aware consent gating (EEA/UK behavior distinct from regions without the same requirement)
- Server-side consent-state propagation, so server events respect the same consent decision as browser events
- A documented QA method for verifying consent signals fire correctly, before and after a consent decision
- Documentation of the resulting consent architecture
Price and timeline
Next step
If the task is already clear, I can quote the implementation directly. If we first need to establish the cause or scope, we agree a separate diagnostic engagement: the Tracking Health Check, read-only, includes a consent-mode check as standard, so the verdict says whether consent work is what the store actually needs.
Email next@taskfordaniel.com with your CMP details and what looks wrong — discussing the task is free — or request a Tracking Health Check when the cause needs establishing first. Where consent needs to propagate to a server layer, this pairs with server-side tracking and Google Tag Manager work.
QuoteFixed before work starts
- Price
- Focused Fix from USD 450 · Custom Engineering Project from USD 1,500 · quoted in writing
- Turnaround
- Quoted directly for a defined task, or scoped from the Health Check; typical engagements run 3–5 business days
A note from Daniilbefore you decide
What this is not
This is not a legal compliance service, and I won’t represent it as one. I don’t determine your legal consent obligations, write consent-banner copy, or advise on regulatory scope — that’s the job of a privacy lawyer or compliance consultant. What I build and verify is whether the technical plumbing behind your consent decisions actually works. It’s also not a guarantee against Unassigned traffic disappearing entirely; some volume of unattributed sessions is structural once consent is respected properly, because declined consent legitimately means less signal, not a bug to fix.
And this doesn’t replace your CMP — I work with whatever consent platform you already have or help you evaluate one, but building a CMP from scratch isn’t in scope here.
— Daniil
Questions
FAQ
What's the difference between basic and advanced Consent Mode v2?
Basic mode blocks Google tags entirely until a consent decision is made, then loads them normally if consent is granted — simple, but you lose all measurement for users who haven't decided yet. Advanced mode lets tags load in a limited, cookieless state before a decision is made and sends anonymous pings that Google can use for conversion modeling. Which one fits depends on your traffic volume and how much you rely on modeled data versus exact measurement.
I already have a CMP installed. Why would I still need this?
A CMP banner being present doesn't mean tags actually respect the choice a visitor makes — that's a separate, common failure. I've seen accounts where a visitor declines analytics cookies and GA4 or Meta tags fire anyway because nothing in GTM is actually checking consent state. This service audits and fixes that gap, on both the browser and server side.
Does this affect GA4's Unassigned traffic bucket?
It can, in both directions. A consent gap where tags fire without checking state can inflate tracked traffic incorrectly; a consent implementation that's too aggressive or misconfigured can suppress legitimate campaign parameters and push sessions into Unassigned. Getting the gating right is part of what keeps attribution data usable.
What does 'server propagation' actually mean here?
If you're running server-side tracking, the server needs to know what consent decision the visitor made in the browser — otherwise it might send events the visitor explicitly declined. Server propagation means that consent signal (granted/denied per category) is passed along with the event data to the server, so server-side tags honor the same decision browser-side tags do.
What do you need to get working?
Describe your taskThe first answer is free, within one working day. Or write directly: next@taskfordaniel.com