Common Google Consent Mode v2 Mistakes (And How to Fix Them)

You've installed Consent Mode v2, added the code, and everything looks correct - but conversions still aren't working. This is frustratingly common. Most Consent Mode v2 implementations have subtle configuration mistakes that break conversion tracking without obvious errors.

After analyzing many broken setups, most Google Ads conversion issues come down to a handful of Consent Mode v2 mistakes. These mistakes are easy to make, hard to detect, and have significant business impact. This is one of several ways Google Ads conversions break.

This guide covers the most common mistakes, why they break conversion tracking, and how to fix them.

Check for Consent Mode v2 Mistakes Automatically

Run a free diagnostic scan to identify Consent Mode v2 configuration mistakes, missing consent updates, and other issues breaking conversion tracking. Use our Consent Mode validation guide to verify your setup.

Run Free Scan →

The scan checks all common Consent Mode v2 mistakes and provides specific fixes.

Mistake #1: Consent Mode Initializes Too Late

What's happening: Consent Mode v2 initialization code runs after Google tags (GTM, GA4, Google Ads) have already loaded. By the time Consent Mode initializes, tracking scripts have already fired without consent signals.

Why It Breaks

Consent Mode v2 must initialize BEFORE any Google tags load. If tags load first, they fire without consent signals, and Google Ads may suppress or not attribute those conversions. For details on the correct default denied configuration, see our guide.

The Fix

Move Consent Mode initialization to the <head> section, BEFORE any Google tag scripts:

<head>
  <!-- Consent Mode v2 MUST be first -->
  <script>
    gtag('consent', 'default', {
      'ad_storage': 'denied',
      'analytics_storage': 'denied',
      'wait_for_update': 500
    });
  </script>
  
  <!-- Then load Google tags -->
  <script async src="https://www.googletagmanager.com/gtag/js?id=..."></script>
</head>

Mistake #2: Consent Updates Never Fire

What's happening: Consent Mode v2 is initialized correctly (default denied), but consent updates never fire when users click "Accept" on the consent banner. Consent state stays 'denied' forever.

Why It Breaks

Google Ads needs to see consent state change from 'denied' to 'granted' to know when tracking is allowed. If consent updates never fire, Google Ads treats all users as non-consented and may suppress conversion attribution. This is why Google Ads shows 0 conversions but GA4 shows events.

The Fix

Ensure your consent banner calls gtag('consent', 'update') when users accept:

// When user clicks "Accept"
function onAcceptConsent() {
  gtag('consent', 'update', {
    'ad_storage': 'granted',
    'analytics_storage': 'granted'
  });
  
  // Then trigger your consent banner's accept logic
  // (e.g., show tracking scripts, set cookies, etc.)
}

If you're using a CMP (Consent Management Platform), verify it's configured to call consent updates. See how to check Google Consent Mode v2 to verify consent updates are firing.

Mistake #3: Only One Storage Type Granted

What's happening: Consent updates grant analytics_storage but not ad_storage (or vice versa). This is valid for analytics-only setups, but breaks Google Ads conversion tracking.

Why It Breaks

Google Ads requires ad_storage to be 'granted' for conversion attribution. If only analytics_storage is granted, GA4 might work, but Google Ads conversions won't be attributed.

The Fix

If you run Google Ads, grant both storage types:

gtag('consent', 'update', {
  'ad_storage': 'granted',      // Required for Google Ads
  'analytics_storage': 'granted' // Required for GA4
});

Mistake #4: Default State Is 'Granted' Instead of 'Denied'

What's happening: Consent Mode initialization sets default states to 'granted' instead of 'denied'. This violates privacy requirements and breaks conversion modeling.

Why It Breaks

Consent Mode v2 requires default states to be 'denied' so Google can model conversions for users who reject cookies. If defaults are 'granted', tracking fires before consent is collected (violation), and Google can't model conversions properly. Learn how gtag consent default should be configured.

The Fix

Always set default states to 'denied':

// ❌ WRONG
gtag('consent', 'default', {
  'ad_storage': 'granted',  // Don't do this
  'analytics_storage': 'granted'
});

// ✅ CORRECT
gtag('consent', 'default', {
  'ad_storage': 'denied',      // Must be denied
  'analytics_storage': 'denied', // Must be denied
  'wait_for_update': 500
});

Mistake #5: Missing wait_for_update Parameter

What's happening: Consent Mode initialization doesn't include the wait_for_update parameter. This prevents Google from waiting for consent updates before processing data.

Why It Breaks

