Consent Mode V2 in GA4: What Marketers Must Fix Now

Luxury desk with compliance checklist and pen

Upgrade to Consent Mode V2 if you run Google Ads or GA4 alongside any consent banner. It adds two new signals, ad_user_data and ad_personalization, and Google now requires them for ad measurement and personalized ads. If you have not touched your tag setup since 2023, treat this as urgent: audit your tags this week, confirm your consent management platform can output the new signals, and push the update before your next reporting cycle closes.

TL;DR:

  • Ensure your tag inventory is complete and correctly distinguishes between Google-native and custom tags before implementing Consent Mode V2.
  • Google now requires two additional consent signals, ad_user_data and ad_personalization, for ad measurement and personalized ads, influencing remarketing and attribution.
  • Proper sequence of default consent setting, user consent updates, and SDK version updates is critical for accurate data collection and avoiding broken campaigns.
  • Verifying correct signal transmission involves inspecting network requests for gcs and gcd parameters, not just relying on the consent banner appearance.
  • Most errors stem from unconnected consent updates, outdated SDKs, or improper tag sequencing, risking significant data loss despite compliant-looking banners.

Table of Contents

Before anyone touches a line of gtag.js or opens Google Tag Manager, you need a clear picture of what you are working with. Rushing this step is exactly how brokerages and agencies end up with broken remarketing lists three weeks later and no idea why.

Start with a full tag inventory. You need to know which tags are Google-built (Google tag, GA4, Google Ads, Conversion Linker) and which are custom or third-party, because Google tags with built-in consent checks behave differently than tags you have to wire up manually.

A few things to lock down before you touch production:

  • Pull a complete tag inventory and flag which tags are Google-native versus custom-built.
  • Confirm your GA4 property and any linked Google Ads accounts are correctly connected and accessible to whoever is doing the migration.
  • Verify your consent management platform can actually output granular signals for all four consent types, not just a blanket accept/reject toggle.
  • Assign one owner for the web-side changes and a separate owner for app-side SDK updates, then block out a real testing window before rollout.

That last point matters more than it sounds. Consent Mode V2 touches both your website tags and your mobile SDKs, and those are usually managed by different people on different timelines. Someone needs to own the whole migration, not just their half of it.

Consent Mode V2 adds two consent parameters on top of the original two: ad_user_data and ad_personalization. The original version only asked about ad_storage and analytics_storage. V2 asks a sharper question: can Google use this visitor’s data for ad measurement, and can it use that data to personalize ads shown to them?

Statistic callout: Google has tied V2 enforcement directly to advertising features in the EEA, but the practical effect reaches every market. If your CMP still only sends the legacy two parameters, GA4 and Google Ads treat the missing signals as unconsented, which quietly shrinks your remarketing audiences and degrades conversion modeling regardless of where your traffic comes from.

Here is what actually shifts once V2 is live:

  • Enhanced conversions and personalized ads now depend on ad_user_data and ad_personalization being explicitly set, not inferred from the older parameters.
  • GCLID handling changes: without consent, Google Ads can’t reliably stitch click IDs to conversions, so attribution gets modeled instead of measured directly.
  • Modern tag transport is mandatory. You need gtag.js or Google Tag Manager configured for V2. Older hardcoded tag snippets from 2021 or earlier will not send the new parameters correctly, no matter how well your banner looks.
  • Google’s enforcement push started with the EEA, but the underlying schema change applies globally the moment you update your container, so non European sites feel the same reporting shifts.

The practitioners at Simo Ahava’s blog have been flagging this since the rollout began: a lot of sites technically show a compliant banner but never wire it into Consent Mode at all, which means Google receives nothing and defaults to the most restrictive assumption.

Four consent parameters now govern almost everything GA4 and Google Ads collect: ad_storage, analytics_storage, ad_user_data, and ad_personalization. A fifth flag, ads_data_redaction, controls whether Google strips identifying details from ad clicks even when some consent is granted.

Each parameter controls a distinct slice of behavior, and mixing them up is the single most common implementation mistake we see.

Consent parameter When granted When denied
ad_storage Ad cookies set normally; click IDs stored No ad cookies; cookieless ping sent instead
analytics_storage GA4 cookies persist across sessions Cookieless ping; session data modeled, not measured
ad_user_data User data can be used for ad measurement Enhanced conversions and offline conversion imports blocked
ad_personalization Personalized and remarketing ads allowed Remarketing lists exclude the user entirely

