Seien wir mal ehrlich: Der Google Tag Manger kann schwierig zu verstehen sein. Ich erinnere mich noch gut an das erste Mal als ich versuchte, den GTM einzurichten. Basierend auf der Erfahrung mit anderen Produkten von Google hatte ich erwartet, dass die Bedienung einfach und intuitiv sein würde. Relativ schnell habe ich gemerkt, dass ich da falsch in meiner Annahme lag.
Über die Zeit habe ich aus meinen eigenen Fehlern und den von anderen gelernt. Ich selbst verstehe mich als Marketer und nicht als Teckie und genau für diese Gruppe habe ich einen kleinen Guide zu den häufigsten Fehlern bei der Implementierung des Google Tag Manager geschrieben.
Google Analytics ID ist nicht als Variable gesetzt
Während Analytics-Audits fällt mir sehr häufig auf, dass die Google Analytics ID und mittlerweile auch alle Einstellungen für GA nicht in einer Variable festgeschrieben sind. Eine der allerersten Handlungen beim Einrichten des GTM sollte es sein, eine Variable für die Einstellungen von Google Analytics vorzunehmen.
In dieser Variable sind alle Informationen enthalten, die sie bei der Nutzung von GA-Tags im Tag Manager benötigen. Dadurch lässt sich viele, unnötige Arbeit sparen
Die Benamung von Tags und Triggern
Die oberste Devise bei der Nutzung des GTM sollte eine gewisse Grundordnung in der Struktur der angelegten Tags und Trigger sein. Ohne diese Grundordnung schleichen sich Fehler viel schneller ein. Beispielsweise besteht die Gefahr, dass Sie das falsche Tag bearbeiten oder vergessen, wofür ein bestimmter Trigger eingerichtet wurde.
Mit einer konkreten Namenskonvention lassen sich solche Fehler vermeiden und vor allem viel Zeit sparen. Die Namen Ihrer Tags sollten also genau aussagen, was die Tags auslösen.
Eine konsequente Namenskonvention sorgt für Überblick bei Tags und Triggern
Im Screenshot oben sehen Sie, dass das Tag „GA – Event – Youtube Video“ benannt wurde. Im ersten Teil beschreibe ich stets, welche Art von Tag ausgelöst wird. Der Übersicht halber nutze ich für Google Analytics die Abkürzung „GA“. Der zweite Teil beschreibt die Funktion, die genutzt wird (Events). Weiter geht es mit der Information, wann das Tag ausgelöst wird. In diesem Fall, wenn ein Youtube Video absgespielt wird (gleichzeitig auch die Art des Triggers). Würde es an dieser Stelle unterschiedliche Vidoe-Trigger geben, hätte ich am Ende noch einen Vermerk angefügt, der einen Hinweis gibt, um welches Video es sich handelt.
Hier wird also ein Event an Google Analytics gesendet, wenn jemand mit einem Youtube Video interagiert. Sollten Sie also mal vom Bus getroffen werden, weiß die nächste Person direkt, wofür dieses Tag angelegt wurde. ( Aber bitte lassen Sie sich auch nicht bei einer ordentlichen Namenskonvention vom Bus erfassen! 😉 )
Kein RegEx nutzen, um die Anzahl der Bedingungen pro Tag zu minimieren
Offen gesprochen: Ohne Erfahrung sind RegEx ein Buch mit sieben Siegeln oder eben auch eine Sprache, die man nicht versteht. Wie das folgende Beispiel aber zeigt, lohnt es sich, diese Sprache zu lernen, da viel Zeit gespart werden kann.
Oftmals hat ein Tag mehrere Bedingungen, die erfüllt sein müssen, bevor es ausgelöst werden soll. Ab drei Bedingungen lohnt es sich, mit RegEx zu arbeiten
Mehrere Abhängigkeiten lassen sich meist nur durch RegEx im Trigger einbauen
Im Screenshot wurden mehrere Click IDs und Click Texte angegeben, auf denen das Tag ausgelöst werden soll. Das hilft dabei, die Elemente einzuschränken, auf denen beispielsweise ein Click Tracking aktiv sein soll.
Kleiner Extra-Tipp: Es gibt einige gute Seiten im Netz, um die Syntax von RegEx Schritt für Schritt zu lernen. Beispielsweise https://regexone.com/
Keinen Workspace anlegen, wenn man neue Tags testet
Jeder, der regelmäßig mit den Google Tag Manager arbeitet, testet auch viel. Und nicht immer gelingt das Einrichten beim ersten Versuch – ein wenig testen ist also unvermeidlich. Wann immer Sie Änderungen an ihrem bestehenden Container im GTM vornehmen, sollten Sie einen neuen Workspace anlegen.
Mit einem neuen Workspace können Sie Änderungen an Ihrer Seite testen, ohne das bestehende Setup zu gefährden. Gerade wenn mehrere Personen an einem Container arbeiten macht das sehr viel Sinn. Warum ist das so sinnvoll? Sobald Sie den Container veröffentlichen, verschwindet der Workspace. Daher sollten Sie eine vorherige Version ihres Haupt-Workspaces speichern, bevor Sie live gehen. Somit können Sie auf einen alten Stand zurückwechseln, wenn die vorgenommenen Änderungen nicht wie gewünscht performen oder gar Probleme auf der Seite bereiten.
Keine Anmerkungen eintragen
Kennen Sie das Gefühl, wenn sie Ihr Trackingkonzept getestet haben und bereit sind, die Änderungen endlich live zu schalten?
Bevor sie den Container live stellen, sollten Sie aber Anmerkungen darüber eintragen, welche Änderungen sie in der neuen Version des Containers vorgenommen haben. Auch hilft es wieder anderen Beteiligten dabei, die Änderungen leicht zu verstehen. Und mal Hand aufs Herz: Wissen Sie noch, welche Änderungen sie im letzten Jahr vorgenommen haben? Mit den Anmerkungen wird es Ihnen leichter fallen, auf einen bestimmten Stand zurückzukehren.
Events tauch in Google Analytics als (not set) auf
Ein Problem, das häufig bei Kunden auftritt ist, dass Events als (not set) in Google Analytics erscheinen, wenn man sich die Eventberichte anschauen möchte. Das Eventlabel ist eine hervorragende Möglichkeit, weitere Informationen anzureichern und die Analyse zu vereinfachen.
Google selbst empfiehlt z.B. den Page Path als Variable in das Event Label einzutragen. Somit lässt sich nachvollziehen, auf welcher Seite dieses Event ausgeführt wurde. Hilfreich ist das bei CTAs, die auf mehreren Seiten vorhanden sind oder wenn sie Clicks auf externe Links messen wollen, die auch auf mehreren Seiten vorhanden sind.
Fazit
Ich hoffe der Guide konnte Ihnen helfen, übliche Fehler zu erkennen und sie in Zukunft zu vermeiden. Sollten Sie Probleme mit Ihrem Setup in Google Analytics oder dem Tag Manager haben, stehe ich gerne mit Rat und Tat zur Verfügung.
Bildquelle: alphaspirit / 123RF Standard-Bild
