Development8 min read

Google Consent Mode v2: ad_user_data & ad_personalization Parameters Explained

A complete guide to Google Consent Mode v2's two new parameters — ad_user_data and ad_personalization — what they control, and how to implement them correctly in WordPress with GTM.

JO

James Okafor

Frontend Engineer · 22 January 2026

What Is Consent Mode v2?

Google Consent Mode v2 is Google's framework for adjusting the behaviour of Google tags (GA4, Google Ads, Floodlight) based on the consent status of a user. It was introduced in 2020 and updated to v2 in November 2023.

From March 2024, Google requires all EEA-based advertisers using Google Ads and Google Analytics to implement Consent Mode v2 if they want to:

  • Use audience features in Google Analytics
  • Measure conversions in Google Ads
  • Remarketing and personalised advertising

Without Consent Mode v2, Google will restrict data collection for non-consenting users in ways that degrade campaign measurement.

The Two New Parameters in v2

Consent Mode v2 adds two new consent parameters to the original four:

ParameterWhat It Controlsv2 Status
ad_storageAdvertising cookiesExisting
analytics_storageAnalytics cookiesExisting
ad_user_dataSending user data to Google for adsNew in v2
ad_personalizationPersonalised advertising (remarketing)New in v2

All four must be explicitly set in both your default and update calls for full Consent Mode v2 compliance.

What does ad_user_data control?

ad_user_data governs whether user-provided data — such as hashed email addresses, phone numbers, or names collected via lead forms — can be sent to Google for advertising purposes (Google's Enhanced Conversions feature relies on this).

  • granted — User data can be sent to Google to improve ad measurement and attribution
  • denied — No user data is sent; standard cookie-based attribution only

This is distinct from ad_storage. A user can accept advertising cookies (ad_storage: granted) but still refuse to have their personal data sent to Google (ad_user_data: denied). Your consent UI should reflect this distinction if you collect lead data.

What does ad_personalization control?

ad_personalization controls whether a user's data can be used for personalised advertising — primarily Google's remarketing audiences (e.g. retargeting people who visited your site or abandoned a cart).

  • granted — Remarketing audiences can be built; personalised ads served
  • denied — Non-personalised ads only; no remarketing lists populated

If a user denies ad_personalization, Google will still serve ads but they will not be personalised. This is the correct behaviour under GDPR when a user has not consented to marketing cookies.

Why these two parameters matter for GDPR compliance

The original Consent Mode v1 only controlled cookies (ad_storage, analytics_storage). However, Google's ad products increasingly use server-side signals and hashed user data that bypass cookie restrictions. The v2 parameters close this gap by adding explicit consent signals for data transmission and data use, not just cookie storage.

Without these signals set to denied by default:

  • Google may send user data to its servers even when cookies are blocked
  • Your consent records may not accurately reflect what data processing actually occurred
  • EEA users could have data used for remarketing without their knowledge

Basic vs Advanced Consent Mode

There are two implementation modes:

Basic Consent Mode: Google tags only fire after consent is granted. No data is collected for non-consenting users. Simpler to implement.

Advanced Consent Mode: Google tags fire immediately but behave differently based on consent. For non-consenting users, tags use cookieless pings and modelled data to partially fill measurement gaps. More complex, better data quality.

Advanced mode requires careful implementation to ensure non-essential tracking genuinely doesn't occur without consent.

Implementing Consent Mode v2 in WordPress

Step 1: Initialise Consent Mode Before GTM

The consent state must be set before GTM loads. Add this to your <head>, before the GTM snippet:

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

  // Set default consent state (deny all — wait for user choice)
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'analytics_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'wait_for_update': 500 // Wait 500ms for consent platform to update
  });
</script>

<!-- Google Tag Manager -->
<script>/* GTM snippet here */</script>

Step 2: Update Consent on User Choice

When a user grants or denies consent, update the consent state:

// Called when user accepts analytics cookies
function grantAnalyticsConsent() {
  gtag('consent', 'update', {
    'analytics_storage': 'granted'
  });
}

// Called when user accepts all cookies
function grantAllConsent() {
  gtag('consent', 'update', {
    'ad_storage': 'granted',
    'analytics_storage': 'granted',
    'ad_user_data': 'granted',
    'ad_personalization': 'granted'
  });
}

