Sign up free
Guides

Google Consent Mode v2 and Visitor Identification

How to run website visitor identification alongside Google Consent Mode v2 — consent states, tag gating, and staying compliant without losing data.

Nicolas CanalNicolas Canal··8 min read
Google Consent Mode v2 and Visitor Identification

If you run Google Ads or GA4 in Europe, you’ve had to implement Google Consent Mode v2. The natural question for anyone also running website visitor identification is: do these two things conflict, and will Consent Mode block my visitor-ID tag?

Short answer: they coexist, but only if you gate your identification tag on the right consent signal and treat EEA and US traffic differently. Consent Mode v2 governs how Google’s own tags behave based on a user’s consent choices — it doesn’t automatically control third-party scripts like a visitor-identification pixel. That’s your job to wire up correctly.

This guide explains the consent states, how to gate your identification tag in Google Tag Manager, and how to keep identifying US visitors compliantly while respecting EEA consent. It’s a companion to the GTM setup guide and the GDPR-compliant identification and CCPA-compliant identification guides. This is practical implementation guidance, not legal advice — confirm your specific setup with your privacy counsel.

Consent Mode v2 is Google’s framework for adjusting how Google tags fire based on a visitor’s consent choices. It introduced two new required signals alongside the original two. The four consent parameters are:

Consent signal Governs
ad_storage Cookies/storage for advertising
analytics_storage Cookies/storage for analytics
ad_user_data Whether user data can be sent to Google for ads
ad_personalization Whether data can be used for ad personalization/remarketing

Each is set to granted or denied. In basic Consent Mode, tags don’t fire at all until consent is granted. In advanced Consent Mode, Google tags load in a limited, cookieless state and send anonymized signals even before consent, then upgrade if consent is granted. Google’s own Consent Mode documentation is the authoritative reference for the parameters and behavior.

The critical thing to understand: Consent Mode v2 controls Google’s tags. It does not automatically govern your visitor-identification script. If you drop a visitor-ID tag on the page without wiring it to a consent trigger, it will fire regardless of what the user chose. That’s the gap you have to close deliberately.

In one sentence: Consent Mode v2 tells Google’s tags how to behave; you’re responsible for gating your visitor-identification tag on the same consent signal.

It depends entirely on where the visitor is. This is the part teams get wrong, and it maps directly onto how person-level identification actually works.

  • EEA/UK visitors: Under GDPR and the ePrivacy rules, storing or accessing information on a device and processing personal data generally requires a lawful basis, and for tracking technologies that usually means consent. So in the EEA/UK, your identification tag should be gated behind consent. Realistically, this also means coverage in these regions is lower and often company-level — see GDPR-compliant visitor identification. Nobody “beats” GDPR; you comply with it.
  • US visitors: The US operates on an opt-out model under laws like CCPA/CPRA. You generally provide notice at collection and honor opt-out signals rather than requiring prior opt-in — see CCPA-compliant visitor identification. This is a big reason US traffic supports richer person-level identification.

That geographic split is the whole strategy. You don’t apply one blanket rule; you apply EEA consent-gating to EEA visitors and US notice-and-opt-out handling to US visitors. Consent Mode’s region settings let you scope behavior by geography, which is exactly the seam you build on.

The cleanest way to run identification alongside Consent Mode v2 is to deploy it through Google Tag Manager and tie it to consent. High level:

  1. Deploy via GTM. Add your identification tag as a Custom HTML tag using the GTM setup guide. Don’t hardcode it in the site template where it can’t respect consent.
  2. Set default consent state. Configure a default consent state (typically denied for EEA regions) that fires before your consent banner, so nothing sensitive runs until a choice is made.
  3. Use built-in consent checks or a consent trigger. In GTM, use the tag’s consent settings (or “Require additional consent”) so the identification tag only fires when the relevant consent signal is granted.
  4. Scope by region. Apply consent-gating to EEA/UK traffic; allow US traffic to run under a notice-and-opt-out model per your privacy program.
  5. Update on consent change. When a visitor accepts, your Consent Management Platform pushes an update to the consent state, which releases the gated tag.

The result is a single deployment that behaves differently by geography: EEA/UK visitors are identified only after consent; US visitors are identified under the opt-out framework — with opt-outs and suppression lists honored either way.

