Server-Side Google Tag Manager

Google Tag Manager (GTM) server-side containers move tag execution from the visitor's browser to a server you control. This improves page performance, reduces ad-blocker interference, and gives you tighter control over outbound data. Because the consent banner runs client-side, a hybrid setup is required—your web container handles consent collection, while the server-side container enforces it before forwarding data to vendors.

How It Works

The DataGrail consent banner runs in the browser and communicates consent choices through Google Consent Mode. When you also run a server-side container, the flow looks like this:

1. The consent banner loads in the browser and collects the visitor's preferences.
2. DataGrail updates the Google Consent Mode signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) based on those preferences and your category mappings.
3. Your web container sends events (e.g., GA4 measurement protocol requests) to the server-side container endpoint—typically a first-party subdomain like sgtm.example.com.
4. The consent state travels with the event data in the request payload.
5. Server-side tags read the consent signals and conditionally fire based on the visitor's choices.

Web Container Still Required

A server-side container does not replace your web container. The web container is where the DataGrail consent banner runs and where consent signals originate. The server-side container sits downstream and acts as a privacy-aware proxy.

GTM Deployment

If you deploy DataGrail Consent through Google Tag Manager, consent signals are automatically included in outbound events from your web container. You need to make sure that your server-side GTM configuration properly handles the Google Consent Mode flags so that server-side tags respect visitor choices.

To configure your server-side container for consent:

1. Verify that Google Consent Mode is enabled in DataGrail and your category mappings are configured.
2. In your server-side GTM container, gate each third-party tag on consent using its trigger (see Third-Party Server Tags). Google's consent-aware tags (GA4, Google Ads, Conversion Linker) read the forwarded consent signals automatically and need no extra configuration.
3. Publish your DataGrail changes to the web container.
4. Test using the GTM server-side Preview mode to verify that consent signals arrive with each event and that tags respect them.

Third-Party Server Tags

Server-side containers have no Consent Settings on tags—built-in and additional consent checks exist only in web containers. Non-Google tags (e.g., the HTTP Request tag) don't read consent on their own, so you must block them through their trigger.

Events from the GA4 client carry the visitor's consent state in the x-ga-gcs event data key. Its value is G1 followed by one digit for ad_storage and one for analytics_storage:

Digit	Meaning
1	Granted
0	Denied
-	Not set

For example, G110 means ad_storage is granted and analytics_storage is denied.

x-ga-gcs doesn't include ad_user_data or ad_personalization. To gate a tag on a category, map that category to ad_storage or analytics_storage as well.

To gate a third-party server tag on consent:

1. In your server-side container, create a Variable of type Event Data with the key path x-ga-gcs.
2. Open the trigger that fires the third-party tag and add a condition on that variable for the storage type your DataGrail category (e.g., Marketing) is mapped to:
   • ad_storage granted: matches RegEx ^G11
   • analytics_storage granted: matches RegEx ^G1.1
3. Save and publish the server-side container.

Events without an x-ga-gcs value don't match either pattern, so the tag doesn't fire—treat missing consent as denied.

Internal Parameter

Google documents x-ga-gcs as an internal parameter whose format may change. Re-verify your triggers in Preview mode after Google tag updates.

Advanced vs Basic Consent Mode

Both Advanced and Basic Consent Mode work with server-side containers. In Advanced mode, Google's consent-aware tags send cookieless pings even when consent is denied, enabling modeled conversions. In Basic mode, DataGrail blocks each web tag until its category is consented, so a blocked GA4 tag sends nothing to your server container.

This affects third-party server tags gated on x-ga-gcs: in Basic mode, if a visitor grants the category your server tag requires (e.g., Marketing) but denies the category your GA4 tag is assigned to (e.g., Performance), no event reaches the server container and the server tag doesn't fire. The tag never fires without consent, but it can miss some consented visitors. Advanced mode avoids this at the cost of sending cookieless pings before consent.

Embedded Deployment

If you use an embedded deployment or need to send events directly to your server-side container outside of GTM's built-in data flow, you can use DataGrail callbacks to read consent state and include it in your server-side requests.

The example below listens for consent changes and sends an event to a server-side GTM endpoint, including the consent state in the payload:

<script>
  window.dgEvent = window.dgEvent || [];

  function sendToServerGTM(preferences) {
    var consentState = {
      ad_storage: window.DG_BANNER_API.categoryEnabled("marketing") ? "granted" : "denied",
      analytics_storage: window.DG_BANNER_API.categoryEnabled("performance") ? "granted" : "denied",
      ad_user_data: window.DG_BANNER_API.categoryEnabled("marketing") ? "granted" : "denied",
      ad_personalization: window.DG_BANNER_API.categoryEnabled("marketing") ? "granted" : "denied",
      functionality_storage: window.DG_BANNER_API.categoryEnabled("functional") ? "granted" : "denied"
    };

    // Send event to your server-side GTM endpoint
    fetch("https://sgtm.example.com/your-endpoint", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        event_name: "consent_update",
        consent: consentState
        // Include any other event data as needed
      })
    });
  }

  // Fire on initial page load with existing preferences
  window.dgEvent.push({
    event: "initial_preference_callback",
    params: sendToServerGTM
  });

  // Fire when visitor updates their preferences
  window.dgEvent.push({
    event: "preference_callback",
    params: sendToServerGTM
  });
</script>

Your server-side container must be configured to parse the consent fields from incoming requests and apply them before firing any tags. How you implement this depends on your server-side client template—consult your GTM server-side client documentation for details on reading custom consent fields from inbound requests.

Verifying Consent Propagation

After configuring your server-side container, verify that consent signals are arriving correctly.

1. Open your server-side GTM container in Preview mode.
2. On your website, interact with the consent banner to set specific preferences (e.g., deny marketing).
3. Trigger a page view or event that sends data to the server-side container.
4. In the server-side Preview panel, open the incoming event's Event Data tab. Confirm that x-ga-gcs reflects the choices made in step 2 (e.g., if ad_storage is mapped to Marketing and you denied Marketing, the third character is 0). Server-side Preview has no Consent tab, and consent does not appear as ad_storage or analytics_storage keys.
5. Verify that tags configured to require consent are not firing when the relevant category is denied.

Server-Side Tags Without a Web Container

If you send data to a server-side container directly from your backend (e.g., via HTTP calls without a browser involved), there is no consent banner in play. In this scenario, you are responsible for determining and attaching the correct consent state to each request before sending it to the server-side container.