
Consent Mode v2
Update Oktober 2024:
Echter Kundentest: Auswirkungen des Consent Mode auf Google Analytics.
Update April 2024:
Wenn deine Website und dein Traffic aus Spanien kommen und du Google Ads nicht nutzt, kannst du GA4 legal ohne Cookie-Banner installieren.
Update Februar 2024:
Der erste Teil des Artikels ist ein Update mit einem allgemeinen Überblick und den Neuerungen von Version 2 des Google Consent Mode. Wenn du das System noch gar nicht kennst oder tiefer einsteigen möchtest, findest du direkt darunter den ursprünglichen Artikel , in dem ich dir die Grundlagen des Consent Mode erkläre.
Es scheint, als wäre Ende Januar 2024 der Consent Mode in aller Munde.
Man müsse ihn unbedingt kennen und in allen Webprojekten einsetzen, sonst gehe die Welt spätestens im März 2024 unter.
Und ja, er ist wichtig, aber nicht für alle. Und dein Onlinegeschäft muss auch nicht zwangsläufig enden, wenn du ihn nach diesem Datum nicht nutzt.
Deshalb möchte ich meinen ursprünglichen Artikel zu diesem Thema, mit Version 2 des Protokolls und den Neuerungen, die in nächster Zeit kommen, aktualisieren, damit du weißt, ob und wie sehr du dich damit (be)schäftigen musst. Und wie stark es dich betrifft.
Bevor wir anfangen, aber noch ein Hinweis:
- Wenn du keine Display- und Remarketing-Kampagnen in Google Ads nutzt.
- Wenn dir die Zahlen in deinem Google Analytics egal sind oder deine Website wenig Traffic hat.
Dann ist der Consent Mode (Version 1 oder 2) für dich kaum bis gar nicht relevant.
Überblick über den Consent Mode und Version 2
Es reicht mir, wenn du weißt, dass er ein Google-Protokoll ist, das als Brücke zwischen den Tags und Pixeln dient, die du auf deiner Website meist über Tag Manager implementierst, und den CDPs (Consent Data Platforms), also den Systemen, die die von Nutzern akzeptierten Cookies erfassen.
Mit anderen Worten: Der Consent Mode ist ein Protokoll, das zwischen beiden Systemen sitzt und ihr Verhalten definiert und verändert.
Im Grunde macht der Consent Mode Folgendes: Er teilt GTM mit, welche Cookies ein Nutzer akzeptiert oder abgelehnt hat, damit die Tags entsprechend reagieren und Cookies setzen oder eben nicht.
Wenn du mehr Details möchtest, erkläre ich es im ursprünglichen Artikel ausführlicher. Wenn du es schon kennst, reden wir ein wenig über Cookies…
Wie Cookies funktionieren
Beginnen wir mit einer wichtigen Klarstellung: Cookie ist nicht dasselbe wie Information.
Ein Cookie ist eine kleine Datei, die in deinem Browser gespeichert wird und Informationen enthält, die sich auf den Nutzer einer Website beziehen können oder auch nicht.
Wenn ein Nutzer Cookies ablehnt, verhindert er damit, dass deine Website und die implementierten Tags (GA4, Facebook, Google Ads) diese Cookies im Browser dieses Nutzers speichern.
Aber diese Tools können weiterhin Informationen über den Nutzer erfassen, nur eben nicht in Form eines Cookies. Und sie speichern diese Informationen in ihren Systemen.
Und das tun sie. Natürlich tun sie das. Sie erfassen weiterhin Informationen auf andere Weise, die derzeit legal ist.
Diese Informationen sind – wiederum nach heutigem Stand – nicht so vollständig wie die über Cookies erfassten. Aber ich habe wenig Zweifel daran, dass sie früher oder später dasselbe Niveau erreichen werden.
Neben ihrer Funktionsweise solltest du wissen, dass es hauptsächlich zwei Arten von Cookies gibt:
- First-party: Sie werden von der eigenen Domain für verschiedene Zwecke erzeugt, unter anderem für Analyse und Werbung. Die von GA4 und Google Ads gehören hierher.
- Third-party: die berühmten „Drittanbieter-Cookies“. Im Grunde verfolgen sie den Nutzer beim Surfen auf verschiedenen Websites und ermöglichen personalisierte Werbung und Remarketing. Warst du schon einmal auf AliExpress und siehst später auf Marca Werbung für Produkte, die du dir angesehen hast? Das liegt an Drittanbieter-Cookies.
Wegen des Missbrauchs dieser Drittanbieter-Cookies hat Europa ihre Nutzung gesetzlich geregelt und uns zu diesen schönen Bannern verpflichtet. Und Medien dazu gezwungen, von denen Geld zu verlangen, die sie nicht akzeptieren wollen.
Bedeutung von Drittanbieter-Cookies und Consent Mode v2
Gut, damit haben wir die beiden Teile, die bei der Änderung eine Rolle spielen:
- Consent Mode teilt den GTM-Tags mit, ob sie Cookies setzen dürfen oder nicht.
- Drittanbieter-Cookies ermöglichen personalisierte Werbung und Remarketing.
Google hat also beide Punkte zusammengeführt und gesagt, dass du ab März 2024 keine Display- und Remarketing-Kampagnen in Google Ads mehr nutzen kannst, wenn Consent Mode auf deiner Website nicht aktiviert ist.
Das ist der Kern des ganzen Wirbels um Consent Mode. Google wird diese Kampagnen nämlich deaktivieren, wenn du die Anforderungen nicht erfüllst.
Und wie relevant ist das für dich?
Um das herauszufinden, schauen wir uns jeden Teil des Satzes einzeln an:
- März 2024: Das ist die Frist, die du für die Implementierung von Consent Mode auf deiner Website hast, wenn du nicht betroffen sein willst.
- Consent Mode aktiviert: Das bedeutet Änderungen an deinem GTM und an der CDP. Je nachdem, wie deine CDP implementiert ist, reicht vielleicht ein Update der Plugin-Version, weil der Entwickler den Rest erledigt hat. Bei GTM musst du selbst etwas ändern, vielleicht ist es aber so einfach wie ein Update des CDP-Tags.
- Display- und Remarketing-Kampagnen: ausschließlich diese. Das heißt, die übrigen Kampagnen (Suche, Shopping, Pmax) sind NICHT betroffen. Wenn du keine Display- oder Remarketing-Kampagnen hast, betrifft dich das NICHT.
- In Google Ads: ein weiterer wichtiger Punkt. Es betrifft nur Google Ads. Wenn du Remarketing-Kampagnen mit Criteo nutzt – um nur ein Beispiel zu nennen –, bist du nicht betroffen (zumindest vorerst). Wir werden sehen, ob die übrigen Display-Netzwerke nachziehen.
Klar, oder?
Mit diesen vier Punkten weißt du, ob dein Projekt betroffen sein wird oder nicht.
Noch etwas: Hier spreche ich über den Grund für den aktuellen Wirbel um diese Version 2, nämlich die Aussetzung bestimmter Arten von Google Ads-Kampagnen.
Allerdings hat Consent Mode (v1 und v2) Auswirkungen auf die Analyse in Google Analytics, wie ich dir erneut im ursprünglichen Artikel erkläre.
Wenn du ihn also nicht implementiert hast, weil du keine Display- und Remarketing-Kampagnen nutzt, bringt dich vielleicht die Wirkung auf GA4 zum Umdenken. Ich warne dich allerdings: Du brauchst ein gutes Traffic-Volumen, damit es sich lohnt…
Consent Mode v2: Änderungen gegenüber Version 1
Ich habe dir am Anfang gesagt, dass Google seit dem Erscheinen von Consent Mode v1 versucht, Nutzerinformationen zu erfassen, auch wenn der Nutzer Cookies abgelehnt hat.
Das geschieht über das, was Google „ Pings “ nannte: im Grunde das Senden anonymer Informationen über das Verhalten des Nutzers auf der Website an die Google-Server.
Da keine Cookies enthalten sind, fällt der Teil weg, der den Nutzer identifiziert, und seine Daten dienen zum " Modellieren ". Das heißt, sie ergänzen die Daten von Nutzern, die Cookies akzeptiert haben, damit wir weniger unvollständige und realitätsnähere Daten erhalten.
GSC: der Parameter von Version 1
Um festzulegen, welche Informationen übermittelt werden durften und wie, fügte Google in v1 von Consent Mode dem Tracking seiner Pixel einen Parameter hinzu, den GSC ( (Google Consent Status)).
Damit konnte dieser Parameter 4 verschiedene Werte haben:
- G100: Das Google-Tag (wie das von GA4) wird geladen, aber ohne Cookie-Berechtigungen. Das nennt Google in v2 nun den „Erweiterten“ Modus. Gleich erkläre ich mehr dazu.
- G110: Der Nutzer hat Werbe-Cookies akzeptiert, aber keine Analyse-Cookies.
- G101: Der Nutzer akzeptiert Analyse-Cookies, aber keine Werbe-Cookies.
- G111: Der Nutzer hat für beide die Einwilligung erteilt.
Wenn du technische Analytics magst, kannst du diesen Parameter im Tab Network des Chrome-Element-Inspektors sehen, wenn du nach „collect“ filterst:

