Markus Baersch

Wenn potenzielle Wechsler von Analytics zu anderen Lösungen vor der Auswahl stehen, welches Tool künftig zum Einsatz kommen soll, ist in den letzten Jahren speziell in der Gruppe der "kleineren" Lösungen eine reiche Auswahl entstanden. Mit pirsch.io tritt eine weitere leichtgewichtige Webanalyse Lösung für cookie- und consentfreien Betrieb an. Pirsch ist - einfach ausgedrückt - ein funktionales Abbild (AKA "Clone") von Plausible. Das ist nicht wertend zu verstehen, sondern bedeutet, dass alle Funktionen, die man von Plausible kennt, im Wesentlichen auch bei Pirsch zu finden sind. Ebenso wie das Vorbild ist pirsch.io in großen Teilen als Open Source Projekt einsehbar. Der Anbieter stammt aus Deutschland, wo auch das Hosting von Dienst und Daten stattfindet. Das macht diese Lösung - zusammen mit vergleichbaren Preisen - zu einer validen Option bei der Wahl eines Google Analytics Nachfolgers in der "Reporting-Klasse". Was steckt drin?

Reporting / Statistik als Kernfunktion

Die Überschrift soll verdeutlichen, dass sich Pirsch in die gleiche Kategorie einsortiert, wie das (vermeintliche) Vorbild Plausible oder andere typische Vertreter wie Simple, Fathom, Digistats (siehe Kurztest) oder die Trackboxx. Mit gemeinsamen Merkmalen wie:

• Betrieb ohne Cookies und Consent Dialog
• Erkennung von Besuchern via Fingerprint
• Fokus auf Web-Statistik
• Dashboard mit einfachen Komplettreports zu Seiten, Quellen, Kampagnen etc.
• API für Reporting und Datensammlung

Anhand einer öffentlichen Demo kann man sich einen schnellen ersten Eindruck vom Tool machen. Eine kostenlose Fassung „bis zu x Seitenaufrufe“ gibt es hier nicht, dafür ist ein 30-Tage-Testzugang unkompliziert zu erstellen, der einen ausführlichen Check gegen die eigenen Anforderungen problemlos möglich macht. Es gibt wie bei jedem Kandidaten ein paar Dinge, die in einigen der anderen Tools nicht oder anders angeboten werden. Dazu gehört z. B. ein „Drill Down“ per Klick als gefilterte Ansicht des Dashboards (analog Plausible).

Weitere Filter-, Such- und Exportfunktionen sind im Dashboard verfügbar und erlauben damit die Auswertung der Daten innerhalb und außerhalb des User Interface. Berichte zu Seiten (Alle, Einstiegs und Ausstiegsseiten) können optional nach Seitentitel statt Pfad gruppiert werden und zeigen ansonsten alle URLs ohne jeglichen Parameter (aus leidlich bekannten Datenschutzgründen). Wenngleich der Fokus auf Seitenaufrufen liegt, die bei Einbindung des Trackingcodes automatisch vermessen werden, gibt es weitere Möglichkeiten, die Vermessung der eigenen Website zu ergänzen und so mehr über die Nutzung zu erfahren. Die beiden Mittel dazu heißen Events und Goals.

Events: für mehr als nur Seitenaufrufe

Wie in einigen andere Tools können neben Seitenaufrufen auch Ereignisse inkl. Event-Eigenschaften durch Aufruf einer Tracking-Funktion vermessen werden. Um Events aus dem Browser zu senden, ist ein eigenes Script vorgesehen. So bleibt die Last durch das Trackingscript bei ausschließlicher Verwendung von Seitenaufrufen möglichst klein. Hinweis: Events zählen genau wie Aufrufe, wenn es um die Bestimmung des Volumens – und damit der Kosten für einen Account – geht.

Beim Versenden von Events können (theoretisch beliebig viele) weitere Eigenschaften / Daten als „Metadaten“ gesendet werden. Diese finden sich dann in den Details zu jedem Event in Reports wieder und werden je nach Bestückung dann konsolidiert für einzelne Werte beliebiger Felder aufgelistet (hier z. B. zwei Events mit dem gleichen „reference“ Wert).

Das ist eine sehr sinnvolle Funktion, die allerdings erfordert, dass man sich bzgl. Datenschutz diszipliniert, was die hier gesendeten Daten beim Einsatz ohne Zustimmung angeht. Meint: Wer hier PII sendet, hat im Ernstfall ein Problem und muss seinen Account löschen und von vorn anfangen.

Ein Event kann neben Name und Metadaten zusätzlich eine Dauer melden (in Sekunden), so dass es Durchschnittszeiten hierzu im Event-Report zu sehen gibt. Wie man der Abbildung entnehmen kann, sind auch längere Zeiträume möglich (wenn man es darauf anlegt 😉)... und die Bestimmung der Durchschnitte des Gesamtevents scheint unabhängig zu sein vom Detailbericht. Dennoch: für bestimmte Zwecke eine hilfreiche Option. Alle anderen Werte, die als Metadaten gesendet werden, sind ansonsten „funktionslos“. Meint: Wer hier Summen, Durchschnitte oder sonstwas bilden möchte, muss die Daten exportieren und dies extern erledigen. Konsistenz in der Bestückung hinsichtlich Datenformat und -typ der einzelnen Angaben in den Metadaten liegt zudem voll auf Senderseite, denn es muss keine vorherige Definition von Feldern, Formaten und Zweck im Tool selbst erfolgen. Das erlaubt viele Freiheiten und ermöglicht schnelle Erprobung, denn die Daten sind nach dem Senden mehr oder weniger „sofort“ in Reports sichtbar.

Goals: Keine Analyse ohne Ziele!

Es können Ziele aus Basis von Seitenaufrufen oder Events definiert werden, die in einer (isolierten) Liste betrachtet werden können. Über die gefilterte Detailansicht zu einzelnen Zielen sind Merkmale wie Quellen, Kampagnen etc. einsehbar. Es gibt aber (anders als z. B. bei der Trackboxx) keine Auflistung der erreichten Ziele als Metrik-Spalte im Dashboard oder Detail-Übersichten.

Zur Auswertung muss also auch hier der o. a. Weg dienen, ein einzelnes Ziel aus der Liste per Klick zum Filter des Dashboards zu machen und dann dort z. B. Infos darüber zu erhalten, aus welcher Quelle die Besucher stammten, die ein bestimmtes Ziel erreicht haben.

Setup

Ein Account ist nach der Anlage schnell konfiguriert und man kann nach dem Einbau des Trackingcodes prinzipiell schon nach den ersten Test-Aufrufen direkt Ergebnisse im Dashboard sehen.

Tipp: Es ist dennoch eine gute Idee, sich vor dem Einbau des Trackingcodes Gedanken darüber zu machen, mit welchen Optionen man einsteigen möchte. Die Auswahl der Einstellungsmöglichkeiten ist begrenzt, so dass man nicht viel Zeit investieren muss - es lohnt sich dennoch. Anderenfalls handelt man sich selbst Inkonsistenzen in den Daten ein. Ein Beispiel: Es ist wie o. a. wählbar, ob Titel oder Pfade dargestellt werden sollen. Diese Einstellung hat keine Auswirkung auf bereits gesammelte Daten. Wer also mit URLs startet und dann erst auf Titel umschwenkt, hat je nach Auswertungszeitraum eine Mischung aus beidem in denen Reports:

Es gibt verschiedene Möglichkeiten, das Tool mit Daten zu versorgen. Eine API erlaubt z. B. auch Optionen zum typischen Einsatz anhand eines Trackingcodes für die eigene Website - was aber sicher der üblichste Weg ist. Der Code sieht ein Opt Out per DNT Header vor. Durch verschiedene Data-Attribute können zudem einige weitere Optionen gesteuert werden (Adresse des Tracking-Endpunkts etc.- zu finden im Code) und ein paar andere wie Ausschlüsse von Seiten, eigenen Besuchen etc. Eine parallele Verwendung von mehreren Dashboards / Accounts erlaubt RollUp-Properties.

Der Tracking Code sammelt Breite und Höhe des Bildschirms ein – Merkmale, die vermutlich in den Fingerprint einfließen; in Reports hingegen sieht man dazu nichts (obschon es einen Bereich „Screens“ im Dashboard als Option zu Browser, Betriebssystem etc. gibt). Das ist einer von mehreren Unterschieden zu Plausible, wo nur die Breite erhoben wird – aber dafür die des Browsers statt des Screens (was streng genommen aus Sicht des TTDSG tatsächlich einen Unterschied ausmachen kann).

