Matomo ➡ Erfahrungen, Preise und Bewertungen

Auf der Suche nach dem fehlenden Umsatz

Als Softwareentwickler betreue ich seit über 20 Jahren diverse Klein- und Mittelständische Unternehmen bei ihren Aktivitäten im Internet. So kam es natürlich auch dazu, das ich Google Analytics und das Remarketing für Google Ads integrieren sollte.

Schnell wurde klar, das bei den Trackingdaten von Analytics aber vor allem auch bei den Conversions von Google Ads irgendetwas nicht stimmen kann; denn die Umsätze stimmten nie mit denen der von mir entwickelten Software zur Vermarktung von Ferienwohnungen überein.

Lange wurde herumgerätselt und die Ursache in falsch eingebundenen Trackingcodes gesucht, aber die Ursache lag ganz woanders …

Diesen Artikel jetzt als Podcast anhören

Jetzt anhören auf: Spotify | Apple Podcast | Google Podcast

Matomo – eine Alternative zu Google Analytics

Eine der ersten Untersuchungen führt zum Einsatz von Matomo in Ergänzung zu Google Analytics. Matomo ist eine Open Source Lösung für das Tracking von Besuchern und war lange unter dem Namen Piwik bekannt.

Ein großer Vorteil von Matomo ist, dass diese Software auf dem eigenen Server betrieben werden kann und man damit die gesamten erfassten Daten zur Verfügung hat. Aber auch in Hinsicht auf die Anforderungen im Rahmen der DSGVO bietet Matomo Vorteile. Natürlich erkauft man sich diese Vorteile mit neuen Aufgaben und teilweise auch durch Lizenzkosten für bestimmte Module. Aber dazu später mehr.

Schon der direkte Vergleich der Besucherströme und der Umsätze ließ aufhorchen; im Gegensatz zu Google Analytics wurden teils 10 bis 15 % mehr Besuchersessions und einige Umsätze mehr erfasst; aber die Umsätze waren noch immer nicht identisch mit denen aus dem Verwaltungssystem.

kostenfreies Webinar

Vollständiges Besucher-Tracking aus der Anwendung mit Matomo — Joachim Nickel

Das Tracking von Besuchern innerhalb der Webseite wird zunehmend schwieriger; sei es durch Zählverluste durch Opt-In-Bannern auf Grund der DSGVO oder durch die zunehmende Anzahl an Besuchern mit AdBlockern. In di...

Gratis anschauen

Besucher-Tracking aus der Anwendung

Im weiteren Verlauf entwickelte ich dann die Idee, Javascript als Tracking-Quelle abzulösen und direkt aus der Anwendung jede Aktion auf der Webseite zu protokollieren.

Leider bietet Google Analytics keine Schnittstellen, um Daten unabhängig von der Javascript-API zu erfassen, aber Matomo verfügt über eine umfangreiche API, um alle gewünschten Daten direkt zu erfassen.

Die Umsetzung eines Trackings aus der Anwendung – ich nenne das Background-Tracking da es im Hintergrund ohne Zutun des Benutzers/Browsers erfolgt – ist umfangreicher als nur einen Javascript-Code in ein HTML-Template zu integrieren. Aber es ist auch kein Hexenwerk. Im Grunde braucht es nur eine zentrale Funktion die zum Laufzeit-Ende der Anwendung die zuvor gesammelten Daten an die API von Matomo übergibt. Die von mir entwickelte Erweiterung für das CMS Contao, die auf Github (https://github.com/chopsol/contao-matomo-tracker) zur Verfügung steht, kann gerne als Grundlage verwendet werden.

Doppelt so viele Besucher und 90 % mehr Page-Views?

Neben den korrekten Umsatzzahlen waren die weiteren Kennzahlen bemerkenswert. Es gab auf einmal mehr als doppelt so viele Besuchersessions und auch die Anzahl der Page-Views war fast doppelt so hoch gegenüber denen Zahlen bei Google Analytics. Wie kann das sein?

Ausflug in die Analyse der Logfiles

Leider war die Analyse etwas aufwendiger, denn dank der DSGVO waren die IP-Adressen komplett zu 0.0.0.0 anonymisiert. Aber es gibt ja zumindest noch den User-Agent und den Zeitstempel um im Groben die zusammengehörigen Anfragen zu identifizieren.

Glücklicherweise sollten durch den Einsatz von Matomo und der lokalen Installation diese Zugriffe ebenfalls im Logfile (siehe auch unser Artikel zur Logfile-Analyse) auftauchen; wäre nur Google Analytics verwendet worden, hätte man deren Nutzung dort natürlich nicht gefunden.
Wir konnten nachvollziehen, dass es massenhaft Zugriffe auf die HTML, Image, CSS und Javascript-Dateien gab, aber bei vielen Browsern keinerlei Logfile-Einträge für das Javascript von Matomo auftauchten. Ergo musste irgendetwas diese Aufrufe blockieren.

Ad-Blocker blockieren auch Besucher-Tracking

Die Antwort war erstaunlich: mit hoher Wahrscheinlichkeit waren es Ad-Blocker oder Browser wie Brave, die Tracking-Skripte nicht ausführen.

Laut einer Untersuchung von statista lag der Anteil der Ad-Blocker 2018 in Deutschland bei 33 % ¹⁾. Weltweit sah Globalwebindex einen Traffic-Anteil von 47 % durch Ad-Blocker ²⁾ – also fast die Hälfte des Traffics wird demnach auch beim Javascript-basierten Tracking von Besuchern nicht erfasst.

In der gleichen Studie geht Globalwebindex in Europa Ende 2018 von etwa 40 % der User aus, die mindestens einmal monatlich mit einem Ad-Blocker surfen.

¹⁾ https://www.statista.com/statistics/351862/adblocking-usage/
²⁾ https://www.globalwebindex.com/reports/global-ad-blocking-behavior

Der Anteil der Desktop-User, die einen Ad-Blocker nutzen, liegt dabei laut Globalwebindex für Europa mit 36 % der User am höchsten; auf Tablets sind es mit 13 % der User am wenigsten und bei den Smartphone-Usern sind es 23 %.

Die geringere Verbreitung bei den Mobil-Devices liegt vermutlich an der fehlenden Plug-in Architektur. Um einen Ad-Blocker auf iOS oder Android nutzen zu können, muss man vom Standard-Browser auf eine Alternative wie Brave oder Ghostery zurückgreifen; und ich merke es bei mir selbst – Safari auf iOS gewinnt derzeit noch häufiger in der Nutzung, da es der Standard-Browser beim Anklicken von Links aus E-Mails & Co ist. Aber das wird sich mit iOS14 ändern, da dort der Standard-Browser selber festgelegt werden kann.

Dass der Anteil der „Jungen“ Internet-Nutzer bei der Nutzung von Ad-Blocking höher liegt als in der älteren Generation, ist wohl kaum verwunderlich.

Weitere Untersuchungen mit dem Background-Tracking

Im Weiteren habe ich das Tracking der Besucher aus der Anwendung heraus auf diversen Webseiten eingesetzt. Je nach Kundenstruktur konnte man zwischen 30 % und 100 % mehr Besucher-Sessions und Page-Views identifizieren. In diesen Werten ist jedoch noch eine gewisse Quote an Bots und Spidern enthalten, die nicht erkannt wurden; denn genau diese Erkennung ist eine der größten Herausforderungen beim Tracking aus der Anwendung.

Interessant ist auch der Vergleich der Geräteklassen. Aufgrund der bereits genannten höheren Verbreitung von Ad-Blockern auf Desktop-Systemen konnte ich bei fast allen Seiten in den Auswertungen eine Verschiebung zwischen Mobil- und Desktop sehen; im Background-Tracking waren immer weit mehr Desktop-Systeme erfasst als beim Javascript-Tracking.

Grundlage für das Background-Tracking

Background-Tracking aus der Anwendung und Caching vertragen sich nicht

Um Background-Tracking aus der Anwendung durchführen zu können, muss jeder Zugriff des Besuchers von der Anwendung beantwortet werden. Jede Form des Caching ist hierbei ein Hindernis, da dadurch die vollständigen Klickpfade nicht protokolliert werden können.

Browser-Caching muss deaktiviert werden

Das Caching der HTML-Seiten im Browser muss durch entsprechende Header deaktiviert werden. Wenn zum Beispiel die Webseite erstmalig abgerufen wird und der Browser das HTML speichert, dann würde nach dem Besuch einer weiteren Seite und dem Zurückkehren zur Ausgangsseite diese nicht erneut vom Server angefordert; ergo würde die Anwendung diesen Aufruf auch nicht protokollieren können und der Klickpfad wäre somit nicht vollständig.

Im Gegensatz dazu kann beim Tracking per Javascript auch lokales Caching genutzt werden. Javascript wird unabhängig davon, ob das HTML aus dem Cache oder frisch vom Server geladen wird, immer ausgeführt.

HTTP Caching muss umgangen werden

Wenn der gesamte Traffic einer Website über einen HTTP Cache für Lastverteilung geleitet wird, kommen die Anfragen ebenfalls nicht in der Anwendung an. Dies trifft sowohl auf Content Delivery Networks (CDN) als auch auf Reverse-Proxys wie Varnish oder HAProxy zu. Selbst vollwertige lokale HTTP Caches, wie sie im CMS Contao ab 4.9 zum Einsatz kommen, müssen deaktiviert werden, um das Background-Tracking zu ermöglichen oder auf Mediendateien (Bilder, Videos, Javascript, CSS) beschränkt werden.

Alternativ ließe sich das Tracking aber auch im Proxy realisieren. Diesen Ansatz habe ich allerdings bisher nur theoretisch durchgespielt.

Bei Anwendungen die lediglich HTML-Fragmente cachen und bei denen das Framework an sich bei jedem Request gestartet wird, können in der Regel weiterhin verwendet werden. Ob dies im Fall Deiner Anwendung möglich ist, müsste bei der Umsetzung geprüft werden.

Nichts Cachen und trotzdem einsetzen?

Caching ist bei vielen Anwendungsfällen eine wichtige Komponente. Überall da, wo es bisher nicht zum Einsatz kommt, steht dem Background-Tracking nichts im Wege. Da, wo es zum Einsatz kommt, stellt sich natürlich die Frage, ob Background-Tracking eine sinnvolle Lösung sein kann. Die Antwort ist ein klares Jain.

Um Kennzahlen für das eigene Kundenprofil zu erhalten, kann das Background-Tracking bei Anwendungsfällen mit HTTP-Caching ggf. nur kurzzeitig oder über A/B-Tests durchgeführt werden. Im Laufe verschiedener Tests hat sich gezeigt, dass – zumindest innerhalb eines definierten Zeitraums – die Verhältnisse zwischen Background- und Javascript-Tracking sich immer eingepegelt haben. Wenn also auf einer Seite in der Regel (real) viele Nutzer mit Smartphones unterwegs sind, ist die Diskrepanz zwischen Background- und Javascript-Tracking weit geringer als bei Webseiten mit vielen Desktop-Nutzern. Die Erkenntnis dieser Abweichung könnte man dann für fundierte Hochrechnungen heranziehen.

Nutzer-Erkennung durch Anwendungssession

Um den Besucher eindeutig einer Sitzung zuordnen zu können, ist es notwendig, dass die Anwendung mit Sessions arbeitet. Wenn die Anwendung für die Bereitstellung z. B. einer Warenkorbfunktion sowieso ein Session Handling verwendet, ist das perfekt. Andernfalls muss allein für das Background-Tracking in der Anwendung die Sessionverwaltung aktiviert werden.

In der Regel sind Sessions in Anwendungen reine Transaktions-Sessions. Das bedeutet, dass Sie nur eine Lebenszeit von meist 30 Minuten haben und beim Beenden des Browsers ebenfalls beendet werden. Damit ergibt sich, dass das Background-Tracking keine wiederkehrenden Besucher erkennen kann. Ganz so wie das Javascript-Tracking bei Matomo mit deaktiviertem Cookie.

Bot-Detection für das Background-Tracking

Während Bots und Spider in der Regel kein Javascript ausführen und damit im Tracking mit Javascript nicht in Erscheinung treten, müssen diese beim Tracking aus der Anwendung heraus manuell erkannt und gefiltert werden.

Die „guten“ Bots geben sich anhand des User-Agent zu erkennen; Google, Bing, Ahrefs aber auch Sistrix, XOVI & Co sind also schnell gefiltert. Aber es gibt diverse Spider u. a. von den geliebten Script-Kiddies, die auf Schwachstellen scannen – und die halten sich natürlich nicht an diese Spielregel.
Um diese Bots zu erkennen, bedarf es einiger Tricks. Eine Möglichkeit relativ gut automatisiert solche Bots zu erkennen, liegt in der eigenen Sessionverwaltung. Die bösen Bots unterstützen in der Regel keine Cookies und rufen innerhalb kurzer Zeit sehr viele Seiten ab; häufig auch Seiten, die nicht existieren. Anhand dieser Parameter und da die Bots mit einem identischen User-Agent sich erkennbar zeigen, kann man über eine Art Honeypot-Funktion die Erkennung durchführen und in der Anwendung das Tracking deaktivieren. Schwieriger wird es bei Crawlern, die regelmäßig einzelne Seiten in längeren Abständen von ein oder zwei Stunden aufrufen. Um solche Aufrufe zu erkennen, kommt man in der Regel nicht umhin, sich auch die Logfiles anzusehen. Hier hilft es enorm, wenn man die IP-Anonymisierung minimiert, da diese Crawler häufig von statischen IP-Adressen aus agieren. Im Folgenden kann man dann für diese IP-Ranges einen Honeypot einrichten, der die Crawling-Anomalien erkennt. Im Folgenden muss man dann die IP-Adressen direkt in eine Denylist eintragen, um das Tracking zu unterbinden.

Aber egal wie gut man die Bot-Detektion trainiert; ein gewisser Anteil wird auch weiterhin in das Background-Tracking einfließen.

Background-Tracking für CMS Contao und JTL Shop

Für das CMS Contao und JTL Shop gibt es Erweiterungen, die die Datenerfassung mit ein paar Einstellungen ermöglichen und somit der Aufwand das Background-Tracking für seine eigene Website zu testen, sehr gering ist. Neben der Erweiterung muss man noch eine eigene Matomo Installation einrichten. Was es dabei zu beachten gibt, folgt nun.

Was ist Matomo

Wie Eingangs erwähnt, ist Matomo ein Open Source System zum Tracken von Besuchern, welches bis Anfang 2018 unter dem Namen Piwik bekannt war.

Matomo kann man „on Premise“, d. h. auf seinem eigenen Server installieren oder aber als Cloud-Lösung mit Hosting in Deutschland anmieten. Die Cloud-Lösung werden wir im Weiteren nicht weiter betrachten, sondern uns um die selbst gehostete Lösung konzentrieren.

Voraussetzungen für Matomo

Als Grundlage kann jeder Webserver mit Apache, Nginx oder dem IIS in Verbindung mit PHP ab 5.5.9; besser natürlich ein aktuelles PHP 7.2+ dienen. Zur Datenhaltung wird eine MySQL oder MariaDB benötigt. Dann kann es schon losgehen. Bei kleinen Webseiten mit weniger als 100.000 Page-Views pro Monat reicht zumeist die Installation auf dem Shared-Hosting oder vServer, auf dem die Webseite läuft. Für Websites mit bis zu 1 Million Page-Views gilt als Empfehlung einen separaten Server für Matomo mit mind. 4 CPUs, 8 GB RAM und einer 250 GB SSD einzurichten und bei noch mehr Page-Views wird empfohlen, Matomo auf einen separaten Datenbank- und einen Frontend-Server zu verteilen.

Installation und Updates von Matomo

Die Installation von Matomo ist durch den Setup-Assistenten in 8 Schritten erledigt und benötigt nach der Übertragung des Systems auf den Server per FTP nur noch die Zugangsdaten für die Datenbank.

Es werden immer wieder kleinere und größere Aktualisierungen veröffentlicht, die man in der Regel ebenfalls über den eingebauten Update-Prozess schnell übernehmen kann. Bei größeren Installationen müssen ggf. die Aufgaben für die Anpassung in der Datenbank über die Shell ausgeführt werden. Bei kleineren Installationen kann das getrost das Update-Modul über den Webbrowser erledigen.

Man sollte in jedem Fall darauf achten, dass die Software immer aktuell gehalten wird. Ganz so wie es wichtig ist, immer eine aktuelle Version des Shopsystems oder des CMS einzusetzen, um eventuelle Sicherheitslücken zu schließen, so gilt dies natürlich auch für die Analytics Software. Daher muss man dies als auch eventuelle Eingriffe in die Datenbank, falls mal was klemmt, als entsprechenden Kostenpunkt mit einplanen.

Grundeinstellungen von Matomo

Nach dem Abschluss der Installation sollte man in den Einstellungen von Matomo noch ein paar Dinge anpassen. Zum einen empfiehlt es sich, auch bei kleineren Installationen die Archivierung lieber über einen Cronjob auszuführen, als diese bei der Anzeige im Browser berechnen zu lassen.

Des Weiteren sollten die Einstellungen zur Anonymisierung überprüft und eingestellt werden.

Und zu guter Letzt kann dann der Javascript-Code, der in die Webseite eingebunden werden soll, noch angepasst werden.

Matomo und die DSGVO

Nach der aktuellen Auffassung des Datenschutzbeauftragen des Landes Baden-Württemberg kann man Matomo per Javascript-Tracking auch ohne Opt-in über ein Consent-Banner einsetzen, sofern man ein Tracking ohne Cookie verwendet und keine weitere Datenzusammenführung durchführt. Siehe: https://www.baden-wuerttemberg.datenschutz.de/faq-zu-cookies-und-tracking-2/

Um Matomo per Javascript ohne Cookie tracken zu lassen, muss man im Javascript-Code den Parameter _paq.push([‘disableCookies’]); ergänzen. Ein Nachteil des Trackings ohne Cookie ist, dass Matomo wiederkehrende Besucher nicht erkennen kann.

Diese Auffassung vertreten auch einige weitere Rechtsanwälte bzw. Datenschützer. Andere sind jedoch der Ansicht, das das Fingerprinting, welches Matomo zur Erkennung der Nutzer, um diese zu einer Besuchersessions zusammenzufassen verwendet, ebenfalls als eine Art „Cookie“ anzusehen ist und daher ein User-Consent auch für den Einsatz von Matomo notwendig ist.

Welche dieser Ansichten sich schlussendlich durchsetzen wird, muss sich wohl noch zeigen. Bitte beachte, das diese Ausführung keine Rechtsberatung darstellt. Konsultiere hierzu bitte Deinen Datenschutzbeauftragten, der den Einsatz von Matomo in Deinem Spezialfall individuell bewerten sollte.

Was fehlt in Matomo gegenüber Google Analytics

Die Grundversion von Matomo bietet die meisten klassischen Parameter wie die Anzahl der Besucher, die Seitenansichten, durchschnittliche Aufenthaltsdauer und Absprünge, Software, Geräte und Browser, Bildschirmauflösungen und auch die Auswertung von internen Suchen, Downloads, externe Verweise sowie E-Commerce Faktoren, wie abgebrochene Warenkörbe und Umsätze. Aber einige Funktionen sind nur über kostenpflichtigen Premium-Module verfügbar. Diese werden im Abo-Modell über den in Matomo integrierten Marketplace angeboten. Die Kosten sind abhängig von der Anzahl der Benutzerkonten, die in Matomo angelegt sind. Die kleinste Lizenzstufe umfasst meist bis zu 5 Benutzer.

Aber einige Funktionen von Google Analytics kann man für Matomo nicht hinzukaufen. Hierzu zählen unter anderem die demografischen Merkmale wie Alter, Geschlecht und Interessen der Besucher.

Die Standorterkennung ist in Matomo nur über die Lizenzierung entsprechender IP-Adress-Datenbanken möglich. Matomo unterstützt hierfür die kostenfreien Datenbanken von Maxmind und DBIP, die jedoch nicht vollständig und nicht immer aktuell sind. Alternativ stehen die kostenpflichtigen Datenbanken von Maxmind zur Verfügung.

Kostenpflichtige Premium-Module

Viel wichtiger sind aber je nach Ziel des Trackings die Module für Funnel- (ab 179,- € pro Jahr) und Kohorten-Analysen (ab 89,- € pro Jahr) sowie für A/B-Testing (ab 199,- € pro Jahr) und eine Integration für Google Ads, welches als Modul „Paid Advertising Performance“ im Marketplace ab 149,- € pro Jahr angeboten wird.

Fazit

„Traue keiner Statistik, die Du nicht selbst gefälscht hast“ lautet eine alte Weisheit. Und bei Webstatistiken gilt das leider aufgrund der technischen Grundlagen fast genauso. Die stetige Vermehrung von Anti-Tracking-Funktionen in den Browsern, sowie der vermehrte Einsatz von Ad-Blockern führt neben der Problematik der Consent-Abfrage, um DSGVO-konform zu sein dazu, dass eigentlich keine Statistik wirklich zu 100 % die Besucher einer Webseite abbilden kann.

Das Background-Tracking kann, sofern das Thema Caching ausgeklammert wird und man eine gute Bot-Erkennung einsetzt, ein wesentlich genaueres Bild abliefern. In den meisten Fällen wird Background-Tracking keine dauerhafte Lösung sein; schon allein aufgrund der Einschränkungen im Caching. Aber um einen Einblick in die Abweichung bei der jeweils individuellen Besucherklientel zu erhalten, ist es ein probates Mittel.

Ob man das Tracking direkt in der Anwendung oder ggf. kombiniert in einem Reverse-Proxy wie Varnish umsetzt, wird jeder selbst entscheiden müssen. Auch, ob sich der Aufwand des Trackings überhaupt in eine individuelle Softwarelösung zu integrieren lohnt, wird von Fall zu Fall unterschiedlich sein.

Wer das CMS Contao oder einen JTL Shop einsetzt, kann jedenfalls schon heute mit sehr geringem Aufwand mal schauen, was auf der eigenen Seite ohne den Verlust von Ad-Block-Usern im Tracking los ist.

Und wer dabei Unterstützung benötigt, kann mich gerne kontaktieren.

Also dann: let’s track 🙂