Skip to main content

Google Consent Mode v2: Complete Implementation Guide

Google Consent Mode is a framework that adjusts how Google tags behave based on the consent status of your website visitors. When a user declines cookies through your consent management platform (CMP), Consent Mode tells Google Analytics, Google Ads, and other Google services to operate without storing cookies — while still collecting limited, anonymized data through cookieless pings.

Since March 2024, Google has required Consent Mode v2 for any website that collects data from users in the European Economic Area (EEA). Without it, Google Ads cannot build remarketing audiences, conversion modeling is disabled, and Google Analytics 4 loses access to behavioral modeling that fills data gaps caused by consent denials. For advertisers, this directly impacts campaign optimization, bidding strategies, and return on ad spend.

This guide covers the full technical implementation of Consent Mode v2 — from the consent parameters and default states to CMP integration, Google Tag Manager setup, and verification.

Why Consent Mode Exists

EU privacy regulations — primarily the GDPR and the ePrivacy Directive — require websites to obtain explicit consent before storing cookies or processing personal data for advertising and analytics. Simply blocking all Google tags when consent is denied solves the legal requirement but creates a significant data gap. On websites with high denial rates (common in the EU, often 30–60%), this means losing visibility into a large portion of your traffic.

Consent Mode bridges this gap. It provides a standardized API that sits between your consent management platform and Google’s tags. When consent is denied, tags switch to a restricted mode: no cookies are stored, no personal identifiers are collected, but basic measurement signals (like page loads and ad clicks) are still sent to Google in a privacy-safe way. Google then uses machine learning to model the behavior of users who denied consent based on patterns observed from users who accepted.

The result is a system that respects user privacy choices while preserving measurement accuracy. Google reports that behavioral modeling can recover up to 70% of ad-click-to-conversion journeys that would otherwise be lost.

Consent Mode v1 vs v2: What Changed

The original Consent Mode (v1) introduced two core consent parameters: ad_storage (for advertising cookies) and analytics_storage (for analytics cookies). This binary approach — cookies on or cookies off — was sufficient when cookie consent was the primary concern.

Consent Mode v2, announced in late 2023 and required from March 2024, adds two critical new parameters:

  • ad_user_data — Controls whether user data can be sent to Google for advertising purposes. This goes beyond cookies to cover any personal data used for ad targeting, including enhanced conversions data like email addresses.
  • ad_personalization — Controls whether personalized advertising (remarketing, interest-based ads) is allowed. When denied, Google will not use the user’s data to build audience segments or show personalized ads.

These additions reflect the evolving regulatory landscape. The EU’s Digital Markets Act (DMA) and updated GDPR enforcement guidelines now explicitly require separate consent for data sharing with third parties (like Google) and for personalized advertising. A user might accept analytics cookies but refuse to have their data shared with Google for ad targeting — a distinction v1 could not express.

The practical impact is significant. Without ad_user_data and ad_personalization set, Google treats the consent state as unknown and restricts data processing accordingly. For Google Ads customers in the EEA, this means:

  • No new remarketing lists can be built
  • Customer Match uploads will not be processed
  • Enhanced conversions data will not be used
  • Conversion modeling accuracy decreases

The Seven Consent Parameters

Consent Mode v2 defines seven parameters that control how Google tags interact with the browser. Each parameter accepts either 'granted' or 'denied' as its value.

ad_storage — Controls storage (such as cookies) related to advertising. When denied, no advertising cookies are written or read. Google Ads and Floodlight tags will still fire, but they send cookieless pings instead of standard requests. These pings include limited information like the timestamp, user agent, referrer, and a randomly generated identifier for that specific page load.

ad_user_data — Controls whether user data is sent to Google for advertising purposes. This parameter is new in v2 and is required for EEA users. It governs the transmission of personal data (email, phone number, address) that might be used for features like enhanced conversions or Customer Match. When denied, Google will not associate any personal data with the user’s advertising profile.

