How to Implement Consent Mode v2 via Server-Side GTM

November 1, 2026

Implementing Google Consent Mode v2 via Server-Side Google Tag Manager (sGTM) requires capturing four core consent signals on the web client, passing encoded consent strings through the Google Analytics 4 (GA4) transport stream, and configuring sGTM tag templates to parse incoming parameters before dispatching requests to advertising and analytics endpoints.

Key Takeaways

• Consent Mode v2 introduces two mandatory signals—ad_user_data and ad_personalization—alongside legacy ad_storage and analytics_storage flags.
• Server-side containers do not replace client-side Consent Management Platforms (CMPs); sGTM reads encoded gcs and gcd parameters generated by web GTM.
• Advanced Consent Mode routes unconsented, cookieless pings through sGTM to preserve conversion modeling in Google Ads without storing local storage identifiers.
• Third-party server-side tags (such as Meta CAPI or LinkedIn CAPI) require manual trigger conditions or transformation rules to prevent data processing when consent is denied.

Understanding the Payload: How Web Consent Translates to sGTM

Server-Side GTM acts as a proxy for client data. It does not evaluate user consent natively in the browser. Instead, your client-side CMP sets consent states, web GTM updates the gtag consent object, and the client container sends those states inside the query string of outgoing HTTP requests sent to your sGTM custom domain.

When using the GA4 web tag as the transport layer to sGTM, consent parameters are serialized into two distinct parameters: gcs and gcd.

The Legacy GCS Parameter

The gcs (Google Consent Status) parameter carries a three-character string formatted as G1xx. The first position is a fixed header version. The second position represents ad_storage, and the third represents analytics_storage. A value of 1 indicates granted consent, while 0 indicates denied consent.

• G111: Both ad_storage and analytics_storage are GRANTED.
• G100: Both ad_storage and analytics_storage are DENIED.
• G110: ad_storage is GRANTED; analytics_storage is DENIED.
• G101: ad_storage is DENIED; analytics_storage is GRANTED.

The Consent Mode v2 GCD Parameter

To support regulatory updates in the European Economic Area (EEA), Google introduced the gcd (Google Consent Directives) parameter. This parameter encodes all four consent types, including the state source (default settings vs. explicit user updates).

A typical gcd string looks like 11l1l1l1l5 or 11q1q1q1q5. The string breaks down into key signal pairs corresponding to the four primary flags:

1. ad_storage
2. analytics_storage
3. ad_user_data
4. ad_personalization

The encoding uses letter-number combinations (such as p for default denied, q for explicit update denied, t for explicit update granted) to inform sGTM and Google servers how the consent state was derived. When sGTM receives the request, the built-in GA4 Client parses this string into the Event Data object, populating fields accessible by server-side tags.

Step 1: Configure Web GTM and CMP Defaults

Before sGTM can process consent, the web container must establish default consent states before any tags fire. This prevents execution race conditions where tags fire before the CMP loads.

Place your CMP script (such as OneTrust, Cookiebot, or Usercentrics) in the site header, followed immediately by the native Google consent default script. Alternatively, use a native CMP GTM Community Template configured to inject defaults synchronously.

Here is the standard JavaScript implementation pattern to set defaults prior to the GTM container initialization:

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

  // Set default consent states to denied for EEA regions
  gtag('consent', 'default', {
    'ad_storage': 'denied',
    'analytics_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'wait_for_update': 500
  });
</script>

When a user grants consent on your banner, your CMP fires a gtag('consent', 'update', ...) command. Web GTM automatically updates its internal state and appends the updated gcs and gcd strings to subsequent server requests.

Step 2: Transport Consent Signals to Server-Side GTM

To pass client consent states to your sGTM endpoint, configure your GA4 Web Configuration tag to route all events through your sGTM custom tagging domain (for instance, metrics.yourdomain.com).

1. Open your client-side GTM container.
2. Navigate to your GA4 Google Tag configuration.
3. Add the parameter server_container_url and set its value to your custom sGTM URL.
4. Ensure the setting Send Event Data to Server Container is checked.

For a detailed breakdown on establishing server-side transport layers, consult our step-by-step Server-Side GTM for Meta CAPI and GA4 setup guide.

When the GA4 tag triggers, it sends POST requests to https://metrics.yourdomain.com/g/collect. The URL query parameters will automatically contain the gcs and gcd keys. The sGTM GA4 Client automatically intercepts these keys and converts them into normalized internal sGTM variables.

Step 3: Configure Tags inside sGTM

Once payload parameters arrive at your sGTM instance, server tags process the data based on incoming consent status.

Google Ads Conversion Tracking and GA4 Server Tags

