Achtung! Diese Anleitung bezieht sich nur auf die CMP Version 2!
Usercentrics kommuniziert über den DataLayer mit dem GTM. Einwilligungen können von dort ausgelesen und im TagManager verarbeitet werden.
Achtung! Diese Anleitung bezieht sich nur auf die CMP Version 2!
Als erstes müssen Variablen für jeden Service angelegt werden:
Der Variablentyp ist "Datenschichtvariable". Die Konfiguration sollte folgendermaßen aussehen:
Name der Datenschichtvariable: Exakter Name des Services, wie er in Usercentrics angelegt wurde (Case Sensitive, Leerzeichen werden beachtet!)
Datenschichtversion: Version 2
Standartwert: false - Auch wenn ein Service standardmäßig ausgespielt werden soll (Opt-out)!
Formatwert: Alle Haken entfernt (Standarteinstellungen)
In dieser Variable speichert Usercentrics den Zustimmungsstatus für den einzelnen Service (true = Consent erteilt; false = Keine Einwilligung).
Für jeden Service wird zunächst ein Opt-Out-Trigger erstellt. Dieser sollte bei jedem Event gefeuert werden, bei dem der Zustimmungsstatus auf false steht (Keine Einwilligung). 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: Servicevariable ist gleich false
Dieser Trigger muss jetzt bei allen Tags des entsprechenden Services als Ausnahmetrigger ergänzt werden.
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 Usercentrics-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: "consent_status"
Bedingungen: Servicevariable ist gleich true
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 “consent_status” 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 consent_status 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.