Start » Blog » Analytics / Toolcheck
09.07.2022
Kurztest: Digistats Besucherstatistik
Über einen Kommentar zu meinem Beitrag zu Google Analytics Alternativen beim OMT bin ich auf Digistats aufmerksam gemacht worden. Glaubt man dem Changelog, ist zumindest die öffentlich verfügbare Version noch nicht lange am Markt und auch die ID meines Testaccounts mag darauf hinweisen, dass es noch keine Massen an Nutzern gibt. Wie auch immer: Ich hatte bis zum Kommentar noch nichts davon gehört und war neugierig, was drin steckt in einem Tool, das sich auf der Startseite mit dem Versprechen eine "unkomplizierte und datenschutzfreundliche Besucherstatistik" zu sein in der "Plausible-Klasse" einsortiert, aber zugleich in einer Vergleichstabelle gegen Google Analytics und Matomo antritt. Datenschutzkonform und cookielos.
TL;DR: Ich halte es eher für einen Vertreter der ersten Kategorie... mit Potential. Das Ziel ist aber Reporting, nicht Analyse. Wer mehr wissen will: Hier die Langfassung des Kurztests 😉
Registrierung und Setup
Die Registrierung ist simpel und man landet erstmal unkompliziert im kostenlosen Plan, welcher bis 500 Seitenaufrufe / Monat erlaubt. Dabei sind wirklich nur Seitenaufrufe gemeint. Events werden - wenn man mehr als Seitenaufrufe vermisst - in der Übersicht des verbleibenden Volumens nicht gezählt.
Die Nutzung von Events ist aber ohne erfolgte Einrichtung nicht (leicht auffindbar) dokumentiert. Erst im User Interface der Reports zu Events findet sich eine Erklärung zur sehr einfachen „pa()“ Funktion, die Ereignisse und wahlweise auch Beträge / Werte nebst Währung messbar macht.
Um dort hin zu kommen, muss aber zunächst der Trackingcode auf der Website eingebunden werden. Dank „async“ und „defer“ kann das bedenkenlos im Head des Seitenquellcodes passieren… oder an anderer Stelle, wenn es das eingesetzte System nicht anders erlaubt. Das Script sieht wie folgt aus:
<script data-host="https://digistats.de" data-dnt="false" src="https://www.digistats.de/js/script.js" id="xxxxxxxxxx" async defer></script>
Einmal eingebunden, laufen schnell die ersten Daten ein. Allerdings...
Was ist mit Datenschutzhinweisen und Cookie-Consent?
Consent für Cookies braucht man nicht, denn die Messung kommt ohne aus. Also wird vermutlich ein Fingerprint erstellt. Wie genau die Erkennung funktioniert, bleibt leider unklar, aber es scheint ein regelmäßig wechselndes Salt oder anderes Mittel dafür zu sorgen, dass keine Wiedererkennung möglich ist. Aber: Ich brauche keinen Cookie-Hinweis. Das ist erstmal prima. Daher gibt es das auch als Tipp:
Dass aber darüber hinaus nichts zum bestehenden Tracking in den Datenschutzhinweisen zu nennen ist, halte ich für zu kurz gedacht. Außer dem oben abgebildeten eher unsinnigen Hinweis zu Cookies findet sich aber nichts an Hinweisen oder gar Vorlagen. Folgt man dem Tipp, erklärt man zuerst was Cookies sind, nur um dann zu erklären, dass man keine nutzt. Ich glaube nicht, dass das so bei den meisten Websites wirklich stimmt, also ist dieser Hinweis m. E. eher kontraproduktiv.
Aber es ist z. B. ein Opt Out per "Do Not Track" Header möglich und darauf sollte man hinweisen. Damit das funktioniert, muss im Tracking-Code die Out Out Möglichkeit data-dnt="true" statt data-dnt="false" aktiviert werden. Warum dies nicht per Default aktiv ist? Keine Ahnung. Ich habe mir in meinem Test auf analytrix.de selbst etwas aus den Fingern gesaugt und auf die Opt Out Möglichkeit hingewiesen. Ehrlicherweise habe ich mich dabei an der Vorlage von Trackboxx orientiert, wo man mit diesem Aspekt sorgfältiger umgegangen ist.
Exkurs: Auflösung ohne Zustimmung - Okay?
Ich stelle mir diese Frage regelmäßig, denn es ist mehr oder weniger üblich, Dimensionen und andere Dinge aktiv aus dem Browser oder System auszulesen und für das Tracking zu verwenden. Dazu gehören oft Auflösung, Screen-Größe, Viewport-Breite oder andere Dinge. Und so erhalten auch die Messdaten bei Digistats die Auflösung, welche je nach Auslegung lt. TTDSG im Gegensatz zur Viewport-Breite (wie bei Plausible) mal ja oder mal eben doch nicht ausgelesen werden darf, wenn es keine Zustimmung gibt. Nach der ja nicht gefragt werden soll / muss.
Das mag ein rein deutsches Problem sein (wenn es denn eines ist - die Meinungen sind freilich wie immer bei solchen Themen gut verteilt), aber es bleibt evtl. ein Problem. Bewerten muss es wiederum jeder selbst. Das Data Capturing Script ist aber darüber hinaus erfreulich sparsam, was sich auch auf die Dateigröße auswirkt:
Das liefern die Reports
Im Kern der Besucherstatistik stehen neben der Echtzeit-Ansicht und einem Dashboard vor allem verschiedene Einzelreports zu Seitenaufrufen, separat abrufbaren Einstiegsseiten und – wenn implementiert – Ereignissen (Events).
Erwähnenswert bei den URLs in Seitenberichten ist vermutlich, dass alle Parameter erhalten bleiben. Also auch Click-Identifier oder potenziell problematische Daten. Ich habe es mit einer Mailadresse versucht und diversen typischen Click-IDs - nichts davon wurde sonderbehandelt.
Schade: Conversions können nicht definiert werden. Zwar kann man entsprechende Events anlegen, aber da diese keinen Zusammenhang mit Attribution haben, ist das relativ unnütz. Hier am Beispiel der Seiten:
Alle Listen in solchen Detail-Reports sind nach den (wenigen) angegebenen Dimensionen und Metriken such-, filter- und sortierbar. Ebenso gibt es einen einfachen CSV Export. Die Reports sind allerdings „tot“ und erlauben weder Drill-Down noch Einblenden weiterer Metriken und Dimensionen in Kombination mit vorhandenen, also z. B. Einstiegsseiten nach Kampagne, Verweisquelle o. Ä. Das schränkt den Nutzen zu Analysezwecken (wie auch bei anderen Vertretern dieser „Toolklasse“) deutlich ein. Da auch via API keine echten Rohdaten, sondern „nur“ konsolidierte und unabhängige Daten bereitstehen, bleibt es beim reinen Reporting ohne wirkliche Analyse.
Im Attributionsbereich kann man Besuche (sonst nichts) auf Soziale Netzwerke, Suchmaschinen, Verweise oder Kampagnen (anhand utm_campaign Parametern in URLs) in getrennten Tabellen betrachten. Eine Gesamtübersicht gibt es aber nicht und Attribution bezieht sich hier ausschließlich auf die Generierung eines Besuchs.
Gleiches ist für
- Kontinente, Länder und Städte
- Geräte, Betriebssysteme, Browser und Auflösungen
in eigenen Berichten unter Geografie und Technologie zu finden. Alle Reports sind jederzeit aktualisierbar. Ein eigener Echtzeit Bericht existiert ebenso. Das war es eigentlich auch schon. Übersichtlich stimmt also auf jeden Fall. Schade ist, dass hier (wie bei vielen anderen Vertretern dieser Tool-Klasse) selbst mit den wenigen Daten, die erhoben werden, nicht wenigstens flexibel gearbeitet werden kann. Events auf Quellen zurückführen, Sessions mit Events und ggf. generiertem Umsatz (wenn man ihn denn schon an Events hängen kann) zu kombinieren, statt alles in einzelnen Report-Silos zu halten - das würde Digistats durchaus aufwerten, ohne unbedingt "mehr Daten" sammeln zu müssen.
Als Besonderheit bietet das UI neben Deutsch auch Englisch an; weitere Sprachen scheinen in Arbeit zu sein. Nicht immer ist dabei die Wahl der Bezeichnungen glücklich. In diesem Beispiel hier ist es erstaunlicherweise die deutsche Variante, die irreführend ist, während das englische Pendant die Pfeile passend zur Aussage betitelt.
Reporting - API
Es gibt eine API, die zum Abruf von Reports wie Seiten, Referrer etc. erlaubt. Allerdings ist diese nicht ideal beschrieben. Beim Versuch, mit meinem API Key etwas abzurufen, habe ich außer {"message":"Resource not found.","status":404} zunächst nichts ernten können. Der Grund war die benötigte ID, zu der man in der knappen Hilfe nichts erfährt. Bis ich die richtige ID gefunden habe (die man nur kennt, wenn man die im eigenen Account Sites zuerst ebenso per API abruft) war ich zunächst mit dem Projekt-/Domainnamen, den man auch in Report URLs sieht und der ID, die im Trackingcode steht, eine ganze Weile auf dem Holzweg. Nachdem diese Hürde genommen ist, findet man als Ergebnis von Aufrufen die zu erwartenden Daten aus den Reports im JSON Format:
Damit lässt sich alles an aggregierten Daten auch automatisiert aus dem Tool abrufen. Aber eben leider keine Rohdaten für eigene Auswertungen; Attribution von Besuchen oder Events etc. Trotzdem ist eine API eine gute Idee, wenn die Daten aus dem Tool in andere Datenbanken einfließen sollen oder Konnektoren für Data Studio o. Ä. geplant sind.
Was kann man mit Digistats anfangen?
Es ist wie eingangs schon beschrieben ein Tool mit dem Fokus auf Besucherstatistik in Form einfacher Reports. Analysefunktionen gibt es faktisch nicht und alle Daten bestehen in separaten Bereichen ohne Verbindung zueinander. Wer es genauer wissen will, sollte sich selbst ein Bild machen. Angemeldet und ausprobiert ist Digistats schnell, wenn man sich mit den Datenschutz-Implikationen erst einmal auseinandergesetzt hat (oder auf einer nicht öffentlichen Stage ausprobiert). Es scheint mir noch ein junges Tool zu sein. Allgemein habe ich zumindest einige 404 Fehler erlebt. Das FAQ ist nicht erreichbar, es gibt wenig Infos zum Tracking und Datenschutz. Einige Klicks im Backend zum Öffnen der Reports einer neu versorgten Website (das gibt sich aber später, wenn ein paar Daten eingelaufen sind) haben mich ebenfalls auf Fehlerseiten geführt. Abgeschnittene Elemente bei bestimmten Auflösungen, holprige Formulierungen im UI... alles erscheint noch etwas wackelig. Aber im Kern ist die Funktionalität stabil und nutzbar, mit Kleinkram muss man leben.
Kosten vs. Funktionalität
„Für lau“ ist das Ganze am Ende nicht. Denn mit 500 Seitenaufrufen im Monat wird man nur in Ausnahmefällen auskommen. Insofern ist die kostenlose Variante ein guter Weg, sich selbst ein Bild zu machen, aber auch nicht mehr. Ob man darüber hinaus dann in den bestehenden Staffeln etwas findet, das sich mit anderen Tools messen lässt, muss jeder nach seinen eigenen Vorstellungen selbst entscheiden. Denn auch bei den „kleinen“ Vertretern ihrer Zunft gibt es funktionale Unterschiede. Hier gibt es Events und eine API, woanders mehr Dimensionen, Ziele, Rohdaten oder E-Commerce. Auf Detailebene hat also jedes Tool Stärken und Schwächen.
Die Vergleichstabelle unter https://digistats.de/digistats-vs-google-analytics hilft hier nur bedingt, weil man sich nicht mit Plausible, Simple, Fathom, Trackboxx & Co. vergleicht, sondern (aus Marketingsicht nachvollziehbar) mit Matomo und Google Analytics. Dabei ist sie aber oft schlichtweg unwahr. Man kann über einige Einschätzungen diskutieren und ich denke auch, dass Zeit nicht in Kilobyte gemessen wird, aber alles, was ich hier markiert wurde, ist m. E. unstrittig falsch:
Vielleicht ist aber der Serverstandort, 100% Ökoenergie oder die API ein Merkmal, das den Ausschlag für diese Lösung statt für Trackboxx (wo funktional durchaus mehr zu finden ist und ggf. zum eigenen Volumen passendere Preisstufen existieren), Plausible (im gewissen Rahmen vergleichbar) oder andere gibt. Oder selbst im Vergleich zu Produkten, die funktional „höher“ angesiedelt sind wie Matomo, Piwik PRO (durch den Core Plan bis 500.000 Events immer eine gute Alternative) oder eTracker (funktional - und selbst preislich je nach Traffic die günstigere Wahl - im Vergleich zu Digistats).
Zudem wird sich diese Lösung sicher noch weiter entwickeln. Das muss sie auch, um im Vergleich mit den direkten Konkurrenten bestehen zu können. Wie weit dann neben reinem Reporting auch Analyse ermöglicht wird, muss sich dann erweisen.