Consent-Status an Server-Side GTM übergeben
Teil 4 von 4 der Reihe Einwilligung richtig verdrahten

Inhalt
Die Implementierung von serverseitigem Tracking (Server-Side GTM) ist ein entscheidender Schritt in Richtung Datenzuverlässigkeit. Die Server-Umgebung weist jedoch einen architektonischen „Schwachpunkt“ auf: Es besteht kein direkter Zugriff auf den Browser des Nutzers, dessen Cookies oder das Banner der Consent Management Platform (CMP).
Wenn die Zustimmung zum Tracking im Usercentrics-Banner verweigert wird, erhält der Server diese Information nicht automatisch. Erfolgt eine Datenübertragung ohne diesen Consent-Status an die Meta Conversions API (CAPI), wird ein Payload an Facebook gesendet, was gegen DSGVO- und DMA-Vorgaben verstößt.
Die architektonische Aufgabe besteht darin, eine „Brücke“ zu bauen, welche die Entscheidung zur Einwilligung (Consent State) vom Browser (Client GTM) direkt in den Server-Container (Server GTM) überträgt. Hier ist eine technische Schritt-für-Schritt-Anleitung mit Usercentrics, Meta Pixel und Meta CAPI.
1. Die Logik: Funktionsweise der „Brücke“
Anstatt sich ausschließlich auf den integrierten Google Consent Mode zu verlassen (dessen Debugging auf Server-Ebene bei Nicht-Google-Tags komplex sein kann), wird eine zuverlässigere Methode angewandt: Die explizite Übertragung der Nutzerentscheidung als Ereignisparameter (Event Parameter) im Transport-Tag (z. B. GA4).
- Consent: Usercentrics speichert die Wahl des Nutzers.
- Client GTM: Das klassische Meta Pixel wird blockiert, falls keine Zustimmung vorliegt. Der Consent-Status wird erfasst und als Parameter an das Tag angehängt, das Daten an den Server (ssGTM) sendet.
- Server GTM: Der Parameter wird als Ereignisdaten (Event Data) empfangen. Ein Trigger wird erstellt, der das Meta CAPI-Tag nur dann ausführt, wenn der Consent-Parameter den Wert „true“ hat.
2. Client-GTM-Konfiguration (Browser)
Voraussetzung ist eine implementierte Usercentrics CMP, die Ereignisse in das DataLayer pusht.
Schritt A: Die Variable für den Consent-Check
Usercentrics bietet native Möglichkeiten oder erlaubt das Auslesen des Status eines bestimmten Datenverarbeitungsdienstes.
- Erstellung einer Variable vom Typ „Data Layer Variable“.
- Eingabe des Key-Namens, unter dem Usercentrics den Consent für Meta speichert. (Bei Verwendung der offiziellen Usercentrics-Vorlage erfolgt dies oft über benutzerdefiniertes JS, das das Usercentrics-Objekt prüft). Nennen wir die Variable {{UC – Meta Consent}}. Diese muss „true“ oder „false“ zurückgeben.
Schritt B: Absicherung des Meta Pixels (Client-Side)
Das browserbasierte Meta Pixel muss die Nutzerentscheidung respektieren.
- Meta Pixel Tag öffnen.
- Bereich „Triggering“ aufrufen.
- Neuen Trigger vom Typ „Benutzerdefiniertes Ereignis“ (Custom Event) erstellen.
- Ereignisname auf
consent_statussetzen (oder das Ereignis, das Pageviews nach dem Laden von Usercentrics auslöst). - „Einige benutzerdefinierte Ereignisse“ auswählen und die Bedingung hinzufügen: {{UC – Meta Consent}} entspricht „true“.
- (Optional) Bei Nutzung des Google Consent Mode v2 können in den „Erweiterten Einstellungen“ des Tags unter „Consent Settings“ zusätzlich
ad_storageundad_user_dataerforderlich sein.
Schritt C: Übertragung des Consents zum Server (Transport-Tag)
Daten werden meist über ein GA4-Tag an ssGTM gesendet. Der Consent muss an diesen Request angehängt werden.
- Haupt-Transport-Tag öffnen (z. B. Google Tag oder GA4-Konfiguration), bei dem das Routing auf die Server-URL (z. B.
sgtm.ihredomain.de) eingestellt ist. - Bereich „Ereignisparameter“ (Event Parameters) aufrufen.
- Neuen Parameter hinzufügen:
meta_consent_state. - Wert als Variable festlegen: {{UC – Meta Consent}}.
- Speichern und Client-GTM veröffentlichen. Jeder Request an den Server enthält nun das Flag, ob Meta-Tracking erlaubt wurde.
3. Server-Side-GTM-Konfiguration (Server)
Im Server-Container wird der übertragene Parameter empfangen, um das Meta CAPI-Tag zu steuern.
Schritt A: Empfang des Parameters (Event Data Variable)
- Im ssGTM-Container zum Tab „Variablen“ navigieren.
- Neue Variable vom Typ „Ereignisdaten“ (Event Data) erstellen.
- Im Feld „Key Path“ den exakten Namen aus dem Client-GTM eintragen:
meta_consent_state. - Variable als {{EventData – Meta Consent}} speichern.
Schritt B: Erstellung des blockierenden Triggers für Meta CAPI
- Tab „Trigger“ aufrufen.
- Neuen Trigger vom Typ „Benutzerdefiniertes Ereignis“ erstellen.
- Ereignisname:
.*(Regex-Abgleich aktivieren, falls für alle E-Commerce-Events gewünscht) oder ein spezifisches Event wiepage_view. - „Einige benutzerdefinierte Ereignisse“ auswählen.
- Bedingung: {{EventData – Meta Consent}} entspricht „true“.
- (Optional) Bedingung hinzufügen: Client Name entspricht „GA4“.
- Trigger als „Trigger – Meta CAPI – Consent Granted“ speichern.
Schritt C: Zuweisung des Triggers zum Meta CAPI-Tag
- Meta Conversions API-Tag im ssGTM öffnen.
- Standard-Trigger (z. B. „All Events“) entfernen.
- Neuen Trigger „Trigger – Meta CAPI – Consent Granted“ hinzufügen.
- Tag speichern und über den „Preview“-Modus testen.
4. Verifizierung der Implementierung
Um die Rechtskonformität sicherzustellen, sollte folgender Test durchgeführt werden:
- Website im Inkognito-Modus besuchen. Im Usercentrics-Banner alle Zustimmungen ablehnen.
- Client-GTM-Debugger prüfen: Das Meta Pixel darf nicht ausgelöst werden (der Trigger muss ein rotes Kreuz bei der Bedingung {{UC – Meta Consent}} == true zeigen).
- Request an ssGTM prüfen: In der Event-Data-Vorschau des Server-GTM muss der Parameter
meta_consent_stateden Wertfalseaufweisen. - Das Meta CAPI-Tag auf dem Server darf nicht ausgelöst werden. Die Umgebung ist somit sicher und rechtskonform.
Zusammenfassung
Die Übertragung des Consent-Status zwischen Browser und Server bildet das Fundament moderner Daten-Architektur. Die explizite Definition des Parameters meta_consent_state im Transport-Tag bietet volle Kontrolle und Transparenz darüber, welche Daten wann an externe Anbieter gesendet werden. Dies garantiert, dass die Architektur nicht nur technisch einwandfrei, sondern auch vollständig konform mit Usercentrics-Datenschutzrichtlinien, DSGVO und DMA ist.
Fragen und Antworten
Bedeutet ein fehlender meta_consent_state auf dem Server etwas anderes als ein ausdrückliches false?
In der Ursache bedeutet beides etwas anderes, in der Wirkung dasselbe, und diese beiden Ebenen auseinanderzuhalten, lohnt sich.
Der Trigger verlangt, dass der Parameter „true“ entspricht; ein fehlender Wert und ein ausdrückliches false fallen also gleichermaßen durch. Das ist das richtige Verhalten und der Grund, warum der Aufbau von vornherein sicher ist: Was der Browser dem Server nicht mitteilen konnte, führt zu keinem CAPI-Aufruf. Die Ursachen der beiden Fälle unterscheiden sich aber. Ein ausdrückliches false heißt, dass die CMP geantwortet hat und die Antwort Nein lautete. Ein fehlender Parameter heißt, dass das Transport-Tag ausgelöst wurde, ohne dass die Variable einen Wert hatte, meist weil das Tag lief, bevor die CMP ihren Status geschrieben hatte, oder weil sich der Name des Schlüssels im DataLayer geändert hat.
Der zweite Fall kostet unbemerkt Conversions, denn diese Requests tragen keinen Consent-Status, auch bei Nutzern, die einen Moment später zugestimmt haben: Der Request ist dann schon unterwegs. Der Nutzen der Unterscheidung liegt deshalb in der Diagnose. Eine Zählung der Requests je Zustand auf dem Server (true, false, fehlend) macht aus einem unsichtbaren Reihenfolgeproblem eine Zahl, und ein wachsender Anteil fehlender Werte zeigt an, dass das Tag vor dem Banner auslöst.
Einwilligung richtig verdrahten
- Google Consent Mode v2 implementieren
- Wie cookielose Pings im Google Consent Mode funktionieren
- GA4 Consent Mode v2: Der gcd-Parameter, CMP-Wettläufe und serverseitiges Debugging
- Consent-Status an Server-Side GTM übergeben