The wait_for_update parameter tells Google to wait for consent updates before processing data. Without it, Google may process data before consent is granted, breaking conversion modeling and attribution.

The Fix

Always include wait_for_update:

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500  // Required for v2
});

The value (500) is milliseconds to wait. 500ms is typically sufficient for most consent banners to load.

Mistake #6: Consent Updates Fire Before Banner Is Visible

What's happening: Consent updates fire immediately on page load, before users have a chance to see or interact with the consent banner. This effectively grants consent without user action.

Why It Breaks

This violates privacy requirements - users must explicitly grant consent. Additionally, if consent updates fire too early, they might fire before Consent Mode is fully initialized, causing timing issues.

The Fix

Only fire consent updates when users explicitly click "Accept":

// ❌ WRONG - fires on page load
window.addEventListener('load', () => {
  gtag('consent', 'update', { 'ad_storage': 'granted' });
});

// ✅ CORRECT - fires on user click
document.getElementById('accept-button').addEventListener('click', () => {
  gtag('consent', 'update', {
    'ad_storage': 'granted',
    'analytics_storage': 'granted'
  });
});

Mistake #7: Using Legacy Consent Mode Code

What's happening: You're using old Consent Mode code (legacy version) instead of Consent Mode v2. The code looks similar, but v2 has critical differences.

Why It Breaks

Legacy Consent Mode has limited conversion modeling capabilities. Google can't effectively model conversions for users who reject cookies, leading to lost conversion data. See Consent Mode v2 vs Legacy Consent Mode for the full comparison.

The Fix

Update to Consent Mode v2 by adding wait_for_update:

// Legacy (limited modeling)
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied'
});

// v2 (enhanced modeling)
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'wait_for_update': 500  // This makes it v2
});

Mistake #8: CMP Not Integrated with Consent Mode

What's happening: You're using a Consent Management Platform (CMP) like OneTrust, Cookiebot, or Quantcast, but it's not configured to call Consent Mode updates. The CMP collects consent, but Consent Mode never receives the updates.

Why It Breaks

If the CMP doesn't call gtag('consent', 'update'), Consent Mode state never changes from 'denied' to 'granted'. Google Ads treats all users as non-consented and may suppress conversion attribution.

The Fix

Configure your CMP to call Consent Mode updates. Most CMPs have settings for this:

OneTrust: Enable "Google Consent Mode v2" in settings
Cookiebot: Enable "Google Consent Mode" integration
Quantcast: Configure Google Consent Mode in CMP settings

If your CMP doesn't support Consent Mode, you'll need to manually call consent updates when the CMP fires consent events.

How to Check for These Mistakes

To identify which mistakes you're making:

Method 1: Manual Code Review

Check your code for each mistake listed above. Look for:

Consent Mode initialization order (must be first)
Consent update calls (must fire on Accept)
Default states (must be 'denied')
wait_for_update parameter (required for v2)

Method 2: Browser Testing

Test in a fresh incognito window:

Check if Consent Mode initializes before tags load
Verify consent updates fire when you click Accept
Check network requests for proper consent signals

See how to check Google Consent Mode v2 for detailed steps.

Method 3: Automated Diagnostic

Run an automated scan that checks all common mistakes automatically. This is the fastest and most comprehensive method.

The Business Impact of These Mistakes

These mistakes don't just break technical functionality - they have real business impact:

Lost conversion data - If 30% of users reject cookies and Consent Mode isn't working, you lose 30% of conversion data
Degraded campaign optimization - Google's algorithms optimize on incomplete data, reducing performance over time
Budget wastage - Without proper conversion data, budget gets spent on underperforming traffic
Broken attribution - Conversions may not be attributed to campaigns, causing Google Ads to show 0 conversions but GA4 to show events

For a deeper understanding of how consent affects Google Ads, see does Consent Mode affect Google Ads optimization.

Next Steps: Get a Complete Diagnostic

Instead of manually checking each potential mistake, run an automated diagnostic scan that checks:

Consent Mode initialization timing and order
Whether consent updates fire correctly
Default state configuration
wait_for_update parameter presence
CMP integration with Consent Mode
Storage type grants (ad_storage vs analytics_storage)

Check for Consent Mode v2 Mistakes Automatically

Get an automated report that identifies all Consent Mode v2 configuration mistakes, provides specific fixes, and verifies that consent updates work correctly.

Run Free Scan →

See a sample report: View sample report →

Related guides:

Part of the Google Ads conversion tracking series:

← Back to: Why Google Ads Conversions Break