Im Bild oben kannst du sehen, dass:
- Die Cookies auf der Website nicht akzeptiert wurden.
- Google Analytics trotzdem geladen wird (aber ohne Cookies).
- Der Wert des GSC-Parameters G100 ist, also „keine Cookie-Einwilligung“, wie es sein soll.
Gut, das stammt aus Version 1 und bleibt in Version 2 bestehen. Daran hat sich nichts geändert.
Neu ist hingegen, dass ein neuer Parameter hinzugekommen ist.
GCD: der Parameter von Version 2
Zusätzlich zum GSC gibt es jetzt in den Google-Tags einen neuen Parameter, den GCD, der, wie du sehen kannst, aus einer längeren Zeichenkette als der vorherige besteht:

Noch ist nicht vollständig entschlüsselt, was jede Zahl und jeder Buchstabe bedeutet, aber die Struktur kennen wir bereits. Sie sieht so aus:
11<ad_storage>1<analytics_storage>1<ad_user_data>1<ad_personalization>5
Dabei gilt:
- Die „11“ markiert den Anfang des Parameters.
- Die „1“ trennt die einzelnen Werte.
- Die Buchstaben sind die Werte der jeweiligen Einwilligungen. Zusammen bilden sie eine Matrix mit zwei Koordinaten: eine legt fest, ob die Einwilligung erteilt wurde oder nicht, und die andere, ob es sich um den Standardwert handelt (fast nie) oder um ein Update (weil der Nutzer akzeptiert oder abgelehnt hat).
- Ad_storage und analytics_storage gab es schon vorher (es sind dieselben Informationen wie im GSC-Parameter).
- Ad_user_data und ad_personalization sind neu und wichtig. Der erste Wert betrifft die Werbeeinwilligung, der zweite das Remarketing. Nun, diese beiden Werte haben KEINEN Einfluss auf die GTM-Tags und sollen angeblich nur für interne Google-Informationen dienen. Meiner Meinung nach bereitet Google sich damit darauf vor, dass künftig nicht Cookies selbst, sondern die Nutzung von Nutzerinformationen gesetzlich eingeschränkt wird , und zwar für diese Zwecke. Wie ich oben sagte: Informationen reisen nicht immer in einem Cookie.
Bezeichnungen: auf dem Weg zur Standardisierung
Neben diesen technischen Änderungen wollte Google die Situation auch „normalisieren“ und Begriffe klären, damit eindeutig ist, welche Bezeichnungen verwendet werden.
Das betrifft vor allem die zwei Arten, die Einwilligung korrekt zu implementieren: den einfachen und den erweiterten Modus.
Einfacher Modus
Am einfachsten umzusetzen, aber schlechter.
Dabei wird kein Tag oder Pixel ausgelöst, bis der Nutzer das Cookie-Banner akzeptiert.
Das war sehr einfach zu implementieren: Man musste nur das Laden des GTM-Containers an den Moment koppeln, in dem der Nutzer die Cookies akzeptiert.
Allerdings bedeutete das einen erheblichen Datenverlust, etwa bei Quelle und Medium der Sitzung oder der Landingpage, wenn der Nutzer die Cookies erst auf einer anderen Seite als der Landingpage akzeptierte.
Erweiterter Modus
Der gute.
Wir müssen Consent Mode in unserem GTM-Container aktivieren und kompatible Tags verwenden, darunter sämtliche Google-Tags.
Wenn du GA4 also über Consent Mode implementieren willst, ist es normalerweise sinnvoll, dies über GTM zu tun und nicht direkt im Code deiner Website.
Bei der Implementierung über GTM lösen wir das Analytics-Tag jedes Mal aus, wenn GTM geladen wird (normalerweise beim Seitenaufruf), aber es setzt KEINE Cookies, bis der Nutzer das Banner akzeptiert. Bis dahin sendet es Informations-„Pings“ an die Server.
Sobald der Nutzer das Banner akzeptiert, setzt Analytics sein Cookie und erfasst die größtmögliche Menge an Informationen.
Arten der Implementierung von Consent Mode
Damit stehen uns letztlich drei Ansätze zur Auswahl, wie wir auf unserer Website mit dem Einwilligungsmodus umgehen:
- Ohne Consent Mode.
- Mit einfachem Consent Mode.
- Mit erweitertem Consent Mode.
#1. Ohne Consent Mode
Wir ignorieren, was Google uns sagt.
Vorteile:
Wir müssen nichts weiter tun, als sicherzustellen, dass wir die GRDP einhalten.
Unter bestimmten Umständen können wir GA4 ohne Cookie-Banner nutzen.
Nachteile:
Wir können keine Remarketing- und Display-Kampagnen in Google Ads durchführen.
Sehr wahrscheinlich ist die Qualität unserer Daten in GA4 je nach Implementierung geringer.
Geeignet für Websites:
Kleine Websites, die Analytics nur grundlegend und ohne Werbung nutzen. Meist ohne Monetarisierungsziel.
Und möglicherweise auch ohne GTM.
#2. Mit einfachem Consent Mode
Wir setzen die Einwilligung auf einfache Weise und unter Einhaltung der GDPR um.
Vorteile:
Genau das: einfach zu implementieren. Sogar selbst verwaltet.
Nachteile:
Die Datenqualität wird nicht optimal sein.
Geeignet für Websites:
Kleine oder mittelgroße Websites, die wenig oder gar keine Werbung schalten, aber bestimmte Daten erfassen und analysieren möchten. Und dafür GTM und GA4 verwenden.
Sie brauchen eigentlich keine CDP, um die GDPR einzuhalten, oder eine sehr einfache reicht aus.
Denk zum Beispiel an nicht transaktionale Unternehmenswebsites.
#3. Mit erweitertem Consent Mode
Wir legen los, weil uns die Vorteile interessieren oder weil es nötig ist. Und implementieren das System vollständig.
Vorteile:
Möglichkeit, alle Arten von Google Ads-Kampagnen zu nutzen.
Bei großen Websites verbessert sich die Datenqualität – unter Einhaltung der GRDP.
Nachteile:
Es ist etwas kompliziert, wenn du es selbst machen willst und keine CDP bezahlen möchtest.
Du musst mit GTM umgehen können und manchmal ein technisches Profil haben oder jemanden, der dir dabei hilft.
Geeignet für Websites:
Mittelgroße oder große Websites, die in Werbung investieren oder Google Analytics fortgeschritten nutzen.
Projekte, die monetarisieren.
Fazit
Zusammengefasst hat Google mit Version 2 des Consent Mode die vom System verwendeten Informationen erweitert und granularer gemacht . Das Vorherige (Version 1) wird also nicht ungültig, sondern erweitert.
Außerdem wird das System zunehmend standardisiert , wobei die unterschiedlichen Einwilligungsarten eigene Namen erhalten.
Es ist ein weiterer Schritt in der Technisierung von Analytics und digitalem Marketing. Die Branche scheint immer reifer zu werden und mehr Ressourcen zu erfordern, wenn du ein Niveau erreichen willst, das noch vor wenigen Monaten / Jahren leichter erreichbar war.
Wie stark es dich betrifft, hängt davon ab, wie du die Google-Plattformen nutzt: Bei geringer Nutzung betrifft es dich eher wenig, bei großer Abhängigkeit musst du dagegen arbeiten.
Was du in diesem Fall mindestens tun musst, ist, das Tag deiner CDP zu aktualisieren in GTM, falls du überhaupt eine verwendest – vielleicht tust du das nämlich gar nicht.
Möglicherweise erweitere ich diesen Artikel demnächst oder erstelle einen neuen zur Konfiguration von Consent Mode v2 in einigen der gängigsten CDPs.
Wenn dich das Thema interessiert und du mehr Informationen möchtest, lies direkt darunter weiter, denn dort findest du außerdem eine mittelmäßig aufwendige, aber kostenlose Implementierung von Version 1 des Consent Mode. Die v2 wird sich meiner Einschätzung nach nicht allzu sehr unterscheiden.
Wenn ich mich damit beschäftige, gebe ich Bescheid.
Bevor wir weitermachen, glaube ich, dass dich das interessieren könnte
Melde dich an und hol dir meinen 66-seitigen Leitfaden mit den Besten kostenlosen digitalen Tools für:
- Marketing
- Analytics
- UX
- Projektmanagement…
Außerdem bekommst du jeden Tag einen Trick oder Tipp (einen guten) in deinen Posteingang, um dein Unternehmen oder digitales Projekt zu verbessern.
Consent Mode v1: ursprünglicher Artikel
Seit seiner Veröffentlichung wurde ziemlich viel darüber gesprochen, zu meiner Überraschung aber weniger, als es vielleicht verdient hätte. Denn ohne gleich ein Paradigmenwechsel zu sein, hat es Auswirkungen auf zwei zentrale Bereiche von Analytics:
- Die Implementierung (sie wird komplexer).
- Das Reporting (die Datenqualität wird angeblich besser).
Deshalb möchte ich dir dieses System erklären und zeigen, wie es uns helfen kann – im Austausch gegen einen höheren technischen Entwicklungsaufwand für die Einrichtung.
Lohnt es sich?
Das überlasse ich dir nach der Lektüre des Artikels.
Was Consent Mode ist
Consent Mode ist Googles Antwort auf die GDPR: ein System, das GTM nutzt und es ermöglicht, das Datenschutzgesetz einzuhalten und trotzdem bestimmte Tags – etwa Google Analytics und Google Ads – einige Daten der Nutzer erfassen zu lassen, die unsere Websites besuchen.
Im Kern ist es ein Messsystem cookieless, das zwar nicht so präzise ist, wie wenn wir den Google Analytics-Snippet immer direkt beim Laden der Seite einbinden würden (wie vor der GDPR), aber dennoch ein Fortschritt gegenüber dem Laden des Tags erst nach der Cookie-Einwilligung des Nutzers ist.
Um es klarer zu machen: Je nach erfassten Daten gibt es drei Möglichkeiten, Google Analytics zu implementieren:
- Das Tag erst laden, wenn der Nutzer Cookies akzeptiert: Wir verlieren viele Daten, vor allem wenn der Nutzer die Cookies nicht auf der Landingpage, sondern erst einige Seiten später akzeptiert. Entspricht der GDPR zu 100%.
- Das Tag mit Consent Mode immer ohne Cookies laden: Wir verlieren Daten, aber weniger als vorher (darüber sprechen wir gleich). Sobald der Nutzer akzeptiert, laden wir das normale Tag mit seinen Cookies. Entspricht der GDPR ebenfalls zu 100%.
- Das normale Tag laden, ohne auf die Cookie-Einwilligung des Nutzers zu warten: Wir erfassen die maximale Datenmenge. Schade nur, dass es illegal ist, weil es die GDPR nicht einhält.
Nachdem die drei möglichen Szenarien klar sind, konzentriere ich mich in diesem Artikel auf das zweite. Es wird – sofern es das nicht schon ist – der Implementierungsstandard für Analytics-Projekte in Unternehmen sein.
Bevor wir ins Detail der Daten gehen: Consent Mode soll auch das Auslösen anderer Tags oder Pixel (Facebook, Affiliate) je nach den vom Nutzer erteilten Berechtigungen vereinfachen.
Das lassen wir für später, denn wie gesagt konzentriere ich mich in diesem Artikel auf den Vorteil bei der Messung mit Google Analytics. Und da gibt es einiges zu besprechen.
Vorteile von Consent Mode in GA4
Der wichtigste Vorteil dieses Systems bei der Implementierung von GA4 ist, dass Google Analytics mit diesen zusätzlichen Daten einige der nicht erfassten Daten ableiten kann, indem es die vorhandenen Informationen mit seinen eigenen Algorithmen modelliert.
Dadurch kommen Kennzahlen wie die Zahl der täglichen Nutzer und ihre Merkmale (Land, Kampagne) der Realität deutlich näher. Entsprechend werden auch abgeleitete Kennzahlen wie die Conversion Rate beeinflusst.
Google nennt diese Daten „modelliert“, im Gegensatz zu den normal erfassten („beobachteten“) Daten.
Wenn wir die Anforderungen erfüllen, die wir gleich sehen, können wir in der GA4-Verwaltung wählen, ob wir beide Datentypen nutzen wollen („gemischt“, wie Google es nennt) oder nur die beobachteten Daten (also das, was wir bisher gesehen haben):

