Consent Mode v2: what you need to set up and check now

Consent Mode v2: What You Need to Set Up and Check Now

Consent Mode v2 adds two new parameters, ad_user_data and ad_personalization, and if you use Google Ads or GA4, you need to upgrade your implementation and verify it. Without this, you lose personalized advertising and part of your conversion data. The next step is simple: run Tag Assistant, check the consent parameters on your site, and check whether your CMP already has the update built in. If you manage your own custom consent banner, you'll need to add the new parameters manually.

In short:

• If you use Google Ads or GA4, you need to upgrade to consent mode v2, otherwise you'll lose access to personalized advertising and accurate conversion measurement.
• When choosing between a basic and advanced implementation, effective data modeling requires the advanced mode to be active, based on denied values for every tag before the page loads.
• It's essential to set default consent parameters to denied in advance and only update them once the user has actually given consent, otherwise you risk both legal compliance and missed opportunities to use the data.
• Technically, you need to place the default call in your code first, then update the state with an "update" call, where the order and correct configuration matter — especially in GTM or on the server.
• Regularly check that everything's working using Tag Assistant and the diagnostics in Google Ads and GA4, since an incorrect setting or missing signals can silently prevent data collection and behavioral modeling.

Table of Contents

• What consent mode v2 is, and what changes it brings
• Basic or advanced implementation: what happens to your tags
• Implementation in practice: gtag.js, Google Tag Manager, and server-side
• CMP integration and correctly setting the default state
• How to verify your implementation and fix errors
• Behavioral modeling in GA4: thresholds and limitations
• A checklist for a production rollout
• What most often gets overlooked when upgrading to v2
• How Moxy-web helps with the upgrade to v2
• Sources
• Frequently asked questions

What consent mode v2 is, and what changes it brings

Consent Mode v2 is Google's upgraded consent management system, which tells tags what data they're allowed to process based on the user's choice. Google introduced it after changing the rules for personalized advertising in the European Economic Area, and recommends the update to everyone using Google Ads or GA4.

The system works based on consent type parameters. Each one tells Google's tags what they're allowed to do with a specific type of data:

• ad_storage — allows storing cookies related to advertising.
• analytics_storage — allows storing cookies for analytics, such as in GA4.
• ad_user_data — a new v2 setting, allowing user data to be sent to Google for advertising purposes.
• ad_personalization — a new v2 setting, allowing data to be used for personalized advertising and remarketing.
• functionality_storage — allows storage that supports the site's functionality (language settings, for example).
• personalization_storage — allows storage for content personalization not directly related to advertising.

Google uses the first four settings to decide which tags can send data, and in what form. What's new in v2 isn't just the addition of two parameters — it's the fact that, without ad_user_data and ad_personalization, Google Ads can no longer reliably run personalized advertising or accurate conversion measurement for users in the EEA. For a marketing team, this directly affects the reach of remarketing campaigns; for a developer, it means the new parameters need to be correctly included in every gtag call, or in the GTM configuration.

Basic or advanced implementation: what happens to your tags

The choice between a basic and advanced implementation determines how tags behave before a user makes their consent choice. With a basic implementation, tags for which consent is declined simply don't load at all. With an advanced implementation, they load with a default setting of denied, and send a limited, cookieless ping that lets Google model the missing data.

This distinction isn't cosmetic. A basic implementation is simpler to set up, since tags simply wait for consent. But because they never load, Google has no signal at all to model conversions for users who don't give consent. An advanced implementation allows for more precise, advertiser-specific modeling, but requires the developer to correctly set up the default call with denied values before any tag loads.

In practice, this means:

• Sites with a high rate of declined consent and a significant Google Ads budget almost always need an advanced implementation, since basic leaves too many gaps in conversion data.
• Smaller sites with limited traffic can start with a basic implementation, since the difference in modeling accuracy is less pronounced at a small data volume.
• Online stores that rely heavily on remarketing effectively have no choice. Without an advanced implementation and ad_user_data, they lose access to a large part of their advertising audience.

To compare both approaches against real traffic, it's also worth looking at the GA4 setup for online stores, where modeling logic ties directly into the accuracy of revenue reporting.

Implementation in practice: gtag.js, Google Tag Manager, and server-side

The technical implementation of consent mode v2 happens at three levels, and each has its own pitfalls. The basic principle is the same everywhere: set the default state first, then your tags, and update consent through a separate call once the user makes a choice.

Pro tip: The gtag('consent', 'default', …) call needs to be the very first line of JavaScript on the page, before the gtag.js library even loads. If you place it after the GTM container, you risk some tags loading without the default denial in place.

