Google Consent Mode v2: What Is (and Is Not) Transmitted When a User Declines

Google Consent Mode v2: What Is (and Is Not) Transmitted When a User Declines

Most explanations of Consent Mode focus on what you gain by getting consent. This one focuses on what actually happens when a user says no. What data leaves the browser, what Google does with it, and what you are genuinely protected from. No vendor spin. Just the facts.

Google Consent Mode v2 does not prevent all data transmission when a user declines. It prevents persistent identification. Cookieless pings still reach Google’s servers, but they carry no user identifier and cannot be linked to an individual across sessions.

Background: What Consent Mode Actually Does

Google Consent Mode is not a consent banner. It is the mechanism that sits between your Consent Management Platform (CMP) and Google’s measurement tags, translating a user’s yes/no choice into a set of instructions that tell Google tags how to behave.

Consent Mode v2 was released in November 2023, driven by the EU Digital Markets Act and tightening enforcement from European data protection authorities. It added two new parameters on top of the original two, giving advertisers more granular control over what can be shared for advertising purposes.

One thing that makes Google’s implementation unique: it allows tags to fire in a reduced, cookieless state even when consent is declined. LinkedIn’s Insight Tag and Meta’s Pixel have no equivalent. For both of those platforms, your CMP must fully block the tag until the user opts in. Google takes a different approach, and that difference is the entire source of legal and technical complexity.

The Four Consent Parameters

Consent Mode v2 operates across four independent parameters. Each controls a distinct category of data processing and can be set separately from the others.

analytics_storage
Controls reading and writing of analytics cookies. When denied, GA4 sends cookieless pings instead of full event data.
Original v1
ad_storage
Controls reading and writing of advertising cookies. When denied, no ad cookies are set or read.
Original v1
ad_user_data
Controls whether user data (such as hashed email for Customer Match) may be sent to Google for advertising purposes.
New in v2
ad_personalization
Controls whether data may be used to personalise ads, including remarketing. Denial disables personalised advertising regardless of other parameters.
New in v2
Key Point

All four parameters can be set independently. A site can grant analytics_storage while denying ad_personalization. Each combination produces a different data transmission profile. Your CMP must be capable of sending all four signals, not just the original two.

Advanced vs Basic: Two Very Different Data Flows

Before getting into what gets transmitted, you need to know which mode you are running. The two implementation modes produce materially different data flows.

Basic Consent Mode

  • Tags blocked until user interacts with banner
  • Consent declined: zero data sent to Google
  • No cookieless pings
  • Uses only a general (non-site-specific) conversion model
  • Lowest data risk for non-consenting users
  • Loses all measurement for declined users

Advanced Consent Mode

  • Tags load on every page visit, including before banner interaction
  • Cookieless pings sent even when consent is denied
  • Enables site-specific conversion modelling
  • Fills measurement gaps statistically
  • Tags update behaviour in real time when consent is given or changed
  • Higher legal complexity, requires careful privacy notice review

The rest of this post focuses on Advanced Consent Mode, since that is where the complexity lives.

What Is Actually Sent When a User Declines

When consent is denied in Advanced mode, Google does not set or read cookies. Instead, tags send what Google calls cookieless pings: minimal signals that reach Google’s servers but contain no persistent user identifier.

A cookieless ping contains:

  • A consent state signal confirming denial, which consent platform is in use, and a random number generated per page load (not a persistent identifier)
  • GA4 event data such as page_view, sent without any cookie or persistent identifier attached
  • An indication that a conversion-type event occurred, used only to inform Google’s statistical models
  • Passive browser information: user agent string, referrer URL, and timestamp. These are sent automatically by the browser as part of standard HTTP communication, not injected by the tag
  • An indication of whether a GCLID or DCLID (ad click identifier) was present in the URL, used only for approximate measurement

When consent is declined under Advanced Consent Mode, no cookies are written, no persistent user identifier is generated, no remarketing audiences are built, and no personalised advertising is enabled. Cookieless pings do transmit to Google, but they cannot be linked to an individual user across sessions.

On IP Addresses

IP addresses are used solely to derive a country-level location for denied-consent traffic. Google states that Ads and Floodlight systems immediately delete IP addresses and never log or store them. Google Analytics does not store IP addresses in any consent state.

Denied vs Granted: Full Side-by-Side Comparison

