Consent Mode V2 changed the rules for European advertising. Starting March 2024, Google requires Consent Mode V2 implementation to access audience targeting features in Google Ads for EEA users. The combination of server-side GTM and Consent Mode creates a powerful architecture that respects user consent while maximizing signal quality for your advertising platforms. This guide explains how to implement Consent Mode in a server-side GTM setup, the difference between basic and advanced mode, and how to model data from users who decline consent.

Consent Mode V2: What Changed

Consent Mode V2 adds two new consent parameters to the existing ad_storage and analytics_storage: ad_user_data and ad_personalization. Ad_user_data controls whether user data (including hashed email for enhanced conversions) can be sent to Google. Ad_personalization controls whether data can be used for personalized advertising. All four parameters must be set for complete Consent Mode V2 compliance. Google Ads campaigns without Consent Mode V2 cannot target or exclude users in the EEA based on remarketing lists or customer match after March 2024.

Basic vs. Advanced Consent Mode

Basic Consent Mode blocks all tags from firing until the user makes a consent choice. Tags are either fully active (user accepted) or completely inactive (user declined). No pings, no cookieless hits, no modeling. This is the simpler implementation: add the consent default to your dataLayer before GTM loads, and block all tags with consent checks.

Advanced Consent Mode allows tags to fire even when consent is declined, but they fire in a cookieless, restricted mode. When ad_storage is denied, Google’s tags still send a cookieless ping that contributes to Google’s behavioral modeling. This modeling data lets Google estimate conversions for users who declined cookies, improving campaign optimization without storing cookies. Advanced mode requires careful implementation to ensure tags actually respect the consent state they receive.

Implementing in Server-Side GTM

In a server-side GTM setup, consent signals originate in the browser (from your CMP) and must be passed to the server container. The standard approach is to include the consent state in the GA4 client’s events, which the server-side container can read and use to gate tag firing.

Browser-side setup: initialize consent defaults before GTM loads using the gtag consent command:

// Default to denied for EEA users before GTM loads
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  wait_for_update: 500 // ms to wait for CMP to update consent
});

// When user accepts (from CMP callback):
function onConsentAccepted(categories) {
  gtag('consent', 'update', {
    ad_storage: categories.marketing ? 'granted' : 'denied',
    ad_user_data: categories.marketing ? 'granted' : 'denied',
    ad_personalization: categories.marketing ? 'granted' : 'denied',
    analytics_storage: categories.analytics ? 'granted' : 'denied'
  });
}

Server-Side Consent Forwarding

The GA4 client in your server-side container automatically reads consent state from incoming GA4 requests when Consent Mode is properly configured. The browser-side GA4 tag includes consent parameters in its network requests when using Advanced Consent Mode. Your server-side GA4 tag then forwards these consent parameters to Google’s servers.

For other server-side tags (Meta, TikTok), you need to read the consent state from the incoming event and conditionally fire tags. Use a server-side GTM variable to extract the consent state from the incoming request, then add trigger conditions on your server-side tags that check this variable. A tag firing condition of consent_analytics_storage equals granted ensures the tag only fires when the user has accepted analytics cookies.

Verifying Consent Mode in GA4

GA4 provides a Consent Mode report under Admin → Data Collection. This report shows what percentage of your traffic has each consent type granted versus denied versus not set. If the report shows a large percentage of “not set” for your EEA traffic, your consent default is not being set before GTM fires — the most common implementation error.

In BigQuery, you can verify consent mode signals by checking the privacy_info fields in exported events. The privacy_info.analytics_storage, privacy_info.ads_storage, and privacy_info.uses_transient_token columns show the consent state for each event. Filter to events where privacy_info.analytics_storage = ‘Yes’ to see only consented analytics data. Compare this to total events to understand your actual consent rate, which should match your CMP’s reported consent rate within a few percentage points.