/
Google Tag Manager Anpassungen

Google Tag Manager Anpassungen

Cookiebot kommuniziert über den DataLayer mit dem GTM. Einwilligungen können von dort ausgelesen und im TagManager verarbeitet werden.

 

Schritt 1: Variable anlegen

Als erstes sollte das Custom Template “Cookiebot Consent State” aus der Community Template Gallery zu dem Workspace hinzugefügt werden.

 

image-20241008-124203.png

 

Auf Basis dieses Templates kann dann eine Variable “Cookiebot Consent State” angelegt werden. Hierzu kann beim Erstellen der Variable als Typ einfach das Template genutzt werden. Es ist keine weitere Konfiguration der Variable notwendig.

 

In dieser Variable speichert Cookiebot die Kategorien, für die eine Zustimmung vorliegt. Falls der Nutzer alle Kategorien abgelehnt hat, ist diese Variable leer. Hat der Nutzer alle Kategorien akzeptiert, so “enthält” die Variable statistics, marketing und preferences.

 

Schritt 2: Opt-Out-Trigger erstellen

Für jede Kategorie wird zunächst ein Opt-Out-Trigger erstellt. Dieser sollte bei jedem Event gefeuert werden, bei dem die Variable nicht die jeweilige Kategorie erhält, also keine Einwilligung des Nutzers vorliegt. Der Trigger ist folgendermaßen aufgebaut werden:

 

  • Triggertyp: Benutzerdefiniertes Ereignis

  • Ereignisname: ".*" + Haken bei "Übereinstimmung mit regulärem Ausdruck verwenden". Dadurch wird der Trigger bei jedem Event gefeuert, welches der GTM registriert, z.B. Pageloads, Consentänderungen, etc.

  • Bedingungen: Cookiebot Consent State enthält nicht Kategorie

Dieser Trigger muss jetzt bei allen Tags des entsprechenden Services als Ausnahmetrigger ergänzt werden.

 

Schritt 3: Opt-In Trigger für alle "Seitenaufruf-Tags" erstellen:

Auslösende Trigger (z.B. Pageview-Trigger oder Klicks) für die Tags können teilweise weiterhin so bestehen bleiben, wie Sie bereits vor der Cookiebot-Integration angelegt worden sind. “Pageview”, "Window Loaded" oder "DOM ready"-Trigger müssen jedoch durch einen Opt-In-Trigger ersetzt werden:

Mit dem Opt-Out Trigger wird verhindert, dass ein Tag ausgespielt wird, falls keine Einwilligung erfolgt ist.
Der Opt-In Trigger deckt verschiedene Szenarien ab, die eintreten, falls der ursprüngliche Trigger eines der oben angesprochenen Events war. In diesem Fall würde nämlich ohne diesen Trigger der Tag teilweise nicht gefeuert werden, da z.B. das Event “Pageview” schon durchgeführt wurde, bevor der Consent für den Dienst erteilt wurde.

 

  • Triggertyp: Benutzerdefiniertes Ereignis

  • Ereignisname: "cookie_consent_" + Kategorie

  • Bedingungen: Cookiebot Consent State enthält Kategorie

Dieser Trigger ersetzt jetzt den ursprünglichen auslösenden Trigger bei allen Tags, die über "Seitenaufruf", "Fenster geladen" oder "DOM bereit" ausgespielt werden. Bei Tags, die nicht auf jeder Seite feuern sollen sondern z.B. an eine bestimmte URL oder andere Bedingungen geknüpft sind, müssen diese Bedingungen ebenfalls im Opt-In-Trigger ergänzt werden.
Zusätzlich muss für alle Tags, für die ein OptIn-Trigger genutzt wird, unter “Advanced Settings” die “Tag firing options” auf “Once per page” gestellt werden. Der Grund dafür wird unter Szenario 2 erläutert.

 

Für Tags, die über Klicks, benutzerdefinierte Ereignisse oder ähnliches ausgelöst werden sind diese Schritte nicht notwendig.

Die vorher angesprochenen Szenarien für die der OptIn-Trigger notwendig ist (wir gehen hier von dem ursprünglichen Trigger “Window Loaded” aus):

  • Szenario 1: Der Nutzer besucht die Seite und hat noch keinen Consent erteilt und stimmt dann dem Dienst zu.

    • In diesem Szenario kann es vorkommen, dass das Event “Window Loaded” vor dem Event “cookie_consent_xxxxxxx” durchgeführt wird. Das heißt bei “Window Loaded” würde der Tag nicht feuern, da zu diesem Zeitpunkt noch kein Consent für den Dienst erteilt wurde.

  • Szenario 2: Der Nutzer hat dem Dienst bereits zugestimmt, lädt eine neue Seite und stimmt dann auf der neuen Seite einem zusätzlichen Dienst zu.

    • In diesem Szenario gibt es auf der selben Seite 2 verschiedene “cookie_consent_xxxxxxx” Events. Das erste wird automatisch kurz vor (teilweise nach) dem Laden der Seite aktiviert. Das zweite wird zu dem Zeitpunkt aktiviert, zu dem der Nutzer den zusätzlichen Dienst akzeptiert (oder ablehnt). Ohne die Einstellung “Once per page” würde unser Tag nun zweimal auf der selben Seite feuern.

 

Related content