Skip to content
DM · Daniil Maximkin
Service

Consent Mode v2 Implementation — CMP Integration & QA

Consent Mode v2 setup: basic vs. advanced signals, CMP integration, region-aware gating, and server propagation, with a real QA method behind it.

fixed scope after audit Turnaround: Scoped after audit; typical engagements run 3–5 business days

·

What you get

  • 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

The problem this solves

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.

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 mode — reviewing 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 integration — connecting 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 gating — making 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 propagation — passing 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 method — a 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.

How it runs

  1. 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.
  2. 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.
  3. 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.
  4. 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.

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.

This covers technical implementation, not legal advice. 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.

What this is not

This is not a legal compliance service, and I won’t represent it as one — see the note above. 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.

FAQ

Basic mode blocks Google tags entirely until a consent decision is made, then loads them if consent is granted — simple, but no measurement for undecided users. Advanced mode loads tags in a limited, cookieless state before a decision and sends anonymous pings Google can use for conversion modeling. Which fits depends on your traffic volume and how much you rely on modeled versus exact data.

No. This covers technical implementation, not legal advice — I don’t draft consent language or determine your regulatory obligations. That’s a job for a privacy lawyer or compliance consultant. What I build is the plumbing: making sure whatever decision your CMP records is actually respected by every tag and server event, region-aware.

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 checks consent state. This service audits and fixes that gap, browser and server side.

Does this affect GA4’s Unassigned traffic bucket?

It can, in both directions. Tags firing without checking consent state can inflate tracked traffic incorrectly; over-aggressive gating 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 passes that signal (granted/denied per category) along with the event data, so server-side tags honor the same decision browser-side tags do.

Next step

If you’re not sure whether your current consent setup actually gates tags correctly, book a call or email [email protected] with your CMP details and GTM/GA4 access. If consent gaps turn up as part of a broader diagnosis, the Tracking Audit includes a consent-mode check as standard. Where consent needs to propagate to a server layer, this pairs with server-side tracking and Google Tag Manager work.

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.

Do you provide the legal consent banner or cookie policy?

No. This covers technical implementation, not legal advice — I don't draft consent language, determine what your specific regulatory obligations are, or advise on which consent categories you're legally required to offer. That's a job for a privacy lawyer or a compliance consultant. What I build is the technical plumbing: making sure whatever consent decision your CMP records is actually respected by every tag and every server event, correctly and region-aware.

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.

Not sure whether your tracking is actually broken?

Start with a Health Check — a fast, read-only diagnosis that tells you what is wrong before you spend anything fixing it. Prefer email? Send your store URL and one sentence about what looks off.