1. Set up the default call. Something like this pattern needs to run on every page before anything else loads:

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

2. Add an update call after the user's choice. Once the user accepts or declines the categories, the CMP sends:

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

3. Use Consent Overview in Google Tag Manager. This view in the interface shows which tags are tied to which consent type, and where a trigger might be missing. Set default consent values at the container level, not just per individual tag, since this reduces the risk of a new tag forgetting to check consent altogether.
4. Add Conversion Linker. If you're using a server-side container, Conversion Linker needs to run there too, not just in the web container, otherwise you'll lose part of your ad-click data.
5. In a server-side setup, forward the consent pings. A server-side container needs a GA4 client, Conversion Linker, and a Google Ads container correctly connected, so consent state travels from browser to server without loss. If the server-side layer doesn't pass consent parameters along, modeling on the Google Ads side simply won't activate, no matter how correctly the browser side is configured.
6. Update your mobile SDKs. For Android and iOS apps, the SDK needs to be upgraded so consent signals correctly reach Google Ads and Firebase Analytics. Older SDK versions simply don't recognize the v2 consent parameters.

The order of calls is by far the most common source of mistakes here. Default must come first, update only after the user interacts, and neither call should depend on whether the page has fully finished loading.

CMP integration and correctly setting the default state

A certified CMP partner makes the work considerably easier, since Google updates it regularly alongside changes to Consent Mode. If you're using a certified consent management platform, the new v2 settings are often installed automatically, with no developer intervention needed.

Your own custom consent banner gives you full control over design and copy, but requires manual work every time Google's requirements change. This is exactly where things most often go wrong: a developer simply doesn't add the two extra parameters, since they didn't exist when the original setup was built, before v2.

Regardless of which solution you choose, two rules apply and aren't optional for users in the EEA and the UK:

• The default state on the page must be denied before the user makes any choice at all. That means tags must never assume consent.
• The update on the page must only follow the user's actual choice, not come before it and not fire automatically after some period with no interaction.

This isn't just a technical recommendation — it's a requirement stemming from European privacy rules. Businesses operating in the EEA or the UK need to be able to prove that consent signals are genuine and verifiable, not just cosmetically present in the code. Google also checks this through its CMP partner program, which requires providers to send signals in a structured, standardized format. For a broader look at the requirements, the guide to GDPR compliance online is also useful, explaining the wider legal framework within which consent mode operates.

How to verify your implementation and fix errors

Verification isn't optional, since consent mode v2 is a system where a single wrong line of code can silently stop the entire data flow, without the site appearing to behave any differently.

1. Run Tag Assistant. Open the page in debug mode and look at the Consent events output. Check that all four key parameters are visible — ad_storage, ad_personalization, ad_user_data, and analytics_storage — and that they have the correct values both before and after the user interacts.
2. Check the on-page default value. Tag Assistant should show denied as the initial state. If it shows granted, or if a parameter is missing from the output entirely, the default call is set up incorrectly or fires too late.
3. Check the update after the choice. When you simulate accepting consent, the values need to change to granted without a page reload.
4. Review the diagnostics in Google Ads and Analytics. Both interfaces show the status of your consent mode implementation and flag missing key signals. Modeling data appears in reports with a delay, since Google needs time to collect enough samples.
5. Check coverage across the whole site, not just the homepage. A common mistake is having consent mode correctly set up on the homepage, while the checkout page's GTM container never receives the correct signal at all.

The most common mistakes you'll run into during implementation are a missing default call before the GTM container loads, the wrong order between the default and update calls, and GTM containers blocked because of incorrectly configured triggers for specific consent types. All three can be spotted in a single Tag Assistant review, once you know what to look for.

Behavioral modeling in GA4: thresholds and limitations

GA4 doesn't just let data from users who declined consent disappear — it tries to statistically estimate it through behavioral modeling. But this feature isn't automatically enabled for every property.

The threshold for triggering modeling: a property needs to collect at least 1,000 events per day with analytics_storage set to denied for at least seven days, and also have at least 1,000 daily users with analytics_storage granted on at least seven of the last 28 days. Smaller sites often don't meet this threshold, and so don't get more precise, advertiser-specific modeling.

Once the threshold is met, modeling affects metrics such as users, sessions, first visits, and events, meaning GA4 reports show an estimate of overall behavior, not just actually recorded interactions. The impact of modeling on Google Ads conversions shows up at the domain and country level within four weeks of activation.