When consent is denied, Google does not simply stop collecting. It sends what’s called a cookieless ping, a lightweight signal that confirms a visit happened without storing any identifying cookie. Google’s consent mode reference documents how these pings encode consent state directly into the request using two HTTP parameters, gcs and gcd, which is exactly what you’ll be inspecting later when you verify your setup.

A few practical consequences worth memorizing:

  • Denying ad_storage alone does not block analytics. Denying analytics_storage does not block ads. They are independent switches.
  • Remarketing lists in Google Ads require both ad_storage and ad_personalization granted. Miss either one, and that visitor never enters your audience.
  • Click-ID export (GCLID passed to Google Ads for attribution) requires ad_user_data granted, separate from whether ads themselves are personalized.
  • Google fills the resulting data gaps using statistical modeling based on consented traffic patterns, not guesswork pulled from nowhere. The more consented data you have, the more accurate that modeling gets.

Basic mode blocks Google tags entirely until a visitor makes a consent choice. Nothing fires, nothing pings, nothing gets measured until the banner is answered. It’s the safer default but it also means every visitor who ignores your banner (and plenty do) generates zero data.

Advanced mode takes the opposite approach: tags load immediately with default consent states, typically denied, and send cookieless pings that Google uses to model conversions and behavior it cannot directly observe. That modeling is generally more accurate than what basic mode can produce, simply because there’s more signal to work with, even anonymized signal.

Which one should you run?

  • Choose basic mode if your CMP’s consent-update timing is unreliable or your legal team wants zero ambiguity about pre-consent data collection.
  • Choose advanced mode if you want stronger conversion modeling and your CMP updates consent state quickly and consistently after a user’s choice.
  • Consider your traffic mix. Sites with heavy EEA or California traffic under active regulatory scrutiny often lean toward basic mode for the extra caution.

Pro Tip: If your CMP fires the consent update signal within a second or two of the user’s click, advanced mode is almost always worth the modeling upside. If you’ve ever seen your CMP lag or fail silently, stick with basic mode until that’s fixed.

The code side of this migration is more forgiving than most marketers expect, but the sequencing has to be right or nothing works.

Hands adjusting tech hardware cable

Start with a default consent state, set before any Google tag fires. This tells Google how to behave until the user makes a choice:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied'
});

That snippet needs to load before your GA4 config tag and before Google Ads tags, every time, no exceptions. Once the user interacts with your banner, update the state:

gtag('consent', 'update', {
  'ad_storage': 'granted',
  'analytics_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

If you’re managing this through Google Tag Manager instead of hand-coded gtag.js, the pattern shifts slightly:

  1. Open Admin > Container Settings and enable Consent Overview so GTM understands consent types exist.
  2. Set default consent values using a Consent Initialization tag that fires before every other tag category, using the Built-In Consent Settings template.
  3. Configure each Google tag’s Advanced > Consent Settings to require the specific consent types it needs (most GA4 and Ads tags will need this pre-checked by default in newer container versions).
  4. Wire your CMP’s consent update event to a trigger that fires the gtag('consent','update', ...) call the moment a user makes a choice.
  5. Sequence tags so the Consent Initialization tag fires first, banner logic fires second, and measurement tags fire last, respecting the consent state at that point.

Custom or third-party tags don’t get this consent-awareness automatically. You have to add checks manually in GTM for anything that isn’t a native Google tag, since only Google-built tags read consent state out of the box.

A consent banner without a technical bridge to Consent Mode does not “protect” your data, it just throws it away. Google receives nothing, assumes the worst, and models around a gap you created yourself.

That warning, echoed across analytics practitioner commentary, is the single most common failure mode in real migrations. Marketers install a slick-looking banner, feel compliant, and never realize the banner and Consent Mode were never actually connected. The two most frequent causes: legacy tag snippets that predate consent parameters entirely, and asynchronous CMPs that fire their consent-ready event after Google tags have already loaded, creating a race condition where the default state (usually fully denied) sticks permanently.

Mobile apps need the same consent signals as your website, but they travel through your Firebase and Analytics SDKs instead of gtag.js. If you haven’t touched your SDK versions in a while, this is where migrations quietly stall.

The requirements are specific enough to check line by line:

  • Update to Firebase Analytics SDK version 5.0 or later on Android, since older versions do not recognize the V2 parameters at all.
  • On iOS, confirm you’re running a recent Analytics SDK release that supports consent state APIs, and check your dependency manager for pending updates before assuming you’re current.
  • Map your in-app consent choices to the same four parameters, paying particular attention to how advertising ID (IDFA on iOS, advertising ID on Android) collection ties to ad_user_data and ad_personalization.
  • Test consent propagation using a staged rollout rather than pushing to 100% of users at once. Confirm the app correctly reads and applies consent state before the first analytics event fires each session.

Skipping the SDK check is the single most common app-side mistake. Marketing teams update the website perfectly, then forget the app was still running an SDK from two release cycles ago.

Don’t trust the banner. Trust the network requests.

Open your browser’s developer tools, filter for requests to google-analytics.com or googleads.g.doubleclick.net, and inspect the query parameters on outgoing pings. You’re looking specifically for gcs and gcd, the encoded consent state parameters that confirm what Google actually received, not what you think you sent.

Walk through verification in this order:

  1. Load the page with no consent choice made yet and confirm the default state matches what you configured, denied across the board unless you deliberately set otherwise.
  2. Interact with the banner, grant consent, and reload the network panel to confirm gcs/gcd values flip to reflect granted status.
  3. Open GA4’s DebugView and confirm events are firing with the expected consent-aware parameters attached, and check Realtime to make sure the events show up at all.
  4. Check for the presence or absence of GA4 and Ads cookies in your browser’s storage inspector; denied consent should mean no persistent cookie, only the cookieless ping.
  5. If any of this fails, work backward through the usual suspects: CMP mapping errors (the banner says “granted” but never calls the gtag update), tag firing order problems, or an SDK that’s still on a pre-V2 version.

Statistic callout: Modeled conversion data does not appear instantly. Google needs a sustained volume of consented and unconsented traffic to build a reliable model, so plan to monitor GA4 and Google Ads reporting for at least seven full days before judging whether your numbers look right after migration.

Most verification failures trace back to one of three causes: the CMP fires its update event too late, a custom tag was never given a consent check in GTM, or someone forgot the app SDK entirely. Rule those out in order and you’ll usually find the break within an hour.

Work through this in order rather than jumping ahead, since each step depends on the one before it.

  1. Audit every tag and confirm your CMP can output all four consent parameters, then map each consent choice in your banner to its corresponding V2 value.
  2. Update your GTM container or gtag.js implementation, migrating any legacy tag snippets to modern transport that supports the new parameters.
  3. Implement the consent default and update calls, test them thoroughly in a staging environment, then upgrade your app SDKs to versions that support V2.
  4. Verify everything in a development environment first, roll out to production, and monitor GA4 and Google Ads reporting for at least seven full days before drawing conclusions.

Pro Tip: Run steps one through three in a low-traffic window, like a weekend, so if something breaks, you’re not losing a week of prime-time conversion data while you debug it.

Why Most Teams Get This Migration Wrong

The conventional advice treats Consent Mode V2 as a compliance checkbox: install a banner, flip a setting, move on. That framing misses the actual risk, which isn’t legal exposure. It’s data loss you won’t notice until your remarketing audiences quietly shrink and nobody can explain why conversions dropped.

Why Most Teams Get This Migration Wrong — overview diagram

The teams that get this right treat it as a tag management project, not a legal one. They audit before they touch anything, they test the CMP-to-gtag bridge specifically rather than assuming a compliant-looking banner means a working one, and they give the app side equal attention instead of treating it as an afterthought behind the website.

If you take one thing from this whole migration: verify with the network panel, not with your eyes on the banner. A beautiful, GDPR-compliant popup that never fires a single gtag('consent','update', ...) call is worse than no banner at all, because it creates false confidence while your ad data quietly evaporates. Fix the bridge first. Everything else is secondary.

— Jason

Consent Mode V2 is a tag management fix, but the payoff shows up in your pipeline. Once your GA4 signals are trustworthy again, that data becomes the foundation for smarter lead segmentation and sharper remarketing, which is exactly where Plo’s prospecting tools pick up the work. If your team would rather have someone else own the tag audit, the consent mapping, and the ongoing verification while you focus on closing deals, book a demo and we’ll walk through what a clean, consent-compliant measurement setup looks like for your brokerage.

Sources

Get Started