ad_personalization — Controls personalized advertising features. When denied, remarketing audiences will not include this user, dynamic remarketing will not function for them, and they will not see ads personalized based on their activity on your site. This parameter is also new in v2 and required for EEA compliance.

analytics_storage — Controls storage used for analytics purposes (such as Google Analytics cookies like _ga and _gid). When denied, Google Analytics 4 will still receive events via cookieless pings, but cannot identify returning users across sessions. The pings include basic information needed for behavioral modeling.

functionality_storage — Controls storage that supports the functionality of the website, such as language preferences, user interface customization, or other features that improve the user experience. This does not directly affect Google tags but is part of the consent framework for completeness.

personalization_storage — Controls storage related to personalization, such as video recommendations, content suggestions, or other personalized experiences beyond advertising. Like functionality_storage, this is primarily informational and does not directly alter Google tag behavior.

security_storage — Controls storage related to security, such as authentication functionality, fraud prevention, and other mechanisms that protect users. This is typically always granted since security cookies are considered strictly necessary under most privacy frameworks and do not require consent.

Default State vs Updated State

Consent Mode operates in two phases: setting the default state and then updating it based on user interaction with your consent banner.

The default state must be set before any Google tags fire. It defines the assumed consent status before the user has made a choice. For EEA visitors, best practice is to default all parameters to 'denied':

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied',
  'functionality_storage': 'denied',
  'personalization_storage': 'denied',
  'security_storage': 'granted',
  'wait_for_update': 500
});

The updated state is set after the user interacts with the consent banner. Your CMP calls gtag('consent', 'update', {...}) with the parameters that reflect the user’s choices. Only the parameters being changed need to be included in the update call:

// User accepted analytics but denied advertising
gtag('consent', 'update', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'granted'
});

When the consent state is updated from 'denied' to 'granted', Google tags that were waiting for consent will retroactively fire. For example, if analytics_storage is updated to 'granted', Google Analytics will write its cookies and re-send the pageview event with full measurement data. This is known as the "consent-granted" trigger in GTM.

The wait_for_update Parameter

The wait_for_update parameter tells Google tags how long (in milliseconds) to wait for a consent update before proceeding with the default state. This is critical because of timing: the consent default must be set before tags fire, but the CMP may need a moment to load, check for stored preferences, and update the consent state.

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

A value of 500 (500 milliseconds) is Google’s recommended default. If your CMP is slow to load, you may increase this to 1000 or even 2000, but higher values delay tag firing and can affect page performance and data collection. If the CMP updates consent within the wait period, tags fire immediately with the updated state. If the wait period expires without an update, tags fire with the default (denied) state.

For returning visitors whose consent preferences are stored in a cookie, most CMPs can read and apply the stored preference in under 100ms, well within the wait period.

How Consent Mode Works with Google Tag Manager

Google Tag Manager has native support for Consent Mode through its built-in consent configuration. Instead of using gtag() calls directly, you configure consent settings within GTM’s consent overview.

Each tag in GTM has consent settings that define which consent types it requires. For example, a Google Analytics 4 tag requires analytics_storage to be granted, while a Google Ads conversion tag requires both ad_storage and ad_user_data. Google’s own tags come with these requirements preconfigured.

The workflow in GTM is:

  • A consent initialization trigger fires first (before any other triggers), setting the default consent state
  • Tags that require consent check the current consent state before firing
  • If consent is denied, tags either block entirely or fire in restricted (cookieless) mode, depending on the tag’s configuration
  • When the CMP updates consent via a dataLayer push, tags that were blocked will fire if their required consent types are now granted

In GTM, the consent default is typically set via a tag using the "Consent Initialization — All Pages" trigger:

// In a Custom HTML tag with "Consent Initialization" trigger
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}

  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500
  });
</script>

Many CMP vendors provide prebuilt GTM templates in the Community Template Gallery that handle both the default and update calls automatically.

