Was der gcd-Parameter bedeutet und was er belegt, das gcs nicht kann

Alle Beiträge

gcd ist ein Parameter in den Requests, die Googles Tags senden, und er trägt das ganze Consent-Bild: alle vier Consent-Mode-Signale in einem String, wobei jede Position festhält, was der Standardwert war und worauf ein Update ihn geändert hat. Genau das belegt er, was gcs nicht kann. gcs meldet, wo zwei Signale gelandet sind. gcd sagt Ihnen für alle vier, ob überhaupt je ein Standardwert gesetzt war. Google dokumentiert ihn nicht, und das ist die andere Hälfte dieses Beitrags.

Warum gibt es überhaupt einen zweiten Parameter?

Wenn Sie schon einmal ein Consent-Setup im Netzwerk-Panel debuggt haben, kennen Sie gcs. Der Parameter ist kurz, leicht zu lesen und beantwortet eine Frage: War Speichern in dem Moment, als dieser Hit die Seite verließ, erlaubt? G100 für beides abgelehnt, G111 für beides erteilt, die gemischten Zustände dazwischen und G1-- für ein Tag, das ganz ohne Consent-Status ausgelöst hat. Wir nutzen ihn ständig, die Methode beschreiben wir in So prüfen Sie, ob Ihr Banner das Consent-Mode-v2-Signal sendet.

Er hat zwei Grenzen, und sie sind der Grund für diesen Beitrag. Er deckt nur ad_storage und analytics_storage ab, die zwei mit Version zwei eingeführten Signale, beide in Googles Übersicht zu Consent Mode aufgeführt, fehlen also einfach. Und für das Paar, das er abdeckt, meldet er ein Ergebnis ohne Vorgeschichte. Ein Signal, das abgelehnt ist, weil jemand es abgelehnt hat, sieht daher fast genauso aus wie eines, das abgelehnt ist, weil es niemand konfiguriert hat.

Beide Fehler zeigen sich später als fehlende Daten, und nur einer davon ist die Entscheidung des Besuchers. In gcd steckt genau dieser Unterschied.

So ist der String aufgebaut

Der Wert beginnt mit 11 und wechselt dann für jedes Signal einmal zwischen einer Trennziffer und einem Buchstaben, bevor eine Ziffer ihn abschließt. Die vier Buchstaben stehen der Reihe nach für ad_storage, analytics_storage, ad_user_data und ad_personalization. Die Buchstaben sind die ganze Botschaft.

Jeder Buchstabe beantwortet zwei Fragen auf einmal, und genau hier lohnt sich sorgfältiges Lesen. Er hält fest, ob vor dem Auslösen des Tags ein Standardwert gesetzt war und ob danach ein Update kam. Ein einziges Zeichen kann also sagen, dass ein Signal abgelehnt begann und erteilt wurde, als der Besucher zustimmte, oder dass es nie Teil Ihrer Consent-Mode-Konfiguration war.

Schritt für Schritt lesen

1. Einen Request eines Google-Tags erfassen

   Öffnen Sie das Netzwerk-Panel, filtern Sie nach dem collect-Endpunkt und laden Sie die Seite in einer frischen Sitzung. Requests eines aktuellen Google-Tags enthalten gcd, und zwar unabhängig davon, ob Consent Mode konfiguriert ist. Ein normaler Seitenaufruf reicht also meist, um einen zu erzeugen. Ältere oder selbst gebaute Integrationen senden ihn eventuell nicht, und schon das Fehlen ist ein Befund.

2. Den String an den Trennzeichen aufteilen

   Der Wert beginnt mit 11 und wechselt dann zwischen einer Trennziffer und einem Signalbuchstaben. Die vier Buchstaben stehen der Reihe nach für ad_storage, analytics_storage, ad_user_data und ad_personalization. Lesen Sie die Buchstaben; die Ziffern sind Struktur, kein Status.

3. Übersetzen Sie jeden Buchstaben in Standardwert und Update

   l bedeutet, dass das Signal nie über Consent Mode gesetzt wurde. p heißt standardmäßig abgelehnt ohne Update, q standardmäßig abgelehnt und auch nach einem Update abgelehnt. t heißt standardmäßig erteilt ohne Update, v standardmäßig erteilt und auch nach einem Update. r heißt standardmäßig abgelehnt, dann erteilt, u standardmäßig erteilt, dann abgelehnt. m heißt durch ein Update abgelehnt ohne vorherigen Standardwert, n durch ein Update erteilt ohne vorherigen Standardwert.

4. Werte ohne Standardwert als Anbindungsfehler lesen

   l, m und n sagen alle, dass vor dem Tag etwas gefehlt hat. l bedeutet, dass das Signal nie konfiguriert wurde. m und n bedeuten, dass ein Update für ein Signal ohne Standardwert kam. Das ist der Reihenfolgefehler: Das Tag durfte schon laufen, bevor die Einwilligung erklärt war.

5. Bestätigen Sie es an einer dokumentierten Stelle, bevor Sie etwas ändern

   Nehmen Sie die Hypothese aus dem String mit in Tag Assistant oder die Consent-Ansicht Ihres Tag Managers und prüfen Sie sie dort. Diese Oberfläche dokumentiert Google, und nach ihr sollten Sie handeln.

Was sagt Ihnen jeder Buchstabe wirklich?

Die neun nach dem zu gruppieren, was sie belegen, ist sinnvoller, als sie auswendig zu lernen. Drei beschreiben ein Signal, das vor dem Tag keinen Standardwert hatte, und genau bei diesen müssen Sie handeln. Nach l sollten Sie zuerst suchen: Das Signal wurde nie über Consent Mode gesetzt. Das ist ein anderer Fehler, als wenn jemand etwas ablehnt, und er kommt häufig bei Installationen vor, die älter als Version zwei sind und noch das ursprüngliche Paar senden. Ein l an der Position ad_user_data oder ad_personalization beendet die Untersuchung meist, denn am Banner ist nichts kaputt.

m und n bedeuten, dass ein Update ein Signal ohne Standardwert erreicht hat. Das ist ein Fehler in der Reihenfolge, nicht in der Zuordnung: Das Tag durfte laufen, bevor die Einwilligung erklärt war. Wie Sie das verhindern, steht in Warum Tags auslösen, bevor das Cookie-Banner lädt. Die übrigen sechs beschreiben ein Signal, das konfiguriert war und dann einem Weg gefolgt ist. Das sind gesunde Werte, auch wenn die Antwort eine Ablehnung ist.

Die Warnung, die immer dazugehört

Google veröffentlicht gcd nicht als verbindliche Spezifikation. Es ist ein interner Parameter, seine Codierung kann sich ohne Ankündigung ändern, und keine Version dieser Decodierung übersteht garantiert ein Tag-Release. Das gehört hierher und nicht in eine Fußnote: Eine Decodierung ohne Ablaufdatum macht aus einer Debugging-Hilfe eine falsche Gewissheit.

Unsere Arbeitsregel ist deshalb eng. Nutzen Sie gcd, um innerhalb einer einzelnen Sitzung eine Hypothese aufzustellen, wenn etwas fehlt und Sie noch nicht wissen, warum. Bestätigen Sie sie an einer Stelle, die Google dokumentiert, etwa in der Consent-Übersicht von Tag Manager, bevor Sie etwas ändern, und bauen Sie nie ein Monitoring auf dem String auf: Ein Parser, der einen undokumentierten Parameter liest, ist kein Monitoring. Er ist ein Ausfall, der auf eine Release Note wartet, die niemand verschickt hat.

So eingesetzt hat er seinen Platz verdient, wegen der einen Sache, die keine dokumentierte Oberfläche so schnell liefert: ein einziges Zeichen in einem Request, den Sie schon offen haben, das sagt, ob ein Signal abgelehnt oder nie angebunden wurde.

Velo sendet alle vier Signale aus einer Kategoriezuordnung, die Sie auf einem einzigen Bildschirm lesen können, und der Status, den ein Besucher gewählt hat, ist der Status, der die Seite verlässt. Deshalb ist so ein String bei uns langweilig zu lesen. Wie das verdrahtet ist, steht auf der Produktseite.