Consent Mode v2 Parameter Architecture

Consent Mode is Google’s framework for adjusting how tags behave based on user consent choices. Version 2, released in November 2023 and enforced for EEA/UK traffic from March 2024 onward, expanded the original two-parameter system to four parameters. The distinction between the original and new parameters is architectural, not just incremental, and understanding it matters for both implementation and debugging.

The Original Two Parameters (v1)

Consent Mode v1, launched in 2020, introduced two parameters:

• ad_storage controls whether advertising cookies (such as _gcl_* cookies from Google Ads) can be set in the user’s browser.
• analytics_storage controls whether analytics cookies (such as _ga and _gid from GA4) can be set.

These are upstream qualifiers. They determine what data leaves the browser. When analytics_storage is denied, GA4 tags won’t set cookies and will either send cookieless pings (in Advanced mode) or not fire at all (in Basic mode). When ad_storage is denied, Google Ads conversion tags won’t set click identifiers.

The key mental model: v1 parameters gate the browser-side collection mechanism. They control whether identifiers exist in the first place.

The Two New Parameters (v2)

Version 2 added:

• ad_user_data tells Google’s services whether personal data can be used for advertising purposes. When denied, user_id values, Enhanced Conversions hashed data (email, phone, address), and other personally identifiable signals are suppressed server-side.
• ad_personalization tells Google’s services whether remarketing is permitted. When denied, remarketing audiences stop building entirely — no new users enter audience lists, and existing audience membership is not refreshed.

These are downstream instructions. They don’t change what data the browser sends. Instead, they tell Google’s servers how to handle the data after it arrives. This is a fundamentally different control surface.

Upstream vs Downstream: Why It Matters

The separation creates combinations that wouldn’t make sense in a two-parameter world:

The second row is the scenario that trips up most implementations. Everything appears to work — conversion tags fire, data flows to Google Ads — but Enhanced Conversions silently fails because ad_user_data blocks the hashed personal data from being processed. You only discover this weeks later when Enhanced Conversions diagnostics shows no matched data.

Similarly, ad_personalization being denied while other signals are granted means your remarketing audiences quietly stop growing. Conversion measurement continues normally, but your retargeting campaigns gradually lose reach as audience lists expire without new entries.

The Legal Driver

The expansion from two to four parameters wasn’t a product decision. It was driven by the EU Digital Markets Act (DMA), which designates Google as a “gatekeeper” platform with direct regulatory responsibility for obtaining user consent before processing personal data for advertising.

The DMA requires gatekeepers to demonstrate that consent was properly obtained and that data processing respects the specific purposes the user consented to. Two binary parameters — cookies yes/no, analytics yes/no — couldn’t express the granularity the regulation demands. The new parameters map to specific data processing purposes:

• ad_user_data maps to the purpose of processing personal data for advertising
• ad_personalization maps to the purpose of building personalized audience profiles

This legal obligation flows down to every advertiser’s tag implementation. Google doesn’t just recommend Consent Mode v2 — it requires it. Accounts without a compliant implementation for EEA/UK traffic face automated enforcement: conversion tracking, remarketing, and demographic reporting get disabled.

The Consent Update Flow

In practice, the four parameters are set together. A default command fires before any tags load, setting all four to denied for regions where consent is required:

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

When the user grants consent through the CMP, an update command sets the parameters based on the specific purposes the user agreed to:

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

A granular CMP might grant analytics_storage and ad_storage while denying ad_personalization — allowing measurement but blocking remarketing. The four parameters give the CMP enough expressiveness to map to TCF v2.2 purposes and to satisfy the DMA’s requirement for purpose-specific consent.

What the Parameters Don’t Control

Consent Mode parameters don’t prevent data from reaching Google’s servers in Advanced mode. Cookieless pings still fire when analytics_storage is denied. The parameters control what Google does with the data, not whether data is transmitted at all. For that level of control, you need Basic mode, which blocks tag execution entirely when consent is denied.

The parameters also don’t extend to non-Google vendors. Meta, TikTok, LinkedIn, and other third-party tags have no awareness of Consent Mode signals. Server-side implementations must handle consent enforcement for these vendors separately.