Google Consent Mode v2: A Complete Implementation Guide

Google Consent Mode v2 (GCM v2) became mandatory in March 2024 for any website or app serving users in the European Economic Area (EEA) and the United Kingdom that uses Google Ads or Google Analytics 4 (GA4). If your site falls into this category — and most do — you need to implement Consent Mode v2 to maintain access to key Google advertising features, including remarketing audiences, conversion modelling, and behavioural reporting. Google's enforcement timeline is real: sites that fail to adopt Consent Mode v2 risk losing remarketing list eligibility, seeing conversion measurement degrade, and eventually facing restrictions on personalised advertising delivery in European markets. This guide walks through exactly what Consent Mode v2 requires: the four consent parameters you must configure, the difference between Basic and Advanced implementation modes, how to set the default consent state before any tags fire, how Nuvo Consent automates the entire Consent Mode integration so you never touch gtag directly, and how to verify your implementation using Google Tag Manager Preview and Tag Assistant. By the end, you will have a complete, production-ready Consent Mode v2 setup — whether you use gtag directly, Google Tag Manager, or both.

What is Google Consent Mode v2 — and why it became mandatory

Google Consent Mode is a mechanism that lets your website communicate user consent choices directly to Google's tags — gtag, Google Tag Manager, Google Analytics 4, and Google Ads — so those tags can adjust their behaviour based on whether the user has granted or denied consent for specific types of data processing. Version 1, launched in 2020, introduced two consent signals: ad_storage and analytics_storage. Version 2, which became mandatory for EEA and UK traffic in March 2024, expanded the model to four consent signals by adding ad_user_data and ad_personalization, bringing Consent Mode into alignment with the Digital Markets Act (DMA) and evolving guidance from European data protection authorities. The key shift in v2 is that Google no longer treats the absence of a consent signal as implicit permission. If you do not send explicit consent signals for all four parameters, Google will assume consent is denied — effectively blocking conversion modelling, remarketing data collection, and personalised ad serving for your European traffic. For advertisers and publishers who depend on these capabilities, implementing Consent Mode v2 is not optional; it is a prerequisite for continued access to Google's advertising measurement and optimisation tools in one of the world's largest digital ad markets.

The four consent parameters: ad_storage, analytics_storage, ad_user_data, and ad_personalization

Consent Mode v2 defines four consent types that map to specific Google tag behaviours. Each must be set to either 'granted' or 'denied' before any Google tags fire on your page. ad_storage controls whether cookies related to advertising can be set or read — this covers Google Ads conversion tracking, remarketing tags, and Floodlight tags. When denied, Google will not set advertising cookies and will use cookieless pings instead (in Advanced mode) to maintain limited measurement capability. analytics_storage governs analytics cookies used by Google Analytics 4, including the _ga and ga* cookies. When denied, GA4 will not set these cookies and will rely on cookieless signals for basic measurement. ad_user_data, new in v2, controls whether user data can be sent to Google for advertising purposes — this is the parameter most directly tied to the DMA's consent requirements. When denied, Google will not use the user's personal data for building advertising audiences or for conversion measurement that relies on user-level data. ad_personalization, also new in v2, controls whether the user's data can be used for personalised advertising — specifically, for remarketing and for tailoring ad creative based on user behaviour. Denying this parameter prevents the user from being added to remarketing lists and disables personalised ad features in Google Ads. These four parameters are independent: a user could grant analytics_storage while denying ad_storage, or grant ad_user_data while denying ad_personalization. Your consent management platform should support this granularity, and your default consent state should deny all four until the user makes an explicit choice.

Setting the default consent state: deny all, wait for user choice

The most critical technical detail in Consent Mode v2 is the default consent call. This snippet must execute before any Google tags load — typically as the first script in your page's . It sets all four consent parameters to 'denied' and configures a wait_for_update timeout (in milliseconds) that tells Google tags how long to wait for an updated consent signal before proceeding with denied defaults. The region parameter is also important: it lets you scope the default-deny behaviour to specific geographic regions (typically EEA countries plus the UK), so that users outside those regions are not affected. Google recommends a wait_for_update value of 500ms, which gives your consent management platform enough time to retrieve saved preferences and fire the consent update call before tags execute. If the user has previously granted consent and that preference is stored (for example, in a first-party cookie set by your CMP), the update call with 'granted' values should fire within that 500ms window, and Google tags will behave as though consent was granted from the start. If the user has not consented, or if the update call does not arrive before the timeout, tags will operate in consent-denied mode and will not set cookies.

<script>
// Set default consent state before tags fire
window.dataLayer = window.dataLayer || [];
function gtag() { dataLayer.push(arguments); }
gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500,
  region: ['GB', 'AT', 'BE', 'BG', 'HR', 'CY', 'CZ', 'DK', 'EE', 'FI', 'FR', 'DE', 'GR', 'HU', 'IE', 'IT', 'LV', 'LT', 'LU', 'MT', 'NL', 'PL', 'PT', 'RO', 'SK', 'SI', 'ES', 'SE']
});
</script>

Basic vs Advanced Consent Mode: blocked tags vs cookieless pings

