Bots nicht mitzählen oder bei den Reports rausfiltern

Hallo,

Ich glaube auch nicht, dass es nur daran liegt (auch wenn man den Anteil nicht unterschätzen darf).

Garnicht (okay, mit umständlichen selbstgeschreibenen Lösungen)

@Olli, kannst du einmal in deine Serverlogs schauen und für einige der verdächtigen Besucher die User Agents raussuchen und hier posten. Vielleicht ist es eh ein bekannter Bot, der nur noch nicht von DeviceDetector erkannt wird.

Leider habe ich keine Ahnung von dem PHP Tracker, aber was mir hier logischer erscheint ist, dass du die Roh-Daten MIT Bots, Spider und Crawler, also allen Server Requests ohne Filter, für einen Vergleich benötigst.
Probiere mal auf der Kommandozeile (Linux) mit einem grep deiner access_log Datei das hier:
grep -v "piwik" /pfad/zu/logs/access_log | grep -o '17/Jan/2018' | wc -w
Datum und Pfad natürlich anpassen.
Vorher prüfen, wann die letzte access_log archiviert wurde.
Als Ergebnis wird eine Zahl ausgegeben. Diese Zahl zeigt dir, wie viele Server requests es (ohne mit dem Wort “piwik”) an diesem Tag gegeben hat. Vergleiche diese mit den Pageviews (Visits Overview) für diesen Tag.
Zum Vergleich: Auf einer meiner Websites sind es ~3 Mal mehr Server Requests (access_log Datei) als Pageviews (Matomo Visits Overview).
Du kannst den grep natürlich noch erweitern.
Wie genau das ist, kann ich aber auch nicht sagen.
Benutzung auf eigenes Risiko.

Habe mal eben einen Artikel geschrieben mit ein paar Kommandozeilentools zur leichteren Auswertung der Server Log access_log Dateien.


Verwendet, wenn ihr könnt, eine Kopie der access_log.

Laut Dokumentation per

setResolution()

Das von @Lukas bereits erwähnte Problem besteht darin, dass Du Breite/Höhe in php nicht hast, der Server weis beim Ausführen des Codes nicht, wie die Browserdimension ist, dass erschließt sich erst wenn später JS im Browser ausgeführt wird.

Was mich an Deinem Tracking-Code stutzig gemacht hat sind die Zeilen

$t->setBrowserHasCookies(true);
$t->setPlugins($flash = true, $java = true, $silverlight = true, $pdf = true);

Du ergänzt hier scheinbar statische Default-Werte, die nichts mit dem aktuellen Aufruf zu tun haben - bei Bots würde ich erwarten, dass "setBrowserHasCookies" bei einer Prüfung false sein müsste.
Ob das innerhalb der Auswertung zur Verwirrung führt kann ich nicht sagen, aber es wäre das Erste, was ich mal versuchsweise rausnehmen würde.

Ich bin offen gestanden nicht ganz sicher, ob Du beim Auswerten der Server Logs einfach fündig werden wirst -
am Ende triffst Du dort auf dreierlei Logs:

  1. Solche, die Matomo korrekt als Bots erkannt und nicht als Besucher gewertet hat,
  2. die fragwürdigen Aufrufe, die in Matomo beim php tracking auftauchen und
  3. die “echten” Besucher, die Du vom JS-tracking kennst.

Wie sich Dir da auf Anhieb erschließen soll, welche zur zweiten Kategorie gehören ist mir nicht klar geworden.
Um das zu beschleunigen wäre es u.U. eine Idee, das anonymisieren der IPs in Matomo für einen kurzen Zeitraum abzuschalten, um danach gezielt nach den fraglichen IPs aus der neuen Besuchergruppe in den Logs suchen zu können.
Das ist natürlich streng genommen Datenschutz-technisch tabu, ich erwähne es mal als pragmatische Möglichkeit.

Danke, das habe ich mal rausgenommen…

Hmmmm, noch so ein Thema.
Check doch mal, was deine Server Log Dateien an Statistiken hergeben. Die sind so ziemlich die genauesten.
Habe gerade einen Artikel darüber geschrieben und in einem Nachbarthema gepostet.

… mit ein paar Kommandozeilentools zur leichteren Auswertung der Server Log access_log Dateien.
https://pen-ultima.blogspot.de/2018/01/matomo-server-log-vs-javascript.html