Behavioral Modeling: Filling the Data Gaps

When users deny consent, Google receives limited data through cookieless pings. Behavioral modeling uses machine learning to estimate what the full data would look like if those users had consented. This is not fabrication — it is statistical inference based on observed patterns from consenting users.

For Google Analytics 4, behavioral modeling estimates:

  • Session counts and user counts from non-consenting visitors
  • Conversion rates and event counts
  • Geographic and device-level traffic patterns
  • Bounce rates, session duration, and pages per session

For Google Ads, conversion modeling estimates:

  • Conversions that cannot be directly observed due to consent denial
  • Attribution data for ad clicks that led to modeled conversions
  • Return on ad spend calculations including modeled data

Behavioral modeling requires a minimum data threshold to activate. Google requires at least 1,000 events per day with analytics_storage denied and at least 1,000 daily events with analytics_storage granted for at least 7 days. Sites below this threshold will not see modeled data in their reports.

Modeled data appears in GA4 reports automatically and is indicated by a small icon in the report header. You cannot separate modeled from observed data in standard reports, though the data is excluded from explorations by default.

Integration with Consent Management Platforms

A CMP is the user-facing component — the cookie banner, preference center, and consent storage mechanism. Consent Mode is the technical bridge between the CMP’s consent decisions and Google’s tags. The integration pattern follows a consistent flow regardless of which CMP you use:

  • Page load: The CMP script loads and checks for an existing consent cookie. If found, it immediately calls gtag('consent', 'update', {...}) with the stored preferences. If no cookie exists, the default (denied) state remains active and the consent banner appears.
  • User interaction: When the user makes a choice (accept all, reject all, or granular selection), the CMP stores the preference in a cookie and calls gtag('consent', 'update', {...}) with the selected values.
  • Subsequent visits: On return visits, the CMP reads its consent cookie and immediately updates the consent state before the wait_for_update timer expires, so tags fire with the correct consent from the start.

The CMP must map its own consent categories to Google’s consent parameters. For example, a CMP might have categories like "Marketing," "Statistics," and "Preferences." The mapping would look like:

// Example CMP callback when user makes a choice
function onConsentUpdate(categories) {
  gtag('consent', 'update', {
    'ad_storage': categories.marketing ? 'granted' : 'denied',
    'ad_user_data': categories.marketing ? 'granted' : 'denied',
    'ad_personalization': categories.marketing ? 'granted' : 'denied',
    'analytics_storage': categories.statistics ? 'granted' : 'denied',
    'functionality_storage': categories.preferences ? 'granted' : 'denied',
    'personalization_storage': categories.preferences ? 'granted' : 'denied',
    'security_storage': 'granted'
  });
}

Google CMP Partner Program

Google maintains a CMP Partner Program that certifies consent management platforms meeting specific technical and compliance requirements. As of March 2024, websites serving ads through Google Ad Manager, AdSense, or AdMob in the EEA must use a CMP certified under the IAB Transparency & Consent Framework (TCF) v2.2 or a Google-certified CMP.

To qualify for the partner program, a CMP must:

  • Implement the IAB TCF v2.2 specification
  • Support all seven Consent Mode v2 parameters
  • Integrate the Google-approved consent update API
  • Pass Google’s technical certification process
  • Provide compliant default consent banner templates

Popular certified CMPs include Cookiebot, OneTrust, Usercentrics, Didomi, and CookieYes. Using a certified CMP simplifies implementation because the Consent Mode integration is built in — you typically just enable a toggle in the CMP’s dashboard rather than writing custom code.

Implementation: Basic gtag.js Setup

For sites using gtag.js directly (without GTM), the consent default must be set before the Google tag snippet. The complete implementation looks like this:

<!-- 1. Set consent defaults BEFORE the Google tag -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}

  // Set defaults for all users (deny everything except security)
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'functionality_storage': 'denied',
    'personalization_storage': 'denied',
    'security_storage': 'granted',
    'wait_for_update': 500
  });

  // Optional: grant everything for non-EEA users
  gtag('consent', 'default', {
    'ad_storage': 'granted',
    'ad_user_data': 'granted',
    'ad_personalization': 'granted',
    'analytics_storage': 'granted',
    'region': ['US', 'CA', 'AU', 'GB']
  });
</script>

<!-- 2. Load the Google tag -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
  gtag('js', new Date());
  gtag('config', 'G-XXXXXXX');
</script>

<!-- 3. Load your CMP (it will call gtag('consent', 'update', ...) ) -->
<script src="https://your-cmp.example.com/script.js"></script>

Note the use of the region parameter in the second default call. This allows you to set different defaults for different regions. The most restrictive applicable default applies, so EEA users get denied defaults while users from listed countries get granted defaults.

Implementation: Google Tag Manager Setup

In GTM, the implementation involves three components: a consent initialization tag, CMP integration, and properly configured consent settings on your tags.

Step 1: Create a consent initialization tag. In GTM, go to Tags and create a new Custom HTML tag. Set the trigger to "Consent Initialization — All Pages" (this fires before all other triggers):

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}

  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500
  });
</script>

Step 2: Add your CMP tag. Most certified CMPs offer a GTM Community Template. Search the template gallery for your CMP, add it, and configure it. The template handles both loading the consent banner and calling the consent update API.

Step 3: Verify consent settings on your tags. In GTM, go to Admin → Container Settings → Additional Settings and enable "Enable consent overview." This shows which consent types each tag requires and helps identify tags that might fire without proper consent.

Implementation: CMP Integration Pattern

If you are building a custom consent solution or integrating a CMP that does not have a prebuilt Consent Mode integration, here is the pattern to follow:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}

  // Check for existing consent cookie
  var savedConsent = getConsentCookie(); // Your cookie-reading function

  if (savedConsent) {
    // Returning visitor: update consent immediately
    gtag('consent', 'default', {
      'ad_storage': savedConsent.marketing ? 'granted' : 'denied',
      'ad_user_data': savedConsent.marketing ? 'granted' : 'denied',
      'ad_personalization': savedConsent.marketing ? 'granted' : 'denied',
      'analytics_storage': savedConsent.analytics ? 'granted' : 'denied',
      'functionality_storage': savedConsent.functional ? 'granted' : 'denied',
      'personalization_storage': savedConsent.functional ? 'granted' : 'denied',
      'security_storage': 'granted'
    });
  } else {
    // New visitor: set denied defaults
    gtag('consent', 'default', {
      'ad_storage': 'denied',
      'ad_user_data': 'denied',
      'ad_personalization': 'denied',
      'analytics_storage': 'denied',
      'functionality_storage': 'denied',
      'personalization_storage': 'denied',
      'security_storage': 'granted',
      'wait_for_update': 500
    });
  }

  // Consent banner callback
  function handleConsentChoice(preferences) {
    // Save to cookie
    setConsentCookie(preferences);

    // Update Google Consent Mode
    gtag('consent', 'update', {
      'ad_storage': preferences.marketing ? 'granted' : 'denied',
      'ad_user_data': preferences.marketing ? 'granted' : 'denied',
      'ad_personalization': preferences.marketing ? 'granted' : 'denied',
      'analytics_storage': preferences.analytics ? 'granted' : 'denied',
      'functionality_storage': preferences.functional ? 'granted' : 'denied',
      'personalization_storage': preferences.functional ? 'granted' : 'denied',
      'security_storage': 'granted'
    });
  }
</script>

Testing and Verification

Verifying that Consent Mode is correctly implemented requires checking both the default state and the update behavior. Google provides several tools for this.

Google Tag Assistant: The Tag Assistant browser extension (now integrated into the Google tag) shows consent state in real time. Navigate to your site, open Tag Assistant, and check the "Consent" tab. You should see all parameters listed with their current state (granted or denied). Make a consent choice in your CMP and verify that the states update accordingly.