APIs und „nicht nur Web“

Alternativen wie eine serverseitige Anbindung oder ein Proxy für das Trackingscript sind vorbildlich dokumentiert. Damit ist z. B. die Nutzung eines serverside GTM mit den dortigen Bordmitteln (ein HTTP Request Tag) umsetzbar – mit etwas Custom Code sogar inkl. des Autorisierungs-Parts. In Summe ist die Verfügbarkeit einer API Anbindung sowohl bei der Versorgung mit Daten als auch dem Abruf von Reports ein Merkmal, das pirsch.io für individuelle Anbindungen an bestehende Systeme empfiehlt – und ggf. auch die Vermessung von mehr als nur einer Website (oder App). Nach eigener Aussage des Anbieters passiert dies auch durchaus in nennenswerter Weise und Support bei der individuellen An- bzw. Einbindung gehört zu den angebotenen Leistungen.

Generell war der Support während meiner kurzen Testphase vorbildlich. Fragen werden schnell beantwortet und Vorschläge nach Prüfung einer (leider offenbar nicht öffentlich einsehbaren) Roadmap hinzugefügt.

Data Retention

Wie viele andere Anbieter behält der Account seine Daten bis zur Löschung des Accounts selbst. Es gibt also keine begrenzte Datenhaltung (auch nicht optional) und da es sich nicht um Daten handelt, die unter die DSGVO fallen, ist das vermutlich sinnvoll.

Details machen den Unterschied?

Ist pirsch.io also im Wesentlichen ein kompletter Clone von Plausible? Auf den ersten Blick mag es so erscheinen: Der Aufbau, die Bedingung und der Umfang der Reports sind sehr ähnlich. Hier das Dashboard von Plausible.

Es gibt aber durchaus (kleine) Details, die sich unterscheiden. So ist z. B. die Auswahl des Reporting-Zeitraums theoretisch gleich aufgebaut und arbeitet sogar in beiden Fällen auch mit Hotkeys zum schnellen Wechsel (wenngleich unterschiedlich), aber eine Eingabe eines eigenen Zeitraums ist z. B. in der Pirsch-Version anders (m. E. komfortabler) geregelt.

Weitere Unterschiede, die die sich bei Pirsch finden:

• Optik: Details wie z. B. wählbare Auflösung (Tag, Woche, Monat, Jahr) und Balken vs. Liniendiagramm für die grafische Darstellung
• Mehr / andere Metiken in Komplettreports wie z. B. Anteil an Seitenaufrufen für einzelne Zeilen
• Integration der Search Console
• Attribute wie Standort DE, Support etc. – siehe oben
• Wiedererkennbarkeit der Besucher: Plausible nutzt (soweit ich weiß) einen Salt bei der Generierung des Fingerprints, der jeden Tag wechselt. Pirsch macht das nicht, sondern ein Hash behält seine Form, solange sich IP, User Agent und die anderen Merkmale (vermutlich die Auflösung, siehe oben) nicht ändern. Eine site-spezifische Komponente (also „Pepper“) verhindert eine domain-übergreifende Erkennung

Umgekehrt gibt es bei Plausible Funktionen wie „Enhanced Measurement“ für Fehlerseiten, Outbound Links und Downloads oder Hosting auf dem eigenen Server, die sich bei Pirsch in dieser Form (noch) nicht finden. Es gibt also bei pirsch.io wie auch allen anderen o. g. Kandidaten einige Besonderheiten, die für den geplanten eigenen Einsatz wesentlich sein mögen. Ein 30 Tage Test ist (wie immer) die beste Option, sich ein Bild davon zu machen, wie gut die Eigenschaften und Besonderheiten die eigenen Anforderungen abdecken, wenn ein Blick auf die Live-Demo und die Dokumentation nicht ausreichen. Im Gegensatz zu anderen jungen Lösungen, die mitunter nur deshalb existieren scheinen, weil jemand Morgenluft gewittert hat und etwas vom zerbröselnden Universal-Analytics-Kuchen abhaben will, scheint mir hier eine Option zu bestehen, die bei einer Auswahl verschiedener Kandidaten einen Platz ebenso verdient wie die o. g. typischen Vertreter ihrer Zunft.