Piwik und QlikView

Mein neues Freizeitprojekt ist eine Adhoc-Webanalyseanwendung auf der Basis von QlikView. Piwik wird dazu die Daten liefern.

Über ein HTTP-API lassen sich Daten aller Reports aus einem Piwik-System extrahieren. Die Daten werden dabei in verschiedenen Formaten geliefert, ein einfacher CSV-Export scheint mir zunächst die besten Resultate zu versprechen. QlikView unterstützt zwar auch HTML und XML als Eingabeformate, der Overhead bei der Übertragung wird jedoch deutlich größer.

Eine automatische Aktualisierung der Applikation wird dadurch möglich, dass Piwik eine Authentifizierung mittels Hash-Token unterstützt.

Wünschenswert wäre ein Durchgriff auf Detaildaten. Wenn man die Reports erst auf dem QlikView-Client rechnet, wird die Flexibilität nämlich noch größer. Man könnte sich dann von den festgelegten Zeitgranularitäten (Tag, Woche, Monat, Jahr) verabschieden und z. B. Unique Visitors über einen beliebig festzulegenden Zeitraum messen, wie etwa die Laufzeit einer Kampagne. Das ist meines Erachtens der entscheidende Vorteil, den der Einsatz eines In-Memory-Analysetools in diesem Umfeld bringt.

Der grundlegende Mechanismus einer solchen Integration ist auch auf andere Webanalyse-Tools übertragbar, soweit sie per API abfragbar sind. Das eröffnet viele mögliche Anwendungsfälle.

IE 8: Webtracking in Zukunft unmöglich?

Wie ich da so gestern mit meiner Piwik-Installation herumspielte und -testete, bat ich auch eine Freundin, für mich Site-Traffic zu erzeugen. Sie nutzt Internet Explorer 8 auf Windows 7. Zu meinem Schrecken konnte ich aber ihre Zugriffe weder in Piwik noch auch im parallel laufenden Google Analytics sehen.

Die Erklärung fand ich anschließend hier. Microsoft hat im IE 8 eine einfache, aber schlaue Heuristik eingeführt, um Tracking-Skripte auszuhebeln: Wenn der Browser entdeckt, dass mehr als 10 Websites auf dieselbe Offsite-Skriptressource zugreifen, stuft er sie als Trackingcode ein und blockiert sie. So zumindest sagt es der zitierte Artikel. Ich vermute, dass die Kriterien sogar noch schärfer sein müssen. Denn mein Piwik-Trackingcode wird nur von meinen eigenen Domains genutzt, und das sind nicht mehr als drei. Wahrscheinlich reichen also schon 10 unterschiedliche URLs, um den Tracking-Alarm auszulösen.

Es scheint, dass es bis jetzt keinen Workaround gibt. Natürlich gibt es andere Trackingverfahren, die aber allesamt näher am Server ansetzen. Aber das Javascript-basierte Tracking hatte sich in den letzten Jahren, auch wegen der Einfachheit und Flexibilität der Implementation, im Online-Marketing-Bereich als Standard durchgesetzt. Mehr oder weniger große Unschärfen gab es dabei immer. Zum Beispiel konnte allein die Ladereihenfolge oder die Stelle, an der das Script-Tag in den Seitencode eingebunden wird, die Messergebniss massiv beeinflussen. Auch gibt es schon längst Tracking-Blocker für Browserplugins wie Adblock Plus für Firefox, die aber explizit installiert und aktiviert werden müssen. Während man sich aber selbst eine dreißigprozentige Abweichung damit schönreden kann, dass ja immerhin der Trend stimmt, führt der neue IE-Default dazu, dass gar nichts mehr gemessen werden kann.

Mit einem Auge freue ich mich natürlich auch darüber. Es war schon lange Zeit, den Usern mehr Privacy zurückzugeben. Dass ausgerechnet Microsoft hier vorwärts geht, verdient ein dickes Lob.

Andererseits ist Tracking für die Onlinebranche heutzutage unverzichtbar. Ich bin gespannt, wie lange es dauern wird, bis es einen Workaround für die Trackingblockade im Internet Explorer 8 gibt.

Piwik

Diesen Blog analysiere ich jetzt auch mit Piwik. Bin überrascht, wie schnell und leicht die Installation von der Hand ging.

Das Tool ist Freeware und aufgrund seiner Architektur eine echte (bessere?) Alternative zur Nutzung von Google Analytics. Der große Vorteil ist, dass ich bei der Nutzeung von Piwik keine Daten aus der Hand gebe. Sie liegen auf meinem eigenen Server. Da alle Detaildaten archiviert werden, lässt sich der Reportumfang im Nachhinein erweitern. Das wird durch die offene, plugin-basierte Architektur erleichtert.

Strukturelle Nachteile sehe ich eigentlich nur zwei:

• Die Software setzt auf MySQL auf. Bei high-traffic-Websites dürfte man hier schnell an Performance-Grenzen stoßen.
• Die Implementationssprache ist PHP, eine meiner Meinung nach "unordentliche" Sprache. Aber das mag mancher auch als Vorteil betrachten.

Ich denke, dass es ein Leichtes sein sollte, auch eine e-commerce-Analyseumgebung auf der Basis von Piwik aufzusetzen. Die Software erlaubt eine größere Flexibilität als so manches kommerzielle Tool, und diejenigen Tools, die mit ihrer Baukastenstruktur werben, können sich von der Produktreife dieses freien Tools hier und da vielleicht noch eine Scheibe abschneiden.

Pentaho goes SAP

Leicht off-topic, aber doch noch in das Gesamtthema passend:

Der Trend zur Open-Source-BI verstärkt sich. Das Linux-Magazin schreibt, dass ein Wiener Unternehmen einen SAP-Konnektor für die Open-Source-Suite Pentaho anbieten wird. Damit wird diese Art von Software wieder ein Stück attraktiver für Projekte, die eine Integration von Daten aus verschiedenen Quellen erfordern. Pentaho zieht damit auf einer weiteren Ebene mit den kommerziellen Tools gleich.

Meines Erachtens zeigt sich hier auch der Grad der Reife eines Marktes. Wie zuvor bei den Datenbanken, kommt auch BI immer mehr in den Zustand einer Commodity-Technologie, bei der man nicht mehr an Lizenzen verdient, sondern eben am Know-How, wie die Technologie auf die Datenlandschaft des jeweiligen Kunden angewandt werden kann. Silo-Modelle, seien sie physisch oder politisch motiviert, sind nicht mehr zukunftsfähig.