Consent Mode v2 Deep-Dive: How Google Models Conversions from Cookieless Pings

Since March 2024, Consent Mode v2 is no longer a recommendation but a prerequisite. Google requires the implementation for all advertisers in the EEA who use Google Ads remarketing or conversion tracking. Without Consent Mode v2, you lose access to Modeled Conversions, remarketing audiences, and Enhanced Conversions.

This article explains not just what Consent Mode v2 is (that is in Google's documentation), but how it works technically, which data flows at which consent state, and which levers you have to maximize data quality.

The four signals in detail

Consent Mode v2 works with four signals. Each signal controls a specific dimension of data processing.

analytics_storage

Function: Controls whether GA4 may set cookies and collect analytics data.

When granted: GA4 sets _ga (Client ID, 400 days), _ga_{STREAM} (Session ID, 30 minutes), and additional cookies. Full data collection: pageviews, events, ecommerce, user properties.

When denied: GA4 sets no cookies. Instead, GA4 sends cookieless pings: HTTP requests to google-analytics.com without Client ID, without Session ID, without user identifier. The ping contains: pageview URL, referrer, user agent, screen resolution, language setting, consent state. Google uses these pings for Behavioral Modeling (more on this later).

Special case: analytics_storage is the only signal for which some businesses argue for special treatment. The argument: if data flows through first-party SST and personal data is filtered, analytics_storage: granted could fall under legitimate interest. The German Data Protection Conference (DSK) views this critically. Our GDPR tracking guide covers the legal risk assessment in detail.

ad_storage

Function: Controls whether Google Ads and Floodlight may set cookies.

When granted: Google Ads sets conversion cookies (_gcl_aw, _gcl_dc) that link click IDs with user sessions. Floodlight sets similar cookies for DV360 campaigns. These cookies enable direct attribution of conversions to ad clicks.

When denied: No cookies. Google Ads sends cookieless pings with the gcs parameter (Google Consent State), which encodes the consent status. Attribution of conversions to clicks happens through modeling instead of direct cookie matches.

Campaign impact: Without ad_storage: granted, direct click-to-conversion paths are missing. Smart Bidding has fewer data points for optimization. Google compensates through Behavioral Modeling, but modeling quality depends directly on your consent rate.

ad_user_data

Function: Controls whether user data may be sent to Google for advertising purposes.

When granted: Enhanced Conversions work: hashed email addresses and phone numbers are sent to Google to attribute conversions even without cookies. Customer Match audiences can be created.

When denied: No user data to Google. Enhanced Conversions are disabled. Customer Match is not possible. Conversion attribution is limited to cookie-based and modeled attribution.

Important: ad_user_data was introduced with Consent Mode v2. It did not exist in v1. If your setup only sends v1 signals (analytics_storage and ad_storage), ad_user_data and ad_personalization are missing. Google treats missing signals as denied.

ad_personalization

Function: Controls whether personalized advertising (remarketing) is allowed.

When granted: Remarketing audiences are populated. The user can appear in remarketing campaigns, similar audiences, and Customer Match audiences.

When denied: No remarketing. The user is not added to any audience. Existing audience memberships for this user are not updated.

Practical impact: Remarketing is the most profitable campaign type for many stores. Every percentage point of consent rate you gain directly enlarges your remarketing audiences.

The gcs parameter: Google's consent encoding

With every request to Google servers, the current consent state is sent as the gcs parameter. The value is an encoded string that compresses the four signals:

gcs=G111  → All granted
gcs=G100  → analytics_storage granted, rest denied
gcs=G110  → analytics + ad_storage granted, rest denied
gcs=G000  → All denied

The gcs parameter is relevant for server-side tracking: when your SST container forwards the request to Google, the gcs parameter must be passed through correctly. If it is missing, Google does not know which consent state applies and treats the request as "unknown", which leads to data loss.

Checking gcs in practice

Chrome DevTools > Network > Filter for google-analytics.com or googleads.g.doubleclick.net:

1. Before consent: gcs=G000 (all denied)
2. After consent (all accepted): gcs=G111
3. Only analytics accepted: gcs=G100

If the gcs value does not match the actual consent state, something in your consent implementation is wrong. Our consent debugging article describes the systematic audit process.

Behavioral Modeling: How Google turns pings into conversions

Behavioral Modeling is the mechanism Google uses to transform data from cookieless pings into usable metrics. Google describes the process deliberately vaguely. What is publicly known:

Input data

Google uses for modeling:

1. Cookieless pings from users who did not consent (contains URL, referrer, user agent, timestamp, consent state)
2. Complete data from users who did consent (contains everything: Client ID, session data, ecommerce events)
3. Aggregated patterns across all websites using Consent Mode (global conversion rates per industry, region, device type)

Modeling logic

Google observes the behavior of users with consent and extrapolates to users without consent. Simplified:

If 3% of consented users who arrive from a Google Ads ad and view the product page complete a purchase, Google models a similar rate for non-consented users with comparable behavior patterns (same ad, same page type, similar time period).

Conversion Recovery Rate

The Conversion Recovery Rate describes the share of conversions "recovered" through modeling. Google does not provide an exact formula, but practical experience yields these benchmarks:

Consent Rate	Conversion Recovery	Effective data coverage
80%+	60 to 70% of denied conversions	~94%
60 to 80%	50 to 65% of denied conversions	~82%
40 to 60%	35 to 50% of denied conversions	~70%
Below 40%	20 to 35% of denied conversions	~55%

The logic: the more users consent, the more "real" data Google has as a basis for modeling. With a consent rate of 80%, Google has rich data from which it can reliably extrapolate. At 30% consent rate, modeling becomes uncertain.

Minimum requirements

Behavioral Modeling in GA4 has minimum thresholds:

• Consent Mode must be correctly implemented. Defaults before the first tag, updates after consent changes.
• At least 1,000 events per day with analytics_storage: denied over at least 7 days.
• At least 1,000 users per day with analytics_storage: granted over at least 7 days.

If your store does not reach these thresholds, GA4 shows the original (unmodeled) data. For small stores with under 500 daily visitors, modeling does not activate.

Default vs. Update: Timing is everything

Consent Mode works with two commands:

consent default

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

This command must appear before the GTM script and before any other Google resource. It defines the initial state. If no consent update follows (e.g. because the user ignores the banner), these values remain active.

wait_for_update: Tells Google tags to wait up to 500 milliseconds for a consent update before firing. This matters when the banner loads quickly and the user clicks immediately. Without wait_for_update, tags fire immediately with the default values.

consent update

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

This command is sent after the consent decision. On accept: all relevant signals set to granted. On reject: all set to denied (or no update is needed at all, because the defaults are already denied).

Common timing errors

GTM before consent defaults. If the GTM script loads before the consent default command, tags fire without a consent signal. Google treats this as "unknown" and sets its own defaults (which vary by tag type).

wait_for_update missing. Without wait_for_update, tags fire immediately with the default state (denied). If the user consents 300ms later, the first pageview has already fired without consent. This creates cookieless pings even though the user consented.

Consent update after page reload. The user accepts on page A. On page B, the stored consent must be set immediately as a consent update before tags fire. If the banner reads the consent from the cookie only after page load and then sends the update, tags fire for 200 to 500ms with denied.

Implementation with Shopify

Shopify Customer Privacy API as consent source

Shopify's Customer Privacy API is the cleanest consent source for Shopify stores:

// 1. Load Privacy API
Shopify.loadFeatures([{ name: 'consent-tracking-api', version: 0.1 }], function() {

  // 2. Check region
  const region = Shopify.customerPrivacy.getRegion();

  // 3. Set consent defaults (before GTM)
  const isEU = EU_REGIONS.includes(region);
  const defaultState = isEU ? 'denied' : 'granted';

  gtag('consent', 'default', {
    'analytics_storage': defaultState,
    'ad_storage': defaultState,
    'ad_user_data': defaultState,
    'ad_personalization': defaultState,
    'wait_for_update': isEU ? 500 : 0
  });

  // 4. React to consent decision
  document.addEventListener('visitorConsentCollected', function() {
    const analytics = Shopify.customerPrivacy.analyticsProcessingAllowed();
    const marketing = Shopify.customerPrivacy.marketingAllowed();

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

Consent Mode in GTM Server Container

The GTM Server Container receives requests from the browser. The gcs parameter is automatically included in the GA4 request. The GA4 client in the server container reads this parameter and makes it available for server tags.

Three things that can go wrong:

1. Custom server tags ignore the consent state. If a tag in the server container has no consent check, it fires regardless of the gcs value. Solution: configure consent settings for every server tag.

2. gcs parameter is filtered. Some proxy configurations or WAFs filter unknown URL parameters. Verify that the gcs parameter arrives at the server container.

3. Timing mismatch. The browser sends an event with gcs=G000 (before consent). Two seconds later, it sends the same event with gcs=G111 (after consent). The server container sees two events. This is not a deduplication problem (different consent states), but it can lead to duplicate pageviews.

Optimizing consent rate

The quality of Behavioral Modeling rises and falls with the consent rate. Every percentage point of additional consent means better modeling and more accurate data.

Legitimate optimizations

Banner design. Present "Accept" and "Reject" with equal prominence (GDPR requirement), but the banner itself can be clear and quickly understandable. The less text, the faster the user decides.

Banner timing. Load the banner immediately after page build. Any delay increases the likelihood that the user ignores the banner or leaves the page.

Region-based consent. Visitors from regions without GDPR requirements do not need a banner. Details in our article on region-based consent management.

Forbidden optimizations

Dark patterns. Hiding "Reject", displaying it smaller, or requiring more clicks. This is a GDPR violation and supervisory authorities are increasingly enforcing against it.

Forced consent. Showing content only after acceptance. This is not a free choice and therefore not valid consent.

Consent wall. Blocking access to the website entirely until the user consents. Legally disputed, impermissible in many jurisdictions.

GA4 reports: Modeled vs. observed data

GA4 marks modeled data in reports with a triangle icon. In BigQuery exports, modeled data is not separately marked.

Where modeling is visible

• Realtime report: Shows only observed (not modeled) data
• Standard reports: Contain modeled data (if modeling is active and thresholds are met)
• Explorations: Can contain modeled data
• BigQuery export: Contains all events, but without marking whether modeled or observed

Reporting strategy

For campaign reporting, we recommend: use Google Ads as the conversion source (not GA4), because Google Ads has its own modeling optimized for campaign data. Use GA4 for website analytics and user journey analysis. And use Shopify orders as ground truth for validating both sources.

Conclusion

Consent Mode v2 is not an on/off switch. It is a complex system of four signals, timing requirements, and a modeling mechanism whose quality depends on your consent rate. Correct implementation requires understanding of defaults, updates, the gcs parameter, and the interaction with server-side tracking.

The good news: when Consent Mode v2 is correctly implemented, at typical consent rates of 60 to 70%, you do not lose 30 to 40% of your data, but only 10 to 15%. Behavioral Modeling closes the gap, even if not completely.

Is your Consent Mode correctly implemented? Our GDPR & Compliance Audit checks the implementation in detail: defaults, updates, timing, gcs parameter, server-side forwarding.