Das Consent-Signal an einen Container für Server-side Tagging übergeben

Alle Beiträge

Konfigurieren Sie Consent Mode v2 in Ihrem Web-Container in GTM so, dass der Status gesetzt ist, bevor ein Tag feuert. Google hängt ihn dann als gcs-Parameter an die Anfrage, die es weiterschickt, nichts muss doppelt gesendet werden. Lesen Sie den Status im Server-Container aus, binden Sie jedes Anbieter-Tag daran und prüfen Sie, dass Ihr GA4-Client nicht stillschweigend eine Kennung wiederherstellt.

Das Signal nimmt keinen eigenen Weg

Der typische Fehler beim Aufbau: Die Einwilligung wird so behandelt, als müsse man sie dem Server-Container separat mitteilen, über eine zweite Integration. Der vom Besucher gewählte Status hängt aber an derselben Anfrage, die das Event transportiert. Ist der Web-Container richtig eingerichtet, hat die Serverseite ihn also schon. Googles Anleitung zu Consent Mode mit serverseitigem Tag Manager beschreibt dieselbe Aufteilung: Der Web-Container erfasst die Einwilligung, der Server-Container lässt Tags entsprechend feuern.

Das hat eine Konsequenz, die man klar aussprechen sollte, weil sie bestimmt, wo Sie suchen, wenn etwas kaputtgeht: Ein Server-Container kann kein Einwilligungsproblem reparieren. Er hat kein Banner und keinen Besucher, den er fragen könnte. Hat der Status den Browser nie korrekt verlassen, prüft jede Sperre, die Sie dort bauen, ein leeres Feld. Die Pflichtenseite dazu behandelt Brauchen Sie mit Server-side Tagging noch ein Cookie-Banner?

Das Consent-Signal an einen Container für Server-side Tagging übergeben

1. Consent Mode v2 im Web-Container setzen, nicht im Server-Container

   Die Einwilligung wird im Browser entschieden und in Ihrem Web-Container in GTM konfiguriert: Die CMP setzt für jedes nicht notwendige Signal einen „denied“-Standardwert, bevor ein Tag initialisiert wird, und aktualisiert ihn, wenn der Besucher entscheidet. Der Server-Container hat kein Banner und keinen Besucher, den er fragen könnte. Er ist also nie der Ort, um ein Einwilligungsproblem zu beheben.

2. Prüfen, ob der Status wirklich in der ausgehenden Anfrage steckt

   Suchen Sie in einem privaten Fenster die Anfrage, die Ihre Google-Tags an den Server-Container senden. Sie sollte bereits einen gcs-Parameter enthalten: G100, wenn beide Speichertypen abgelehnt sind, G111, wenn beide erlaubt sind, G101 und G110 für gemischte Fälle. G1-- bedeutet, dass das Tag ohne Consent-Status gefeuert hat und alles danach nur rät.

3. Consent-Status im Server-Container auslesen

   Öffnen Sie die Vorschau des Server-Containers und sehen Sie sich ein eingehendes Event an. Der Status kommt mit der Anfrage an und lässt sich dort auslesen. Erst dadurch kann ein Tag entscheiden, ob es feuert. Legen Sie benannte Variablen für die Signale an, auf die Sie prüfen, statt in jedem Tag Rohfelder zu verwenden.

4. Jedes Anbieter-Tag an das Signal binden, das es wirklich braucht

   Jedes Tag erhält eine Auslösebedingung, die an die richtige Kategorie gebunden ist, und die Kategorien sind nicht austauschbar. Analytics-Tags prüfen das Analytics-Signal. Werbeziele, darunter eine Conversions API, prüfen die Werbesignale, und Version 2 hat zwei hinzugefügt, auf die ältere Setups nie prüfen. Ein Tag ohne Bedingung feuert bei allem, auch bei Ablehnungen.

5. Prüfen, was Ihr GA4-Client mit Cookies macht

   Der Schritt, den keine Anleitung enthält und der die anderen vier stillschweigend aushebelt. Der GA4-Client hat eine Cookie-Einstellung. Steht sie auf „Server Managed“, erzeugt der Client eine eigene First-Party-Kennung oder stellt sie wieder her und kann so eine dauerhafte ID an einen Ping hängen, der anonym sein sollte. Stellen Sie auf „JavaScript Managed“ um, damit der Client die Kennung nutzt, die der Browser gesendet hat, und sonst nichts.

