Bots nicht mitzählen oder bei den Reports rausfiltern

@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:

Hallo,
vielen Dank euch alle für den Einsatz.
Ich glaube auch nicht das DNT beim PHP-Tracking wirkt.
Mich interessiert grundsätzlich auch immer noch, warum der Unterschied so groß ist.
Das deaktivieren von

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

hat nichts gebracht.

Ich glaube mit dem erstellen eines Segments mit nur Besucher aus DE komme ich am weitesten.
Werde das Thema auch noch weiterverfolgen.
Danke & Viele Grüße
Olli

Die PiwikTracker.php ist nur ein Teil von Matomo. Damit wird die Matomo DoNotTrack function nicht ignoriert.

@Olli, wieso solltest du voreilig eventuell echte Besucher absichtlich ignorieren? Es ist weiterhin gut möglich, dass mit PHP Tracking viel mehr als mit JavaScript Tracking getrackt werden. AdBlocker und dergleichen AddOns sind kein Mysterium.

Das führt nur dazu, dass nicht mehr fälschlicherweise angezeigt wird, dass alle Benutzer Flash unterstützen, weil der Server das ja nicht wissen kann.

Die PiwikTracker.php ist unabhängig vom Rest und macht nur eine HTTP Anfrage an die Tracking API (wo vermutlich der DNT Header des Besuchers nicht mehr weitergeleitet wird)

Für mich sieht das nur nach einer Sammlung von functions in einer class aus, die von Matomo genutzt wird, nix unabhängig, niemals standalone. Es wäre seltsam, wenn DNT ignoriert werden würde.
https://developer.matomo.org/api-reference/PHP-Piwik-Tracker

Dafür kann es doch eine Menge Gründe geben, z.B., dass Ollis Interesse ausschließlich Besuchern aus Deutschland gillt.
Es kommt halt immer drauf an, was man denn auswerten will, wenn Hits aus China und Korea nicht interessant sind gibt es m.E. keinen Grund, warum man die nicht filtern sollte.
Für Ollis Anwendung passte die Default-Auswertung nun mal nicht, ist doch gut, wenn er über Segmentierung dort ankommt, wo die für ihn relevanten Daten zu finden sind - und die AdBlocker der ihm wichigen Besucher hat er ja trotz Segmentierung erfolgreich umschifft.

Wir können jetzt trefflich streiten, wie und ob die Matomo php tracking default Einstellung verbessert werden könnte (mein Dank an jene, die die Bot-Liste pflegen), aber bei den von Dir selber beschriebenen individuellen Unterschieden der Logs Deiner Projekte zeigt sich doch, dass die projektspezifischen Unterschiede groß sind - und damit eine “one-size-fits-all” default Lösung eher unwahrscheinlich ist.

Am Ende bieten sowohl das JS tracking als auch das php tracking jeweils nur einen Kompromiss, und das wird sich auch nicht gänzlich ändern lassen.
Gut ist halt, wenn man mit den Vor- und Nachteilen eines Kompromisses vertraut ist.
Was m.e. konstruktiv getan werden könnte, währe eine Übersichtstabelle zu erstellen, in denen die erwartbaren Vor- und Nachteile der jeweiligen Tracking-Varianten übersichtlich verglichen werden könnten -
die gibt es meines Wissens nicht.

Ob dann in der “Unterstützt/Respektiert DNT”-Zeile beim php tracking ein Häckchen rein muss oder nicht wäre noch herauszufinden,
aber für jemanden wie Olli gäbe es dann schon im Vorfeld der Entscheidung eine Referenz-Seite,
auf der er sich mit den Unterschieden der Tracking-Varianten hätte vertraut machen können.

Offensichtlich sind die Unterschiede recht groß, darauf im Vorfeld hinzuweisen erscheint mir sinnvoll, denn am Ende geht es auch darum, dass die Nutzer Ihren Matomo Ergebnissen vertrauen wollen.
Unverhoffte 200% Besucherzuwachs innerhalb der selben Software ist m.E. keine so vertrauenerweckende Nutzererfahrung, und nicht jeder Nutzer wird sich dann erstmal Rat suchend hier im Forum melden.

@Lukas Ich wäre bereit, besagte Übersichtstabelle bzw. eine Art Entscheidungshilfe “Welche Tracking Variante soll ich wählen” mal anzudenken, wenn Du/Ihr das für sinnvoll erachtest.
Inhaltlich müsste das aber jemand verifizieren, da ich mit dem php Tracking selber keine ausreichende Erfahrung habe.