Browser console commands: You can inspect the consent state directly in the browser’s developer console:

// View the current consent state in the dataLayer
dataLayer.filter(function(item) {
  return item[0] === 'consent';
});

// Or check individual consent values via Google's API
google_tag_data?.ics?.entries

Network tab inspection: When consent is denied, Google tags send requests to different endpoints and with different parameters than when consent is granted. Look for these indicators:

  • GA4 requests go to /g/collect with a gcs parameter indicating consent state (e.g., gcs=G100 means analytics denied, ads denied)
  • The gcd parameter encodes the full consent state across all parameters
  • No _ga cookie should be present when analytics_storage is denied
  • No _gcl_* cookies should be present when ad_storage is denied

GTM Preview Mode: In GTM’s preview mode, the consent status is shown for each tag. Tags that are blocked due to insufficient consent are clearly marked. You can simulate consent changes by using the console to call gtag('consent', 'update', {...}) and watch tags fire in real time.

Common Implementation Mistakes

These are the errors most frequently seen in Consent Mode implementations, often causing either compliance failures or unnecessary data loss.

Setting defaults after the Google tag loads. The consent default must be set before the Google tag script. If the tag loads first, it fires with an implicit "granted" state, setting cookies before consent is obtained. This is both a compliance violation and a data quality issue.

Missing ad_user_data and ad_personalization. Many implementations were built for v1 and only set ad_storage and analytics_storage. Without the v2 parameters, Google treats EEA user data as having unknown consent, disabling remarketing and conversion modeling features.

Not using wait_for_update. Without this parameter, tags fire immediately with the default (denied) state before the CMP has a chance to check for stored consent preferences. Returning visitors who previously accepted cookies will have their first pageview recorded without consent, then a second with consent — inflating session counts.

Setting defaults to ‘granted’ for EEA users. Some implementations default to 'granted' and rely on the CMP to deny consent. This means tags fire with full tracking before the user makes a choice — a clear GDPR violation. Always default to 'denied' for regions where consent is required.

CMP not calling gtag consent update. The CMP stores the user’s choice in its own cookie but never calls gtag('consent', 'update', {...}). Result: Google tags permanently operate in denied mode even for users who accepted all cookies. This is surprisingly common with custom or non-certified CMPs.

Blocking Google tags entirely when consent is denied. Some setups block the Google tag script from loading when consent is denied. This prevents cookieless pings from being sent, which means behavioral modeling cannot function. Consent Mode is designed to let tags load but operate in a restricted mode — not to be blocked entirely.

Inconsistent consent categories. Mapping CMP categories incorrectly to Google parameters. For example, mapping analytics consent to ad_storage or marketing consent to analytics_storage. Always verify the mapping between your CMP’s categories and Google’s consent parameters.

Not testing consent revocation. Users can change their consent preferences after the initial choice. Verify that re-opening the consent banner and changing choices correctly triggers a new gtag('consent', 'update', {...}) call and that cookies are removed when consent is revoked.

How Passiro Handles Consent Mode

Passiro’s accessibility scanner automatically detects and interacts with consent banners during page analysis. When scanning a website, Passiro identifies the consent management platform, dismisses the consent dialog to access the full page content, and evaluates the accessibility of the consent banner itself — an often-overlooked aspect of compliance.

Cookie consent banners that fail accessibility requirements (missing focus management, insufficient color contrast, keyboard inaccessibility, or missing ARIA labels) create a paradox: users with disabilities cannot exercise their privacy rights because the consent mechanism itself is inaccessible. Passiro flags these issues alongside other accessibility violations.

Try a free scan at passiro.com to see how your consent implementation performs from both an accessibility and usability perspective.

IAB TCF Guide CMS Guides

Este site-ul tău accesibil?

Scanează-ți site-ul gratuit și obține scorul WCAG în câteva minute.

Scanează-ți site-ul gratuit