How Consent Signals Work in Server-side Tagging

How Consent Signals Work in Server-side Tagging

Consent management becomes more complex — and more important — when you move from client-side to server-side tagging. In a browser-only setup, blocking a script is straightforward: if the user hasn't consented, the script simply doesn't run. With server-side tagging, the event data has already left the browser by the time tags fire on the server. Consent must be explicitly carried through the data pipeline and enforced at each stage.

The Consent Signal Flow

In a properly configured server-side setup with CookieBeam, consent signals follow this path:

1. Banner displays — CookieBeam shows the consent banner and sets Consent Mode defaults (all denied until the user acts).
2. User makes a choice — The visitor accepts or rejects cookie categories (analytics, marketing, preferences).
3. Consent Mode updates — CookieBeam updates Google Consent Mode v2 signals (ad_storage, analytics_storage, ad_user_data, ad_personalization), Microsoft Consent Mode signals, and Meta Pixel consent state.
4. Event fired — When the user performs an action (page view, purchase), the GTM web container sends the event to your tagging server. The consent state is embedded in the event data.
5. Server receives event — The sGTM server container reads the consent signals from the incoming request.
6. Tags check consent — Each server-side tag (GA4, Google Ads, Meta CAPI) checks the relevant consent signal before firing. If analytics_storage is denied, the GA4 tag won't send full measurement data. If ad_storage is denied, Google Ads conversion tags won't fire.

Google Consent Mode v2 on the Server

Google Consent Mode v2 defines these consent types:

• ad_storage — Allows storage (cookies) for advertising purposes.
• ad_user_data — Allows sending user data to Google for advertising.
• ad_personalization — Allows personalised advertising.
• analytics_storage — Allows storage for analytics purposes.
• functionality_storage — Allows storage for site functionality.
• personalization_storage — Allows storage for personalisation.
• security_storage — Allows storage for security (always granted).

When these signals arrive at the sGTM server container, Google's built-in tags automatically respect them. For example, the GA4 tag in server-side GTM will check analytics_storage and behave accordingly — sending pings without cookies when denied (Advanced mode) or not sending at all (Basic mode).

Microsoft Consent Mode on the Server

Microsoft Consent Mode works with two platforms:

• Microsoft Clarity — Respects analytics_storage. When denied, Clarity won't start session recording.
• Microsoft Ads (UET) — Respects ad_storage. When denied, UET won't track conversions or build remarketing audiences.

CookieBeam maps the visitor's analytics category to analytics_storage and the marketing category to ad_storage, so both Microsoft platforms receive the correct signals automatically.

Meta Pixel and CAPI Consent

Meta uses a different consent mechanism. Instead of Consent Mode signals, the Meta Pixel uses:

CookieBeam automatically calls the appropriate fbq consent function when the visitor updates their preferences. On the server side, the Meta CAPI tag in your sGTM container checks the ad_storage consent signal to decide whether to fire.

Why Dual-layer Enforcement Matters

A common misconception is that server-side tagging removes the need for client-side consent management. In reality, you need both:

Client-side enforcement:

• Prevents scripts from running before consent is given.
• Ensures Consent Mode defaults are set early (before any tags fire).
• Provides the visual consent interface (banner).
• Handles fbq consent calls for the Meta Pixel.

Server-side enforcement:

• Acts as a second check — even if a client-side script error or browser extension bypasses blocking, the server won't forward data without valid consent.
• Enables consent-aware processing — for example, hashing PII before forwarding only for consented users.
• Provides an audit trail — server logs show that consent was checked before each dispatch.

Consent State in the Data Layer

When CookieBeam updates consent, it pushes events to the dataLayer:

• cookie_consent_update — Fired on every consent change and on every page load.
• cookie_consent_marketing — Fired when marketing consent is granted.
• cookie_consent_statistics — Fired when analytics consent is granted.
• cookie_consent_preferences — Fired when preferences consent is granted.

These events, combined with the Consent Mode state, travel with every subsequent event to the tagging server. The server container reads the consent state from the x-ga-gcs parameter (Google's consent state encoding) in the incoming request.

Best Practices

1. Always set consent defaults before any tags fire. CookieBeam handles this automatically by setting strict defaults (denied) on page load.
2. Use the same consent categories across all platforms. CookieBeam maps your banner categories (analytics, marketing, preferences) to Google, Microsoft, and Meta consent signals consistently.
3. Don't rely solely on client-side blocking. Server-side consent checks provide defense in depth.
4. Test consent flows end-to-end. Use GTM's Preview mode and sGTM's logging to verify that denied consent actually prevents data from reaching vendors.
5. Document your consent architecture. Regulators and auditors want to see how consent is enforced across your entire data pipeline, not just the banner.