Facebook Linkedin Instagram Youtube

Upgrade Consent Mode v2 for Google Ads & GA4: Fix Head Placement

Consent Mode v2 adds two ad-related signals, ad_user_data and ad_personalization, to the original ad_storage and analytics_storage parameters. Any site running Google Ads or GA4 needs to upgrade. The action items are straightforward: fire your default consent state before any tag loads, map your consent platform’s categories to all four signals, and test both the grant and deny paths. Skip this, and you lose modeling accuracy and personalized advertising features.

TL;DR:

  • Consent Mode v2 requires setting four signals—ad_storage, analytics_storage, ad_user_data, and ad_personalization—before any tags load to ensure accurate data control.
  • Advanced implementation offers better measurement and modeling capabilities by firing tags instantly and adjusting based on user consent, but it demands precise default configuration and category mapping.
  • Default consent commands must be placed in the page head prior to tags, with region-specific defaults for areas like the EEA, and need to be verified in browser dev tools to prevent silent failures.
  • Connecting your consent platform and IAB TCF to Consent Mode is straightforward for Google-only setups but requires proper consent update handling for multi-vendor environments.
  • Validating implementation involves inspecting network traffic and cookies, confirming that consent signals are correct, and understanding that modeling improves measurement but cannot replace first-party data or supply raw event data.
Theartistevolution
Strengthen Your Marketing Foundation
The Artist Evolution builds and manages comprehensive campaigns, helping businesses develop their brands and improve visibility across digital channels.

Explore The Artist Evolution

Table of Contents

The original Consent Mode ran on two signals: ad_storage and analytics_storage. Both controlled whether Google tags could read or write cookies. Consent Mode v2 keeps those two but bolts on ad_user_data and ad_personalization, and the distinction between them matters more than most teams realize.

ad_storage and analytics_storage govern storage, meaning whether a cookie gets written to the browser at all. ad_user_data and ad_personalization govern use, meaning what Google is allowed to do with data once it has it, even data that arrives without a cookie. A tag can technically send a hit without writing a cookie, but that hit still carries user data. The new signals decide whether that data can be used for advertising purposes at all.

Here’s the practical breakdown:

  • ad_storage controls whether advertising cookies get set in the browser.
  • analytics_storage controls analytics cookies, the ones GA4 relies on for session and user identification.
  • ad_user_data governs whether user data can be sent to Google for advertising purposes, cookie or not.
  • ad_personalization governs whether that data can power personalized advertising, including remarketing audiences.

Enforcement centers on advertising features and Google’s Ads Help documentation on this makes clear that Consent Mode is a signaling layer, not a consent banner. The EEA is where this shows up most, since regional defaults there typically start denied. But any site targeting EEA users, or serving EEA traffic, needs both new signals wired correctly or personalized ad features simply stop working.

Consent Mode v2 gives you two implementation paths, and the choice affects how much data you keep when someone declines tracking.

  1. Basic implementation blocks Google tags entirely until a user makes a choice. No tag fires, no cookieless ping, nothing. It’s the simplest to build and the easiest for a legal team to sign off on, because the behavior is binary: no consent, no data, full stop.
  2. Advanced implementation loads tags immediately with default consent states applied, then adjusts behavior based on the user’s actual choice. If someone denies consent, Google tags still fire, but instead of cookies, they send cookieless pings. Those pings feed Google’s modeling systems, letting Analytics and Ads estimate what conversions and behavior probably happened among denied-consent users.

The trade-off is real. Basic mode is conservative and predictable. Advanced mode preserves far more measurement value, particularly for advertiser-specific modeling, but it demands cleaner default configuration and tighter mapping between your consent platform categories and the four signals. Some legal teams still prefer basic mode precisely because it never sends a byte before consent is given.

For most marketing-driven sites running Google Ads campaigns, advanced mode is worth the extra setup work; the modeling gains typically outweigh the added complexity. Sites with minimal advertising spend, or those in highly regulated sectors like healthcare or legal services, sometimes lean toward basic mode’s simplicity instead.