Verwende, wenn du kannst, eine Kopie der access_log.

plugins/PrivacyManager/DoNotTrackHeaderChecker.php:

    protected function isHeaderDntFound()
    {
        return (isset($_SERVER['HTTP_X_DO_NOT_TRACK']) && $_SERVER['HTTP_X_DO_NOT_TRACK'] === '1')
            || (isset($_SERVER['HTTP_DNT']) && substr($_SERVER['HTTP_DNT'], 0, 1) === '1');
    }

Weitere Antwort hier:

Eine kleine Ergänzung noch:
Falls man alle access_logs nach user agents durchsuchen will, hilft dieses Snippet von der DeviceDetector Seite:

zcat ~/path/to/access/logs* | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -n20000 > /home/matomo/top-user-agents.txt

Es gibt alle eindeutigen User Agents aus.

Ich verstehe gerade überhaupt nicht, was DoNotTrack mit der frage von @MrSnuts zu tun hat, ob Piwik auch Bots ignoriert, wenn man nicht das Javascript Tracking verwendet. (Antwort ist “Ja”)

Hallo,
das Kommando habe ich mal ausgeführt.
Kann ich die Textdateien hier irgendwie hochladen?

Hallo,

Ich vermute mal, dass das Ergebnis sehr groß ist, also poste es lieber hier und schreib den Link:
https://gist.github.com

Top User Agents 18.01.2018:

Außerdem noch folgenden Befehl:
grep -v "piwik" ~/access.log.03.4 | grep -v -i "bot" | grep -v -i "crawl" | grep -v -i "spider" | grep -v -i "slurp" | grep -v -i "google" | grep -v -i "bing" | grep -v -i "yandex" | grep -w '18/Jan/2018' | awk -F\" '{print $6}' | sort | uniq -c | sort -n > sort002.txt

Hallo,

Ich habe alle Diskussionen zu @Olli’s Problem mal hierher verschoben, weil ich langsam den Überblick verliere.

Ja, danke, ging mir auch so :wink:

Hallo,

Die Liste enthält eine Menge Bots, aber alle die ich getestet habe (bis um die 200) werden von DeviceDetector erkannt.

Off-Topic:
Microsoft Office Excel 2014: !?!
AfD-Verbotsverfahren JETZT!: Eine sehr effektive Methode, seine Nachricht unter die Leute zu bringen.

@Lukas, der Kommandozeilenbefehl von DeviceDetector tut nichts anderes, als die in meinem Artikel, allerdings ohne Filter für einen bestimmten Tag und ohne Bot, Spider, Crawler Filter. Das “zcat” kann man sich sparen, sowie auch das “head -n20000”. Wichtiger Bestandteil ist das Split und Sort. Somit bekommt man eine schöne Übersicht. Das ganze kann auch mit den IPs gemacht werden, sowie vieles mehr. Einfach den awk Befehl anpassen.

Bei dem DNT Einwurf zu später Stunde habe ich wohl was durcheinander gebracht, weil ich zeitgleich einen DNT detector gebastelt habe. Ich war dem Bot Detecting schon auf der Spur, bin aber zu später Stunde nicht eindeutig fündig geworden, also habe keine Badword-Liste gefunden. Es gibt aber einige PHP Functions diesbezüglich, also das wird serverseitig erledigt, ohne Javascript.

Olli, ein Count mit und ohne Filter wäre hilfreich gewesen. Deine geposteten Files haben sehr viel mehr “Pageviews” als du “Besucher” angegeben hast, oder du hast die Befehle von mir nicht mit Datum-Filter verwendet. Zudem sind zu einem Vergleich die “Pageviews” aus Matomo nötig.
Server Log Tracking: "Schnitt 1200 Besucher am Tag."
JavaScript Tracking: "400-500 Besucher am Tag."
In der Datei ohne Filter: “61288” (Pageviews)
In der Datei mit Filter: “48291” (Pageviews)

Also bei mir kamen die Pageviews aus Matomo (Javascript Tracking) mit den Count Ergebnissen aus den Kommandozeilenbefehlen mit Filter(!) sehr nahe. Eines passte sogar genau. Bei einem anderen mit Brut Force Attacks überhaupt nicht.