// Called when user declines all non-essential cookies
function denyAllConsent() {
  gtag('consent', 'update', {
    'ad_storage': 'denied',
    'analytics_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied'
  });
}

Step 3: Persist and Restore Consent on Return Visits

Consent must be remembered. Store the consent state and restore it on subsequent page loads:

function restoreConsentFromStorage() {
  const stored = localStorage.getItem('consent_state');
  if (!stored) return;

  const state = JSON.parse(stored);
  gtag('consent', 'update', state);
}

// Call on page load before GTM fires
restoreConsentFromStorage();

GTM Configuration

In your GTM container, you'll need to configure consent settings on each tag:

  1. In GTM, go to Tags → [Your Tag] → Advanced Settings → Consent Settings
  2. Add the required consent types for that tag (e.g., analytics_storage for GA4)
  3. GTM will automatically suppress the tag if consent isn't granted

Built-in Variables

GTM v2 has built-in consent state variables. You can use these in triggers and variables:

  • Consent State - ad_storage
  • Consent State - analytics_storage
  • Consent State - ad_user_data
  • Consent State - ad_personalization

DPOKit + GTM Integration

DPOKit's GTM integration handles all of the above automatically:

  1. Injects the gtag('consent', 'default', {...}) call before GTM loads
  2. Updates consent state when users interact with the consent banner
  3. Persists consent state across sessions
  4. Maps DPOKit's consent categories to GTM consent parameters
  5. Supports both basic and advanced Consent Mode
// WordPress filter to customise GTM consent mapping
add_filter('dpokit_gtm_consent_map', function($map) {
    $map['analytics'] = ['analytics_storage'];
    $map['marketing'] = ['ad_storage', 'ad_user_data', 'ad_personalization'];
    return $map;
});

Testing Your Implementation

Use the Google Tag Assistant Chrome extension to verify:

  1. Consent Mode is initialised before GTM loads
  2. All four parameters are present in the default state
  3. Consent updates fire correctly when user interacts with your banner
  4. Tags are firing/suppressed correctly based on consent

Also check the GTM Preview mode — tags with required consent will show a "Consent check failed" status when consent is denied.

Frequently Asked Questions

What is ad_user_data in Google Consent Mode v2?

ad_user_data controls whether user-provided data (e.g. hashed email addresses from lead forms) can be sent to Google for advertising. It is separate from ad_storage (advertising cookies). Both must be granted for Enhanced Conversions and full remarketing to function. Default both to denied and only update to granted after explicit user consent.

What is ad_personalization in Google Consent Mode v2?

ad_personalization controls whether data can be used for personalised advertising — primarily remarketing audiences. Setting it to denied means Google will not build remarketing lists from that user's activity and will serve non-personalised ads only. This is the required behaviour under GDPR when a user has not consented to marketing cookies.

What are all four Consent Mode v2 parameters?

The four parameters are:

  • ad_storage — advertising cookies (existing)
  • analytics_storage — analytics cookies (existing)
  • ad_user_data — sending user data to Google for ads (new in v2)
  • ad_personalization — personalised/remarketing ads (new in v2)

All four must appear in your gtag('consent', 'default', {...}) call.

Do ad_user_data and ad_personalization need to be set separately from ad_storage?

Yes. They are independent signals. A user can accept ad_storage (advertising cookies) while denying ad_user_data (data transmission) or ad_personalization (remarketing). Your consent banner categories should map correctly: the marketing/advertising category should set all three to granted or denied together in most standard implementations.

What happens if I don't implement Consent Mode v2?

For EEA users, Google restricts measurement and audience features in Google Ads and Analytics. You lose conversion modelling, remarketing audiences, and attribution data for non-consenting users, with no modelled data to partially fill the gap. Google began enforcing this requirement from March 2024.

Conclusion

Consent Mode v2 is not optional for EEA advertisers using Google products. The two new parameters — ad_user_data and ad_personalization — extend consent signals beyond cookies into data transmission and use, closing a gap that v1 left open. Implementing all four parameters correctly protects both your legal compliance posture and your measurement quality. The DPOKit integration handles this automatically for WordPress sites without requiring manual gtag() calls.

JO

James Okafor

Frontend Engineer

Google Tag ManagerConsent ModeAnalyticsGTMad_user_dataad_personalization
← Back to Blog