Matomo 5.10.0: Insuffiziente Umsetzung von AI Chatbot reports Teil II

Dieser Post adressiert besonders @Ronan Chardonneau, weil Du Dich im Teil I des besagten Themas augenscheinlich für meine Kritik interessiert hast. Von daher wäre es wünschenswert, wenn Du Dich im Teil II erneut damit auseinandersetzen würdest.

Meine Kritik an Matomo und wie Matomo versucht durch die KI Assistenten Funktion daraus ein wertvolles Feature zu machen, ist unverändert gleich. Matomo spricht damit zwar etwas an, ist damit aber Lichtjahre davon entfernt, dass man daraus einen Nutzen ziehen könnte. Zumal diese KI Funktion über den JS Tracker erst gleich gar nicht möglich ist. Man bräuchte mindestens die PHP API dazu, aber selbst damit ist man weit davon entfernt etwas brauchbares zu ermöglichen.

Das bezeichnete Problem (“Die Kritik“) fängt schon damit an, dass man sich seitens Matomo noch nicht mal ansatzweise damit auseinandersetzt, welche Logik es braucht, um zumindest KI Crawler erfassen zu können. Die bekannten KI Crawler sind dabei das kleinste Problem, wenngleich Matomo sich dabei bei CloudFlare bedienen will. CloudFlare ist in dieser Hinsicht aber maximal insufizient! Man muss schon selbst wissen, wie man einen KI Crawler identifizieren kann, was Matomo nur sehr bedingt kann. Zumal es mindestens die bereits erwähnte PHP API bräuchte.

Ich beschäftige mich nun schon seit ca. 10 Jahren mit der Thematik, wie ich das, was der JS Tracker systembedingt nicht erfassen kann, trotzdem sichtbar machen kann, ohne dass ich dafür die access_log brauche, aber zweifelsohne und trozdem nur mit der PHP API möglich ist. Ich nutze also die Php API UND den JS Tracker, aber nicht gleichzeitig, was andernfalls zu doppelten Traffic Daten führen würde. Um genau das zu verhindern, definere ich zunächst, was “ not human like“ sein kann. Alles andere ist dann automatisch human like und nur dieser Traffic wird vom JS Tracker erfasst. Den not human like Traffic ignoriere ich aber nicht, sondern erfasse ich per Definiton über eine andere “Website“ in Matomo, eben weil ich gerne wissen will, was und wer sich sonst noch so auf einem Webserver herumtreibt, ohne dass ich die access_log dazu heranziehen muss.

Das Thema “KI“ und KI Crawler hat mich in meinen Bemühungen den not human like traffic zu erfassen eher noch bestärkt und bestätigt. Das Thema KI Crawler ist aber hochbrisant!! Wenngleich der not human like Traffic in der Summe betrachtet um das x-fache größer ist als der Traffic, der durch bekannte KI Crawler verursacht wird, werden Nutzer durch KI Crawler zumindest sensibilisiert, aber nicht durch den Traffic. KI Crawler haben es sich zu eigenen gemacht Webseiten kostenlos zu crawlen, um damit KI zu trainieren, ohne dass man als Webseiten Betreiber etwas zurückbekommt. Der frühere und klassische Deal, dass ein Bot, allen voran der Googlebot, eine Webseite crawlt und man im Gegenzug in den Suchergebnissen erscheint, gilt nicht mehr. Allen voran Google mutiert gerade von einer Suchmaschine hin zu einer Antwortmaschine und verschiebt dadurch ein Weltbild, obgleich andere Chatbots bereits jetzt schon massiv dazu beitragen, dass Suchaschinen in erheblichem Maße nicht mehr genutzt werden, zumindest nicht oder sehr stark bei der organischen Suche eingeschränkt.

Auf Reddit gibt es einen von mir initiierten Thread, der auf große Resonanz gestoßen ist:

https://www.reddit.com/r/Wordpress/comments/1sxvtqz/wordpress_sites_why_allow_ai_crawlers_if_they/

Ungeachtet dieser KI Crawler Brisanz geht es darum, wie man mit Matomo nicht nur KI Crawler erfassen kann, sondern jeglichen anderen Not Human Like Traffc. Warum lege ich so viel wert darauf? Ganz einfach. Zumindest bei meinen Webseiten Angeboten kommt auf 1 human like Nutzer täglich mindestens 500 not human like Requests. Kann einem das egal sein? Mit Einschränkung ja, aber mann muss sich bewusst sein, dass ein sehr hohes Maß an Traffic, den Matomo selbst über den JS Tracker erfasst, keinen natürlichen Ursprung hat. Wenn man so will, gaugelt einem Matomo ungewollt etwas vor, was nicht der Realität entspricht.

