Befreiung vom digitalen Überfluss

Matomo cookiefrei

Matomo mit dem Log-Analyse-Tool ohne Cookie-Opt-in DSGVO-konform betreiben.

Der datenschutzbewußte Websitebetreiber verwendet für die Webanalyse oftmals das Open-Source-Programm Matomo. Aber auch Matomo setzt in der Standard-Installation einen Tracking-Cookie – mit allen Problemen die daran hängen. DSGVO-konform ist Matomo dann nur noch mit einem Opt-In-Banner zu betreiben, was ich persönlich lieber ganz vermeiden möchte. Denn neben der schlechten »User Experience« erfasst man dadurch nur noch einen Bruchteil der Websitebesucher. Ein Teil fällt schon weg wegen der »do not track«-Unterstützung von Matomo. Und man kann davon ausgehen, dass die meisten User Tracking nicht erlauben werden, wenn sie aktiv zustimmen müssen. Das gilt natürlich in gleicher Weise für den Einsatz von Google Analytics. Nach meinen Erfahrungen gehen die erfassten Zugriffszahlen in der Statistik durch den Einsatz eines Opt-In-Banners auf 20% zurück. Man verliert dadurch also den größten Teil (80%) der Daten über das Nutzerverhalten!

Ich denke, das sind zwei sehr gute Argumente, wieder zu der guten alten Logfile-Analyse zurückzukehren, die alle Besuchervorgänge erfasst. Da die Logfiles als technisch notwendig gelten, ist eine darauf basierende anonymisierte Statistik nach DSGVO nicht zustimmungspflichtig und kommt ohne lästiges Opt-In-Banner aus.

Viele kennen Webalizer und AWstats als vom Provider vorinstallierte Logfile-Analysetools – und die reichen auch oft, wenn an sich eh' nur dafür interessiert, wie viele Besucher es auf der Website gibt und welche Bereiche oder Artikel viel nachgefragt werden.
Was dagegen nicht so bekannt ist: auch Matomo kann auf der Basis von Logfiles arbeiten. Das hat den Vorteil, dass Kunden, die an Matomo gewöhnt sind, sich nicht umgewöhnen müssen und viele Berichte (wie z.B. die Länderherkunft oder welche Geräte und Software von den Usern eingesetzt wird) weiter funktionieren. Auf einige Feature muss man aber verzichten. Die Ermittlung der Bildschirmauflösung geht nur in Verbindung mit Cookies und auch wiederkehrende Benutzer können nicht mehr identifiziert werden. Außerdem sind in der Statistik nur noch die URLs bekannt und nicht mehr die Seitentitel.

» How to use Matomo Log Analytics Tool…


Meine Implementierung bei Domainfactory

Jeder Provider hat eine andere Umgebung. Ich möchte hier vorstellen, wie ich die Matomo-Logfile-Analyse für Managed Hosting-Accounts von Domainfactory umgesetzt habe.
(Die Anleitung gilt für die alte 32-Bit-Plattform und Matomo-Versionen kleiner als 4.0.0. Für den neuen M64-Tarif und die neueste Matomo-Version werde demnächst Infos ergänzen.)

Vorbereitung

Folgende Daten werden benötigt (Beispieldaten):

  • URL der Matomo-Installation: https://example.com/piwik/
  • absoluter Pfad der Server-Logfiles: /kunden/12345_67890/logs/
  • relativer Pfad der Matomo-Installation: webseiten/example/piwik/
  • token_auth von einem Matomo-User mit Schreibrechten: TOKEN_AUTH
  • Matomo Site-ID von example.com: SITE_ID

Im Kundenbereich von Domainfactory die Erstellung von Logfiles aktivieren:

  • Domain: Statistik & Logfile-Konfiguration
  • “example.com” editieren
  • “Logfiles erstellen” ankreuzen (nicht aber “Logfiles mit gzip komprimieren”)

Es dauert einen weiteren Tag, bis die erste Logdatei im Verzeichnis logs/ zu finden ist. Es gibt zukünftig 6 Tage zurückgehend eine Logdatei für jeden vergangenen Tag.

Scripte

Im konkreten Beispiel sieht die Verzeichnistruktur so aus:

/kunden/12345_67890/logs/
/kunden/12345_67890/webseiten/example/piwik/
/kunden/12345_67890/scripts/


Folgende Shell-Scripte müssen angepasst und im (neu erstellten) Verzeichnis scripts/ hochgeladen und als ausführbar markiert werden:

matomo_import.sh

#!/bin/bash

base_dir=/kunden/12345_67890/scripts