Bezüglich Blacklist bin ich jetzt fündig geworden und habe meinen Artikel nochmal überarbeitet, mehr hilfreiche Befehle und Infos zur Blacklist von Matomo und Fake User Agents von Spam-Bots und Brute Force Attacks.


Habe unter anderem ein Wordpress am laufen. Die Brut Force Attacken machen da den Großteil der Server Log Einträge aus.
Im Quellcode von Matomo habe ich keine Funktion zur Erkennung und Filterung von Fake User Agents gefunden, aber die Bot-Blacklist.
/piwik/vendor/piwik/device-detector/regexes/bots.yml

Hallo,
Eine kleine Begriffserklärung für alle um die Verwirrung aufzuklären. Matomo parst seit den Anfangszeiten den User Agent um die Browser/OS und ähnlichen Reports zu erstellen. Zusätzlich werden auch Bots erkannt.
Da diese Liste die mit jedem Matomo Update größer geworden ist und auch anderen Entwicklern helfen kann, wurde sie unter dem Namen DeviceDetector in einen eigenen Programmteil ausgelagert.
Die Datei die du gefunden hast, ist ein Teil davon und beinhaltet alle regex zur Erkennung.

Matomo verwendet diese Liste um Bots zu erkennen und nicht in der Statistik zu inkludieren.