Developers implementing Consent Mode v2 need to know exactly what each parameter does and what values it accepts. Here’s the reference:

  • ad_storage: Controls advertising cookies. Values: granted or denied.
  • analytics_storage: Controls analytics cookies used by GA4. Values: granted or denied.
  • ad_user_data: Controls whether user data can be sent to Google for advertising. Values: granted or denied.
  • ad_personalization: Controls personalized advertising and remarketing use. Values: granted or denied.
  • functionality_storage: Governs cookies that support site functionality, like language preferences.
  • personalization_storage: Governs storage related to personalization features outside advertising, such as video recommendations.
  • security_storage: Governs storage used for security purposes, like authentication and fraud prevention.

A frequently missed detail: both ad_user_data and ad_personalization must be set to granted for personalized advertising features to function at all, according to Google Analytics Help’s consent mode reference. Grant ad_storage alone and Google still won’t run personalized ads if either of those two is denied.

There’s also ads_data_redaction, a setting rather than a consent signal. When ad_storage is denied, setting ads_data_redaction to true tell Google tags to strip identifying information more aggressively, redacting click identifiers and page parameters that carry ad-click IDs, and rerouting requests to different domains entirely.

A few common combinations show how this plays out. Deny all four signals, and you get no advertising cookies, no analytics cookies, and no personalized features, though a cookieless ping still lands if you’re running advanced mode. Grant analytics_storage but deny the ad signals, and GA4 measurement runs normally while advertising features stay dark. Grant everything, and the full feature set activates: cookies, personalization, and remarketing audiences all function as designed.

Getting Consent Mode v2 wired correctly comes down to sequencing and mapping. Get either wrong and tags fire before consent is captured, or your consent management platform’s categories never reach Google at all.

Start with placement. Default consent commands must execute in the document <head>, before your Google Tag or Google Tag Manager container snippet loads. This ordering issue is the single most common cause of Consent Mode failing silently, since developer guidance from Google’s Tag Platform is explicit that defaults executed after the container has already fired do nothing useful.

Consent command before tag container sequence

A minimal gtag.js default block looks like this, placed in the head before the container snippet:

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

For region scoping, especially EEA traffic where denied-by-default is the common posture, add a region array to the default call so only specified countries get the conservative default, while other regions can run a more permissive baseline if your legal position supports it.

If you’re running Google Tag Manager instead of raw gtag.js, the setup lives under Admin > Container Settings > Additional Settings > Consent Settings, where you enable built-in consent checks for each tag type. GTM handles the default and update commands through its own consent API, so you don’t need a manual gtag call, but the same head-placement rule still applies to whatever snippet sets your defaults.

Here’s the sequence to follow:

  • Place default consent state in the page head, ahead of any tag container.
  • Configure region-specific defaults for the EEA or any jurisdiction requiring denied-by-default.
  • Map every consent management platform category (functional, analytics, advertising, personalization) to the corresponding one of the four consent signals.
  • Confirm your CMP fires an In-Page Update command the moment a user makes a choice, not just on page reload.
  • Verify stored consent choices persist across sessions and replay correctly before any tag fires on return visits.
  • Decide whether ads_data_redaction should be true for denied ad_storage states, particularly for stricter privacy postures common in healthcare and legal industries.

Pro Tip: Test your default consent state with browser dev tools open on a fresh, unauthenticated profile. If you see any Google tag request fire before your consent banner even renders, your defaults are misplaced, and no amount of CMP configuration downstream will fix it.

Consent Mode itself has no interface. It’s a signaling protocol, not a banner, which is why Google Ads Help frames it as something that works alongside your consent management platform, never in place of one.

Certified CMPs, along with plugins built for platforms like WordPress, typically handle the translation automatically. Once a user makes a choice, the CMP fires the update command that adjusts all four signals without any custom code from your team. That automation is the main reason most mid-size and enterprise sites run a certified CMP instead of hand-rolling consent logic.

The IAB Transparency & Consent Framework matters mainly for programmatic advertising setups involving multiple ad tech vendors beyond Google. If your stack is Google-only, mapping your CMP’s native categories directly to the four consent signals is usually simpler and less error-prone than layering in full TCF string parsing.

Whichever path you take, verify these three things before calling the integration done:

  • The CMP sends automatic consent updates for every tag managed through Google Tag Manager, not just a subset.
  • Hard-coded tags, meaning scripts placed directly in your site’s code outside the tag container, actually respect the same consent signals.
  • Consent choices persist and correctly replay on repeat visits, rather than resetting or defaulting to granted after a session ends.

Testing consent behavior means catching failures that are invisible in the rendered page but obvious in network traffic. Here’s a routine that works across most setups:

  1. Open a fresh, unauthenticated browser profile and load your site without interacting with the consent banner at all. Check the Network tab for any Google tag requests firing prematurely.
  2. Inspect outgoing requests to google-analytics.com or googleads.g.doubleclick.net and look for the consent-state parameters attached to each ping, confirming they match your intended default.
  3. Check the browser’s cookie jar directly. If ad_storage is denied, no advertising cookie should exist, period.
  4. Accept all consent categories and reload. Confirm cookies now appear and that the consent-state parameters flip to granted on subsequent requests.
  5. Deny consent, then return to the site in a new session. Confirm the stored choice replays correctly before any tag fires, rather than resetting to a permissive default.
  6. Test partial grants, such as granting analytics_storage while denying both ad signals, to confirm GA4 measurement continues while advertising features stay dark.

Google’s Tag Assistant extension speeds this up considerably, since it surfaces consent state directly rather than requiring you to parse raw network requests by hand. A reproducible test matrix, covering first-time visitors, returning visitors, full grants, full denials, and partial grants, is worth building once and reusing for every future tag addition. A study on GA4 traffic verification notes that inspecting live GA4 network traffic is one of the more reliable ways to confirm tags are behaving as configured rather than assumed.

Consent Mode’s advanced implementation doesn’t just block or allow tags. It feeds Google’s modeling systems, which estimate conversions and behavior for users who denied consent, based on patterns observed among users who granted it.

Modeling has real thresholds. Google’s own documentation lists volume requirements, generally in the range of 1,000 events per day within a given denied or granted slice over a rolling seven day window, before advertiser-specific modeling activates at all. Below that threshold, you get general country-level or aggregate modeling instead, which is far less precise.

Modeling cannot replace everything a granted cookie gives you. It does not supply:

  • Remarketing or custom audience creation, since those require actual user-level identifiers.
  • Certain raw data exports available only for observed, non-modeled events.
  • Predictive metrics like purchase probability, which depend on individual-level signal history rather than aggregated estimates.

The practical move is to treat modeled data as a directional supplement, not a replacement for first-party data collection. Combining server-side first-party signals with Google’s modeled estimates, an approach covered in more depth in Theartistevolution’s cookieless marketing roadmap, tends to produce the most reliable reporting picture for teams navigating shrinking cookie-based visibility.

Most Consent Mode failures don’t throw errors. They just quietly under-report or over-restrict, and nobody notices until a quarterly report looks off.

The most common culprit is defaults declared inside the tag container instead of the page head. Fix it by moving the default consent call above the container snippet entirely.

Second is the single-toggle banner, one accept/reject button that collapses all four signals into one choice. This flattens nuance your legal team may actually want. Split categories in your CMP configuration so functional, analytics, and advertising consent can be granted or denied independently.

Third: assuming your CMP automatically covers every tag. It usually doesn’t cover hard-coded scripts outside the tag container. Audit your codebase directly for any Google tag not routed through GTM.

Pro Tip: Never read a modeled conversion count as an observed one in your reporting deck. Label modeled figures explicitly, since treating estimates as raw data is one of the fastest ways to make a stakeholder distrust your entire measurement setup.