Voraussetzungen
Bei den eigentlichen Anforderungen gibt es zwei Arten: die technischen -bezogen auf die Implementierung des Systems- und die der Datenmenge -bezogen auf die erforderliche Datenmenge, damit GA4 korrekt schätzen kann und das System robust ist-.
Beginnen wir mit Letzteren.
Erforderliche Volumina
Wenn wir in der Analytics-Dokumentation nachsehen, lesen wir:
“Die Property erfasst mindestens 1000 Ereignisse pro Tag mit analytics_storage='denied' über mindestens 7 Tage.
Die Property hat mindestens 1000 tägliche Nutzer, die Ereignisse mit analytics_storage='granted' an mindestens 7 der letzten 28 Tage senden.
Das Modell kann mehr als 7 Tage benötigen, um in diesem Zeitraum von 28 Tagen den Datenschwellenwert zu erreichen. Es ist allerdings möglich, dass selbst die zusätzlichen Daten nicht ausreichen, damit Analytics das Modell trainiert.
Die Verhaltensmodelle beginnen ab dem Datum zu funktionieren, an dem eine bestimmte Property die Anforderungen erfüllt.
In dem seltenen Fall, dass eine Property, die die Anforderungen bereits erfüllt hat, diese nicht mehr erfüllt, sind geschätzte Daten nicht mehr verfügbar. Erfüllt die Property die Anforderungen später erneut, sind geschätzte Daten wieder verfügbar. Geschätzte Daten sind nur ab dem Datum verfügbar, an dem die Property die Anforderungen erneut erfüllt.”
Falls du dich fragst, was analytics_storage bedeutet: Es geht um die Einwilligung des Nutzers in Analyse-Cookies. “denied” bedeutet, dass er sie NOCH NICHT akzeptiert hat.
Für die vollständige Funktionalität (vor allem im Zusammenhang mit der Aktivierung von Signals) benötigt GA4 außerdem die Einwilligung in Werbe-Cookies, also ad_storage.
Technische Voraussetzungen
Neben diesen Datenmengen müssen vor dem Start einige weitere Punkte erfüllt sein:
- Wir benötigen implementiertes GTM auf der Website, und zwar auf eine der möglichen Arten:
- Einbindung in den Code.
- Über ein Plugin (so habe ich es eingerichtet).
- Über Optionen des Themes.
- Einen Web-Datenstream von GA4, der über GTM implementiert ist.
- Ein Cookie-Banner, das es erlaubt, mindestens Analyse- und Werbe-Cookies zu akzeptieren oder abzulehnen. Es kann implementiert sein:
- Mit individuellem Code.
- Plugin des CMS (so habe ich es eingerichtet).
Wenn wir all das implementiert haben, können wir mit der Konfiguration des vollständigen Systems beginnen.
Der Ablauf
Bevor wir etwas konfigurieren, müssen wir jedoch zuerst verstehen, wie das System funktionieren soll, denn die Reihenfolge der Elemente ist wichtig.
Wenn also ein neuer Nutzer die Website besucht, muss Folgendes passieren:
- Es wird das Tag für den anfänglichen Status des Consent Mode von GTM geladen. Zu diesem Zeitpunkt stehen analytics_storage und ad_storage auf „denied“, weil der Nutzer noch nichts akzeptiert hat.
- Aus GTM wird das GA4-Tag ohne Cookies geladen, da Consent Mode aktiv ist.
- Es erscheint das Cookie-Banner. Hier hat der Nutzer drei Möglichkeiten:
- Wenn er die Cookies nicht akzeptiert: Auf jeder Seite wird das cookieless GA4-Tag geladen, mit unvollständigen Informationen, die GA4 modelliert.
- Si acepta solo algunas cookies: en este caso, GA4 recogerá los datos correspondientes a analytics_storage (los principales) o a ad_storage (secundarios) en función de lo que haya aceptado el usuario.
- Si acepta todas las cookies: se mandará la aceptación a GA4 y se empezará a recoger la información completa.
Wichtig: Unabhängig davon, welche Option der Nutzer wählt, werden auf jeder Seite zuerst analytics_storage und ad_storage in GTM geladen und an GA4 gesendet. Das ist der komplexeste / technischste Teil der Implementierung.
So konfigurierst du Consent Mode in WordPress
Nachdem wir verstanden haben, wie alles funktionieren soll, können wir jetzt loslegen.
Eine Klarstellung: Je nach Website kann ein System besser passen als ein anderes. Deshalb verlinke ich dir hier ein paar Tutorials, die den vollständigen Prozess mit WordPress-Plugins erklären:
- Mit Cookiebot: vielleicht am einfachsten, weil es eine maßgeschneiderte Vorlage in GTM gibt. Das Problem: Die kostenlose Version dieser CMP erlaubt nur bis zu 50 URLs auf der Website, was für die meisten zu wenig sein wird. Hat dein Projekt weniger als 50, fang hier an (Methode 3).
- GDPR Cookie Compliance: so habe ich es implementiert, weil meine Website mehr als 50 URLs hat. Ich habe allerdings einige Änderungen bei der Aktivierung des GA4-Tags vorgenommen, und darauf werde ich meine Schritt-für-Schritt-Erklärung mit zusätzlichen Kommentaren stützen.
Jetzt aber Schritt für Schritt.
#1. Plugin installieren
Wir installieren dieses Plugin in unserem WordPress:
https://es.wordpress.org/plugins/gdpr-cookie-compliance/
Wenn wir ein anderes Cookie-Plugin verwenden, deaktivieren wir es, sobald das neue System funktioniert.
Texte und Buttons kannst du konfigurieren, wie du möchtest, aber den Bereich „Drittanbieter-Cookies“ richten wir so ein:

Und den Bereich „Zusätzliche Cookies“ so:

Wir speichern alles.
#2. Status beider Cookies erkennen und an den DataLayer senden
Wenn du dich erinnerst, habe ich gesagt, dass wir auf jeder Seite den Status der Nutzer-Einwilligungen an GA4 senden müssen, damit das System weiß, welche Daten gespeichert werden dürfen und wie (analytics_storage und ad_storage, erinnerst du dich).
Hier fügen wir unserem WordPress Code hinzu, der bei jedem Seitenaufruf den Einwilligungsstatus des Plugins ausliest und zwei Variablen mit den entsprechenden Werten an den DataLayer sendet:
- Standardmäßig muss der anfängliche Einwilligungsstatus für beide auf „denied“ (abgelehnt) stehen.
- Sobald der Nutzer eine Art von Cookies akzeptiert, erfasst das Plugin die Änderung und beim nächsten Seitenaufruf lesen wir mit diesem Code bereits den geänderten Wert aus (auf der Seite, auf der er akzeptiert, haben wir die Änderung bereits an GTM gesendet).
Das muss in die Datei functions.php unseres Child-Themes eingefügt werden:
/*Función GDPR*/
if (!is_admin()){
if ( function_exists( 'gdpr_cookie_is_accepted' ) ) {
/* supported types: 'strict', 'thirdparty', 'advanced' */
/*Analítica*/
if ( gdpr_cookie_is_accepted( 'thirdparty' ) ) {
?>
<script>
dataLayer = [{
'cookies_analitica': 'granted'
}];
</script>
<?php
} else {
?>
<script>
dataLayer = [{
'cookies_analitica': 'denied'
}];
</script>
<?php
}
/*Marketing*/
if ( gdpr_cookie_is_accepted( 'advanced' ) ) {
?>
<script>
dataLayer.push({
'cookies_marketing': 'granted'
});
</script>
<?php
} else {
?>
<script>
dataLayer.push({
'cookies_marketing': 'denied'
});
</script>
<?php
}
}
}
Zur Erinnerung: Den Code habe ich von hier.
Wir können ihn per FTP oder über die WordPress-Administration hinzufügen. Aber Vorsicht, wenn du es nicht gewohnt bist, hier Änderungen vorzunehmen:

So erhalten wir bei jedem Seitenaufruf den richtigen Wert über GTM-Data-Layer-Variablen und übergeben ihn an GA4.
#3. Die korrekten Einwilligungswerte an den DataLayer übergeben
Um die Werte von analytics_storage und ad_storage an GA4 zu übergeben, verwenden wir zwei DataLayer-Variablen: eine mit dem Einwilligungsstatus für Analyse-Cookies und eine für Werbe-Cookies.
Wir müssen beide so anlegen, wie ich es dir zeige.
Analyse-Cookies

Am wichtigsten ist der Name der Variable: cookies_analitica.
Werbe-Cookies

Wichtig ist erneut der Name der Variable: cookies_marketing.
#4. Consent Mode aktivieren
Das ist ganz einfach. Es geschieht in den Container-Einstellungen:

#5. Vorlage von Simo Ahava importieren
Wenn du schon einen anderen GTM-Artikel von mir gelesen hast, wäre es ungewöhnlich, wenn ich dir nicht den weltweit größten Experten für GTM-Implementierungen erwähnt hätte: Simo Ahava.
Simo stellt uns eine Vorlage zur Verfügung, die uns das Leben bei der Konfiguration des Verhaltens der vom Nutzer erteilten Cookie-Berechtigungen deutlich erleichtert.
Um sie zu importieren, gehe zum Bereich Vorlagen, suche nach „consent“ und klicke auf die Vorlage, die ich markiert habe:

#6. Tags für den Consent Mode erstellen
Nachdem wir die Vorlage importiert haben, erstellen wir die beiden benötigten Einwilligungs-Tags: das anfängliche, das auf allen Seiten vor den übrigen Tags geladen wird, und das Update-Tag, das geladen wird, wenn der Nutzer seine Einwilligung für eine Cookie-Art ändert.
Das anfängliche Tag
Nach dem Import der Simo-Vorlage steht uns ein neuer Tag-Typ für den Consent Mode zur Verfügung:

Wir erstellen ein neues Tag dieses Typs mit folgender Konfiguration:

Dazu gibt es einiges zu sagen:
Zuerst müssen wir verstehen, wofür dieses Tag dient.
Dieses Tag teilt den übrigen Tags, die Consent Mode verwenden (wie das von GA4), mit, welche Cookies der Nutzer akzeptiert hat.
Deshalb wird dieses Tag in GTM vor allen anderen geladen und sein Befehl ist Default.
Direkt darunter sehen wir, dass das Tag 5 Arten von Cookies:
- berücksichtigt. Analyse: bezieht sich auf analytics_storage.
- Werbung: bezieht sich auf ad_storage.
- Personalisierung.
- Funktionalität.
- Sicherheit.
Die letzten beiden dürfen laut GDPR standardmäßig für den Nutzer gesetzt werden.
Personalisierungs-Cookies werden verwendet, um uns Videos auf YouTube, Songs auf Spotify oder Produkte auf Amazon zu empfehlen. Für GA4 sind sie nicht relevant.
Die anderen beiden, die hier wichtig sind, haben wir bereits erklärt.
Nach dieser Klarstellung verstehst du, warum wir Sicherheit und Funktionalität auf „granted“ lassen (das heißt, der Nutzer gibt uns die Erlaubnis, sie zu setzen).
Den Wert für Analyse- und Werbe-Cookies laden wir abhängig davon, was der Nutzer zuvor getan hat (ob er sie akzeptiert hat oder nicht).
Diesen Wert erhalten wir durch den Code, den wir der Datei functions.php hinzugefügt haben, und er wird in den beiden DataLayer-Variablen gespeichert, die wir zuvor erstellt haben. Deshalb verwenden wir diese Variablen als standardmäßigen Einwilligungsstatus.
Denk daran: Wenn ein Nutzer unsere Website betritt, stehen sie beim ersten Seitenaufruf auf „denied“. Auf den folgenden Seiten kann sich der Wert ändern, wenn der Nutzer eine Art von Cookies akzeptiert hat.
Wie gesagt, all das steckt im Code der functions.php, wenn dir das also zu komplex erscheint und du einfach möchtest, dass es funktioniert, kopiere ihn und konfiguriere ihn genau so.
Die Personalisierungs-Cookies können wir für GA4 schließlich auf „denied“ setzen. Wenn du die Einwilligung für diese Cookie-Art auf deiner Website erfasst, weil du sie verwendest, kannst du wie bei den beiden vorherigen eine DataLayer-Variable nutzen (du musst dafür den Code der functions.php ändern, natürlich).
Zu den markierten Optionen unter Other Settings : Sie helfen uns, die Kampagne genauer zu erfassen, indem sie Parameter zu den URLs hinzufügen. Ich empfehle, sie aktiviert zu lassen.
Zum Schluss der Trigger. Hier gibt es Neues.
Wenn du hinsiehst, siehst du: Consent Initialization – All Pages.
Dieser Trigger ist standardmäßig in GTM enthalten und gehört zu den neuen Triggern, die Google zusammen mit Consent Mode eingeführt hat.
Dieser Trigger sorgt dafür, dass dieses Tag vor allen anderen in GTM geladen wird, sodass die übrigen Tags seine Werte lesen und entsprechend handeln können.
Zur Information: Wenn Consent Mode aktiviert ist, erfasst GA4 in seinen Requests den Wert eines neuen Parameters (“gcs “) in seinen Requests. Dieser Parameter kann vier Werte haben:
- G100: Anfangsstatus, weder Analyse- noch Werbe-Cookies akzeptiert.
- G101: Analyse-Cookies akzeptiert.
- G110: Werbe-Cookies akzeptiert.
- G111: Beide Cookie-Arten akzeptiert.
Der Wert dieses Parameters sorgt dafür, dass GA4 je nach Nutzer unterschiedliche Daten erfasst und bestimmt, wie sie anschließend verarbeitet werden.
Wenn der Nutzer etwas akzeptiert
Kommen wir zum zweiten Tag für den Consent Mode. Er aktualisiert die Einwilligungen des Nutzers und ändert dabei auch den Wert des GCS-Parameters.
Dieser Schritt hat etwas mehr Substanz, denn zusätzlich zum eigentlichen Tag für den Consent Mode müssen wir davor weitere Tags erstellen , die die Werte der zuvor erstellten DataLayer-Variablen aktualisieren.
Tags zum Senden der Einwilligungsaktualisierung an den DataLayer
Je nachdem, ob der Nutzer alle oder nur einige Cookies akzeptiert, wird etwas anderes an den DataLayer gesendet.
Beginnen wir mit dem häufigsten Fall.
Der Nutzer akzeptiert alle Cookies
Auf der Website hat das Plugin uns diesen Button eingefügt:

