Der Google Tag Manager (kurz GTM) ist ein Werkzeug und eine Hilfe für IT- und Marketing-Abteilungen. Er vereinfacht den Einbau von Remarketing- und Conversion-Tags und kann auch für die Implementierung von Tracking- und Event-Codes verwendet werden. Die Stärke des Tag Managers besteht aus der Unabhängigkeit von den Release-Zyklen der Website selbst: neue Conversion-Tags oder eine Änderung des Tracking (z. B. um eine Erweiterung von Events) können in der Regel ohne einen neuen Release erfolgen.
Der Google Tag Manager ist in Konten und Container organisiert und greift auf ein Zusammenspiel von Variablen, Triggern und Tags zurück, was eine extrem hohe Flexibilität ermöglicht.
Einbettung im Quelltext
Der GTM-Code kann nach den Empfehlungen von Google direkt im head-Bereich platziert werden, muss aber nicht. Es gibt mehrere funktionierende Möglichkeiten, einen Tag Manager Container auf einer Seite einzubauen:
direkt im head (lädt umgehend, wichtig für A/B-Tests mittels GTM)
im body-Bereich (lädt später, bei schnellen Seiten absolut ausreichend)
via Script (lädt später oder sehr viel später)
Wenn der GTM lediglich für Tracking, Remarketing und Conversion-Erfassung genutzt wird, ist eine Einbindung im body des HTML absolut ausreichend, sofern die Seiten grundsätzlich schnell laden (unter 5 Sekunden). Lediglich bei A/B-Tests empfehlen wir eine Einbindung in den head-Bereich, um ein "Flackern" der Seite beim Austausch des Inhalts zu vermeiden.
Der noscript-Teil des Tag Manager Codes kann ebenfalls im Body eingebettet werden, muss aber nicht. Der Grund: wer JavaScript in seinem Browser deaktiviert hat, wird die Tag Manager Funktionen nicht nutzen können oder wollen, weshalb die Berücksichtigung dieser Nische aus unserer Sicht vernachlässigbar ist.
Data Layer und Events
Der Google Tag Manager arbeitet immer mit einer Datenschicht, dem sogenannten Data Layer. GTM selbst bevorzugt die Version mit der Schreibweise dataLayer, jedoch kann der Code beim Einbetten des Tag Managers dahingehend modifiziert werden, dass auf eine andere Datenschicht als den dataLayer zugegriffen wird – beispielsweise dem "digitalData", welcher von anderen Plugins und Systemen verwendet wird. Im weiteren Verlauf beziehen wir uns der Einfachheit halber immer auf die Version dataLayer.
Werden Daten nicht nur mittels dataLayer.push nach dem Seitenladen später hinzugefügt, sondern sollen schon zum Start voll verfügbar sein, muss der dataLayer zwingend vor dem Tag Manager Code eingebaut werden:
Auch wenn im Quellcode kein Data Layer hinterlegt wird, gibt es mit dem Einbau des Tag Managers einen: GTM erstellt und befüllt selbst den dataLayer, sofern noch nicht vorhanden. Die Events, die von Googles Tag Manager selbst implementiert werden, beginnen alle mit "gtm.name". Ist – wie im Beispiel oben – bereits ein dataLayer vorhanden, erweitert der GTM diesen mit den eigenen Events:
gtm.start (initiales Laden gtm.js)
gtm.dom (Event bei DOM Ready)
gtm.load (Event bei Seite geladen / Page load)
gtm.timer (Event bei zeitbasiertem Trigger)
Diese Liste wird dann – abhängig von der Konfiguration – mit weiteren Events befüllt:
gtm.click (bei Mausklick wenn Trigger mit „Kick – Alle Elemente“ aktiv)
gtm.linkClick (bei Mausklicks auf a href mit „Klick – Nur Links“)
Diese Standard-Events von Google Tag Manager können jederzeit um weitere, individuelle Events ergänzt werden. Sie sind eine der zuverlässigsten Trigger und am einfachsten im Tag Manager zu implementieren. Oftmals bedarf es aber hierbei der Hilfe durch die IT-Abteilung. So kann aus einem einfachen Link mit einer Code-Zeile ein solider Click-Trigger werden, der bereits weitere Informationen in Variablen mitliefert.
Diese Werte können via GTM an Tracking-Tools wie Google Analytics, AT-Internet oder etracker weitergereicht werden und dort Labels, Kategorien und Werte befüllen.
Synchrones und asynchrones Laden
Remarketing- und Conversion-Tags, Tracking-Codes und vieles mehr kann synchron oder asynchron geladen werden. Grundsätzlich gilt: ursprünglich wurde alles synchron geladen, mit moderneren Browsern und mehr Augenmerk auf Seitenladezeiten & Performance werden jedoch asynchrone Codes immer beliebter. Denn das synchrone Laden eines Elements blockiert das Holen von weiteren Elementen – die Verarbeitung dauert länger.
Vergleich synchrones vs. asynchrones Laden mit Quellen von anderen Domains: DOM geladen in 3,45 vs. 1,77 Sekunden
Das Zauberwort beim Problem mit synchronem Laden heißt Blockieren. Wenn alles zwingend der Reihe nach abgearbeitet werden muss, hat der Browser nicht schnellstmöglich die wichtigen Informationen, um die ersten Inhalte anzeigen zu können, sondern muss warten, bis alles da ist. Bei asynchronem Laden wird unterschieden, ob es für den Anfang wichtig ist oder nicht. So kann im obigen Beispiel der Browser bei synchronem Laden nach 3,45 Sekunden, bei asynchronem Laden hingegen schon nach 1,77 Sekunden Inhalte darstellen. Die Gesamt-Ladezeit verändert sich durch den Einsatz der asynchronen Tags eher marginal, aber die Seite wird trotzdem spürbar schneller, weil zu einem früheren Zeitpunkt die ersten Inhalte sichtbar sind.
Die Queue ist unsere Bezeichung für die Warteschlange zum Abarbeiten von Anfragen und wird als Benutzerdefiniertes HTML-Tag im Google Tag Manager implementiert. Die Queue bildet das "Herzstück" für die Remarketing- und Conversion-Tags, um mit den Marketing-Maßnahmen und Erfolgsmessungen die Performance der Website für die Besucher nicht zu beeinträchtigen.
etracker
Das Webanalyse-Tool etracker bietet trotz Neuerungen des User-Interfaces nach wie vor lediglich einen synchronen Code zum Einbinden an.
Zum Vergleich: asynchoner Tracking-Code von Google Analytics
Wird dieser nun in einen asynchron geladenen Tag Manager implementiert, kann es zu sogenannten Timing Issues kommen: Soll beispielsweise mit dem Aufruf einer Anmeldebestätigung (Aufruf Danke-Seite) zeitgleich eine Conversion erfasst werden, feuert der Tag Manager das Event, noch bevor der Seitenabruf fertig initialisiert und bereit ist. Die Folge: der Seitenaufruf wird gezählt, die Conversion nicht.
Die Lösung, wenn auf die Vorteile einer asynchronen Einbindung nicht verzichtet werden soll, heißt Queue: eine Warteschlange, welche die Events "zwischenparkt" und erst dann weitergibt, wenn etracker fertig geladen und bereit ist.
Remarketing
Wenn die Queue sowieso schon mit dem JavaScript Core steht, kann sie auch für Remarketing- und Conversion-Tags verwendet werden. Mit der Einbindung über Toast und die Queue ziehen die Tags auch den oft als KPI verwendeten Google Page Speed Index nicht in Mitleidenschaft. An dieser Stelle wollen wir aber noch einmal betonen: ein guter Page Speed Wert entscheidet nicht allein über eine performante Seite. Jedoch wird damit sichergestellt, dass die wichtigen Elemente (also die Inhalte der Seite) früher geladen werden und bereit stehen – und die Remarketing-Tags hinten angestellt werden und die persönliche Empfindung einer schnell ladenden Website nicht beeinträchtigen.
Übergreifende und individuelle Google Tag Manager Container
Ein Problem beim professionellen Arbeiten mit dem Google Tag Manager ist das Management von verschiedenen Versionsständen und das Ausrollen neuer Features auf eine Vielzahl von Tag Manager Containern. Mit Werkzeugen wie den GTM Tools von Simo Ahava fällt das Übertragen zwar leichter, bringt aber immer noch Schwierigkeiten beim Nachziehen von Änderungen mit sich.
Die Tags und Trigger für ein Tracking sind beim Einsatz von gleichen Systemen, beispielsweise beim Einsatz einer WordPress Multisite-Installation, in der Regel identisch. Die Variablen (Analytics- und Conversion-IDs, Piwik- oder etracker Secure-Code usw.) unterscheiden sich natürlich von Seite zu Seite. Da diese aber über Suchtabellen (ein Variablen-Typ im GTM) pro Website individuell ausgespielt werden können, steht dem Einsatz eines Konstrukts mit übergreifendem und individuellen Containern oftmals nichts im Weg.
Übergreifender Container
Ein übergreifender Container bezeichnet einen Google Tag Manager Container, welcher auf einer Vielzahl von Websites (also Seiten mit unterschiedlichen Domains) eingebunden wird.
Unsere Voraussetzungen und Empfehlungen für ein solches Setup:
Der technische "Unterbau" der Webseiten ist pro Container gleich. Das ist z. B. der Fall, wenn das gleiche CMS (z. B. WordPress, Drupal oder Magento) eingesetzt wird.
Das Tracking darf zu gleichen Zeiten verbessert bzw. modifiziert werden (eine Änderung von mehrfach verwendeten Tags im Container betrifft i. d. R. dann auch alle Websites und Analyse-Systeme).
Die Webanalyse- und Conversion-IDs der jeweiligen Websites können mit Integrationstests (halb-)automatisiert überprüft werden.
Umfangreiche und individuelle Remarketing- und Conversion-Tags werden über einen zweiten Tag Manager Container implementiert.
Der erste GTM-Container verwaltet das standardisierte Tracking (das für alle Websites auf gleiche Art und Weise erfolgen soll) und die Auslöseregel für die individuellen, zweiten Container (also ob, und wenn ja welcher Container bei einer Seite zusätzlich vorhanden sein soll). Alles, was nicht auf mindestens zwei oder mehr Web-Auftritten zum Einsatz kommen soll, wird in den individuellen zweiten Google Tag Manager Container einer Website ausgelagert.
Das Tracking für alle drei Seiten wird über den allgemeinen Container abgewickelt, das Remarketing (im Beispiel nur bei A und C gewünscht) über individuelle Zweit-Container, welche ebenfalls mittels übergreifendem Container ausgelöst werden. Im Quelltext der Websites A, B und C steht also nur der GTM-Code des allgemeinen Containers.
Individueller zweiter Container
Im individuellen Container gibt es im Idealfall keine Tags, welche für das Tracking der Seite verantwortlich sind (diese liegen alle im übergreifenden). Außnahme: ganz spezielle Tracking-Events, welche es nur auf dieser Seite geben soll.
Remarketing- und Conversion-Tags, welche sehr spezifisch auf einzelnen Seiten bzw. mit komplexen Auslöseregeln implementiert werden müssen, landen in diesem individuellen Container. Das können beispielsweise ID-basierte Conversion-Pixel sein, welche pro bestimmter Unterseite eine eigene Conversion-ID übermitteln. Diese können über Variablen als Suchtabellen angelegt sowohl für den Trigger wie auch für den Conversion-Tag verwendet werden.
Testen
Unit-Tests
Die Wichtigkeit von Unit-Tests wurde schon ausführlich im Artikel über die Entwicklung mit Symfony beschrieben. So wie PHPUnit unser Werkzeug der Wahl ist, wenn es um das Testen von PHP-Code geht, so bietet die Kombination aus Karma und Jasmine ganz ähnliche Möglichkeiten, um JavaScript-Code zuverlässig abtesten zu können. Das folgende Code-Beispiel zeigt einen einfachen Jasmine-Test der Funktion addElement() der Klasse Queue:
Der Test erwartet, dass nach dem Ausführen von addElement() genau ein Element in der Queue gespeichert wurde. So ähnlich werden auch alle anderen Klassen und Funktionen unserer Anwendung getestet.
Integrationstests
Der Begriff Integrationstest bezeichnet eine aufeinander abgestimmte Reihe von Unit-Tests, die dazu dienen, verschiedene voneinander abhängige Komponenten eines komplexen Systems im Zusammenspiel miteinander zu testen. Für uns bedeutet das, dass wir konkret die jeweiligen Seiten testen, auf denen der Google Tag Manager eingebaut wurde. Dabei kann durch eine entsprechende Konfiguration von Karma die Funktionalität in unterschiedlichen Browsern (PhantomJS, Chrome, Firefox, Edge usw.) und auf unterschiedlichen Arten von Geräten (Desktop, Tablet oder Smartphone) getestet werden. Statt Jasmine benutzen wir für die Integrationstests Webdriver I/O. Die Funktionsweise eines solchen Integrationstests zeigt der folgende Beispielablauf.
Testablauf
Test-Browser wird im Hintergrund gestartet.
Die zu testende URL wird aufgerufen.
Es wird geprüft, ob JavaScript-Fehler auftreten (dieser Test funktioniert derzeit nur im PhantomJS-Browser):
Es wird geprüft, ob der richtige Tag Manager eingebunden wird:
Prüfung weiterer window-Variablen
Bei dieser Art von Tests ist die korrekte zeitliche Abfolge entscheidend. Denn ein Test auf das Vorhandensein eines Objekts würde fehlschlagen, wenn dieses vor dem eigentlichen Initialisieren dieses Objektes aufgerufen würde.
Diese "Timing Issues" können durch den Einsatz der Methode waitForVisible im before-Bereich gelöst werden. Der Code zwischen den Funktionsklammern wird vor allen anderen Tests ausgeführt, damit sichergestellt ist, dass der Body der Seite fertig geladen wurde und die anschließend folgenden Tests darauf zugreifen können.
Erste Erfahrungen
Das vorgestellte Setup fahren wir – je nach Kunde leicht unterschiedlich – seit mehreren Monaten:
deutliche Arbeitserleichterung beim Verbessern des Trackings für viele Websites (Konzept übergreifende und individuelle Container)
schnelle Ladezeiten trotz des Einsatzes mehrerer Trackingsysteme, Remarketing- und Conversion-Tags (Toast-Queue)
Sicherheit, dass einmal implementierte Tags auch nach einem Umbau immer noch vorhanden sind und korrekt in den richtigen Account feuern (Integrationstests)
Der Hauptaufwand war sicher die initiale Implementierung der Konstrukte mit übergreifendem und nachgelagertem Container, die Queue mit der Toolbar und das Schreiben der Integrations-Tests. Doch die Umsetzung spart im Alltag wertvolle Zeit und sichert dem Kunden das gewünschte Tracking. Projekt gelungen, Fortsetzung folgt.
