Über dieses Blog Blog-Beiträge Tags Impressum Datenschutz E-Book
Befreiung vom (digitalen) Überfluss

Matomo cookiefrei

Matomo/Piwik 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 (ehemals »Piwik«). 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!

Es ist zwar möglich, Matomo so zu konfigurieren, dass kein Cookie gesetzt wird. Von Ad- und Tracking-Blockern wird das zugehörige Javascript-Snippet trotzdem als Tracker identifiziert und geblockt.

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, AWstats oder GoAccess 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 Implementierungen bei Domainfactory und Manitu

Jeder Provider hat eine andere Umgebung. Ich möchte hier vorstellen, wie ich die Matomo-Logfile-Analyse für Managed Hosting-Accounts von Domainfactory und Manitu umgesetzt habe.

Implementierung für Domainfactory

Vorbereitung

Folgende Daten werden benötigt (Beispieldaten):

  • URL der Matomo-Installation: https://example.com/matomo/
  • absoluter Pfad der Server-Logfiles: /kunden/12345_67890/logs/
  • relativer Pfad der Matomo-Installation: webseiten/example/matomo/
  • 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

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/matomo/
/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 +'/kunden/12345_67890/logs/example.com_access.log-%Y%m%d.gz'`

echo '*******************************' > matomo_results
echo 'LOG IMPORTIERUNG '$log_file >> matomo_results
python3.6 ../webseiten/example/matomo/misc/log-analytics/import_logs.py --token-auth=TOKEN_AUTH --recorders=4 --url=https://example.com/matomo --idsite=SITE_ID --exclude-path=*/matomo/* $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
php -d memory_limit=1024M ../webseiten/example/matomo/console core:archive --force-idsites SITE_ID --url='https://example.com/matomo' >> 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: scripts/matomo_import.sh
  • Jeden Monat :: Jeden Tag im Monat :: Jeden Wochentag :: 7:00 Uhr

und

  • …
  • Ziel: 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. Und die Datenschutzerklärung muss angepasst werden. Ein Cookie-Opt-In oder -Opt-Out ist (für Matomo) nicht mehr nötig.

Implementierung für Manitu

Die Skripte und das Format der Logdatei unterscheiden sich geringfügig. Ein wichtiger Unterschied ist, dass Manitu die Logfiles nur einmal in der Woche am Sonntag archiviert. Daher läuft der Cronjob auch nur einmal wöchentlich und die statistische Auswertung hinkt maximal 7 Tage hinterher.
Es gibt pro Webhosting-Paket nur eine Logdatei, die keine Domainnamen in der URL beeinhaltet. Es ist also nur möglich, eine einzige statistische Auswertung zu machen, die nur Sinn macht, wenn nur eine Domain im Webhostingpaket produktiv genutzt wird.

Im Kundenbereich von mein.manitu.de sollte die Anonymisierung der Logfiles ausgeschaltet werden:

  • Webhosting-Paket aufrufen
  • auf der Eingangsseite (=“Übersicht”) ganz unten bei “Einstellungen” auf “konfigurieren” klicken
  • Reiter “Web-Log-Dateien (EU-DSGVO)”: “IP-Adresse wird voll geloggt / gespeichert” ankreuzen

matomo_import.sh

#!/bin/bash
base_dir=/home/sites/site12345678/scripts

cd $base_dir

log_file=`date +'/home/sites/site12345678/logs/web.log-%Y%m%d.gz'`

echo '*******************************' > matomo_results
echo 'LOG IMPORTIERUNG '$log_file >> matomo_results
python ../web/example/matomo/misc/log-analytics/import_logs.py --token-auth=TOKEN_AUTH --recorders=4 --url=https://example.com/matomo --idsite=SITE_ID --exclude-path=*/matomo/* $log_file >> matomo_results
echo '*******************************' >> matomo_results


matomo_archive.sh

#!/bin/bash

base_dir=/home/sites/site12345678/scripts

cd $base_dir

echo '*******************************' >> matomo_results
echo 'LOG ARCHIVIERUNG' >> matomo_results
php -d memory_limit=1024M ../webseiten/example/matomo/console core:archive --force-idsites SITE_ID --url='https://example.com/matomo' >> matomo_results
echo '*******************************' >> matomo_results

Cronjobs

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

Cronjob-Konfiguration im Webhosting-Paket bei mein.manitu.de:

  • Cronjobs/Neuen Cronjob hinzufügen…
  • Typ: Befehl ausführen
  • Befehl und Argumente: /home/sites/site12345678/scripts/matomo_import.sh
  • Zeitplan: Crontab-Format 0 7 * * 0
    (= Sonntags um 7:00)

und

  • …
  • Befehl und Argumente: /home/sites/site12345678/scripts/matomo_archive.sh
  • Zeitplan: Crontab-Format 5 7 * * 0
    (= Sonntags um 7:05)

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