Consent Mode v2 offers two implementation approaches: Basic and Advanced. In Basic mode, Google tags are completely blocked from loading until the user grants consent. When consent is denied, tags never fire — no data reaches Google servers, and no cookieless pings are sent. This is the simpler model and the one preferred by data protection authorities because it most cleanly respects user refusal. The downside is that you lose all measurement for users who deny consent, including aggregated, non-identifiable data. In Advanced mode, Google tags load regardless of consent state, but when consent is denied, the tags operate in a restricted cookieless mode: they send cookieless pings to Google servers that contain no personal data and set no cookies. These pings enable Google's conversion modelling and behavioural modelling features, which use machine learning to fill gaps in your analytics and conversion data caused by users who deny consent. Google claims that Advanced mode can recover up to 70% of the conversion journey data otherwise lost to consent refusals. The trade-off is that Advanced mode involves data transmission even for users who deny consent — albeit without cookies or personal identifiers. Which mode you choose depends on your risk tolerance, your regulator's expectations, and your reliance on modelled data for ad campaign optimisation. Most advertisers in competitive European markets adopt Advanced mode because the modelled data recovery materially improves campaign performance, but you should review this choice with your legal or compliance team.

How Nuvo Consent activates Google Consent Mode v2 automatically

Nuvo Consent integrates with Google Consent Mode v2 at the SDK level, so you do not need to write or maintain any gtag consent calls yourself. When you install the Nuvo Consent SDK on your domain and configure your consent categories, the SDK automatically maps your consent categories to the four GCM v2 parameters. The default consent state is injected into the page before any other scripts execute, with all four parameters set to 'denied' and a 500ms wait_for_update window. When a user makes a consent choice — whether accepting all categories, rejecting all, or selecting a custom mix — the SDK immediately fires the corresponding consent update call with the correct 'granted' or 'denied' values for each parameter. This mapping follows a simple logic: if the user accepts the analytics category, analytics_storage is set to 'granted'; if the user accepts the marketing or advertising category, ad_storage, ad_user_data, and ad_personalization are set to 'granted'. The SDK also handles consent resubmission on every page load: it reads saved preferences from the consent cookie, fires the default-deny call, then fires the update call with the user's saved choices — all within the wait_for_update window so Google tags never see a missing consent state. For teams using Google Tag Manager, the SDK also pushes consent state into the dataLayer so you can build consent-aware triggers and variables in GTM. The result is that your Consent Mode v2 implementation is always correct, always up to date, and always aligned with the actual user choices managed by your consent banner — without a single line of gtag boilerplate to maintain.

<!-- Nuvo Consent SDK auto-propagates consent to Google Consent Mode v2 -->
<script>
  window.NuvoConsent = window.NuvoConsent || { consent: {} };
  // When the user accepts analytics and marketing:
  // SDK automatically calls gtag('consent', 'update', {
  //   ad_storage: 'granted',
  //   analytics_storage: 'granted',
  //   ad_user_data: 'granted',
  //   ad_personalization: 'granted'
  // });
</script>

Verifying Consent Mode v2 in Google Tag Manager and Tag Assistant

Once you have deployed Consent Mode v2 — whether through Nuvo Consent's automatic integration or a manual implementation — you need to verify that your consent signals are reaching Google correctly. The primary tool for this is Google Tag Manager's Preview mode, which now includes a dedicated Consent tab. Open GTM Preview for your container, navigate to your site, and click the Consent tab in the debug pane. You should see the initial default state with all parameters set to denied, followed by an update event reflecting the user's actual consent choices. Verify that each of the four parameters — ad_storage, analytics_storage, ad_user_data, ad_personalization — appears in both the default and update events with correct values. You can also inspect the dataLayer directly in the browser console: run dataLayer.filter(e => e[0] === 'consent') to see every consent event that fired on the page. For a more comprehensive audit, use Google's Tag Assistant (tagassistant.google.com), which provides a dedicated Consent Mode validation report. Tag Assistant will flag missing consent signals, incorrect parameter values, and timing issues — such as tags firing before the default consent call, which is a common implementation mistake. A passing validation report from Tag Assistant is your signal that Consent Mode v2 is correctly configured and ready for production.

<!-- Check consent state in GTM Preview -->
<script>
// In GTM Preview mode, open the "Consent" tab to see the current state.
// Alternatively, inspect the dataLayer in the browser console:
console.log(window.dataLayer.filter(e => e[0] === 'consent'));
</script>

Shipping a production-ready Google Consent Mode v2 setup

Google Consent Mode v2 is not just a compliance checkbox — it is the foundation for maintaining accurate measurement, effective remarketing, and competitive ad campaign performance in European markets. The implementation boils down to a clear sequence: deny all four consent parameters by default before any Google tags load, collect the user's consent choices through a compliant consent banner, update the consent state as soon as those choices are known, and verify the end-to-end flow with GTM Preview and Tag Assistant. Nuvo Consent automates every step of this sequence. The SDK handles the default consent injection, the category-to-parameter mapping, the consent update on every user choice, and the cross-page-load consent resubmission — so your engineering team never has to maintain a single line of gtag consent boilerplate. If you are running Google Ads or GA4 in the UK, EU, or EEA and have not yet implemented Consent Mode v2, the time to act is now. Start with a free scan of your domain to inventory your Google tags, then follow the Nuvo Consent setup workflow to deploy a correctly wired Consent Mode v2 configuration in the same afternoon.