6. Mit einer Ablehnung prüfen, nicht mit einer Zustimmung

   Alle testen per Zustimmung, weil dort Daten auftauchen. Lehnen Sie stattdessen ab, in einem sauberen privaten Fenster, und verfolgen Sie dieses eine Event: den Status in der Anfrage, den Status im Container, welche Tags gefeuert haben und welche Kennung an jeden Anbieter ging.

Der Fehler, der ein korrektes Setup überlebt

Die Schritte eins bis vier deckt jede Anleitung ab, und ein Setup, das sie besteht, wirkt fertig. Schritt fünf finden wir immer wieder in sorgfältig gebauten Containern, und er sieht überhaupt nicht nach einem Consent-Fehler aus.

So sieht es aus: Das Banner stimmt, der Standardwert ist „denied“, der Status kommt unversehrt im Container an, und die Anbieter-Tags sind korrekt gesperrt, sodass ein abgelehntes Event kein Werbe-Tag auslöst. Alles, was Sie testen würden, besteht. Gleichzeitig verwaltet der GA4-Client seine eigenen Cookies. Bei jeder Anfrage erzeugt er eine First-Party-Kennung oder stellt sie wieder her und schreibt sie ins Event. Ein Ping, der anonym rausgehen sollte, trägt plötzlich eine stabile ID.

Das Symptom deutet nie auf die Einwilligung. Es zeigt sich als leicht zu hohe Zahlen und als Sitzungen, die eigentlich nicht zugeordnet sein sollten, aber zugeordnet ankommen. Genau das haben wir in einer Debug-Sitzung an einem Live-Server-Container nachverfolgt, und die Lösung war eine einzige Einstellung. An der Sperrlogik hat sich nichts geändert, weil sie nie falsch war.

Die Lehre daraus gilt allgemein. Tags sperren und die Kennung kontrollieren sind zwei verschiedene Aufgaben. Eine Sperre entscheidet, ob eine Anfrage einen Anbieter erreicht. Eine Kennung entscheidet, ob dieser Anbieter erkennen kann, um wen es ging. Die Dokumentation behandelt das Erste und schweigt zum Zweiten. Ein Container kann sich also exakt an die Vorgaben halten und trotzdem Identitäten herausgeben.

Was die Verdrahtung bringt, wenn sie hält

Wie viel Traffic hinter dem Banner liegt, hängt von Ihren Regionen, Ihrer Zielgruppe und dem Design Ihres Banners ab. Messen Sie selbst: Lesen Sie die Einwilligungsrate in Ihrer CMP ab oder vergleichen Sie GA4-Sitzungen mit den Anfragen, die Ihr Server-Container erhält. Korrekte Verdrahtung liefert Google ein „denied“-Signal, aus dem es modellieren kann, sobald Ihre Property die Datenschwellen erreicht, und hält erlaubten Traffic sauber zugeordnet.

Was Sie gewinnen, kommt aus der Modellierung und aus sauber zugeordnetem erlaubtem Traffic, nie daraus, Menschen, die abgelehnt haben, stillschweigend wiederzuerkennen. Ein Container, der eine Kennung durchsickern lässt, schließt keine Lücke. Er erhebt Daten, die ihm verweigert wurden, und dass das Dashboard dadurch besser aussieht, ist genau das, was es verdeckt.

Kurz gesagt

Die Einwilligung wird im Browser entschieden und im Web-Container konfiguriert. Sie erreicht den Server mit der Anfrage selbst, in gcs, ohne zweite Integration. Lesen Sie sie dort aus, binden Sie jedes Anbieter-Tag an die Kategorie, die es braucht, und stellen Sie den GA4-Client so ein, dass er die vom Browser gesendete Kennung nutzt, statt selbst eine zu erzeugen. Belegen Sie das anschließend an einem abgelehnten Event. Das Vorgehen auf Browserseite steht in So prüfen Sie, ob Ihr Banner das Signal sendet, und welchen Modus Sie nutzen, klärt einfacher und erweiterter Consent Mode im Vergleich.

Velo setzt alle vier Signale mit einem einzigen Snippet, bevor Ihre Tags initialisiert werden. Das ist die vordere Hälfte des oben Beschriebenen. Wie das funktioniert, steht auf der Produktseite.

Wenn Sie den Container selbst aufbauen und nicht nur die Consent-Verdrahtung, finden Sie die vollständige Checkliste des Teams hinter Velo dazu, was ein produktives Server-side-Setup braucht, im Beitrag Server-side Tagging Best Practices für 2026 im Blog von Amplio Data.