cd $base_dir

log_file=`date --date=yesterday +'/kunden/12345_67890/logs/example.com-%Y-%m-%d'`

echo '*******************************' > matomo_results
echo 'LOG IMPORTIERUNG '$log_file >> matomo_results
python2.7 ../webseiten/example/piwik/misc/log-analytics/import_logs.py --token-auth=TOKEN_AUTH --recorders=4 --url=https://example.com/piwik --idsite=SITE_ID $log_file >> matomo_results
echo '*******************************' >> matomo_results

Hiermit wird die Server-Logdatei des Vortags in die Matomo-Datenbank importiert. In der Protokolldatei matomo_results wird der jeweils letzte Import-Vorgang zu Kontrollzwecken festgehalten. Jeder neue Import überschreibt die Protokolldatei. Wer ein fortlaufendes Protokoll haben will, schreibt in der ersten echo-Zeile “>>” statt “>”.

matomo_archive.sh

#!/bin/bash

base_dir=/kunden/12345_67890/scripts

cd $base_dir

echo '*******************************' >> matomo_results
echo 'LOG ARCHIVIERUNG' >> matomo_results
php7-73STABLE-CLI -d memory_limit=1024M ../webseiten/example/piwik/console core:archive --force-idsites SITE_ID --url='https://example.com/piwik' >> matomo_results
echo '*******************************' >> matomo_results

Dies löst die Verarbeitung der importierten Logdaten aus.

Cronjobs

Wir brauchen zwei Cronjobs, die jeden Tag morgens (z.B. um 7:00 Uhr) beide Scripte aufrufen und so die Statistik des Vortags verarbeiten. Zuerst matomo_import.sh und ein paar Minuten später matomo_archive.sh.

Cronjob-Konfiguration im Kundenbereich von Domainfactory:

  • Webspace: Cronjobs/Neuen Cronjob erstellen…
  • Direkter Scriptaufruf
  • Ziel: webseiten/scripts/matomo_import.sh
  • Jeden Monat :: Jeden Tag im Monat :: Jeden Wochentag :: 7:00 Uhr

und

  • Ziel: webseiten/scripts/matomo_archive.sh
  • Jeden Monat :: Jeden Tag im Monat :: Jeden Wochentag :: 7:15 Uhr

Nach dem Anlegen der Cronjobs können beide Prozesse einmal manuell über das Cronjob-Webinterface ausgeführt werden. Damit wird das Logfile des Vortags importiert und verarbeitet. In Zukunft erledigt das der Cronjob automatisch. Es ist wichtig, dass der Cronjob nur einmal am Tag ausgeführt wird, weil sonst die Daten eines Tages u.U. doppelt gezählt und damit die Statistik verfälscht werden könnte.

Obwohl die Logdateien den Zeitstempel 23:59 vom Vortag haben, scheint Domainfactory die Dateien relativ spät zur Verfügung zu stellen. Ich rate daher dazu, den Cronjob nicht zu früh zu terminieren. Mit 7:00 bin ich bisher ganz gut gefahren.

Sofern die Website noch den Javascript-Tracker-Code enthält, muss dieser natürlich entfernt werden. Da es am (Vor-)Tag der Umstellung zu einer Addition von Tracker-Zugriffen und Logfile-Daten kommen kann, sollte das Javascript auch schon einen Tag vor der Umstellung entfernt werden. Die Datenschutzerklärung sollte angepasst werden. Ein Cookie-Opt-In oder -Opt-Out ist (für Matomo) nicht mehr nötig.

Konfiguration für Subdomains

Domainfactory listet die Zugriffe auf alle Subdomains einer Domain gemeinsam in einem Logfile auf. Wer das in der Statistik trennen will, muss in der Logfile-Konfiguration von Domainfactory “Subdomains in Logfiles anzeigen” aktivieren und bei Matomo in der Website-Verwaltung einen Haken machen bei “Zeichne Besuche und AKtionen nur auf, wenn die Aktions-URL mit einer der oben genannten URLs beginnt. Die Umstellung auf “Subdomains” bei Domainfactory dauert mindestens einen Tag und passiert u.U. mitten im Logfile. Matomo kann keine Logfiles fehlerfrei verarbeiten, in denen sich mittendrin das Format ändert. Es kann also sein, dass bei einer nachträglichen Aktivierung des Subdomain-Features der Statistik-Import am Umstellungstag nicht korrekt läuft. Davon braucht man sich nicht irritieren lassen.

» Diskussion bei forum.df.eu...


« E-Books mit HUGO | Volltextsuche für Hugo »