Markus Baersch

Gleich vorweg: Es geht nicht um einen Vergleich auf Feature-Ebene. Den würde Matomo auch haushoch verlieren. Dieser Beitrag soll viel mehr dazu dienen, meine Erfahrungen zu teilen, die ich als m. E. für die meisten Dinge ausreichend versierter Google Tag Manager Anwender im Zuge meiner "ersten Gehversuche" mit dem Matomo Tag Manager gemacht habe.

Wenig überraschend lautet das vorweggenommene Fazit: Der MTM ist kein GTM. Das will er sicher auch nicht sein. Trotzdem sollte er einem Vergleich bis zu einem gewissen Grad standhalten, wenn es um das "Vertaggen" einer typischen Website geht. Neben Seitenaufrufen also einige Events, passende Trigger (die hier "Impulse" genannt werden), möglicherweise ein paar virtuelle Seitenaufrufe oder Events nach Absenden eines Ajax-Formulars... oder gar E-Commerce im Fall eines Shops. Vielleicht noch Facebook, ein paar Conversion-Tracking-Tags. Das Übliche eben.

Matomo Tag Manager: Das gelebte Pareto Prinzip?

Wenngleich im MTM vielleicht nur 20% dessen drin steckt, was in aller Tiefe mit dem GTM angestellt werden kann, wird man damit doch 80% der GTM-Anwendungsfälle trotzdem abdecken können. Es mögen ein paar Prozent mehr oder weniger in der realen Gleichung sein, aber prinzipiell geht die "Pareto-Rechnung" m. E. auf. Alles, was an typischen Aufgaben oben genannt ist, ist machbar mit Matomo - und folgerichtig auch mit dem Matomo Tag Manager. Er bringt auch alle erforderlichen Werkzeuge mit, um ähnlich wie beim GTM Informationen entweder aus einer Datenschicht oder dem DOM der Website zu entnehmen, um damit Tags zu versorgen. Für Matomo und viele andere Dienste. "Von Haus aus" sind zwar andere Tag-Typen als im GTM verfügbar, aber da auch hier benutzerdefiniertes HTML (oder ein "Bild" / Pixel) als Tag genutzt werden kann, sind Dinge wie Google Ads Conversiontracking & Co. ebenso umsetzbar.

Komplexere Hilfsmittel wie Tag Sequencing und andere Zaubereien, die in umfangreicheren Tagging Szenarien gelegentlich hilfreich sind, fehlen dem Matomo Tag Manager. Man muss sich also häufiger mit JavaScript selbst behelfen. Prinzipiell kann der MTM aber eine ganze Menge und ist - wie im Google Universum - auf jeden Fall gegenüber direkter Implementierung die bessere Option, wenn man eine Seite mit Matomo Tracking versehen möchte.

Stärken und Schwächen

Wer mit dem Gedanken spielt, seine eigene Website statt mit Google Analytics und dem Google Tag Manager lieber mit dem Pendant von Matomo zu versehen oder von der Google Lösung auf diese umzusteigen, mag folgende Eindrücke zu Stärken und Schwächen aus meiner Sicht hilfreich finden. Einer Sicht, die von einem recht tiefen Verständnis des Google Tag Managers, aber sehr oberflächlichen Erfahrungen mit Matomo und dem dortigen Tag Manager geprägt ist. Es mag also sein, dass ich bestimmte Dinge "unfair" einschätze, weil ich bessere alternative Wege nicht gefunden habe. Ist das so, freue ich mich über jeden Hinweis per Mail, Facebook, Twitter oder sonstwie!

Angenehm / Überraschend

• Man findet sich schnell zurecht, wenn man den GTM gewohnt ist
• Keine Aktivierung vorkonfigurierter Variablen erforderlich. Die sind einfach da
• Facebook Pixel ist als Tag - wie viele andere - schon da und muss nicht erst als Vorlage (die es hier auch in der Form wie im GTM nicht gibt) installiert werden
• Sinnvolle Beschränkung von Rechten hinsichtlich der Verwendung benutzerdefinierter HTML Tags und Variablen
• Variablentyp zum Auslesen von Metadaten der Seite
• Seitenbezogene Triggertypen wie Window Unload, Leave etc. sind direkt vorhanden
• Weniger Funktionen bedeuten auch: Weniger Verwirrung. Zusammen mit den allgegenwärtigen Hilfetexten vermutlich ein leichterer Einstieg als beim GTM
• Im Debugger kann man auch die Zwischenablage nutzen. Das geht mir beim GTM schon immer auf die Nerven!

Nicht so schön

• Das ganze Design ist durchgehend sehr verschwenderisch. Sowohl in der Preview als auch im Backend des MTM.
  • In der Debugger Konsole hat es mich einiges sogar so gestört, dass ich eine (nicht perfekte) Lösung dafür als JavaScript-Tag für den MTM gefrickelt habe
• Es fehlt an Suchfunktionen und sortierbaren Listen bei Tags, Impulsen und Variablen. Hier ist generell Luft nach oben, wenn es um eine einfache und zügige Bedienung geht, sobald mehr als nur ein paar Einträge vorhanden sind.
• Nach der Neuerstellung eines Elements wie einem Impuls bleibt man auf der Bearbeitungsansicht, statt in die Liste zurück zu kehren. Daher ist ein eigentlich immer ein unnötiger Klick auf "Abbrechen" erforderlich, um die Ansicht zu verlassen... und den Link muss man sich ggf. sogar erst erscrollen, wenn man keine Riesenauflösung hat
• Zur Neuerstellung muss man unter die Liste scrollen, statt einen Button oben zu haben
• Bei der Auswahl von Variablen muss man auf Hilfsmittel wie eine Suche oder Auto-Vervollständigung nach Eingabe von "{{" in Eingabefeldern leider verzichten
• Die Auswahl eines Impulses für ein Tag ist ähnlich unübersichtlich, da es nur eine Auswahlliste gibt. Zumindest kann man hier zum Suchen einfach Buchstaben eingeben und so an die passende Stelle der Liste springen
• "Extrem rudimentäre" Eingabe und Pflege von JavaScript Code
  
• Die Funktionalität des Debuggers ist eingeschränkt, wenn man z. B. ermitteln möchte, warum bestimmte Tags zu bestimmten Ereignissen nicht gefeuert haben
• Umlaute machen gern mal Ärger
• Ordner wären prima, um Tags etc. zu organisieren

Stolperfallen

Auf folgende Besonderheiten sollte man achten, wenn man seine ersten Schritte mit dem Matomo Tag Manager macht und eher aus der Erfahrung mit dem GTM an die Dinge herangeht:

• E-Commerce braucht Benutzerdefinierte HTML Tags zur Übergabe, um "trackEcommerceOrder" manuell aufzurufen und die E-Commerce-Daten aus dem _mtm zu übernehmen. Noch zumindest.
• Tracking mit dem MTM kann auch auf dem Google dataLayer aufgebaut werden, solange der Push - siehe unten - schon stattfindet, bevor die Seite ganz geladen ist. Aber:
  • _mtm ist nicht der dataLayer! Bei Umstellung kann man mit "Altlasten" aus vorangegangenen Pushes schon mal unerwartete Dinge erleben
  • Der dataLayer kann, muss aber nicht vor dem MTM Code initialisiert werden. Diese Werte stehen aber nur dann zur Verfügung, wenn ein Push in den dataLayer passiert, nachdem der MTM Code geladen wurde... aber vor dem DOM Ready der Seite. Spätere Pushes kommen offenbar nicht an. Das ist zu wenig für eine Nutzung im Rahmen von Enhanced E-Commerce im Google Format oder anderen Dingen, die erst nach dem Seitenaufruf / -aufbau stattfinden. Daher ist eine "Übersetzung" oder Umstellung erforderlich
• dataLayer-Variablen können im MTM genauso wie _mtm-Variablen ausgelesen werden. Es gibt also keine Differenzierung der Datenschicht, aus der Informationen stammen
• Es gibt ein Tag für Google Analytics. Aber das ist so rudimentär, dass man auch hier - z. B. zum Setzen von Feldern - auf eigene HTML Tags angewiesen ist. Oder wenn man etwas anderes als einen Seitenaufruf vermessen will. Zumindest sind die Hits anonymisiert, ohne dass man dazu ein Feld braucht wie im GTM

Trotzdem: Klares "Ja"!

Wenn man es dank des ganzen Gejammers nicht bemerkt haben sollte: Ich halte den MTM für einen nutzbaren und nützlichen Tag Manager - vor allem dort, wo man sich bewusst gegen die Lösungen von Google entscheiden will oder muss. Fehlende Komplexität wird i. d. R. eher hilfreich als hinderlich bei einem Umstieg sein. Und man kann ungeachtet der kleinen oben angesprochenen Ärgernisse bei der Bedienung auch wirklich "Spaß" mit dem MTM haben. Wenn man denn überhaupt Nerd genug und daher in der Lage ist, Spaß an der Arbeit mit einem Tag Manager zu entwickeln 😉

Soll künftig Matomo den Part der Webanalyse übernehmen, sollte der zugehörige Tag Manager auf jeden Fall genutzt werden, da er ähnliche Vorteile und Flexibilität mit sich bringt, wie es der Google Tag Manager (nicht nur, aber meistens) für Google Analytics Trackings leistet.