Falls der User Agent von einem Bot nicht erkannt wird (was man unter http://devicedetector.net/ testen kann), macht ihr @SteveG eine Freude, wenn ihr dort ein Github Issue mit Details aufmacht (oder gleich einen Pull Request mit Tests).

Bots ohne markanten UserAgents zu erkennen wird schwieriger, da jeder Filter nicht eindeutig ist und auch echte Nutzer erwischen kann.

@Lukas, du meinst sicher “Falls der User Agent eines Bots vom DeviceDetector nicht erkannt wird”.

Die Bots/Crawler/Spider Liste ist schon sehr umfangreich, aber um beim Thema zu bleiben, dort steht kein “Firefox/40.1”, der von Brut Force Bots verwendet wird, (aber regex Kram, der das erkennen könnte?). Ob Matomo diesen und ähnliche filtert wäre in Erfahrung zu bringen. Zumindest mit JavaScript Tracking werden die “Besuche” nicht getrackt, wie ich getestet habe. Möglich, dass sie mit Server Log Tracking getrackt werden. Das wäre sehr leicht herauszufinden, wenn sich jemand, der Server Log Tracking fährt, dazu bereit erklärt einen kleinen Test durchzuführen. Dazu einfach ein Browser AddOn installieren “User Agent Switcher” und diesen User Agent eingeben.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1

Danach einen oder mehrere eindeutige Webseitenbesuch durchführen (Uhrzeit und Webseiten notieren) und die IP merken.
Es gibt noch einige mehr bereits gut bekannte Fake User Agents dieser Art.
In den Logs von Olli war der “Firefox/40.1” nicht so oft. Wohl kein Wordpress am Start.
Der Test kann mit jedem beliebigen (Fake) User Agent durchgeführt werden.

@Olli. Habe meinen Artikel ein weiteres Mal erweitert. Die Anzahl der Visitor ohne Bots anhand der Rohdaten in der access_log Datei herauszufinden würde bedeuten Matomo nachzubauen. Aber, für einen Vergleich reicht ein ungefähr. Ich denke, das ein ungefähres Vergleichsergebnis anhand der verschiedenen IPs, mit vorher aussortierten Bots, auszumachen ist. Der Bot Filter von DeviceDetector ist natürlich nicht im Einsatz, aber die gängigsten Kandidaten werden gefiltert.
Das Ergebnis kann allerdings auch täuschen, aber es ist ein Versuch wert. Bei einer meiner Seiten war das Ergebnis doppelt so hoch wie das Javascript Tracking, obwohl die IPs im Server Log gekürzt sind. Der Kommandozeilenbefehl:

grep -v -i "piwik\|bot\|crawl\|spider\|slurp\|google\|bing\|yandex" /path/to/logs/access_log | grep -w '18/Jan/2018' | awk '{print $1}' | sort | uniq -c | wc -l

Das Ergebnis wird als Zahl gleich in der shell angezeigt.
Mehr Infos dazu findest du in meinem bereits verlinkten Blog unter
IP ADDRESSES + Filter

Hallo zusammen,
ich kann mir irgendwie nicht helfen, aber: Sind wir hier auf einem konstruktiven Weg, Ollis Problem zu lösen?

Wie sich das bisher darstellt scheint es keine einfache Erklärung für Ollis veränderte Statistik zu geben, und nach Eurer Prüfung wenig Aussicht, dass sich die Situation über das Ergänzen eines neuen Bots zum DeviceDetector beheben lässt.
Wie @Lukas richtig sagt:
Es gibt einfach Grenzen, was man herausfiltern kann ohne mit dem Filter potentiell echte Besucher zu erwischen.
Getarnte Bots mit herkömmlichen User Agents werden halt erfasst, und bevor eine eindeutige Zuordnung (wie lt. @melbao im Fall von Firefox/40.1) erfolgen kann wird immer erst einmal Zeit vergehen, wärend der das php Tracking solche Hits listet.

Interessant ist allemal die Erkenntnis, dass beim php - tracking (was ja bekanntlich Besucher, die JS-tracking geblockt hätten, erfasst) mehr vermeintliche Bot-hits als offenkunding echte Besucher hinzukommen.
Mit einem Zuwachs der getrackten Aufrufe war zu rechnen, dass das php tracking bei Olli aber deutlich mehr “Spreu” als “Weizen” fängt hätte ich so nicht erwartet.

Um nochmal zu Ollis ursprünglicher Frage zurück zu kommen:

@Olli: Die Idee mit den Segmenten ist wahrscheinlich der schnellste Weg zum Ziel.
Du hast ja Deine echten Besucher vom JS-tracking noch in etwa im Kopf, und hast beschrieben, aus welchen Regionen die normalerweise so kommen.
Wenn ich Deine Aussage zur veränderten Absprung-Rate richtig verstanden habe, rufen Deine “normalen” Besucher meist mehrere Seiten auf, die hinzugekommenen jedoch immer nur eine Seite.
als drittes Merkmal hast Du erwähnt, dass die neuen Besucher ausschließlich direkte Seitenaufrufe tätigen.

Ein Segment zu erstellen, dass nur Besucher anzeigt die entweder aus der von Dir erwarteten Region (DE / AT / CH, oder EU), oder aber über einen Referrer von einer Website kommen ist machbar,
und Du könntest versuchsweise ein weiteres Segment anlegen, dass nur Besucher mit mindestens zwei Seitenaufrufen anzeigt.

Solche Segmente haben dann natürlich nur einen auf bestimmte Auswertungen eingeschränkten Nutzen, aber auf dem Weg kommst Du wahrscheinlich am ehesten zu Werten, wie Du sie brauchen kannst.

Hallo,

Du hast Recht, meine Idee mit den User Agents war ein Holzweg. Ich dachte, dass vielleicht ein einziger Crawler, den DeviceDetector nicht kennt, die Webseite wiederholt aufrufen würde, aber dass ist ja nicht der Fall.

Bots, die nicht erkannt werden wollen, wird man nie mit einer generellen Lösung in Matomo blockieren können.

Aber da ihr ja das PHP tracking (im Gegensatz zu LogAnalytics) verwendet, gibt es ja die Möglichkeit individuelle Regeln zu programmieren:

  • Ist die Seite außerhalb der EU irrelevant? Dann kann man bei Besuchern außerhalb einfach keine Daten an Matomo schicken (kein $t->doTrackPageView($seitenname);)
  • Gibt es ein Äquivalent von wp-login.php? Dann könnte man alle Aufrufe dorthin ignorieren.
  • Wird dauernd /gibt-es-nicht/ aufgerufen? Dann gilt dasselbe.

Falls die Daten schon da sind, sind Segments, wie @MrSnuts sie gerade beschrieben hat, sicher die beste Lösung.

Zwischenfrage: Wie groß ist der mögliche Unterschied zwischen PHP Tracking und Server Log Tracking?
DNT respect bei PHP Tracking ist sicherlich vorhanden. DNT enable ist heute nicht mehr selten.
Die Kommandozeilenbefehle in meinem Blog sind natürlich keine Lösung und sollen nur beim aufspüren der Ursachen helfen. Wenn damit nichts eindeutiges ersichtlich ist, braucht es mehr, etwas komplexeres, und da bin ich gerade dran, weil es mich selbst interessiert. Geduld.

Ich bin mir nicht sicher.
Immerhin habe ich hier nichts dazu gefunden: