Cookie-Banner mit Consent Mode v2 verbinden: Cookiebot, Usercentrics, Borlabs Cookie, Real Cookie Banner
Welche Einstellung in Cookiebot, Usercentrics, Borlabs Cookie und Real Cookie Banner die vier Consent-Signale erzeugt, wie Shopify das im Shop löst und wie du in zehn Minuten prüfst, ob die Signale bei Google ankommen.
Fabian Weiss Der Cookie-Banner läuft, aber niemand weiß, ob die vier Consent-Signale wirklich bei Google Analytics und Google Ads ankommen
Die dokumentierte Einstellung je Banner setzen, die Kategorien bewusst auf die Signale abbilden und jeden Fall im Netzwerk-Request prüfen
Der Banner ist da, die Signale vielleicht nicht
Ein Cookie-Banner auf der Seite heißt noch nicht, dass Google Analytics und Google Ads von der Einwilligung erfahren. Consent Mode v2 ist ein zweiter Kanal daneben: vier Signale, die dein Banner an die Google-Tags übergeben muss, einmal als Vorgabe vor der Entscheidung und einmal als Aktualisierung danach.
Genau dieser Kanal fehlt oft oder ist falsch verdrahtet. Dieser Leitfaden zeigt für Cookiebot, Usercentrics, Borlabs Cookie und Real Cookie Banner, welche Einstellung laut Herstellerdokumentation die Signale erzeugt, wie Shopify das im Shop löst und wie du in zehn Minuten prüfst, ob die Signale wirklich ankommen.
Die vier Signale in Kürze
Consent Mode v2 arbeitet mit vier Signalen, jedes kann granted oder denied sein:
| Signal | Steuert |
|---|---|
ad_storage | Speicherung für Werbung, zum Beispiel Conversion-Cookies |
ad_user_data | Ob Nutzerdaten zu Werbezwecken an Google gesendet werden dürfen |
ad_personalization | Ob die Daten für personalisierte Werbung genutzt werden dürfen |
analytics_storage | Speicherung für Analytics, zum Beispiel die GA4-Client-Kennung |
Erst setzt die Seite eine Vorgabe, bevor irgendein Google-Tag lädt:
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'wait_for_update': 500
});Nach der Entscheidung im Banner folgt die Aktualisierung:
gtag('consent', 'update', {
'ad_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted',
'analytics_storage': 'granted'
});Google schreibt in der Dokumentation zu Consent Mode vor, dass der Default-Befehl vor jedem Befehl kommt, der Messdaten sendet. Das ist der Punkt, an dem die meisten Banner-Integrationen kippen: Der Banner sendet zwar eine Aktualisierung, aber das Google-Tag war schneller.
Wie du die Signale grundsätzlich im Tag Manager einrichtest, steht im Leitfaden GA4 Consent Mode v2 einrichten. Ob deine Tags vor der Entscheidung gar nichts oder cookielose Signale senden sollen, klärt Consent Mode Basic oder Advanced.
Was sich am 15. Juni 2026 geändert hat
Bis Juni 2026 gab es zwei Schalter für die Werbedaten aus Google Analytics: das Consent-Signal ad_storage und den Google-Signals-Schalter in der GA4-Property.
Laut Google Analytics Hilfe stellt Google Analytics seit dem 15. Juni 2026 auf Consent Mode als alleinige Steuerung um. Der Google-Signals-Schalter regelt seitdem nur noch, ob Analytics-Daten für Berichte mit angemeldeten Nutzern verknüpft werden. Welche Werbedaten von Google Analytics an das verknüpfte Google-Ads-Konto gehen, bestimmt allein das Consent-Signal.
Für dich heißt das: Die Abbildung deiner Banner-Kategorien auf ad_storage, ad_user_data und ad_personalization ist jetzt der einzige Schalter. Ein ausgeschaltetes Google Signals schützt nicht mehr. Cookiebot beschreibt in der eigenen Dokumentation die Folge für Konten mit ausgeschaltetem Google Signals: Google Ads beginnt, Werbe-Cookies zu nutzen, sobald Nutzer ad_storage zustimmen. Wer das nicht will, setzt die Vorgabe für ad_storage auf denied.
Cookiebot
Cookiebot ist auf der Partnerseite von Google als zertifizierte CMP gelistet. Laut Cookiebot-Dokumentation sendet das Cookiebot-Skript die Aktualisierung nach der Einwilligung automatisch. Die Vorgabe musst du selbst sicherstellen, auf einem von drei Wegen je nach Einbindung.
Einbindung über den Google Tag Manager, beschrieben in der GTM-Anleitung von Cookiebot:
- In der Vorlagengalerie des Tag Managers die Vorlage “Cookiebot CMP” in den Arbeitsbereich holen.
- Ein neues Tag vom Typ Cookiebot CMP anlegen und im Feld “Cookiebot ID” die Domain Group ID aus dem Cookiebot-Konto eintragen.
- Als Trigger “Consent Initialization - All Pages” wählen.
- Im Abschnitt “Default Consent State” die Vorgabe prüfen. Ohne Eintrag gilt
denied, bis der Nutzer entschieden hat.
Die Kategorien von Cookiebot werden laut derselben Anleitung fest auf die Signale abgebildet:
| Cookiebot-Kategorie | Signal |
|---|---|
| marketing | ad_storage, ad_user_data, ad_personalization |
| statistics | analytics_storage |
| preferences | functionality_storage, personalization_storage |
| necessary | security_storage, immer erlaubt |
Einbindung über das WordPress-Plugin: Im Plugin die Option für Google Consent Mode aktivieren und das Plugin aktuell halten.
Direkte Einbindung des Skripts: Das Default-Snippet mit dem Attribut data-cookieconsent="ignore" vor gtag.js beziehungsweise dem GTM-Snippet einfügen. Cookiebot empfiehlt zusätzlich das Attribut data-consentmode-defaults="disabled" am Cookiebot-Skript, damit deine eigene Vorgabe gilt und nicht die Rückfall-Vorgabe von Cookiebot.
Zum Tarif sagt die Dokumentation ausdrücklich: Consent Mode ist in jedem Cookiebot-Abo enthalten, auch im kostenlosen.
Usercentrics
Usercentrics ist ebenfalls auf der Partnerseite von Google gelistet. Die Schritt-für-Schritt-Anleitung sagt es deutlich: Usercentrics behandelt die Vorgabe nicht selbst. Du setzt sie entweder per Skript so hoch wie möglich im Head nach dem Banner-Skript oder über die Usercentrics-Vorlage im Tag Manager im Abschnitt “Default Consent State” mit “Add region”.
Die Aktualisierung sendet der Banner standardmäßig. Der Schalter dafür liegt im Admin Interface unter “Configuration > CMP Settings”.
Der zweite wichtige Punkt: Usercentrics bildet nicht Kategorien auf Signale ab, sondern einzelne Google-Dienste aus der eigenen Datenbank. Laut Anleitung gilt:
| Dienst in der Usercentrics-Konfiguration | Signal |
|---|---|
| Google Analytics 4 | analytics_storage |
| Google Ads, Google Ads Conversion Tracking, Google Ads Remarketing, Conversion Linker | ad_storage |
| Display & Video 360, Campaign Manager 360, Search Ads 360 | ad_storage |
ad_user_data und ad_personalization folgen dem Wert von ad_storage. Drei Regeln aus der Dokumentation:
- Ist kein Google-Dienst in der Konfiguration oder nur als eigener Dienst angelegt, wird bei der Aktualisierung kein Signal gesetzt.
- Hängen mehrere Dienste am selben Signal, müssen alle zugestimmt sein, damit das Signal auf
grantedgeht. - Für jedes Signal muss mindestens ein Dienst angelegt sein. Fehlende Dienste ergänzt du unter “Service Settings > Data Processing Services” mit “Add DPS via Database”.
Basic oder Advanced entscheidet sich laut dem Artikel zu Advanced und Basic über die Trigger im Tag Manager, nicht über eine Einstellung im Banner.
Borlabs Cookie (WordPress)
Borlabs Cookie 3.0 unterstützt Consent Mode v2, dokumentiert in der Borlabs-Dokumentation. Zwei Wege:
Ohne Tag Manager: Das Paket “Google Analytics” oder “Google Ads” aus der Bibliothek installieren. Laut Borlabs ist der Basic-Modus mit der Installation des jeweiligen Pakets bereits aktiv.
Mit Tag Manager, beschrieben in der Anleitung zum Google Tag Manager in Borlabs Cookie 3.0:
- Unter “Bibliothek” das Google-Tag-Manager-Paket öffnen, auf “Details” klicken und unter “Google Tag Manager - Einstellungen” die GTM-ID eintragen.
- Die Option zum lokalen Speichern des Tag Managers aktivieren. Die Service-Gruppe des GTM-Services wechselt dann von “Statistik” auf “Essenziell”. Der Tag Manager darf so vor der Einwilligung laden, solange die Tags im Container erst nach der Einwilligung feuern.
- “Aktivieren des Einwilligungsmodus” einschalten und die Service-Gruppen den Einwilligungsarten zuordnen. Im Beispiel der Dokumentation löst eine Zustimmung zur Gruppe “Marketing” die Signale Ad Storage, Ad User Data, Ad Personalization und Personalization Storage aus.
- Jede zugeordnete Service-Gruppe braucht mindestens einen aktiven Service, sonst greift die Zuordnung nicht.
- Für Dienste, deren Code der Tag Manager ausliefert, in den Service-Einstellungen unter “Zusätzliche Einstellungen” die Option “Code-Ausführung deaktivieren” einschalten.
Zwei Hinweise aus derselben Anleitung, die oft übersehen werden: Änderungen im GTM-Container werden bei lokaler Speicherung erst aktiv, wenn du im Google-Tag-Manager-Service einmal auf “Einstellungen speichern” klickst. Und im Tag Assistant lädt immer der Standard-Code, nicht die lokale Kopie.
Zur Zertifizierung schreibt Borlabs in einem eigenen Artikel, dass der Antrag beim Partnerprogramm läuft und eine Zertifizierung für die Nutzung von Consent Mode nicht erforderlich ist.
Real Cookie Banner (WordPress)
Die Dokumentation von devowl beschreibt den Einstieg unter “Cookies > Settings > Google Consent Mode”. Dort aktivierst du Google Consent Mode. Die Option “Google Tag Manager integration” übergibt die Einwilligungen als zusätzliche Consent-Typen an den Tag Manager, daneben gibt es Optionen wie “Collect additional data via URL parameters” und “Redact ads data without consent”.
Die Zuordnung zu den Signalen läuft pro Service. Laut Dokumentation sind die Service-Vorlagen dafür bereits vorausgefüllt, du kannst die Zuordnung in der Service-Konfiguration anpassen.
Für den Tag Manager beschreibt die GTM-Anleitung diesen Weg:
- Unter “Services (Cookies) > Add service” die Vorlage “Google Tag Manager” anlegen. Ist der Tag Manager schon im Theme eingebunden, “Create content blocker for this service” aktivieren, damit er bis zur Einwilligung blockiert wird.
- “Google Tag Manager integration” in den Consent-Mode-Einstellungen einschalten.
- Jeder Service erhält unter “Technical handling” bei “Requested consent types for Google Consent Mode” eine eigene Kennung, zum Beispiel
google-analytics-analytics-4. - Im Tag Manager beim jeweiligen Tag “Require additional consent for tag to fire” wählen und die Kennung unter ”+ Add required consent” eintragen.
- Im Tag Manager unter “Admin > Container Settings” die Consent-Übersicht aktivieren.
Der ältere Weg über Ereignisse ist in der Anleitung zu Google Tag Manager oder Matomo Tag Manager beschrieben: Unter “Settings > General” bei “Load services after consent via” den Tag Manager wählen und pro Service unter “Event names for Google Tag Manager” Opt-in- und Opt-out-Ereignisse vergeben. Die Consent-Signale kommen in beiden Fällen aus der Consent-Mode-Einstellung.
Auf der Partnerseite von Google ist Real Cookie Banner beim Stand dieses Artikels nicht gelistet. Zu Tarifgrenzen bei Consent Mode macht die Dokumentation keine Angabe.
Shopify: die Customer Privacy API
Im Shop gilt eine andere Logik. Shopify bringt laut Shopify-Hilfe einen eigenen Banner mit, konfiguriert unter “Settings > Customer privacy > Cookie banner”. Bei neuen Shops ist “Use automated settings” aktiv, der Banner erscheint dann für Besucher aus dem EWR und dem Vereinigten Königreich, sofern dort Märkte aktiv sind.
Die Einwilligung landet in der Customer Privacy API. Sie kennt vier Zwecke: analytics, marketing, preferences und sale_of_data. Gesetzt wird die Entscheidung mit setTrackingConsent, gelesen mit currentVisitorConsent (Werte yes, no oder leer für unentschieden) und bei jeder Änderung feuert das Ereignis visitorConsentCollected.
Für Google gilt laut Shopify-Hilfe zu den Datenschutzeinstellungen: Wer einen Banner eines Drittanbieters einsetzt, muss ihn mit den Customer-Privacy-Einstellungen von Shopify verbinden und den Shopify-Banner unter “More actions > Remove cookie banner” entfernen. Wer einen eigenen Custom Pixel nutzt, muss den Consent-Mode-Aufruf selbst in den Pixel-Code einfügen. Shopify liefert dafür in der Anleitung zum Tag-Manager-Pixel ein Beispiel und weist darauf hin, dass die Beispielwerte nicht zu jeder Region passen.
Die Konsequenz: Dein WordPress-Banner spricht nicht mit der Customer Privacy API.
Testprotokoll für jeden Banner
Dieses Protokoll funktioniert unabhängig vom Hersteller, weil es nur das prüft, was bei Google ankommt.
- Ein privates Fenster öffnen, die Entwicklerwerkzeuge auf dem Reiter Netzwerk starten und nach
collectunddoubleclickfiltern, bevor die Seite lädt. - Die Seite laden und nichts anklicken. Die ersten Anfragen an
google-analytics.comundgoogleads.g.doubleclick.netansehen. Im Basic-Modus darf hier gar nichts erscheinen. Im Advanced-Modus erscheinen Anfragen mit dem Parametergcsim abgelehnten Zustand. - Die Parameter
gcsundgcdlesen. Laut Usercentrics-Dokumentation beginntgcsmitG1, gefolgt von zwei Ziffern: die erste steht fürad_storage, die zweite füranalytics_storage,0heißt abgelehnt,1erteilt.gcdenthält den Zustand von Vorgabe und Aktualisierung für alle vier Signale in einer Zeichenkette. - Die vier Fälle durchspielen, jeweils in einem frischen privaten Fenster:
| Fall | Erwartung im Request |
|---|---|
| Alles ablehnen | alle vier Signale denied, keine Analytics- oder Werbe-Cookies |
| Alles akzeptieren | alle vier Signale granted, neue Anfrage mit gcs auf erteilt |
| Nur Analytics | analytics_storage granted, die drei ad_-Signale denied |
| Widerruf nach Zustimmung | Aktualisierung auf denied, danach keine Messung mit Kennung mehr |
- Den Tag Assistant öffnen, die Seite laden und laut Google-Anleitung zur Prüfung das früheste Consent-Ereignis in der Zusammenfassung wählen. Im Reiter Consent muss die Spalte “On-page Default” auf Denied stehen und der Abschnitt API Call muss alle vier Parameter enthalten. Nach dem Klick auf Akzeptieren das jüngste Consent-Ereignis wählen und in “On-page Update” Granted sehen.
- Ein leerer Consent-Reiter bedeutet laut Google, dass Consent Mode nicht implementiert ist oder das Google-Tag blockiert wurde.
- Das Ganze auf einer zweiten Seitenart wiederholen, bei Shopify mindestens auf einer Produktseite und im Checkout.
So sehen Fehler aus
Vorgabe nach dem Google-Tag. Im Tag Assistant fehlt der Eintrag in “On-page Default” oder Google meldet, dass das Werbe-Tag bereits ein Cookie gelesen oder geschrieben hat, bevor die Vorgabe gesetzt wurde. Ursache ist fast immer die Reihenfolge: Bei Cookiebot der fehlende Trigger “Consent Initialization”, bei Usercentrics das fehlende Default-Skript, bei Borlabs ein Tag im Container, der ohne Consent-Bedingung feuert.
Kategorie am falschen Signal. Der Fall “Nur Analytics” liefert ad_storage auf granted oder umgekehrt bleibt analytics_storage nach voller Zustimmung auf denied. Bei Usercentrics steckt dahinter meist ein fehlender oder als eigener Dienst angelegter Google-Dienst, bei Borlabs eine Service-Gruppe ohne aktiven Service, bei Real Cookie Banner eine Service-Vorlage mit angepasster Zuordnung.
Zwei Banner nebeneinander. Wer den WordPress-Banner auch in den Shop kopiert, hat dort zwei Systeme: den kopierten Banner und Shopifys Customer Privacy API, die davon nichts erfährt. Shopify weist darauf hin, dass ohne verbundenen Drittanbieter-Banner nicht-notwendige Daten unter Umständen gar nicht erhoben werden.
Änderung im Container kommt nicht an. Bei Borlabs mit lokal gespeichertem Tag Manager sieht die Änderung im Tag Assistant korrekt aus, live gilt die alte Kopie bis zum Klick auf “Einstellungen speichern”.
Was FW Delta macht
Die Verbindung zwischen Banner und Signalen ist ein Baustein im Messsetup. FW Delta richtet die technische Seite ein: Vorgabe vor dem Google-Tag, dokumentierte Zuordnung, Trigger, die Shopify-Seite und das Testprotokoll oben mit festgehaltenen Ergebnissen. Der Service GA4 und Consent Mode v2 deckt die Consent-Schicht ab, das Web-Tracking das Messfundament drumherum.
Ob dein Setup die Signale heute korrekt sendet, prüft der Tracking-Check anhand der echten Anfragen deiner Seite.
Die rechtliche Bewertung der Banner-Texte, der Kategorien und der Rechtsgrundlagen bleibt bei dir beziehungsweise deiner Rechtsberatung. Dieser Leitfaden ist eine technische Erläuterung, keine Rechtsberatung.