Data / Signal Consent Denied Consent Granted
Analytics cookies (_ga, _gid) Not set or read Set and read normally
Advertising cookies (_gcl_*, GCLID) Not set or read Set and read normally
Third-party Google cookies (doubleclick.net) Requests re-routed to avoid sending existing 3rd-party cookies Accessible
User ID / persistent identifier None generated Persistent ID for cross-session tracking
IP address Country derivation only; immediately deleted, never logged by Ads/Floodlight Collected as part of normal communications (GA does not store IP)
Full page URL (including GCLID/DCLID) Collected; click IDs used only for approximate measurement, NOT for ad targeting Used fully for attribution and measurement
User agent / browser info Sent via standard HTTP headers (passive browser behaviour, not injected by tag) Sent via standard HTTP headers
GA4 events (page_view, etc.) Sent as cookieless pings. No user identifier. Cannot link to an individual. Sent with cookies, user identifiers, and full measurement data
Advertising ID / IDFA (mobile) Not collected Collected
Google Signals (cross-device, demographic) Not accumulated Accumulated where Google Signals is enabled
Remarketing / audience building Not possible Possible via ad cookies and audience lists
Conversion attribution Modelled (estimated statistically, not individually observed) Directly observed and attributed

Statistical Modelling: What It Is, What It Is Not

Even when consent is declined, Google uses the cookieless pings from denied users as inputs to statistical models. These models estimate behaviours that cannot be directly observed, such as conversion rates among non-consenting users.

Consent Mode modelling does not reconstruct or identify individual denied users. It uses aggregated, cookieless ping data to predict population-level trends. Modelled data is applied to aggregate reporting metrics, not to individual user profiles.

How site-specific modelling activates
Consent Mode deployed across all pages
→
1,000+ events/day with analytics_storage denied for 7 days
→
1,000+ daily users with analytics_storage granted for 7 of last 28 days
→
Site-specific modelling activates

If these thresholds are not met, no modelling occurs and denied-user data is simply absent from reports.

Optional Enhancement: Ads Data Redaction

Operators can enable ads_data_redaction alongside ad_storage denial. When active, this setting fully redacts ad-click identifiers (GCLID, DCLID) even from cookieless pings, ensuring no ad attribution signal of any kind is transmitted for non-consenting users.

This does not affect analytics_storage behaviour, but it is the right choice for any organisation that wants full data minimisation for advertising data in denied-consent scenarios, particularly for EEA traffic.

Processing Activity by Consent State

Processing Activity analytics_storage Denied analytics_storage Granted ad_storage Denied ad_storage Granted
Analytics cookies set / read No Yes N/A N/A
Persistent session tracking No Yes No Yes
GA4 events transmitted Yes (cookieless) Yes (with cookies) Yes (cookieless) Yes (with cookies)
Ad cookies set / read N/A N/A No Yes
Remarketing audiences built No No No Yes
Conversion attributed (direct) No No No Yes
Conversion modelled (statistical) Yes* No Yes* No
Google Signals active No No No Yes

* Modelling applies only when property-level data volume thresholds are met.

Key Findings

  • Events still fire under denial. In Advanced mode, GA4 events including page_view do transmit to Google even when consent is denied. However, these are cookieless pings with no persistent identifier. They cannot be attributed to an individual user by Google.
  • No cookie is set without consent. This is an absolute restriction. The absence of cookie writing means there is no persistent tracking across sessions for denied users.
  • IP addresses are processed but not retained. Used to derive country for denied-consent traffic, then immediately discarded by Ads and Floodlight systems and never logged.
  • Advertising is fully blocked without consent. Without ad_storage granted, no advertising cookie is set and no remarketing audience can be built. Without ad_personalization granted, personalised advertising cannot occur regardless of other parameter states.
  • v2 adds explicit controls that v1 was missing. Prior consent mode implementations may have transmitted user data for advertising purposes without separate explicit consent for each use. Confirm your CMP captures signals for all four parameters independently.

A Consent Management Platform that only signals analytics_storage and ad_storage is not Consent Mode v2 compliant. The two new parameters, ad_user_data and ad_personalization, must be captured and transmitted independently for each user interaction.

Recommendations

  1. Audit your CMP for all four parameters Confirm the CMP is capturing and transmitting all four v2 parameters. A CMP that only signals analytics_storage and ad_storage is not v2 compliant.
  2. Review your default consent states by region Where a region requires opt-in consent (such as the EEA), all four parameters should default to denied until affirmative consent is given. Do not assume your CMP vendor has configured this correctly.
  3. Consider enabling ads_data_redaction for EEA traffic This ensures GCLID and DCLID values are not transmitted in any form for non-consenting users, providing an additional layer of data minimisation beyond the standard denied state.
  4. Document your CMP configuration in your ROPA The consent state defaults, regions, and update mechanisms should be explicitly recorded as part of your records of processing activities. This is not optional under GDPR.
  5. Review your privacy notice against Advanced Mode behaviour Cookieless pings are still data transmissions to Google. While they do not identify individuals, the legal team should confirm that the transmission of anonymised behavioural signals under Advanced mode is consistent with the privacy notice and the lawful basis relied upon for analytics.
Sources
This analysis is based on publicly available Google documentation. It does not constitute legal advice.