Enterprise rollouts fail more often from coordination gaps than technical ones. Start with a full tag inventory: every Google tag, who owns it, and whether it’s managed through Google Tag Manager or hard-coded. That inventory becomes your remediation punch list.

Schedule the upgrade in a defined window with a QA plan attached, not as a background task squeezed between other sprints. Privacy and legal teams need to sign off on category mapping before analytics teams touch a single line of code, and ad-ops needs visibility into how the change affects campaign optimization signals.

Where possible, use Google Tag Manager’s built-in consent settings rather than custom scripting. It’s easier to audit and easier to hand off to another developer later. Enforce head placement as a non-negotiable rule in your deployment process, and build a lightweight regression test that runs after every tag change to confirm consent behavior hasn’t broken.

The Real Bottleneck Isn’t the Code

Most Consent Mode v2 guides treat this as a purely technical exercise: paste the script, map the categories, done. That undersells what actually determines success. The hard part is rarely the gtag call. It’s getting privacy, analytics, and ad-ops teams to agree on category definitions before a single line of code ships.

Conventional advice leans heavily on “basic mode is safer,” and for narrow legal risk tolerance, that’s fair. But teams that default to basic mode without seriously weighing advanced mode’s modeling benefits are often leaving real measurement value on the table out of caution rather than necessity. The EEA’s denied-by-default posture doesn’t require basic implementation. It requires correct region scoping and defaults, which advanced mode handles just as well.

If you take one thing from this, prioritize placement and mapping over the more visible parts of setup. A perfectly designed consent banner wired to defaults that fire too late accomplishes nothing. Get the sequencing right first. Everything else, modeling quality, personalized ad performance, clean reporting, follows from that foundation.

— Derek

Theartistevolution gives you a faster path to a compliant, correctly wired Consent Mode v2 setup than trying to reverse-engineer Google’s documentation team by team across legal, analytics, and ad-ops.

Theartistevolution

A consent audit maps every Google tag on your site, flags hard-coded scripts your CMP might be missing, and produces a prioritized remediation plan ranked by risk and measurement impact. From there, a marketing agency can manage the rollout directly, handling default placement, category mapping, and the ongoing tag governance that keeps things from drifting out of compliance over time. This work sits alongside broader marketing tools support and campaign management services, so your measurement stack and your active advertising campaigns stay in sync rather than working against each other. If your Ads and GA4 data has looked shakier since privacy regulations tightened, request a marketing assessment and get a clear picture of what’s broken and what it will take to fix it.

Where to Verify the Details

For the parameter definitions and setup mechanics covered here, go directly to Google’s Tag Platform consent guide and the Analytics Help consent mode reference. Both stay current as Google updates enforcement and default behavior.

Sources

FAQ

It’s not legally mandatory everywhere, but Google requires it for sites using personalized advertising features or advertiser-specific modeling in the EEA and UK. Sites running Google Ads or GA4 without it risk losing access to those features and to accurate modeled reporting.

Place a default consent command in your page head before your Google Tag or Google Tag Manager container loads, then map your consent management platform’s categories to ad_storage, analytics_storage, ad_user_data, and ad_personalization. Confirm your CMP fires an In-Page Update when a user makes a choice.

Version 1 used only ad_storage and analytics_storage to control cookie storage. Version 2 adds ad_user_data and ad_personalization, which govern whether user data can be used for advertising and personalization, regardless of whether a cookie was stored.

Inspect network requests on a fresh browser profile to confirm consent-state parameters match your defaults, check the cookie jar to verify denied categories write no cookies, and test accept, deny, and partial-grant flows on both first-time and returning visitor sessions. Tools like Google’s Tag Assistant make reading consent state faster than parsing raw requests manually.

Yes. When users deny consent, GA4 relies on modeled data to estimate their behavior, and Google requires a certain volume of daily events over multiple days before advertiser-specific modeling activates reliably.