Try Leadpipe free with 500 leads →

EEA vs US: two behaviors, one setup

Here’s the practical split, side by side, so you can hand it to whoever owns your tag manager.

EEA / UK visitors US visitors
Legal model Consent (opt-in) Notice + opt-out
Identification tag Fires only after consent granted Fires under notice-at-collection
Typical coverage Lower, often company-level Person-level, 30–40% match
Consent Mode role Gate the tag behind granted Honor opt-out signals
Reference GDPR guide CCPA guide

Two implementation notes:

  • Don’t over-block US traffic. A common mistake is applying EEA-strict consent-gating globally, which needlessly suppresses US identification where the law doesn’t require opt-in. Scope your gating to the regions that need it.
  • Don’t under-block EEA traffic. The opposite mistake — firing your ID tag on EEA visitors without consent — is the one that creates real compliance exposure. When in doubt in the EEA, gate it.

A quick implementation checklist

Before you push a consent-gated identification setup live, walk this list. It catches the mistakes that create either compliance exposure or needless data loss:

  • Consent Mode v2 is configured with all four signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) and a sensible regional default.
  • Your CMP fires before other tags. The banner and default consent state must load first, so nothing sensitive runs before a choice is made.
  • The identification tag lives in GTM, not hardcoded in the template, so it can respect consent triggers.
  • Consent-gating is scoped to EEA/UK. You’re not blanket-blocking US traffic where opt-in isn’t required.
  • Consent update releases the tag. When an EEA visitor accepts, the gated identification tag fires; when they decline, it stays off.
  • Opt-out and suppression are wired for US traffic, so notice-and-opt-out is actually honored, not just documented.
  • You tested both paths — accept and decline — in GTM preview mode and confirmed the tag behaves correctly in each.

If all seven are true, your identification runs cleanly alongside Consent Mode v2: gated where the law requires opt-in, active where it requires only notice.

Will you lose data? What actually happens

Teams worry that consent-gating tanks their identification volume. The honest picture:

  • In the EEA/UK, yes — some. If a visitor declines consent, you don’t identify them, and you shouldn’t. That’s the cost of compliance, and it’s non-negotiable. This is also why EEA coverage is structurally lower.
  • In the US, largely no. Under the opt-out model, most US traffic remains identifiable with proper notice, so person-level identification continues to work at its normal 30–40% match rate.

The takeaway for most B2B teams: your US traffic is where person-level identification carries the load, and Consent Mode v2 doesn’t meaningfully reduce it when configured correctly. Your EEA traffic will be more limited — plan for company-level context there and lead with compliance, not volume. For a deeper look at how identification survives cookie deprecation, see cookieless visitor identification.

In one sentence: Configured right, Consent Mode v2 costs you some EEA identification you shouldn’t have collected anyway — and leaves your US person-level identification intact.

FAQ

Not by itself. Consent Mode v2 controls how Google’s own tags behave; it doesn’t automatically govern third-party scripts like a visitor-identification pixel. You must gate your identification tag on the appropriate consent signal yourself, ideally through Google Tag Manager. See the GTM setup guide.

Generally the US follows an opt-out model under laws like CCPA/CPRA, so you provide notice at collection and honor opt-out signals rather than requiring prior opt-in. That’s different from the EEA’s consent-first model. Confirm specifics with counsel and see CCPA-compliant visitor identification.

Gate your identification tag so it only fires when the relevant consent is granted, set a sensible default (denied) before the banner loads, and update on consent change via your CMP. Expect lower, often company-level coverage in the EEA — that’s the compliant reality. See GDPR-compliant visitor identification.

No. This is practical implementation guidance for running visitor identification alongside Consent Mode v2. Privacy law varies by jurisdiction and changes over time — validate your specific configuration and consent language with qualified privacy counsel before going live.

You don’t have to choose between compliant tag management and identifying your visitors. Deploy identification through GTM, gate it on consent for EEA/UK traffic, honor notice-and-opt-out for US traffic, and Consent Mode v2 and visitor identification coexist cleanly — you keep the US person-level data that matters most, without cutting corners in Europe.

See the identification product for how the tag deploys and how opt-outs flow through, and pair this with the GTM setup walkthrough.

Try Leadpipe free — 500 identified leads, no credit card required.

View All →