Some features aren't supported by modeled data. These include building remarketing audiences based on individual events, using the tool to investigate individual users, and exporting raw data. Modeling corrects the aggregate picture — it doesn't reconstruct the individual trail of every single visitor.

A checklist for a production rollout

Before you publish the upgrade live, check the following points, since these are where things most often go wrong in practice:

• The default call runs before every other script on every page, not just the homepage.
• The update call correctly sends all four consent type parameters, not just the original two from v1.
• The server-side container has Conversion Linker set up and is receiving consent pings from the browser.
• Your CMP is either a certified partner with built-in v2 support, or your own banner has been manually updated with the new parameters.
• Tag Assistant shows no missing or incorrect values for any consent type on any key page (homepage, category, checkout).
• Mobile apps are using updated SDKs for Android and iOS.

Pro tip: Write up a short internal note on who's responsible for updating consent parameters every time Google makes a future change. Marketing often notices a data drop before a developer does, so there needs to be a clear path for that notice to reach the right person.

Regular testing after every major site change matters precisely because consent mode operates in the background, and an error isn't visible at a glance — not until you look at conversion reports a week or two later.

What most often gets overlooked when upgrading to v2

Working on projects that required upgrading an old consent mode implementation, the problem usually turned out not to be a lack of knowledge, but the wrong order of work. Teams set up the CMP banner first, and only afterward think about how it connects to the GTM container — and that's when they discover the default call is missing, or placed after other scripts have already loaded.

We recommend an advanced implementation practically every time a business is actively investing in Google Ads campaigns, since a lost signal under a basic implementation directly means worse-optimized campaigns. A server-side setup makes sense once a site already has serious traffic and multiple advertising channels, since at that point the benefit of more accurate data transfer outweighs the added technical complexity.

Collaboration between legal, marketing, and development matters just as much here as the code itself. Legal defines which consent categories are needed, marketing defines which data is business-critical, and the developer makes sure both are correctly mapped into the code, with no gap between the default and update calls.

— Ziga

How Moxy-web helps with the upgrade to v2

Some providers offer end-to-end consent mode services, covering the website, the GTM container, and a server-side setup all at once, which can mean less time coordinating between a developer and an agency, and faster fixes for errors that only show up in Tag Assistant after a detailed review. Under its Support & Maintenance and Online Stores services, Moxy-web handles GTM and server-side container implementation, CMP platform integration, and testing consent parameters after every major site change.

Since Moxy-web builds code custom rather than relying on pre-built platforms, every consent mode upgrade is tailored to your site's actual structure, not a generic template. If you'd like to find out where your current implementation is leaking data, check out the Moxy-web offering and arrange an initial review of your setup.

Sources

For further reading, Google's own official resources are the most reliable: the documentation on consent mode concepts, Google Ads help, and GA4 help on behavioral modeling. This technical overview of checking unusual traffic sources is also useful, as an example of detailed data testing in GA4.

• Adapt to privacy and regulatory changes with consent mode - Google Ads Help
• Google developers — consent mode concepts

Frequently asked questions

How do I enable Google consent mode v2?

First, add a default call with all four consent parameters set to denied, before any other script loads. Then add an update call that fires once the user makes their consent choice, whether through a certified CMP or your own custom banner.

What's the difference between v1 and consent mode v2?

Consent mode v2 adds two new consent type parameters, ad_user_data and ad_personalization, which v1 didn't have. Without these two parameters, Google Ads can't reliably run personalized advertising for users in the EEA and the UK.

Is consent mode v2 mandatory?

Google doesn't formally describe it as legally mandatory beyond what local legislation already requires, but without the upgrade you lose access to personalized advertising and part of your remarketing audiences in the EEA. For businesses advertising on Google Ads, the upgrade is, in practice, essential to maintaining campaign performance.

Is consent mode v2 GDPR-compliant?

Consent mode v2 is a tool that helps a business technically implement a user's choices, but it doesn't guarantee GDPR compliance on its own. Compliance depends on whether your CMP or your own banner is legally sound — whether the default state is genuinely denied, and whether the user gives consent freely — which the guide to GDPR compliance also explains.

How many events do I need for modeling in GA4?

A property needs at least 1,000 events per day with analytics_storage denied for at least seven days, plus at least 1,000 daily users with a granted state on seven of the last 28 days. Smaller sites often don't reach these thresholds, so modeling doesn't activate for them.

Recommended

• A Web Analytics Guide for Better Decisions
• Integrating Your Website with a CRM Without Losing Leads
• Website Data Security Without Guesswork