Was ist nun die Konsequenz daraus?

Obgleich ich mich schon seit vielen Jahren mit der not human like Traffic Thematik beschäftige, haben mich die KI Crawler getriggert.Deswegen habe ich für WordPress ein Plugin mit dem Namen “LiteCache Suspicous Traffic Viewer“ programmiert, das sich der Thematik annimmt. Dieses Plugin ist kein Realtime Traffic Viewer, sondern trackt ausnahmlos das, was suspicous erscheint, aber 10 Jahre praktische Erfahrung darin einfließt. Herkömmliche von natürlichen Nutzern ausgelöste Requests werden deswegen ignoriert. Dieses Plugin ersetzt keine WAF oder ein Security Plugin, sondern macht ledigleich sichtbar, was größtenteils unsichtbar ist und selbst die access_log nicht ausweisen kann. Es schließt außerdem die physische Lücke bei GA4 und Matomo, die PHP API inklusive.

Das sog. STV Plugin stellt ein gesäubertes Logile zur Verfügung, das 1x täglich in die DB importiert wird und dann zur Anzeige gebracht wird. Man muss also nicht selbst herausfinden, was einem “spanisch“ vorkommt, sondern wird einem auf dem Silbertablet serviert, aber maximal für den Vortag. Man bekommt aber auch eine Möglichkeit zur Lanzeitbeobachtung, wenngleich sich lang auf 30 Tage reduziert. Wichtig ist in diesem Zusammenhang, dass durch das STV keine zusätzliche Server Last entsteht.

Was würde das STV Plugin für Matomo interessant machen?

Das besagte Plugin ist OpenSource. Man könnte das Design und die Logik des Plugins entweder für Matomo übertragen oder man greift einfach das aufbereitete Logfile ab. Wenn Matomo seinen Nutzer tatsächlich einen Mehrwert bieten will, dann sollte man sich mit diesem Plugin auseinandersetzen.

Das STV Plugin steht in Kürze über das WP Plugin Repository zum Download zur Verfügung. Studieren kann man aber jetzt schon die readme.txt
www.litecache.dev/readme.txt

1 Like

Du “vermischst” hier ein paar Themen, die man vielleicht trennen sollte:

  • Die Problematik des Zero Click Internets für Sites und User
  • Die Problematik, dass die AI-Intermediäre sich gratis bedienen für ihr Geschäftsmodell und gleichzeitig das Geschäftsmodell ihrer Quellen zerstören
  • Die Empfehlung, dass man Bot-Traffic nicht nur vom Mensch-Traffic trennen, sondern sich auch für beide Teile interessieren sollte
  • Kritik an Matomo, weil es das nicht genug gut tut
  • Ein irreführender Werbelink am Ende :expressionless_face:

Was du leider nicht aufführst, sind konkrete Kriterien, um Bot-Traffic von Mensch.-Traffic zu trennen. Du schreibst zwar von 10 Jahren Erfahrung und OpenSource, lässt uns aber leider nicht von deiner Erfahrung profitieren :slight_smile:

Ich beschäftige mich auch schon eine Weile damit und es ist bei mir einfach Trial&Error. Zurzeit beachte ich ungefähr dies:

  • User-Agent enthält bot, crawler, spider, scrapy, python, curl, wget
  • User-Agent fehlt komplett
  • User-Agent passt nicht zum technischen Verhalten, zum Beispiel Chrome-User-Agent, aber keine echten Browser-Header
  • sehr alte Browser-Versionen in hohem Volumen
  • viel Traffic aus Cloud-/Hosting-Netzen statt normalen ISPs
  • viele Sessions von derselben IP oder demselben /24-Netz
  • Land passt nicht zur Zielgruppe oder Kampagne
  • plötzliches Volumen aus neuen Regionen
  • viele Länder mit identischem Verhalten
  • Browser-User-Agent, aber fehlende Browser-Header
  • keine Cookies trotz mehrfacher Seitenaufrufe
  • kein JavaScript-Event nach Seitenaufruf
  • identische Header-Fingerprints über viele IPs hinweg
  • ungewöhnliche Kombinationen, zum Beispiel mobiler User-Agent mit Desktop-Auflösung
  • 1 Pageview, 0 Sekunden, keine Interaktion
  • extrem viele Seitenaufrufe in kurzer Zeit
  • gleichmäßige Abstände zwischen Requests
  • immer derselbe Pfad
  • keine Scrolls, keine Klicks, keine Consent-/Cookie-Events
  • unrealistische Geschwindigkeit, zum Beispiel 30 Produktseiten in 20 Sekunden
  • sehr hohe Bounce-Rate bei gleichzeitig auffällig hohem Volumen
  • plötzliche Referrer von irrelevanten Domains
  • viele Sessions mit Fake-Referrern
  • UTM-Parameter, die nicht von deinen Kampagnen stammen
  • hoher Direct-Traffic auf tiefe URLs, die kaum jemand direkt eintippen würde
  • Traffic auf nicht beworbene oder alte Landingpages
  • extrem hohe oder extrem niedrige Conversion Rate
  • viele Leads mit ungültigen E-Mails
  • viele identische Formularwerte
  • Formular wird schneller abgeschickt, als ein Mensch es ausfüllen könnte
  • Conversions ohne vorherige sinnvolle Interaktion
  • viele Add-to-Carts ohne Checkout
  • auffällig viele fehlgeschlagene Logins oder Passwort-Reset-Versuche
  • Traffic-Spikes ohne Kampagnen- oder News-Auslöser
  • konstant gleichmäßiger Traffic rund um die Uhr
  • viele Sessions exakt zur gleichen Sekunde
  • wiederkehrende Wellen, zum Beispiel alle 5 Minuten
  • ungewöhnliche Aktivität nachts in der Zielregion

Diese Liste wächst und wächst, und sie ist sicher bei Weitem nicht vollständig. Und das ist alles (extrem!) NICHT schwarz-weiss, nichts davon alleine ist “oh Bot”. Also braucht es ein Scoring-System mit Schwellenwerten etc., was weitere Unschärfe und Fehlerquellen mit sich bringt. Und das ist sehr aufwändig zu messen, braucht viele Datenquellen, IP- WAF-, CDN- und Bot-Listen, Mustererkennung etc. blabla. Nur Hobbylose wie ich machen so was… und weisst du was? Cloudflare macht genau das, und sie machen es leider besser als ich. Was mich allerdings nicht verwundert, denn erstens sind dort Profis, zweitens ist es für die ein Produkt und drittens haben die unfassbar viele Daten. Leider bin ich kein Fan von Cloudflare und ich unterstelle ihnen, dass sie für genug Geld Löcher öffnen. Aber grundsätzlich macht das Cloudflare ziemlich gut.

Ich trenne nun also (vermeintliche) Bots von Menschen und dann noch gute in schlechte Bots. Suchmaschinen-Crawler, Monitoring-Tools, Link-Preview-Bots, SEO-Tools, Accessibility-Scanner. Diese will ich nicht als “User” zählen, aber auch nicht blockieren. Das wiederum ist eigentlich nur über IP-Whitelists zu lösen, für die man jemandem vertrauen muss.

Fazit
Am Ende habe ich zwar mit sehr viel Aufwand wohl ein realistischeres Bild, aber erhrlich gesagt ist es bei mir eher “ich kann es” als “ich brauche es”. Dienste wie jene von Cloudflare würden mit sehr geringem Aufwand mindestens das gleiche Ergebnis liefern.
Das ganze Filter-Gecode würde ich ohne KI (ja, ich sehe die Ironie!) ohnehin nicht stemmen, viel zu aufwändig.

jm2c.

@soardiac

Du denkst viel zu kompliziert. :slight_smile: und hättest mit Deiner Kritik vielleicht warten sollen bis das besagte WP Plugin zum Download zur Verfügung steht. Die verlinkte readme.txt kann Dir die Antworten nicht geben und ich werde hier auch nicht die Details zur Logik ausführen, weil das besagte Plugin eigentlich nur als Denkvorlage für die Matomo Entwickler dient.

Was mich an deinen Ausführungen aber trotzdem irritiert, ist wie Du darauf kommst, dass es einen Werbelink gäbe?! Es gibt nur einen Link und der zeigt auf die readme.txt des WP Plugins.

Um aber noch direkter auf Deinen Kommentar einzugehen und um meine Intention vielleicht noch besser zu verstehen, will ich aufzeigen, worum es tatsächlich geht.

