Consent-Status an Server-Side GTM übergeben

Ein serverseitiger Google-Tag-Manager-Container (sGTM) verarbeitet eingehende Requests. Die aktuelle Auswahl im Consent-Banner ist darin nur verfügbar, wenn ein geeignetes Signal mitgeschickt oder aus einer verlässlichen serverseitigen Quelle gelesen wird. Ein fehlendes Signal löst nicht automatisch einen Meta-CAPI-Aufruf aus: Entscheidend sind die eingerichteten Tags und Auslöser.

Das folgende Beispiel überträgt die dienstbezogene Meta-Freigabe aus Usercentrics als Ereignisparameter. Google Consent Mode bleibt für Google-Tags separat eingerichtet. Das Beispiel ist eine technische Sperrlogik und kein Nachweis der rechtlichen Zulässigkeit einer Datenverarbeitung.

1. Voraussetzungen und eindeutiger Status

Vorausgesetzt sind ein funktionierender Web- und Server-Container, ein GA4-Client im Server-Container sowie eine Usercentrics-Integration mit dokumentierten Consent-Ereignissen. Die Datenstruktur hängt von der CMP-Version und Einbindung ab. Im Web-Preview muss deshalb zuerst das tatsächliche Ereignis mit dem exakten Namen des Meta-Dienstes geprüft werden. Ein beliebig benannter Data-Layer-Schlüssel funktioniert nicht automatisch.

Eine Data-Layer-Variable {{UC - Meta Consent}} liest diesen dienstbezogenen Wert; der Rückfallwert ist false. Bei einer Integration über Window Events muss zuvor eine passende Übertragung in die Data Layer bestehen. Das folgende Beispiel für eine benutzerdefinierte JavaScript-Variable vereinheitlicht ausschließlich bestätigte Wahrwerte:

function () {
  var value = {{UC - Meta Consent}};
  return value === true || value === 'true' ? 'granted' : 'denied';
}

Der Variablenname lautet hier {{Meta Consent State}}. Fehlende Werte, Zahlen und andere Zeichenketten ergeben denied. Die beiden Ausgabewerte sind eine eigene Konvention dieses Beispiels, keine eingebauten Meta- oder Google-Consent-Parameter.

2. Browser-Tags und Transport konfigurieren

1. Das Meta-Pixel-Initialisierungstag erhält einen passenden Consent-Ereignisauslöser und die Bedingung {{Meta Consent State}} equals granted. Usercentrics dokumentiert hierfür je Einbindung Ereignisse wie consent_status beziehungsweise entsprechende Varianten. Der konkrete Ereignisname wird im Preview geprüft.
2. Weitere Meta-Ereignisse, beispielsweise ein Kauf, benötigen dieselbe dienstbezogene Freigabe an ihrem jeweiligen Ereignisauslöser. Ein Initialisierungstrigger allein schützt nicht sämtliche späteren Tags.
3. Der Google-Tag-Transport wird auf den eigenen Tagging-Server konfiguriert. An jedem relevanten GA4-Ereignis steht der Parameter meta_consent_state mit dem Wert {{Meta Consent State}}. Gemeinsam genutzte Ereigniseinstellungen können Wiederholungen vermeiden; die tatsächliche Vererbung ist je Ereignis zu kontrollieren.

Google-Consent-Signale sind kein Ersatz für die dienstbezogene Meta-Auswahl. Auch der Transport selbst muss zum gewählten Consent-Konzept passen: Bei Basic Consent Mode kann ein nicht erlaubtes Analytics-Tag vollständig ausbleiben. Dann erreicht auch der angehängte Meta-Parameter den Server nicht. Eine Meta-Freigabe allein rechtfertigt keine pauschale Freigabe des GA4-Transports.

Eine bereits geladene Pixel-Bibliothek wird durch einen später gesperrten GTM-Auslöser nicht entladen. Automatische Pixel-Ereignisse und weitere Einbindungen benötigen deshalb eine eigene Kontrolle. Beim Widerruf muss die verwendete CMP-/Pixel-Integration auch den Zustand der geladenen Bibliothek aktualisieren; die Meta-Vorlage unterstützt dafür grant/revoke. Der dafür nötige Zustandswechsel darf nicht selbst an einer „nur bei granted“-Regel scheitern.

3. Serverseitigen Freigabeauslöser setzen

Eine Variable vom Typ Event Data mit dem Key Path meta_consent_state liest den angekommenen Wert. Der GA4-Client muss den Parameter tatsächlich in das Ereignis übernehmen; die Event-Data-Ansicht zeigt das Ergebnis.

Der Meta-CAPI-Auslöser verlangt gleichzeitig den erwarteten Client, ein ausdrücklich vorgesehenes Ereignis und meta_consent_state equals granted. Der Client-Name muss dem konfigurierten Namen entsprechen. Für page_view und purchase sind getrennte Regeln oder eine präzise Ereignisliste sinnvoll; .* erfasst sämtliche Ereignisse, nicht nur E-Commerce.

Dieser Auslöser wird als auslösender Trigger am Meta-CAPI-Tag eingetragen. Das ist keine blockierende Ausnahme: Eine Ausnahme mit der Bedingung „granted“ würde gerade erlaubte Vorgänge sperren. Andere, weiter gefasste auslösende Trigger müssen entfernt oder entsprechend eingeschränkt sein. Fehlend, denied und unerwartete Werte erfüllen die Freigabebedingung nicht.

4. Datenfluss begrenzen und prüfen

Ein Transportparameter muss nicht bei sämtlichen Empfängern landen. Eine gezielt auf das GA4-Tag angewandte sGTM-Transformation vom Typ Exclude parameters kann meta_consent_state vor der Weiterleitung an Google entfernen. Die Meta-Auswertung darf dadurch nicht versehentlich den benötigten Wert verlieren. Eine fehlende Registrierung als benutzerdefinierte Dimension verhindert keine Übertragung.

Die Prüfung umfasst Web- und Server-Preview, Variablenwerte sowie die tatsächlich ausgehenden Requests. Bereits versandte Ereignisse werden durch einen späteren Widerruf nicht zurückgeholt. Ein frisch gewährter Consent ist außerdem kein Anlass, zuvor gesperrte Ereignisse ungeprüft nachzusenden.

Quellen und Stand

2026-10-24

• Google: server-side consent mode
• Google: event transport and event data
• Google: transformations
• Usercentrics: consent-aware GTM tags
• Usercentrics: consent events for third-party systems
• Usercentrics: CMP v2 event structure
• Meta: Pixel template consent controls