Official Google tags running inside sGTM (GA4 and Google Ads Conversion Tracking / Remarketing) have built-in consent reading capabilities. They automatically extract consent parameters from the Event Data generated by the sGTM GA4 Client.

1. In sGTM, open your Google Ads Conversion Tracking tag.
2. Observe that built-in consent checks are enabled by default. You do not need to construct custom blocking triggers for native Google tags if you are utilizing Advanced Consent Mode.
3. When ad_storage or ad_user_data is marked as denied, the sGTM Google Ads tag strips identifiers (such as gclid, _gcl_au, and hashed user data) from the outgoing HTTP request sent to googleadservices.com, converting the ping to a modeled, cookieless hit.

Gating Non-Google Tags (Meta CAPI, LinkedIn, TikTok)

Unlike native Google tags, vendor tags like Meta Conversions API do not natively parse Google’s gcd parameter. If a user denies marketing consent, running a Meta CAPI tag will violate legal compliance unless you explicitly block or redact the server event.

To create a consent-gated trigger for third-party tags in sGTM:

1. In sGTM, navigate to Variables and create a new Event Data variable.
2. Set the Key Path to x-ga-gcs (or parse the gcs query parameter directly from page_location).
3. Name the variable Event Data - gcs.
4. Create a Trigger named Fire - Meta CAPI - Granted Consent.
5. Set the trigger condition to: Event Data - gcs matches RegEx ^G1.1 (this ensures the third character, representing ad_storage, is set to 1).
6. Attach this trigger to your Meta CAPI and LinkedIn CAPI tags.

Standard vs. Advanced Consent Mode in sGTM

Choosing between Standard and Advanced Consent Mode dictates whether data touches your server-side environment when consent is denied.

Step 4: Validating Consent Mode v2 Signals in sGTM

Verification requires testing network requests, previewing sGTM container execution, and confirming signal reception in ad platform interfaces.

1. Inspect Network Payloads

Open browser Developer Tools, switch to the Network tab, and clear cookies. Load your website without interacting with the consent banner. Filter for your sGTM domain name.

Click the outgoing /g/collect request and check the Payload tab. Confirm that gcs reads G100 and gcd contains default denied states (e.g., 11p1p1p1p5). Accept the consent banner and verify that a secondary ping is sent with gcs=G111 and an updated gcd string (e.g., 11q1q1q1q5).

2. Check sGTM Preview Mode

In sGTM, click Preview to launch the server-side debugger. Select an incoming event in the left pane and inspect the Event Data tab.

Verify that the following keys are correctly parsed from the request:

• consent_state.ad_storage: granted or denied
• consent_state.analytics_storage: granted or denied
• consent_state.ad_user_data: granted or denied
• consent_state.ad_personalization: granted or denied

If these variables show as undefined, review your client-side container setup. You may need to review how to fix missing Consent Mode v2 signals in Google Ads and GA4 to correct payload formatting errors.

3. Verify GA4 and Google Ads Diagnostics

Within Google Ads, navigate to Tools & Settings > Conversions, click your primary conversion action, and inspect the Diagnostics tab. The system should show an active status for "Consent Mode v2".

If you observe unassigned traffic spikes or missing campaign parameters when unconsented users navigate your site, make sure your server tags are not stripping required session markers. Refer to our guide on how to fix GA4 unassigned traffic to protect attribution reporting while remaining compliant.

Frequently Asked Questions

Does Server-Side GTM eliminate the need for a client-side CMP?

No. Server-Side GTM operates downstream from the browser and cannot render UI consent banners or directly read user consent preferences. You must use a client-side Consent Management Platform (CMP) to capture user choices and set consent defaults in web GTM before routing data to your server container.

How does sGTM handle user IP addresses when consent is denied?

Under Advanced Consent Mode, sGTM receives incoming HTTP requests containing the user's IP address. However, when the incoming request carries unconsented gcs signals, native sGTM Google tags automatically truncate or drop IP addresses and client user-agent strings before transmitting event payloads to Google Ads or GA4 endpoints.

Why are my server-side Meta CAPI tags still firing when consent is denied?

Meta CAPI tags do not natively recognize Google's gcs or gcd parameters. If you run Advanced Consent Mode, cookieless pings will reach sGTM even when consent is denied. You must configure custom blocking triggers or sGTM Transformations based on the x-ga-gcs parameter to prevent Meta CAPI tags from firing without explicit consent.

What happens if I don't implement ad_user_data and ad_personalization signals?

If your web payload lacks ad_user_data and ad_personalization flags, Google Ads will drop incoming server-side events for EEA users from audience remarketing lists and auto-bidding optimization algorithms, significantly degrading ad performance and campaign reach.