Die Idee den durch KI Chatbots, bzw. KI Crawler erzeugten Traffic durch das Matomo 5.8.0 Update zu erfassen, ist gut, aber bei weitem nicht zuende gedacht und ist deswegen nach meinen Maßstäben wertlos. Was über den AI Assistenten an Traffic erfasst werden kann, entspricht weniger als 2% des gesamten Traffics, der durch KI Crawler erzeugt wird. So wenig deswegen, weil nur die well known KI Crawler sich als “gute“ KI Crawler selbst identifizieren, wobei selbst das nicht sicher ist. Allen voran OpenAI, als der aggressivste KI Crawler, verwendet seit einiger Zeit nicht mehr ausschließlich bestimmte User-Agents, sondern stattdessen den signature-agent Request Header und bleibt deswegen dem AI Assistant gänzlich verborgen.
Das eigentliche Problem, also die restlichen 98%, sind die KI Crawler, die ihre Identität so gut verschleiern, dass es nur mit sehr großem Aufwand möglich ist, diese zu erfassen. Dafür braucht es zusammen mit der PHP API CMS abhängige Lösungen, welche ich seit inzwischen 10 Jahren verwende. Trotzdem rechne ich es Matomo hoch an, dass man sich der Problematik bewusst geworden ist, dass die Traffic Erfassung zunehmend verfälscht wird. Allerdings ist das kein Problem, das nur Matomo betrifft, sondern jedes andere Tool zur Traffic Analyse davon betroffen ist.
Wenn man seitens Matomo die Sache weiter und tatsächlich zuende denken will, dann gilt als Voraussetzung, dass man seinen Traffic kennen muss, bevor man sich der Sache annimmt. Aber ich bezweifle, dass sich das ohne zusätzliche und vor allem CMS abhängige Programmierungen möglich ist. Machbar ist es aber!
Man muss zunächst mal das Problem verstehen und dazu gehört, dass man seinen tatschlichen Traffic kennt, was mit Matomo designbedingt nicht möglich ist. Die PHP API verkleinert zwar die Lücke, aber eben und ebenso designbedingt nicht vollständig. Als ich vor mehr als 10 Jahren damit angefangen mir Gedanken drum zu machen, wer oder was meine Seiten tatsächlich aufruft, habe ich die Requests nur per PHP Logging erfasst und das unabhängig von Matomo. Dieses PHP Logging erfasste auch die Request Header. Bevor es Chatbots gab, war die Sache noch vergleichsweise einfach, wobei es mir anfänglich nur darum ging den “guten = erwünscht” Traffic vom “bösen = unerwünscht“ Traffic zu identifizieren und den bösen Traffic per WAF erstmal gleich gar nicht auf meine Seite zu lassen. Aktuell sind das bis zu 10.000 Requests pro Tag und entsprechen fast 90% des gesamten Traffics. Wenn man solche Requests erst gleich gar nicht auf die Seite lässt, dann geht es nur mehr um Feinarbeit und dafür verwende ich den JS Tracker und die PHP API, aber nicht gleichzeitig.
Aber selbst bei den verbleibenden 10% gibt es einen blinden Fleck, der durch KI Crawler entsteht, die mittels Headless Chrome einen natürlichen Nutzer zu 99,99% immitieren können. Dieser blinde Fleck bedeutet, dass dieser durch den AI Assistant nicht berücksichtigt werden kann. Dieses AI Assitant Feature “gaukelt“ einem also etwas vor, was gar nicht möglich ist, bzw. nur sehr unzureichend möglich ist und aus meiner Sicht erstgleich gar nicht möglich sein sollte, weil es beim KI Traffic aus meiner weiteren Sicht um etwas ganz anderes geht als nur um die Traffic Erfassung. Und zwar, will ich ChatBots den Content meiner Seite zur Verfügung stellen? Ja oder Nein? Berücksichtigt man diesen Aspekt, dann geht es nicht um Traffic Auswertung für KI Crawler, sondern darum, wie ich mir egal welches “Dreckszeug“ vom Leib halte. Das kann man so sehen, muss man aber nicht. Wer hier eine andere Philosophie hat, der muss sich im Klaren sein, dass mindestens 2/3 des Traffics keinen natürlichen Ursprung hat und Matomo das auch nicht mit dem AI Assistant lösen kann.
Die Idee von @Serpent_Driver in allen Ehren. Sie ist auch nützlich. Eine Überprüfung der Nützlichkeit ist aber schwer bis unmöglich, wegen dem “man muss seinen Traffic kennen”.
Die neuen Reports “AI Assistants” in der Kategorie “Aquisition” sind nur Gimmick. Vergleichbar wäre ein separater Report mit Referrer nur “Google”.
Die neue Kategorie “AI Assistants” mit “AI Chatbots Overview” und “AI Agents Overview” ist etwas widersprüchlich zum Reports “AI Assistants” in der Kategorie “Aquisition”.
Wie es den Anschein hat werden dafür nur die Referrer und Browser Agents ausgewertet. Vermutlich wird der Device Detector dafür genutzt. Die Frage ist, ob das PlugIn BotTracking (Core) und TrackSpamPrevention nicht eh schon alles rausfiltert und die Reports leer bleiben. Sie würden dann nur etwas als Überprüfung nützen, ob die beiden PlugIns korrekt funktionieren.
Es gibt dann noch das PlugIn “AIAgents (Core)”. Das ist bei mir bisher inaktiv.
Im Gegensatz zu Serpent_Driver geht es mir nicht darum den Traffic von Bots komplett zu blocken, sondern diesen nur nicht zu tracken. Bots werden bei einigen Webhostern bereits serverseitig geblockt und das ist die korrekte Herangehensweise. Es ist falsch alles durchzulassen und den Webhost-Usern den Traffic (anhand “angepasster” Tarife) in Rechnung zu stellen. Die Unterschiede zwischen den Reports bei den Webhostern und denen bei Matomo sind riesig.
Ich habe viele Jahre lang viel Zeit investiert um nur “human” und insbesondere auch nur “interessierte” Visitors zu tracken. Das Problem dabei ist, keine interessierten human Visitors abzuschrecken. Mit einer einfachen Lösung von Consent-Banner mit Buttons (Tracking erst nach onclick), kann das Tracking reduziert werden. Je mehr Buttons (nacheinander), umso weniger werden die getrackten Visitors. Bei 3 Buttons reduziert sicht das Tracking auf 10 % gegenüber komplett ohne. Das bedeutet, dass 90 % der Visitors nicht alle drei Buttons klicken. Manche klicken nur einen und bouncen. Aber darunter scheinen auch humans zu sein, die abgeschreckt werden. Bouncing ist schlecht fürs Ranking.
Die Bouncing-Rate ist ein wesentlicher Bestandteil des Trackings. Dies betrifft auch das nur Tracken von “interessierten” Visitors. Leider wurde die Queue-Funktion in Matomo auf einer falschen Basis (Consent) heraus programmiert und ist damit im Grunde nur eine Consent-Funktion. Dazu besteht bereits ein Issue bei Github.
Das würde auch weitere Probleme beim Tracking lösen, wenn diese Queue-Funktion allgemein zur Verfügung stehen würde. Wie zum Beispiel das Duration Problem bei iPhones, dass immer 0 ist. Eine Queue mit 10 Sekunden TimeOut würde nur Visits tracken, die mindestens 10 Sekunden auf der Page sind. Da fallen viele uninteressierte Bouncer raus, die nur Datenmüll erzeugen.
Grundlegender hat Serpent_Driver bereits ein Problem angesprochen. Heutzutage ist JavaScript-Tracking sehr ungenau und kann auch geblockt werden. Server Log Tracking ist zu aufwendig, insbesondere bei 1 Matomo Instanz und vielen Websites bei verschiedenen Webhostern. Was fehlt ist ein einfach zu installierendes PHP-Tracking. Da viele sowieso WordPress nutzen, wäre das realisierbar. Bei selbstprogrammierten Websites kann es etwas umständlicher werden, was Title und so weiter betrifft. Nur für das Event-Tracking würde zusätzlich ein JavaScript-Tracking erforderlich sein.
Ich habe mich von der Idee nur human und nur interessierte Visitors zu tracken bereits verabschiedet. Ich tracke vorwiegend nur noch als Funktionsüberprüfung, ob die Websites noch funktionieren und der Content (z.B.: Title, 404) Fehler enthält. Wegen Event-Tracking kann ich nicht auf reines und eigenes PHP-Tracking umsteigen.
Der Matomo PHP Tracking Client ist mir zu umständlich. Es müsste eine sehr einfache Funktion sein, die im Background (auf dem Server der jeweiligen Website) die IP, den Referer, die Request-URL und den Browser Agent zur Matomo Instanz sendet. Da könnten bereits Filteroptionen angeboten werden. Den Rest kann optional das JavaScript Tracking machen. Minimalistischer Einstieg mit Optionen zur Steigerung.
Minimal (PHP): IP, Referer, Request-URL und Browser Agent.
Mehr: JavaScript-Tracking.
Edit: Ich hatte zwischendrin auch mal versucht den Traffic auf meinen Websites besser kennenzulernen. Dazu hatte ich die Standorterkennung “DBIP” verwendet mit der dbip-city-lite und der dbip-asn-lite. Anfangs nur die ASN. Dann auch die CITY. Die City ist aber extrem ungenau und wurde wieder deaktivert. Die ASN gibt einen kleinen Überblick. Teils sind sehr viele verschiedene dabei, aber diese dann nur mit 1/Tag. Am meisten sind die bekannten Provider (Vodafone, Telekom, Telefonica, …). Zusammen mit der Browsersprache ist es möglich eine (gedachte) Filterung vorzunehmen, wie viele Visitors sozusagen “wilde” sind, die sich wohl nur verirrt haben. Leider gibt es da ein technisches Problem bei Matomo. Wenn die Standorterkennung aktiviert ist, aber die CITY nicht, sondern nur die ASN genutzt wird, dann erscheinen keine Länderflaggen mehr. Mit der CITY besteht das Problem, dass die Länderflaggen nur noch per City und nicht mehr per Browsersprache angezeigt werden. Der Unterschied zwischen City und ASN und Browsersprache ist aber ein gutes Erkennungsmerkmal insgesamt. Weil mir Browsersprache wichtiger als (schlechte) CITY ist, habe ich CITY deaktiviert, aber nun sehe ich keine Browsersprache-Länderflaggen mehr. Dazu gibt es bereits ein Issue:
@Serpent_Driver , deine Meinung zu meiner ist bereits bekannt.
Kannst du bei Matomo den Unterschied zwischen:
AI Bots und AI Agents per Browser Agent und Referer erkennen.
Bots per AI erkennen.
erklären?
Es scheint so, als wenn allgemein ein Missverständnis unterwegs ist, dass Matomo Bots mittels AI erkennt.
Wenn Matomo das von mir vorgeschlagene “Minimal (PHP) Tracking” (IP, Referer, Request-URL und Browser Agent … und Header) inkludiert hätte, würdest auch du dich leichter damit tun deine PHP Rules in das Tracking zu inkludieren. Du wärst dann eventuell auch nicht mehr auf Access Log Tracking angewiesen.
Was sollte ich an meiner Ansicht revidieren? Ich nutze Matomo fast nur noch zur Funktionskontrolle. Und ob die Websites ein Bot oder ein Human besucht ist dabei egal. Ich habs aufgegeben nur Humans zu tracken. Der Aufwand ist zu groß. Bin auch schon am überlegen alles bereits eingebaute wieder rückgängig zu machen.
Ich bin nicht auf die access_log angewiesen und habe das auch nirgendwo geschrieben, geschweige denn, dass ich sie nutzen würde.
Ich geb aber zu, dass meine Ausführungen etwas verwirrend wirken mögen, wenn ich sage, dass ich die PHP API und den JS Tracker verwende, was dem Umstand verschuldet ist, dass ich mit LiteSpeed einen Page Cache verwende, was unter normalen Bedingungen die PHP API eigentlich ausschließt. Deswegen ist meine Lösung sehr custom! Nichtsdestotrotz würde es jeden WP Nutzer betreffen, der das LiteSpeed Cache Plugin installiert hat.
Kannst du bei Matomo den Unterschied zwischen:
Da fange ich gleich gar nicht an zu erklären, weil beides für mich sinnfrei ist. Die AI Bots per Browser Agent zu erkennen, würde nur bei der PHP API einen, aber nur theoretischen, Sinn machen, weil diese Bots kein JS ausführen. AI Bots senden übrigens keinen Referer. Dies nur für den Fall, dass dir das noch nicht aufgefallen sein sollte…. Aber abgesehen davon, lässt sich dieser noch mehr verfälschen als den UA.
Zumindest ich bin davon nie ausgegangen.
Wie ich bereits vorausgehend angemerkt habe, muss das jeder für sich selbst entscheiden, wie er damit umgeht. Wobei ich den Standpunkt vertrete, dass es nicht nur um Traffic Analyse geht, sondern es bereits damit beginnt, wen ich auf meine Seiten lasse. Ginge es nur um eine handvoll Requests, dann würde ich vermutlich wie Du darüber hinwegsehen, aber dem ist leider nicht so. Allerdings kann ich Deiner Logik nicht ganz folgen, dass du den unerwünschten Traffic einfach nur nicht sehen willst. Das ist wie ein Vogel, der mit den Flügeln nach unten fliegt, um das Elend nicht sehen zu müssen.
Ich habe zu dem Thema “Bots blocken” einen größeren und sehr bekannten Webhoster gefragt: Das machen wir nicht. Ein kleinerer hat hingegen bereits begonnen Bots zu blocken, weil es ihm zu viel sinnloser Traffic wurde, den er bezahlen muss. Ich habe für mich entschieden: Es ist nicht meine Sache, sondern der der Webhoster. Sollen die entscheiden, wann es ihnen zu viel wird.
Meine Websites betreffend betrifft es nicht den Traffic, sondern den Content. Dass dieser geklaut wird, davor schützt mich ein Bot-Blocking nicht.
Die einizige Gefahr besteht hier bei JavaScript-Bots, die das HTML Document unter meiner Domain und SSL-Cert nutzen können um mit z.B. fetch() Unfug zu treiben. Das ist dann aber ein allgemeines Sicherheitsrisiko, für das es allgemeiner Lösungen bedarf.
Du hast bisher nicht erwähnt was dein spezieller Grund zum Bot-Blocking ist. Bisher hast du nur geschrieben, dass man nicht wüßte was die alles machen und sie deswegen blocken sollte. Aber was machen die denn, damit sie geblockt werden sollen?
Ich glaube, dass Du hier falsche Erwartungen setzt. Seit es Chatbots gibt, haben sich die Anforderungen, um unerwünschte “Bots“ zu blocken, extrem verschärft und zwar dahingehend, dass klassische Schutzmaßnahmen hier nicht mehr greifen, obwohl es trotzdem einfach wäre. Aber das den Hostern zur Verfügung stehende Werkzeug dafür nur bedingt geeignet ist. Die Problematik, bzw. die Ursache sind aber nicht die well known KI Crawler. Davon gibt es nicht all zu viele und diese lassen sich mit einfachsten Mitteln identifizieren und bei Bedarf auch blocken. Darauf ist auch das letzte Matomo Update ausgelegt. Viel kritischer siehts mit den KI Crawlern aus, die sich ganz bewusst maskieren, um nicht als Scaper identifiziert zu werden. Bei solchen Bots reichen herkömmliche Lösungen bei weitem nicht mehr aus. Würden man diese trotzdem verwenden, käme es ganz schnell zum überblocken, also dass man mit dem Blocken übers Ziel hinausschießt. Dafür braucht es Lösungen auf Applikationsebene, aber setzt eine individuelle Konfiguration voraus damit es nicht zum gleichen Effekt es Überblockens kommt. Auch wenn Du den Satz nicht zu mögen scheinst, aber man muss seinen Traffic kennen, um hier etwas brauchbares zu bekommen. Den Traffic kennen zu müssen, heißt, dass man zur Grundanalyse entweder mindestens die access_log braucht oder noch besser ein PHP getriebenes Logging, um darüber auch die Request Header zu bekommen. Was ich Dir damit letztlich sagen will, ist, dass Du selbst etwas dafür tun musst, wenn es Dir nicht egal ist, dass Dein Server die meiste Zeit mit Beantworten von nicht natürlichen Requests beschäftigt ist und Du Deinen Traffic halbwegs sauber halten willst.
Natürlich schützt Dich das. Wenn Du weißt, wer sich an Deinem Content bedient, dann ist es egal, ob Du blocken willst oder nur diesen Traffic ausfiltern willst. Die Maßnahmen sind fast die Gleichen.
Habe ich das wirklich nicht geschrieben? Ich gebe Dir eine, bzw. 2 einfache Antworten:
1.) Alles, was mir noch nicht mal im entferntesten einen wirtschaftlichen Nutzen einbringt, hat auf meiner Seite nix verloren. Egal welche Intention der jeweilige Bot hat. “Nutznießer Bots” rauben mir schlichtweg nur Ressourcen, ohne dass ich davon einen Nutzen habe.
2.) Bei ChatGPT & Co gilt eine Ausnahme und habe quasi einen Pakt mit dem Teufel abgeschlossen, wovon ChatGPT aber nix weiß. Ich nutze lediglich die Gier nach Trainingsdaten, um Content einzuschleusen, bzw. das Spektrum des Context zu erweitern, den ChatGPT nicht ausreichend interessiert, weil alle KI Crawler nur die Interessen des main streams bedienen, was übrigens auch für Google gilt. Hintergund: Bis zu 2/3 an Wissen wird nie öffentlich, weil sich der main stream dafür nicht interessiert.
@Serpent_Driver , was du für alle willst, also default in Matomo, ist das was ich vorgeschlagen habe. Aber da ich es vorgeschlagen habe, willst du es nicht.
Needed: “Minimal PHP-Tracking” (IP, Referer, Request-URL und Browser Agent … und Header).
Da brauchst du dann nicht die PHP API und nichts selber coden, sondern dieses nur erweitern. Das wäre dann auch bei mir der Fall, also dass ich meine selbstgecodeten PHP Matomo-Filter auf dieses Mininal PHP-Tracking anwendte. Fürs Event-Tracking dann zusätzlich noch JS-Tracking.
Wie schon geschrieben interessiert mich Traffic nicht. Es ist nicht mein Server. Habe nur virtual Webhost auf virtual Server, so wie die meisten.
Wo habe ich denn geschrieben,dass ich was für alle will? Ich habe kritisiert, dass Matomo eine Funktion einbringt, die in hohem Maße fehlertolerant ist und deswegen falsche Vorstellungen weckt. Zumal die Erkennungskriterien nicht fälschungsicher sind. Für meinen Geschmack hat man das Thema AI Bots zwar angedacht, aber bei weitem nicht zuende gedacht. Ich gehe sogar so weit, dass sich Matomo diesbezüglich raushalten sollte, weil sich diese Erkennung von AI Bots auf well known Bots beschränkt, aber das macht nur einen Bruchteil (<1%) von dem aus, was die maskierten AI Bots an Traffic verursachen.
Und wie soll das ohne PHP API gehen?
Traffic heißt Last und wenn Du den Traffic ignorierst, dann ignorierst Du auch die Verfügbarkeit Deiner Webseite. Ich mag wie ein Hardliner wirken, aber selbst bei toleranterer Betrachtung kann ich Deiner Ignoranz nicht folgen?!
Ohne diese API, sondern ein einfaches Request mittels PHP von der Website an die Matomo Instanz, das beim Aufruf einer Webpage die Visitor-IP, Referer, Request-URL, Browser Agent und Header an Matomo übersendet. Der Rest ist auf Matomo-Instanz-Seite zu erledigen. Das erspart, dass auf jedem Server, auf dem eine Website liegt, zusätzlich dieses Matomo PHP API Skript MatomoTracker.php gespeichert werden muss.
Es ist ein reiner One-Way Request, der keine Antwort-Daten zurück bekommt. Außer den HTTP-Status.
Dieser Request soll minimaler Code sein.
Das kann noch minimiert und in eine kleine Funktion gepackt werden.
Diesen Request kannst du dann mittels Visitor-IP, Referer, Request-URL, Browser Agent und Header filtern.
Matomo bekommt somit die Basis-Tracking-Daten. Alles weitere per JS, falls im Browser aktiviert.
Was stört Dich an der PHP API? Verwende sie und nutze nur das, was Du benötigst. Es ist ohnehin nur eine Frage der Konfiguration der API. Die Kunst liegt letztlich nur darin, dass Requests nicht doppelt getrackt werden, was bei Deiner Schmalspur Version nicht anders wäre.
Egal wie man die PHP API oder Deine Schmalspur Version verwendet, spätestens bei einem Page Cache ist Schluss mit lustig, egal ob Page Cache am origin host oder CDN Cache.
weiß doch jede, dass es ein 100-prozentiges Tracking nicht gibt.
Ein Minimal PHP-Tracking würde deine selbstgecodeten PHP-Tracking-Filter um ein Tracking erweitern. Du könntest also direkt in deinem selbstgecodeten PHP-Tracking-Filter auch gleich Tracken.
Die PHP-Tracking API ist mir zu aufwendig. Habe verschiedene Webhost. Ich brauch was minimales ohne viel Schnickschnack. Ein Einzeiler wäre angenehm, aber ist wohl zu viel verlangt.
function matomo_php() {
$url = 'http://matomo.example.com/';
$server = $_SERVER;
$allheaders = getallheaders();
$data = [$server, $allheaders];
$headers = ["Content-type: application/x-www-form-urlencoded"];
// use key 'http' even if you send the request to https://...
$options = [
'http' => [
'header' => $headers,
'method' => 'POST',
'content' => http_build_query($data),
'ignore_errors' => true,
],
];
$context = stream_context_create($options);
$response = file_get_contents($url, false, $context);
}
Du scheinst Dich mit der PHP API noch nicht wirklich befasst zu haben?! Wie viel einfacher willst Du es denn noch haben?
$matomoSiteId = ; // Site ID $matomoUrl = “”; // Your matomo URL $matomoToken = “”; // Your authentication token $matomoPageTitle = “”; // The title of the page include_once (‘MatomoTracker.php’); $matomoTracker = new MatomoTracker((int) $matomoSiteId, $matomoUrl); $matomoTracker->setTokenAuth($matomoToken); $matomoTracker->doTrackPageView($matomoPageTitle);
Und diese wird in JEDE Webpage geladen. Das sorgt für Serverlast und Verzögerung der Ladezeit. Kannste bei dir machen. Ich mache es nicht.
Ich schlage stattdessen vor, dass Matomo ein Minimal PHP-Tracking anbieten soll. Du bist ja dagegen. Danke für die Unterstützung.
Auweia, da geht das mit den Cookies wieder los: function setFirstPartyCookies()
Die Matomo PHP API verwendet curl für function sendRequest(). if (function_exists(‘curl_init’) && function_exists(‘curl_exec’)) {
Das ist wieder ein Sicherheitsrisiko. Manche haben curl deaktiviert.
OK, alternativ wird file_get_contents() verwendet, wenn stream_context_create() vorhanden ist.
Diese Funktion müsste radikal gekürzt werden (curl und vieles weitere raus): protected function sendRequest(string $url, string $method = ‘GET’, $data = null, bool $force = false)
Bei der Minimal-Version könnte noch ein Hash generiert und gesendet und als var _paq.push('phphash', 345fgfdg1dr5g1gf32g1f); ins HTML Document geprinted werden, der eine Verbindung zu JS-Tracking herstellen kann und doppeltes Tracking vermeidet. Das ist allemal besser als Cookies.
@Serpent_Driver , wenn du die Matomo PHP API bereits in Verwendung hast, dann zeig doch mal, was die protected function sendRequest() an die Matomo Instanz sendet. Am besten was file_get_contents($url, 0, $ctx) sendet. Also den Inhalt von $url und $ctx.
Wenn die matomo.php nicht geladen werden würde, wie soll das JS Tracking denn die Daten in die DB schreiben können? Hat Matomo was erfunden, was nur Du zu kennen scheinst?
