GTM-Konfiguration: Diese 5 Fehler sollten Sie unbedingt vermeiden

GTM-Konfiguration: Diese 5 Fehler sollten Sie unbedingt vermeiden

Inhaltsverzeichnis

Mehr anzeigen Weniger anzeigen

Wer sich näher mit dem Google Tag Manager beschäftigt hat, weiß, dass die Konfiguration von Variablen, Triggern und Tags ihre Tücken hat. Mit der Integration der Usercentrics Consent Management Platform kommt noch ein weiterer Punkt hinzu, den es zu beachten gilt: Die gängigen Marketing- und Analyse-Tags sollen nur nur gefeuert werden, wenn der Nutzer dieser Verwendung zuvor über einen der Consent-Layer zugestimmt hat.

Wird die Einwilligung verweigert, so müssen die Tags in ihrem Setting so beschaffen sein, dass sie nicht ausgelöst werden.

 

Sie wollen die Usercentrics CMP ganz einfach mit dem Google Tag Manager implementieren? Wie das geht zeigen wir Schritt für Schritt in unserem kostenlosen Webinar.  

 

Folgende Stolpersteine gilt es zu vermeiden, wenn man Google Tag Manager-Container in Verbindung mit der Usercentrics CMP konfiguriert.

Fehler Nr. 1: Benennung der DLV nicht identisch zur Benennung des zugehörigen Data Processing Services

Ein Fehler, der schnell passieren kann, ist, dass der Name einer dataLayer Variablen nicht mit dem Namen des korrespondierenden Data Processing Services übereinstimmt. 

Dies führt dazu, dass, obwohl der Websitebesucher einer bestimmten Technologie seine Zustimmung erteilt, diese nicht korrekt durch den Google Tag Manager verarbeitet werden kann.

 

Maßgeblich dabei ist nicht zwangsläufig die Benennung, wie sie im Admin Interface zu finden ist, sondern sicherheitshalber sollte über die Console geprüft werden, wie die Benennung im dataLayer aussieht:

 

 

Dazu öffnet man die Console auf der Website, auf der das CMP-Script installiert und ausgeführt wurde und gibt im Tab “Console” den Befehl “dataLayer” ein.

Wichtig: Die Schreibweise der Variablen im GTM muss exakt der Schreibweise der Variablen entsprechen, die in den dataLayer geschrieben wird (inkl. Groß- und Kleinschreibung).

Die Auswirkungen auf die Messwerte in Webanalyse-Systemen wie Google Analytics sind allerdings überschaubar. In wenigen Fällen sorgt die fehlende Option dafür, dass mehrere Pageview-Hits pro Seite gesendet werden.

 

Die Konfiguration basiert auf dem Event “consent_status”, dass sowohl bei jedem Seitenaufruf initiiert wird (sobald das CMP Script ausgeführt wird) als auch bei jeder Interaktion mit einem der Consent Layer (z. B. wenn man bestimmte Services oder Service-Kategorien an- oder abwählt).

 

Das folgende Video zeigt ein solches Szenario:

  • Zunächst interagiert der Nutzer mit dem First Layer durch den Klick auf “Alles akzeptieren”: Alle Data Processing Services werden als Variablen mit dem Wert “true” in den dataLayer geschrieben.
  • Der für das Google Analytics-Tag bestimmende Trigger basiert auf dem Event “consent_status” und der Bedingung, die dataLayer-Variable “Google Analytics” muss gleich “true” sein. Diese Bedingung ist nach dem Klick auf “Alles akzeptieren” erfüllt. Das Pageview-Tag von Google Analytics wird also ausgelöst.
  • Im nächsten Schritt erfolgt eine Anpassung über den Second Layer. Zwei Kategorien werden deaktiviert. Mit dem anschließenden Klick auf “Speichern” wird das Event “consent_status” erneut ausgespielt. Da sich der Wert der dataLayer Variablen “Google Analytics” nicht verändert hat, sind auch hier wieder alle Bedingungen erfüllt, sodass der Trigger aktiviert und das Pageview-Tag gefeuert wird.
  • Es wurden also bei einem Seitenaufruf zwei Pageview-Hits an Google Analytics gesendet. Gemäß der Definition von Absprüngen (Bounces) in Google Analytics bedeutet dieses Szenario: Wenn der Nutzer in unserem Beispiel ohne weitere Interaktion mit der Seite diese wieder umgehend verlässt, gilt diese Sitzung nicht als Bounce. Wäre auf dieser Seite allerdings nur ein Seitenaufruf protokolliert worden, so hätte Google Analytics diese Sitzung als Absprung gewertet.

 

Webanalysten sind verständlicherweise an möglichst “sauberen” Daten interessiert. Um das mehrfache Senden von Treffern (Hits) an eine Google Analytics-Property zu vermeiden, sollte daher in der Tag-Konfiguration definiert werden, dass das Tag nur einmal pro Seite ausgelöst wird.

 

Fehler Nr. 3: Event-Tracking von Youtube Videos (wenn YT-Videos z. B. durch den Smart Data Protector geblockt werden) – YT iframe API wird nicht nachgeladen.

Ein klassisches Google Tag Manager bzw. Google Analytics-Setup beinhaltet oftmals das Erfassen von Interaktionen mit auf einer Website eingebetteten YouTube-Videos. Dazu gibt es im GTM vorgefertigten Variablen und Trigger, die eine Einrichtung des YouTube-Video-Trackings deutlich erleichtern.

 

Mit laufender Usercentrics- und Smart-Data-Protector-Implementierung allerdings wird das Tracking dieser Videos etwas komplizierter. Warum? Um diese Frage zu beantworten, macht es Sinn sich die Event-Timeline bzw. die Abfolge der GTM-Events anschauen. 

 

Dazu folgendes Szenario: Eine Seite mit einem eingebetteten YouTube-Video wird geladen. Für das Video gibt es noch keine Einwilligung, d. h. über dem Video liegt ein Overlay, mit dem der User interagieren kann, um das Video zur Wiedergabe freizuschalten.

 

 

Wenn die Seite fertig gerendert ist, wäre die Youtube iframe API normalerweise bereits geladen worden. Dies wird mit dem Klick auf Akzeptieren nachgeholt, allerdings bekommt der Google Tag Manager bzw. der zugehörige Trigger an der Stelle davon nichts mit (dies hätte mit dem Page Load erfolgen müssen, da wurde die API allerdings noch geblockt). Nun muss das Laden der API nachgeholt werden, d. h. es wird eine eine Verbindung hergestellt zwischen dem Erteilen des Consents für die YouTube Videos und dem Laden der Youtube iframe API.

In der Template Gallery steht das Tag Template “YouTube iframe API loader” von Simo Ahava zur Verfügung. Dies muss dem Arbeitsbereich hinzugefügt und den passenden Trigger ergänzt werden:

 

 

Gewollt ist, dass das Tag ausgelöst wird, sobald der Nutzer einen Consent für den Data Processing Service “YouTube Video” erteilt, daher nimmt man für die Triggerkonfiguration das Event “consent_status” als Basis und ergänzen dies durch die Bedingung, dass der Trigger erst ausgelöst wird, wenn die dataLayer Variable “YouTube Video” gleich “true” ist.

Fehler Nr. 4: Race Conditions – GTM-Events werden u. U. geladen, bevor das CMP Script ausgeführt wurde

Ein guter Grund eine CMP Implementierung ausgiebig zu testen, ist eine möglicherweise auftretende Race Condition. Eine Race Condition in diesem Kontext entsteht dann, wenn wir einen Trigger konfigurieren, der auf einem Event basiert, welches in der sequentiellen Abfolge noch vor dem Usercentrics-Event “consent_status” ausgelöst wird.

Denn erst ab dem Zeitpunkt, wo “consent_status” in der Event-Timeline auftaucht, stehen uns die Zustimmungs-Status zur Verfügung. Oder anders formuliert: Tags von zustimmungspflichtigen Technologien, können, so sie denn korrekt konfiguriert sind, erst gefeuert werden, sobald das CMP-Script geladen und das Event “consent_status”, welches die Werte der dataLayer-Variablen transportiert, ausgelöst wird.

Dieses Problem lösen die “Trigger-Groups”.

 

Wie genau eine Trigger-Group hier konkret weiterhilft, zeigt folgendes Video:

Fehler Nr. 5: Referrer- und Kampagnendaten gehen verloren, wenn die Funktion “Use Background Overlay” nicht genutzt wird

Die Funktion “Use Background Overlay” bewirkt, dass der Websitenutzer zunächst mit dem First Layer, also dem Consent-Banner oder der Consent-Wall, interagieren muss, bevor er die Websiteinhalte bedienen kann.

 

Folgendes Szenario verdeutlicht die Problematik: 

 

  • Ein Nutzer klickt auf einen Link (z. B. auf einer Suchmaschinen-Ergebnisseite) und gelangt auf die Website. Der Usercentrics First Layer erscheint, der Nutzer kann aber dennoch auf der Website interagieren, ohne dass er einen Consent erteilt bzw. diesen verweigert.
  • Der Besucher klickt auf ein Navigationselement innerhalb der Seite und kommt auf ein weiteres Website-Dokument.
  • Erst auf der zweiten Seite – das Consent-Banner erscheint erneut – klickt er auf “Akzeptieren”. Er gibt einer Tracking-Technologie wie Google Analytics dadurch seine Zustimmung und der Seitenaufruf wird durch Google Analytics protokolliert.
  • Die Verweis- und Kampagnendaten stehen jedoch auf der zweiten Seite nicht mehr zur Verfügung und der Besuch / die Sitzung wird einer unbekannten Trafficquelle (bei Google Analytics:(direct)) zugeordnet.

 

Dafür gibt es zwei mögliche Lösungsansätze:

 

1. Verwendung der Funktion “Use Background Overlay”. Diese findet man im Usercentrics Admin Interface unter Appearance / Layout / Global Layout Options.

 

 

 

2. Sofern die genannte Funktion nicht aktiviert werden soll, können die Referrer- und Kampagnendaten über den Google Tag Manager persistiert werden, sodass diese auch nach dem initialen Seitenaufruf zur Verfügung stehen.

Dafür hat Simo Ahava ein Custom Template für den Google Tag Manager entwickelt, das kostenfrei dem GTM-Container hinzugefügt werden kann.

Mittels dieses GTM-Tags werden die Referrer- und Kampagnendaten jeweils (vorübergehend) als First Party Cookie gespeichert und später wieder ausgelesen.

Ein vollständiges How-To hat Simo Ahava in einem Blog-Beitrag zusammengestellt.

Gastautor:

Benjamin Heilmann, Account Management bei comspace

Benjamin Heilmann ist seit 2013 im Account Management der Bielefelder Digitalagentur comspace tätig und kümmert sich im Online Marketing schwerpunktmäßig um die Themen Webanalyse, Tag Management und – seit Ende 2018 – auch um das Consent Management.