{"id":24,"date":"2026-07-08T18:16:00","date_gmt":"2026-07-08T16:16:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=24"},"modified":"2026-10-26T10:52:19","modified_gmt":"2026-10-26T09:52:19","slug":"passing-cookie-consent-choices-to-server-side-google-tag-manager","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/digital-marketing\/passing-cookie-consent-choices-to-server-side-google-tag-manager\/","title":{"rendered":"Passing Cookie Consent Choices to Server-Side Google Tag Manager"},"content":{"rendered":"

A server-side Google Tag Manager container (sGTM) processes incoming requests. The current consent-banner choice is available only through a suitable transmitted signal or a reliable server-side source. Missing consent information does not automatically send data to Meta CAPI: the configured tags and triggers determine what happens.<\/p>\n

A container groups the configured tags and rules. A tag sends data to a service; a trigger decides when it runs. The consent management platform (CMP), here Usercentrics, manages the banner and saved choices. Meta CAPI sends events from the server to Meta.<\/p>\n

This example carries the service-specific Meta choice from Usercentrics as an event parameter. Google Consent Mode remains separately configured for Google tags. The result is a technical firing rule, not proof that the overall data processing is lawful.<\/p>\n

\"Consent<\/figure>\n

1. Prerequisites and a consistent value<\/h2>\n

The setup requires working web and server containers, a server-side GA4 client, and a Usercentrics integration with documented consent events. CMP versions and integrations expose different structures. The web preview must first confirm the actual event and the exact Meta service name. An invented data-layer key will not retrieve consent automatically.<\/p>\n

A Data Layer Variable named {{UC - Meta Consent}}<\/code> reads that service-specific value, with false<\/code> as its default. The data layer is the collection of event information read by web GTM. If the consent system announces a choice through a window event, integration code must first copy the required value into that collection. This Custom JavaScript Variable example accepts only the Boolean value true<\/code> or the text 'true'<\/code> as consent:<\/p>\n

function () {\n  var value = {{UC - Meta Consent}};\n  return value === true || value === 'true' ? 'granted' : 'denied';\n}<\/code><\/pre>\n
The resulting variable is named {{Meta Consent State}}<\/code>. Missing values, numbers, and other strings become denied<\/code>. These two output strings are a convention for this example, not built-in Meta or Google consent parameters.<\/p>\n
2. Browser tags and transport<\/h2>\n
    \n
  1. The Meta Pixel initialization tag receives the appropriate consent-event trigger plus {{Meta Consent State}} equals granted<\/code>. Depending on the integration, Usercentrics documents consent_status<\/code> or related event variants. Preview confirms the actual name.<\/li>\n
  2. Additional Meta events, such as a purchase, need the same service-specific condition on their own event triggers. An initialization trigger does not protect every subsequent tag.<\/li>\n
  3. The Google tag transport routes to the tagging server. Each relevant GA4 event carries meta_consent_state<\/code> with {{Meta Consent State}}<\/code> as its value. Shared event settings can reduce repeated setup. Preview must still show that every intended event actually contains the parameter.<\/li>\n<\/ol>\n
    Google consent signals do not replace the Meta-specific choice. The transport also needs an appropriate consent configuration. In Basic Consent Mode, an analytics tag without permission can remain completely blocked, so its Meta parameter never reaches the server. Meta permission alone does not justify enabling the GA4 transport indiscriminately.<\/p>\n
    Blocking a later GTM trigger does not unload a Pixel library that is already running. Automatic Pixel events and other integrations therefore need separate checks. Withdrawal must also update the loaded library through the CMP\/Pixel integration; the Meta template supports grant<\/code>\/revoke<\/code> for this. The state-update path must remain usable when consent is denied.<\/p>\n
    3. A server-side firing trigger<\/h2>\n
    An Event Data<\/strong> variable with key path meta_consent_state<\/code> reads the received value. The GA4 client must actually expose that parameter in the event; server preview shows whether that happened.<\/p>\n
    The Meta CAPI trigger requires the expected client, an explicitly supported event, and meta_consent_state equals granted<\/code> together. The client name must match the configured client. Separate rules or a precise list can cover page_view<\/code> and purchase<\/code>; .*<\/code> matches every event, not only e-commerce events.<\/p>\n
    This rule belongs under the tag’s firing triggers<\/strong>. It is not a blocking exception: an exception matching \u201cgranted\u201d would block the allowed case. Other broader firing triggers need removal or equivalent restrictions. Missing, denied<\/code>, and unexpected values do not satisfy this rule.<\/p>\n
    4. Limited forwarding and observable checks<\/h2>\n
    A transport parameter need not reach every destination. An sGTM Exclude parameters<\/strong> transformation targeted to the GA4 tag can remove meta_consent_state<\/code> before forwarding data to Google. Its scope must preserve the value wherever Meta gating needs it. Not registering a custom dimension does not prevent transmission.<\/p>\n\n\n\n\n\n\n\n\n\n
    Test case<\/th>\nExpected Meta behavior<\/th>\n<\/tr>\n<\/thead>\n
    No decision, rejection, or missing parameter<\/td>\nNo Pixel\/CAPI delivery through the protected triggers<\/td>\n<\/tr>\n
    Meta allowed and a relevant event<\/td>\nOnly the intended tags fire<\/td>\n<\/tr>\n
    Other services allowed, Meta denied<\/td>\nMeta stays blocked<\/td>\n<\/tr>\n
    Withdrawal followed by a new event<\/td>\nUpdated state blocks further delivery<\/td>\n<\/tr>\n
    New page with a saved choice<\/td>\nChoice is restored before the relevant event<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Verification covers web and server preview, resolved variables, and actual outgoing requests. Withdrawal cannot recall events already sent. A newly granted choice is also not a reason to replay previously blocked events without a separate assessment.<\/p>\n
    \n
    Questions and answers<\/h2>\n
    Does the parameter prove valid consent?<\/h3>\n
    No. A browser parameter can be altered and is not tamper-proof evidence. Validity, purposes, required information, and any separate evidence requirements belong to the overall system design.<\/p>\n
    Why can events be missing after consent was granted?<\/h3>\n
    Possible causes include a choice not yet restored by the CMP, the wrong key, missing parameter inheritance, or a blocked transport. A later choice cannot change a request already received. These cases need separate technical diagnosis.<\/p>\n
    Does this work with every Meta CAPI template?<\/h3>\n
    Event data and triggers must fit the installed template. Parameter mapping, additional delivery paths, and potential browser\/server duplicates require their own checks. A successful trigger condition alone does not establish a correct overall implementation.<\/p>\n<\/div>\n
    Sources and review date<\/h2>\n
    2026-10-24<\/p>\n