Matomo hat sich neuerdings auf die Fahne geschrieben auch KI Crawler in das Tracken aufnehmen zu wollen, wofür es primär die PHP API braucht. Bekanntermaßen ist das über den JS Tacker nicht möglich, was dann automatisch für fast jeden “not human like“ Traffic gilt. Die Betonung liegt dabei auf “fast“, weil sich per Headless Chrome ein tatsächlich echter human like Request zu 99,99% nachbilden lässt. Die besagte API enthält aber keine besondere Logik, würde aber rudimentär ausreichen, um zumindst die well-known KI-Crawler erfassen zu können. Jedoch muss man sich vor Augen halten, dass die PHP API nicht (Page) Cache friendly ist, was für jeden Page Cache am origin Host und CDN Cache gilt. Solange man per PHP trackt, gibt es also einen blinden Fleck, aber das ist nun mal systembedingt und ist keinerlei Kritik.

Was Matomo durch die neuen KI Features einbringt, ist der Idee nach zwar gut gedacht, aber leider schlecht oder sagen wir besser unzureichend gemacht, weil es das Thema KI Crawler noch nicht mal ankratzt. Damit wird etwas suggeriert, was man noch nicht mal ansatzweise erreichen kann. Das Thema KI, KI Crawler und Chatbots drängt sich zwar unmittelbar in den Vordergrund, aber das Problem, dass es eine Vielzahl an Requests gibt, die einen natürlichen Nutzer maximal imitieren und dadurch die Traffic Anaylyse erheblich beeinträchtigt, gab es schon viel früher. Well-known KI Crawler lassen sich mit Ausnahme von Google war einfachst identifizieren, aber es gibt x-fach mehr an Crawler, die nur Content scrapen, aber sich eben nicht als KI Crawler unmittelbar identifizieren lassen. Man muss das Thema KI-Crawler deshalb viel breiter fassen.

Und spätestens jetzt muss sich Matomo die Frage selbst stellen, so weitermachen wie bisher, also auch ohne KI Feature oder will man sich viel breiter aufstellen?! Das gilt besonders für das Erfassen von tatsächlich natürlich generiertem Traffic.Bei dieser Fragestellung mag ich mich als Hardliner outen, aber Matomo, GA4 usw. sind für mich nur noch bedingt wertvoll, wenn man es bei der Traffic Analyse auf die Verwendung des JS Trackers beschänkt. Dabei weise ich erneut darauf hin, dass bis zu 2/3 oder gar mehr oftmals keinen natürlichen Ursprung hat. Dass es eine Vielzahl an “bad bots“ gibt, die sich über den JS Tracker tatsächlich nicht erfassen lassen, ist dabei das kleinste Problem. Es geht darum seine Traffic Erfassung sauber zu halten und zwar so sauber, dass man als einfacher Nutzer davon ausgehen kann, dass Matomo nur den tatsächlich human like Traffic erfasst, ohne dass dafür irgendwelche Listen pflegen muss und man keine extra KI braucht, die einen jeden Request vor der Erfassung erstmal analysiert. Hört sich das wie Traumtänzerei an? Auf den ersten Blick vielleicht ja, aber es ist einfacher als man denkt. Zumal ich das seit inzwischen 10 Jahren mit Erfolg praktiziere, mit dem JS Tracker und der PHP API.

Wenn man sich seitens Matomo damit beschäftigen will, dann genügt ein Blick in den Code des besagten WP Plugins, das ich spätestens Morgen über das WP Repository zum Download zur Verfügung stelle.

[UPDATE] Das besagte Plugin ist eingereicht, steht derzeit aber noch in der Warteschleife bei den Reviewern. Deswegen wird es noch mind. 1 Woche dauern bis das Plugin freigegeben wird.

@RonanChardonneau Du bist deswegen erneut getriggert. Falls da kein Feedback kommt, belasse ich es dabei und werde mich zu dem Thema nicht erneut äußern.

Keine Kritik, nur meine Sichtweise dazu. Ich habe gar keine Grundlage, dich zu kritisieren. Jeder, der sich engagiert und dabei anständig bleibt, verdient Respekt meiner Meinung nach.

Ich komme halt einfach nicht auf das readme, weil der Server mit einem 301 reagiert:

Und dort, wo ich lande, finde ich ein Produkt, und darum habe ich es “Werbung” genannt. Sorry :innocent:

@soardiac

Ich habe den Link zur readme.txt grad nochmal überprüft und mir ist tatsächlich ein Fehler passiert, sodass Du die Weiterleitung unweigerlich als Werbelink verstehen musstest. Ich hab das grad korrigiert. https://www.litecache.dev/readme.txt

Vielen Dank, schaue ich mir an.

Da sich die WordPress Reviewer grad viel Zeit mit der Abnahme eines Plugins lassen, habe ich das LiteCache - Suspicious Traffic Viewer Plugin für WordPress auf Github verfügbar gemacht.

1 Like