GA4 Consent Mode v2: Der gcd-Parameter, CMP-Wettläufe und serverseitiges Debugging

gcd ist ein Diagnosehinweis in Google-Anfragen. Der Parameter ersetzt weder die Prüfung der Einwilligung noch die Kontrolle ausgehender Daten. Besonders bei einer asynchron geladenen Consent Management Platform (CMP) zählt die Reihenfolge: Ausgangszustand, gespeicherte Auswahl, Aktualisierung, Messereignis und tatsächliche Übertragung.

Vier Signale statt eines pauschalen Freigabewerts

Diese Signale haben unterschiedliche Aufgaben. Eine Analysefreigabe ist keine allgemeine Marketingfreigabe; ad_user_data erteilt insbesondere keine automatische Freigabe für Meta CAPI. Andere Empfänger und Zwecke benötigen eine eigene Zuordnung zur tatsächlich erfassten Auswahl.

Was gcs und gcd zeigen

Google beschreibt gcs als Transport der Zustände für ad_storage und analytics_storage. gcd enthält ausführlichere Consent-Informationen und wird auch ohne aktivierten Consent Mode übertragen. Die bloße Anwesenheit von gcd belegt deshalb keine korrekte Einrichtung.

Google weist ausdrücklich darauf hin, dass codierte HTTP-Felder veränderlich sind. Beobachtete Buchstabentabellen und feste Zeichenpositionen sind kein dauerhaft dokumentierter Schnittstellenvertrag. Eine Prüfung wie gcd.charAt(6) sollte daher keine Freigabeschranke für Datenweiterleitungen bilden. Auch ein scheinbar passender Wert bestätigt weder eine gültige Einwilligung noch einen vollständigen Verlauf aller Entscheidungen.

Einen CMP-Wettlauf nachvollziehbar prüfen

Ein früher Request mit anderem Consent-Muster als spätere Requests kann auf eine verzögerte Aktualisierung hinweisen. Eine normale spätere Zustimmung, unterschiedliche regionale Vorgaben oder eine teilweise Aktualisierung sind ebenfalls mögliche Erklärungen. Der Netzwerkvergleich allein beweist die Ursache nicht.

1. In einer neuen Tag-Assistant-Sitzung den frühesten Consent-Eintrag und alle vier Ausgangswerte prüfen.
2. Den Zeitpunkt der CMP-Initialisierung und eine vorhandene gespeicherte Auswahl dokumentieren. Eine gespeicherte Auswahl muss zum aktuellen Zweck- und Anbietermodell passen.
3. Beim Consent-Update die vier Werte und die zeitliche Position zum ersten Messereignis vergleichen.
4. Beim betroffenen Tag die Consent-Prüfungen und den Auslösegrund kontrollieren; anschließend die Browseranfrage zuordnen.
5. Den Ablauf mit neuer Sitzung, gespeicherter Ablehnung, gespeicherter Zustimmung, Teilzustimmung, Widerruf und langsamer CMP wiederholen. Regionale Varianten gesondert prüfen.

Ein nachvollziehbarer Befund lautet beispielsweise: Die CMP hatte eine passende gespeicherte Zustimmung, das Update erreichte den Consent-Zustand jedoch erst nach dem untersuchten Messereignis. Erst diese Zeitachse grenzt ein Reihenfolgeproblem von einer regulären späteren Entscheidung ab.

Reihenfolge korrigieren, Wartezeit begrenzen

Bei GTM gehört das Setzen der Ausgangswerte in ein geeignetes Consent-Template am Trigger Consent Initialization – All Pages. Für Templates sind setDefaultConsentState und updateConsentState vorgesehen. Ein dort verwendeter gtag('consent', ...)-Aufruf kann durch die Warteschlange zu spät verarbeitet werden. Ein früh gestartetes Template garantiert trotzdem nicht, dass eine anschließend asynchron geladene CMP bereits fertig ist.

Bei einer direkten gtag.js-Integration müssen die Ausgangswerte vor messenden config– oder event-Befehlen stehen. wait_for_update setzt eine begrenzte Wartefrist für ein Update. Der häufig gezeigte Wert 500 Millisekunden ist ein Beispiel, keine verlässliche Obergrenze für CMP-Ladezeiten. Nach Ablauf gelten die dann vorhandenen Consent-Zustände.

Ein dokumentiertes CMP-Ereignis kann Teil einer passenden Auslösestrategie sein. Ein frei erfundener Ereignisname oder ein zusätzlicher Pageview bei jeder Consent-Änderung kann dagegen Messungen verlieren oder doppelt senden. Auslösung, Wiederholung und Seitenwechsel müssen gemeinsam geprüft werden.

Basic und Advanced richtig unterscheiden

Im Basic Consent Mode werden die betreffenden Google-Tags bis zur erforderlichen Zustimmung blockiert. Im Advanced Consent Mode können geladene Google-Tags bei Ablehnung eingeschränkte Pings ohne die betreffenden Cookies senden. Deshalb bedeutet denied nicht automatisch „kein Netzwerkverkehr“. Falls ein Aufbau vor Zustimmung keinerlei entsprechende Übertragung erlauben soll, muss die tatsächliche Blockierung auf allen beteiligten Wegen geprüft werden.

Serverseitig bis zum Empfänger prüfen

Im dokumentierten Google-Aufbau verarbeitet ein GA4-Client die eingehende Anfrage im Server-Container; consentfähige Google-Tags berücksichtigen die transportierten Signale. Das Verhalten unterscheidet sich nach Ziel und Tag. Ein GA4-Request ist kein vorgeschriebener Datenträger für sämtliche anderen Server-Clients oder Drittanbieter.

Die Server-Vorschau muss deshalb die empfangene Anfrage, den zuständigen Client, das erzeugte Ereignis, die ausgelösten Tags und deren ausgehende Requests zusammen zeigen. Drittanbieter-Templates benötigen ausdrücklich geprüfte Regeln für den jeweiligen Empfänger und Zweck. Ein von außen geliefertes Consent-Feld ist zudem kein kryptografischer Einwilligungsnachweis.

Fehlende oder unverständliche Signale sollten als eigener Fehlerfall sichtbar bleiben. Eine Freigabe darf daraus nicht abgeleitet werden. Für erforderliche Nachweise eignen sich minimierte Angaben wie Testfall, Ereigniszeitpunkt, Tagversion, Auslöseentscheidung und Ziel; vollständige URLs oder Nutzerdaten gehören nicht ungeprüft in Diagnoseprotokolle.

Fragen und Antworten

Beweist ein fehlendes gcd eine Ablehnung?

Nein. Der Parameter kann in einem anderen Übertragungsweg fehlen. Herkunft, Client und erwartetes Datenformat müssen geklärt werden. Unbekannt und ausdrücklich abgelehnt sind unterschiedliche Diagnosezustände.

Reicht gcs als Nachweis, dass keine Cookies geschrieben wurden?

Nein. Der Parameter beschreibt übertragene Zustände. Cookie-Zugriffe und tatsächliche Requests müssen zusätzlich im Browser und gegebenenfalls am Server geprüft werden.

Garantiert Consent Mode Rechtskonformität?

Nein. Technische Signale ersetzen keine Prüfung der Einwilligung, Zwecke, Empfänger, Dateninhalte und Aufbewahrung. Eine erfolgreiche Testreihe belegt nur die geprüften Abläufe und Versionen.

Quellen

• Consent mode overview
• Troubleshoot consent mode with Tag Assistant
• Consent Mode implementation
• Create a consent mode template
• Implement consent mode with server-side Tag Manager
• gtag.js reference