Google Consent Mode v2: Complete Implementation Guide

What Is Consent Mode v2?

Google Consent Mode is a framework that adjusts how Google tags behave based on the consent status of your visitors.

When a user declines cookies, consent mode tells Google tags to operate in a restricted state, no cookies are written, no identifiers are stored, but basic measurement signals (like cookieless pings) are still sent to Google so that machine learning models can fill in the gaps.

Version 2 added two new parameters in addition to the original consent signals: ad_user_data and ad_personalization. These give Google explicit signals about whether a user has consented to their data being used for advertising purposes and personalized ads specifically.

The four consent parameters in v2 are:

• analytics_storage, controls whether analytics cookies (like _ga) can be set
• ad_storage, controls whether advertising cookies can be set
• ad_user_data, controls whether user data can be sent to Google for advertising
• ad_personalization, controls whether personalized advertising is enabled

Why Consent Mode v2 Matters

EU Regulatory Compliance

The Digital Markets Act (DMA) designates Google as a "gatekeeper" platform, which means Google itself is required to obtain verifiable consent signals before processing user data for advertising.

Consent Mode v2 is how Google receives those signals from your site. Without it, Google loses the consent inputs it needs for ads personalization, remarketing, and related measurement for EEA traffic.

Conversion Modeling

When consent is denied, GA4 loses direct measurement capability for those users. Consent mode enables Google to use machine learning to model the missing conversions based on the behavior of consented users.

Without consent mode, denied users are simply invisible, no modeling, no recovery.

Audience Features

For EEA traffic, Google Ads features such as remarketing and personalized advertising depend on the consent signals from Consent Mode v2.

If those signals are missing, audience sizes shrink and ads optimisation becomes less complete for the affected users.

Implementation Steps

Step 1: Choose a Consent Management Platform (CMP)

You need a CMP that integrates with Google consent mode. Google maintains a list of certified CMP partners including Cookiebot, OneTrust, Usercentrics, and others.

Your CMP handles the banner UI, consent collection, and storage. It then communicates the consent state to Google tags through the consent mode API.

Step 2: Set Default Consent State

Before any Google tags fire, you must declare the default consent state. For users in regions where consent is required (EEA, UK), the default should be "denied" for all four parameters.

This code must execute before the gtag.js or GTM snippet:

gtag('consent', 'default', {
  'analytics_storage': 'denied',
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'wait_for_update': 500,
  'regions': ['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','IS','LI','NO','GB']
});

The wait_for_update parameter tells Google tags to wait up to 500ms for the CMP to load and provide the actual consent state. This prevents tags from firing before the consent banner has loaded.

Step 3: Update Consent on User Action

When a user interacts with your consent banner, your CMP should call the consent update command with the user's choices:

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

This triggers Google tags to transition from the restricted (cookieless) state to full measurement mode. Tags then fire again with the updated consent state and full page context.

Step 4: Configure GTM (If Applicable)

If you use Google Tag Manager, enable the consent overview in GTM and configure each tag with the appropriate consent requirements. GA4 configuration tags should require analytics_storage.

Google Ads tags should require ad_storage, ad_user_data, and ad_personalization. GTM has built in consent mode support that respects the consent state automatically when configured.

Step 5: Configure Region-Specific Behavior

Use the regions parameter to apply different defaults by geography. Users outside regulated regions can default to "granted" depending on your privacy policy, while EEA users default to "denied".

This prevents unnecessary consent prompts for users in regions where they are not legally required, preserving measurement coverage.

Testing Your Implementation

Testing consent mode is one of the most overlooked steps. Many teams implement consent mode and assume it works without verifying the actual tag behavior. Here is how to test properly:

• Use GA4 DebugView: Enable debug mode and observe the consent state parameter on each event. Events fired before consent should show the restricted state. Events after consent should show the full state.
• Check the Network tab: In Chrome DevTools, filter requests to google analytics.com or analytics.google.com. Before consent, you should see "gcs=G100" (denied) in the request payload. After consent, it should change to "gcs=G111" (granted).
• Inspect cookies: Before granting consent, the _ga and _gid cookies should not exist. After granting consent, they should appear. If cookies exist before consent, your implementation has a critical flaw.
• Test from an EEA IP: Use a VPN or proxy to simulate a European visitor. Verify that the consent banner appears and that the default state is "denied."
• Test consent persistence: Grant consent, close the browser, and return to the site. The consent state should persist, the banner should not reappear and tags should fire in the granted state immediately.

Common Mistakes

• Consent default fires after Google tags: If the gtag consent default command executes after the GA4 config tag, the first pageview is sent without any consent restrictions. This is a compliance violation and the most common implementation error.
• Missing ad_user_data and ad_personalization: Teams that implemented consent mode v1 and never updated to v2 are missing these parameters. Google treats this as an incomplete consent setup for ads features, which limits remarketing and personalized advertising for EEA users.
• Consent banner not loading: If your CMP script fails to load (due to ad blockers, network issues, or script errors), the default "denied" state persists for the entire session. The user never sees a banner, so they never have the opportunity to consent. This silently destroys your measurement coverage.
• Not using wait_for_update: Without this parameter, Google tags fire immediately in the default (denied) state and do not wait for the CMP to load. This means the first pageview is always sent in restricted mode, even if the user has previously consented and the CMP loads a few hundred milliseconds later.
• Applying consent mode globally instead of by region: Setting the default to "denied" for all users worldwide means you lose direct measurement for users in regions where consent is not required. Use the regions parameter to apply "denied" only where legally necessary.
• Not testing after CMP updates: CMP vendors push updates that can change behavior. A CMP update that changes the consent banner timing or default behavior can break your consent mode implementation silently.