Hallo,

Wenn du willst kannst du in der #knowledge-base einen Artikel beginnen und ich mache ihn dann zum Wiki, sodass jeder ihn verbessern kann.

Ich habe auch schon mal zum Tracking-Pixel geschrieben, der ja auch in soeine Tabelle gehören würde:

Richards Idee find ich unterstützenswert!

  • JavaScript Tracking
  • Image Tracking
  • JavaScript Tracking + Image Tracking
  • PHP Tracking
  • Server Log Tracking

Achso, und das Thema an sich ist ja erledigt, da Bots bei allen Versionen gefiltert werden werden.

Kennt ihr das schon?

Ja, aber das hat mit dem Thema nur wenig zu tun. Da geht es um eine kleine Schnittmenge der Bots die so tun als währen sie von ihrer Seite gekommen, wodurch ihre Webseiten in der Referrerliste in Matomo auftauchen.

@Lukas & @melbao
Ich bin die Übersicht mal angegangen, schaut mal hier:
https://forum.matomo.org/t/js-tracking-php-tracking-logfile-import-or-image-tracking-which-method-should-i-choose-and-why/26974
Hoffe, daraus lässt sich mit Eurer Hilfe etwas machen, ist mal ein erster Anlauf :slight_smile:

Hallo,
vielleicht auch nochmal als Abschluss:
Ich hatte zu diesem Thema bevor ich hier im Forum gefragt habe, auch beim Matomo Support nachgefragt und jetzt die Antwort erhalten, die ich euch nicht vorenthalten möchte:

When you use the PHP Tracking API, it is possible to enable an optional Tracking API parameter which will result in all bots being tracked in your instance.
You can do this by calling the following function in your code:

$tracker->setCustomTrackingParameter('bots', 1);

Please note that we currently do not set a flag for bots, therefore it will be hard to see which requests are from bots and which are from normal users. Bots will be mixed with non-bots.
If you are interested, it would be possible for you to actually detect whether user is a bot or not directly in your PHP script, by replicating the logic we do in Matomo.
This way youd be able to set a custom dimension to distinguish bots VS non-bots.
FYI the code we use in Matomo to detect a bot uses our Device detector library:
device-detector
And here is the code:

$deviceDetector = DeviceDetectorFactory::getInstance($this->userAgent);
return !$allowBots && ($deviceDetector->isBot() || $this->isIpInRange());

Das noch für Euch zur Info.
Vielleicht werde ich das mal machen, wenn mehr Zeit ist.

1 Like

@MrSnuts, das sieht schon sehr informativ aus.

@Olli, wirst du einen Testlauf mit deaktiviertem Bot-Detector machen um den Unterschied zu erkennen?

Nachdem ich ein wenig programmiert habe und das access_log sowie die Matomo Datenbank dabei verwendet habe, bin ich zu dem Schluß gekommen, dass ein Vergleich zwischen Javascript Tracking / PHP Tracking / Server Log Tracking am einfachst ist, wenn eine zweite Instanz von Matomo mit eigener Datenbank für das Vergleichs-Tracking verwendet wird. Allles andere selbstprogrammierte würde bedeuten, Matomo nachzubauen.

Apropos Kombinieren:
https://github.com/matomo-org/matomo/issues/9665

Ein Feature, welches bei weitem nicht trivial ist, aber in der fernen Zukunft einmal zu Matomo kommen könnte, wäre die Möglichkeit die Daten aus mehreren Quellen zu verknüpfen.

Das würde natürlich neue Möglichkeiten eröffnen.

A post was split to a new topic: Demo.matomo.org verbessern

Hallo,
ich habe folgende Zeile

heute mal Testweise eingebaut und einen 3/4 Tag mitlaufen lassen.
Ergebnis:
ca 500 (!) Besucher mehr
ca. 3000 (!!!) Seitenansichten mehr

Genauer habe ich nicht geguckt.
Habe mir aber -wie weiter oben geschrieben und jetzt unabhängig vom Custom Parameter “bot”- ein Segment gebaut nur mit Besucher aus Deutschland.
Hier habe ich soweit ich das Beurteilen kann eine reelle Besucher- und Seitenansichtenzahl.

Viele Grüße
Olli

Hallo,

Das ist irgendwie absehbar, da laut der Datei oben, deine Webseite über 5500 mal alleine vom Bing Bot aufgerufen wurde. Und mit $tracker->setCustomTrackingParameter(‘bots’, 1); werden diese nun nicht mehr ignoriert.