CookiePass und Google Consent Mode: Was ein Consent-Banner mit Ihrem Traffic macht

Consent Mode ist kein Ein/Aus-Schalter für Ihre Tags. Der Google-Tag feuert weiterhin auf jeder Seite; was sich ändert, ist ein Kennzeichen auf jedem Treffer und das, was Google deshalb damit tut. Ist analytics_storage verweigert, setzt der Tag keine Cookies, behält keine Client-ID zwischen Seiten und sendet einen sogenannten cookielosen Ping – einen Treffer, den GA4 für Modellierung nutzt, nicht für die Berichte, die Sie lesen.

Das Kennzeichen ist ein Query-Parameter namens gcs: zwei Buchstaben und zwei Ziffern. Die erste Ziffer steht für ad_storage, die zweite für analytics_storage – 1 für erteilt, 0 für verweigert.

gcs=G100   ad_storage denied,  analytics_storage denied
gcs=G101   ad_storage denied,  analytics_storage granted
gcs=G110   ad_storage granted, analytics_storage denied
gcs=G111   both granted
(no gcs)   no Consent Mode on the page — treated as granted

Die letzte Zeile übersehen die meisten. Eine Seite ganz ohne Consent Mode sendet kein gcs, und Google behandelt jeden Treffer von ihr als eingewilligt. Ein Banner mit Consent Mode reduziert also nicht, was gesendet wird – es beginnt, die Wahrheit darüber zu sagen.

Consent Mode v2 verlangt eine Reihenfolge, keine Einstellung. Der Standardzustand muss deklariert sein, bevor der Google-Tag lädt – verweigert für alle, die noch nicht gewählt haben –, ein Update muss in dem Moment folgen, in dem der Besucher entscheidet, und bei jedem weiteren Besuch wiederhergestellt werden. Stimmt die Reihenfolge nicht, geht der erste Seitenaufruf jeder Sitzung als eingewilligt hinaus, bevor das Banner überhaupt gerendert ist.

Diese Sequenz erzeugt CookiePass aus dem eigenen Skript, sodass nichts davon in Ihrem Tag-Manager-Container landet:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// …the visitor accepts…
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

Das ist die ganze Integration. Googles eigene Tags respektieren den Einwilligungsstatus automatisch – auch die Tags, die SignalHost in Ihren Web-Container veröffentlicht. Nichts in Ihrem Server-Container braucht eine Consent-Bedingung; wer eine von Hand ergänzt, hat am Ende einen gesperrten Google-Tag neben ungesperrten Event-Tags, die Daten direkt an Google senden.

Jeder Treffer nimmt weiter denselben Weg: Der Browser sendet ihn an Ihren eigenen Hostnamen, die Edge leitet ihn an Ihren Server-Container weiter, und der Container schickt ihn an GA4. Der Unterschied liegt ausschließlich in der Nutzlast.

• Vor der Entscheidung: gcs=G100 auf jedem Treffer, kein _ga-Cookie und auf jeder Seite eine neue Client-ID. GA4 erhält einen cookielosen Ping; Ihr Container zählt einen Request.
• Nach Akzeptieren: gcs=G111, Cookies werden gesetzt, die Sitzung fügt sich zusammen. Ab hier sind es die Treffer, aus denen Ihre Berichte bestehen.
• Nach Ablehnen: gcs=G100 auf jeder Seite, solange die Entscheidung gilt. Ereignisse der erweiterten Messungen – scroll, file_download und die übrigen – folgen derselben Regel wie page_view.

Deshalb zeigt die Container-Seite mit Banner zwei Zahlen pro Ereignis: die Treffer mit Analytics-Einwilligung – das, was Analytics als Nutzer und Sitzungen ausweist – und nach dem Schrägstrich alles, was der Container weitergeleitet hat. session_start und first_visit tauchen in keiner Spalte auf; Analytics leitet sie aus Flags am ersten page_view ab, statt sie als Ereignisse zu empfangen.

Rechnen Sie damit, dass die beiden Spalten auseinanderliegen – und damit, dass die Lücke die nützlichste Zahl auf der Seite ist.

• Analytics meldet weniger Nutzer und Sitzungen, als Ihr Container Requests zählt. Die Differenz ist der Anteil der Besucher, die abgelehnt oder nie geantwortet haben – Ihre Einwilligungsrate, gemessen statt geschätzt.
• GA4 kann einen Teil dieser Lücke per Verhaltensmodellierung füllen, sobald die Property Googles Schwellen erreicht. Modellierte Daten erscheinen in Berichten; in Ihrem Container erscheinen sie nie, weil sie nie gesendet werden.
• Mit verweigertem ad_storage hat das Google-Ads-Conversion-Tracking nichts zuzuordnen und der Conversion Linker nichts zu verknüpfen. Ein Server-Container ändert das nicht – und sollte es auch nicht: First-Party heißt nicht einwilligungsfrei.
• Das Design des Banners ist jetzt eine Messentscheidung. Eine Einwilligungsrate von 60 % und eine von 85 % sind dieselbe Website mit anderen Buttons – und die Lücke zwischen den Spalten zeigt Ihnen, welche Sie haben.

• Laden Sie das Consent-Skript vor dem Google-Tag. Der Standardzustand muss vor dem ersten Treffer existieren.
• Öffnen Sie eine Seite mit unbeantwortetem Banner und lesen Sie gcs an einem /g/collect-Request im Netzwerk-Panel des Browsers ab. Dort sollte G100 stehen.
• Akzeptieren Sie und lesen Sie es auf der nächsten Seite erneut ab. Dort sollte G111 stehen.
• Fügen Sie im Server-Container nirgends Consent-Trigger hinzu. Der Web-Tag trägt den Status bereits.
• Kommen Sie einen Tag später auf die Container-Seite zurück und lesen Sie das Zahlenpaar an page_view ab. Die erste geteilt durch die zweite ist Ihre Einwilligungsrate.

Wir haben uns für CookiePass entschieden, weil es genau die obige Sequenz umsetzt, an einem Nachmittag auf dieser Website live war und das Banner die Farben der Website annehmen lässt. Die Zahlen aus dem vorigen Abschnitt sind der Beleg, dass es funktioniert.