Damit akzeptiert der Nutzer alle Cookies.
Wenn er das tut, senden wir ein benutzerdefiniertes HTML-Tag mit diesem Code an GTM:
<script>
dataLayer.push({
'event': 'guardar_cookies',
'cookies_analitica': 'granted',
'cookies_marketing': 'granted'
})
</script>
Dadurch ändert sich der Wert unserer DataLayer-Variablen cookies_analitica und cookies_marketing.
Die Konfiguration des Tags sieht so aus:

Dort sehen wir den obigen Code und einen Klick-Trigger für den erwähnten Button mit dieser Konfiguration:

Die Klasse des Buttons entspricht dem regulären Ausdruck: (moove-gdpr-infobar-allow-all)|(moove-gdpr-modal-allow-all).
Das wäre alles.
Der Nutzer aktualisiert einige Cookies
Kommen wir zum Fall, dass der Nutzer nicht alle, sondern nur einige akzeptiert.
Das passiert, wenn er die Einstellungen im Banner öffnet und hier speichert:

Der Code wäre dieser:
<script>
var check_marketing = document.querySelector('#advanced-cookies .cookie-switch input').checked;
if(check_marketing){
var cookies_marketing = 'granted';
} else{
var cookies_marketing = 'denied';
}
var check_analitica = document.querySelector('#third_party_cookies .cookie-switch input').checked;
if(check_analitica){
var cookies_analitica = 'granted';
} else{
var cookies_analitica = 'denied';
}
dataLayer.push({
'event': 'guardar_cookies',
'cookies_analitica': cookies_analitica,
'cookies_marketing': cookies_marketing
})
</script>
Wir machen dasselbe: Wir erstellen ein benutzerdefiniertes HTML-Tag mit dieser Konfiguration:

Dabei muss der neue Trigger so aussehen:

Die Klick-Klasse lautet: moove-gdpr-modal-save-settings.
Benutzerdefiniertes Ereignis zum Speichern der Cookies
Wenn du hinsiehst, siehst du in den beiden vorherigen Codes, dass wir in beiden Fällen ein benutzerdefiniertes Ereignis an den DataLayer senden: guardar_cookies.
Gleich erkläre ich dir den Grund. Zuerst erstellen wir aber einen Trigger mit diesem Ereignis:

Das Update-Tag des Consent Mode
Nachdem wir all das erstellt haben, kommen wir zum zweiten Tag für den Consent Mode, der die Einwilligungen des Nutzers aktualisiert.
Die Konfiguration sieht so aus:

Dabei gilt:
- Der Befehl lautet Update, weil dieses Tag die Werte aktualisiert.
- Der Wert der DataLayer-Variablen wurde aktualisiert und hier wird der neue Wert übernommen.
- Der Trigger ist der, den wir gerade erstellt haben. Er löst das Tag aus, sobald die Einwilligungen des Nutzers aktualisiert werden.
Damit ist die Konfiguration abgeschlossen. Wie du siehst, haben wir an der GA4-Konfiguration überhaupt nichts geändert; ihr Trigger bleibt weiterhin All pages:

Tests
Jetzt ist es Zeit für die Tests.
Als Erstes installieren wir diese Erweiterung falls wir sie noch nicht haben, um die Cookies zu löschen.
Als Zweites installieren wir diese andere um die Google-Tags zu sehen.
Dann machen wir Folgendes:
#1. Cookies unserer Website löschen
Um das Verhalten eines neuen Nutzers zu simulieren, löschen wir sie, indem wir in der Erweiterung auf das Papierkorb-Symbol klicken:

#2. Seite neu laden
So prüfen wir, dass nach dem Löschen tatsächlich keine Analytics-Cookies mehr vorhanden sind:

#3. Vorschau in GTM öffnen
Die Seite wird neu geladen und wir prüfen, dass:
- GTM und das GA4-Tag geladen werden (die verschiedenen, die ich installiert habe):

- Kein Analytics-Cookie geladen wird:

Das bedeutet, dass GA4 die Daten ohne Cookies erhält. Wir sind auf dem richtigen Weg.
#4. Cookies akzeptieren
Wir klicken auf den Button zum Akzeptieren aller oder einiger Cookies.
Wir prüfen, dass GA4-Cookies hinzugefügt wurden:

Zusätzlich und aus Neugier können wir in der Konsole sehen, dass sich der Wert des GCS-Parameters geändert hat:

Das bedeutet, dass alles so gelaufen ist, wie es sollte und wir ab jetzt, sobald wir die zuvor erläuterten Volumenanforderungen erfüllen, von der Datenmodellierung in GA4 profitieren können.
Fragen
Die wichtigste Frage, die dir wahrscheinlich in den Sinn kommt, ist, was passiert, wenn ein Nutzer die Cookies auf einer anderen Seite als der Zielseite akzeptiert.
In meinen Tests konnte ich nicht feststellen, wie GA4 diese Änderung verarbeitet. Allerdings bewirkt sie in BigQuery , dass die Requests der Nutzersitzung mit dem Parameter gcs=G100 vor der Cookie-Einwilligung in Requests mit gcs=G111 geändert werden, sodass die Daten vollständig verarbeitet werden können (wichtig für exakte Daten zur Quelle oder Landingpage).
Deshalb gehe ich davon aus, dass die Verarbeitung in GA4 ähnlich sein wird, auch wenn ich es, wie gesagt, nicht bestätigen konnte.
Die zweithäufigste Frage ist wie viel Genauigkeit wir gewinnen.
Und auch darauf habe ich keine Antwort, denn um das zu prüfen, müsste man eine GA4-Implementierung mit einer anderen vergleichen, die auf der Website immer direkt geladen wird (ohne GTM), wie wir es früher gemacht haben.
Und das verstößt gegen die GDPR.
Außerdem ist mir keineswegs klar, ob ein im GTM-Container aktivierter Consent Mode und sein vor allen anderen geladenes Initial-Tag nicht doch das außerhalb des Containers geladene GA4-Tag beeinflussen. Sollte es nicht, aber meine Tests haben das nicht zweifelsfrei geklärt.
Fazit
Ich hoffe, ich habe dir etwas klarer gemacht, worum es beim Consent Mode geht, welche Vorteile er dir bringen kann und wie du ihn auf einer WordPress-Website implementieren kannst.
Nach einiger Zeit mit dem Thema ziehe ich zusammenfassend mehrere Schlüsse:
Der erste ist, dass Consent Mode dauerhaft bleiben wird, denn alles, was Daten liefert, die Kampagnen optimieren helfen, ist willkommen.
Der zweite ist, dass seine Implementierung nicht ganz einfach ist. Wenn du Entwickler bist, hast du alles in kurzer Zeit konfiguriert. Wenn nicht, ist die laufende Verwaltung des Einwilligungswerts nicht unmittelbar.
Das verstärkt die Technisierung der digitalen Analytics zusätzlich, und vieles deutet darauf hin, dass sie bei Integrationen mit BigQuery noch nützlicher sein wird.
Allerdings ist jetzt, mit der massenhaften GA4-Implementierung, vielleicht ein guter Zeitpunkt, das Thema anzugehen und es nicht für immer aufzuschieben.
Es bleiben Fragen zur Blackbox der Datenmodellierung , die Google vornehmen wird, wobei es Richter und Partei zugleich ist (wird es seinen eigenen Traffic bevorzugen?), auch wenn ich Google in diesem Fall lieber vertraue.
Letztlich ist es eine neue Art, Analytics zu verstehen – nach dem ersten „alles geht“ und dem späteren „fast nichts geht“ der GDPR. Es braucht mehr Zeit und mehr Daten, um zu sehen, ob es sich bei einfachen Implementierungen lohnt.


Schreibe einen Kommentar