Erfahrungsbericht matomo Tracking Rauschen

Hier jetzt mal Listen von IPs von 4 betroffenen Domains. Eine Domain mit .org/.com hat die selbe Matomo-ID.

Monat Juli/2022

Website 1.0 .de (deutsch)

180.163.220.0 -  - Baidu
205.169.39.0 - Vereinigte Staaten - Direkte Zugriffe
205.169.39.0 - Vereinigte Staaten - Direkte Zugriffe
171.13.14.0 - Vereinigte Staaten - Direkte Zugriffe
2003:e8:d718:2700:: - Deutschland - Google
27.115.124.0 -  - Baidu
180.163.220.0 -  - Baidu
27.115.124.0 -  - Baidu
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe
44.206.247.0 - Vereinigte Staaten - Direkte Zugriffe
111.7.100.0 - China - Direkte Zugriffe
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe
205.169.39.0 - Vereinigte Staaten - Direkte Zugriffe
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe

Website 2.0 .org/.com (englisch)

180.163.220.0 -  - Baidu
42.236.10.0 -  - Baidu
66.115.147.0 - Vereinigte Staaten - Direkte Zugriffe
207.102.138.0 - Vereinigte Staaten - Direkte Zugriffe
207.102.138.0 - Vereinigte Staaten - Direkte Zugriffe
156.146.49.0 - Vereinigte Staaten - Direkte Zugriffe
62.152.55.0 - Vereinigte Staaten - Direkte Zugriffe
69.160.160.0 - Vereinigte Staaten - Direkte Zugriffe
104.200.132.0 - Vereinigte Staaten - Direkte Zugriffe
156.146.49.0 - Vereinigte Staaten - Direkte Zugriffe
2a03:2880:20ff:3:: - Vereinigte Staaten - Direkte Zugriffe
156.146.49.0 - Vereinigte Staaten - Direkte Zugriffe
156.146.49.0 - Vereinigte Staaten - Direkte Zugriffe
104.192.108.0 -  - Direkte Zugriffe
171.13.14.0 - Vereinigte Staaten - Direkte Zugriffe
171.13.14.0 - Vereinigte Staaten - Direkte Zugriffe
171.13.14.0 - Vereinigte Staaten - Direkte Zugriffe
104.200.132.0 - Vereinigte Staaten - Direkte Zugriffe
111.7.100.0 -  - Direkte Zugriffe
111.7.96.0 -  - Direkte Zugriffe
111.7.96.0 -  - Direkte Zugriffe
36.99.136.0 -  - Direkte Zugriffe
111.7.96.0 -  - Direkte Zugriffe
211.95.50.0 -  - Direkte Zugriffe
111.7.100.0 -  - Direkte Zugriffe
211.95.50.0 -  - Direkte Zugriffe
180.163.220.0 -  - Baidu
42.236.10.0 -  - Baidu
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe
205.169.39.0 - Vereinigte Staaten - Direkte Zugriffe
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe
101.227.1.0 -  - Direkte Zugriffe
102.129.145.0 - Vereinigte Staaten - Direkte Zugriffe
211.95.50.0 -  - Direkte Zugriffe
111.7.100.0 -  - Direkte Zugriffe
101.227.1.0 -  - Direkte Zugriffe
102.129.145.0 - Vereinigte Staaten - Direkte Zugriffe
211.95.50.0 -  - Direkte Zugriffe

Hier wird manchmal wenige Sekunden später das .org/.com Pendant aufgerufen.

Website 2.1 .de (deutsch)

42.236.10.0 -  - Baidu
92.200.115.0 - Deutschland - Direkte Zugriffe
92.200.115.0 - Deutschland - Direkte Zugriffe
171.13.14.0 - Vereinigte Staaten - Direkte Zugriffe
3.131.97.0 -  - Direkte Zugriffe
42.236.10.0 -  - Baidu
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe
65.154.226.0 - Vereinigte Staaten - Direkte Zugriffe

Da sind einige IPs mehrfach dabei, auch Domain-übergreifend. Bis auf einige Ausnahmen ist das meiner Ansicht nach alles Tracking-Rauschen von Bots. Das selbst zu filtern ist so ziemlich unmöglich. Wenn Matomo seine Bot-Filter nicht erweitert, wird es dieses Rauschen weiterhin geben. Es müllt die Datenbank zu und verfälscht die Auswertung vom Tracking.

Nächster Fall: Wieder nagelneue Domain. Wenige Minuten nach Onlinestellen der nagelneuen Website erstes Tracking. Onepager.

Sofort nach Onlinestellen:
IP: 65.154.226.0 = Palo Alto Networks - 2 Aktionen - 1 Minuten 10s

2,5 Stunden später:
IP: 34.254.53.0 = Amazon[.com] (34.248.0.0 - 34.255.255.255) - 1 Aktion - 2 Sek.

Mehrere Stunden später:
IP: 2a03:2880:11ff:e:: = Facebook[.com] Search Engine Spider - 1 Aktion - 26 Sek. [von Matomo als “von Facebook” erkannt.]
IP: 65.154.226.0 = Palo Alto Networks - 1 Aktion

Das .de Pendant zu dieser Website ist schon länger online. Auch da nur Bot-Rauschen im Tracking. Beispiel:
IP: 69.160.160.0 = Intelium Corp. (crawler-50 nicecrawler com).

Damit dürfte die Sache klar sein, dass Matomo auch Bots trackt. Wieso diese IPs nicht auf der Blacklist stehen, das ist hier die Frage.

Gestern habe ich das gelesen:

Lilith Wittmann: Beispielsweise Amazon Webservices (AWS) bietet die perfekte Lösung. Da kannst du eine Lambda-Funktion schreiben, die jedes Mal, wenn sie aufgerufen wird, eine neue IP-Adresse bekommt. Das bedeutet, dass mit jedem neuem Aufruf dieser Funktion ein neuer kleiner Server startet. Dieser macht dann 60 Requests, wird heruntergefahren, verliert seine IP Adresse und der nächste Server wird gestartet. Das ist so ein bisschen teuer, aber ja, das kann man machen. Außerdem gibt es den Vorteil, dass AWS weltweit Rechenzentren hat. Sprich: Entweder du blockst als Handelsregister den kompletten IP-Space von Amazon, was nicht so klug wäre, oder du hast sehr viel Arbeit beim Aussperren.

https://www.golem.de/news/scraping-des-handelsregisters-wir-machen-das-ja-nur-aus-notwehr-2208-167344-2.html

Wenn Bots per AWS Lambda-Funktion im Internet kursieren, dann bleibt einem wohl nichts anderes übrig als den kompletten IP-Space von Amazon und vielen weiteren zu blockieren. Bzw. alle, weil es gibt mehrere. Da wäre die Frage, wie viele echte Viewer kommen aus dem IP-Space von Amazon?

Ist hier noch jemand dabei? Irgendwie scheint diese ganze Self-Tracking-Sache eher eingeschlafen zu sein. So mein Eindruck. Interessiert keinen wirklich mehr.

Meine Beobachtungen zeigen, dass diese Direkter Zugriff - 0 Sekunden - 1 Page Viewer vorwiegend von Clouds kommen. Da ist viel Amazon dabei, aber auch Google sowie exotische. Ich habe jetzt eine kleine größere Liste an IP-Ranges von solchen Viewern. Es ist sehr aufwendig diese zu erstellen. Ich muss jede IP eines solchen Viewers checken und den IP-Range herausfinden. Es wäre sehr hilfreich, wenn solche IP-Ranges zur Verfügung gestellt werden, wie zB von Amazon und Google Cloud. Diese haben mehrere und sehr viele.

Diesen Direkter Zugriff - 0 Sekunden - 1 Page Viewer, die meist von einer Cloud kommen, kann eine Falle gestellt werden, wie ich in letzter Zeit beobachte. Dazu muss im Header der Webpages der Website die Hauptdomain als canonical eingetragen werden. Dann eine zweite Domain auf die Website aufschalten und diese irgendwo unauffällig, am besten im Footer, zusammen mit der Hauptdomain verlinken, damit sie von den Crawlern gefunden wird. Diese Direkter Zugriff - 0 Sekunden - 1 Page Viewer springen auf diese zweite Domain an und es sind (bei mir) ausschließlich diese Direkter Zugriff - 0 Sekunden - 1 Page Viewer, die von einer Cloud kommen und diese Domain verwenden. Es sind nicht wenige. Es ist relevant.

Nur zur Info: Das ist glaube ich was

unter anderem macht

Danke für den Link zum Plugin, aber obwohl es ein Matomo Plugin ist, telefoniert es jedes mal mit den Cloud-Hostern. Unfein.
Beispiel:

        $aws = Http::sendHttpRequest('https://ip-ranges.amazonaws.com/ip-ranges.json', 120, null, null, 0,
            false, false, false, 'GET', null, null, false);

Taugt also nicht. Es können die IPs aus den JSONs extrahiert werden und im Matomo Backend Einstellungen in den IP-Filter eingetragen werden. Immerhin. Besser als nichts.

Headless Browser erkennen wäre eine feine Sache, aber dafür so ein Plugin installieren? Das sollte eine Default-Funktion von Matomo sein, zum an/abwählen.

Es sind insgesamt 70.040 IP-Ranges. Das ist echt heftig. Es sind einige doppelt, wohl bei Google Cloud und Google Digital Ocean. Nach dem filtern der Doppelten sind es noch 40.017 IP-Ranges.

Im Bezug zu dem verlinkten Plugin sei erwähnt, dass dieses die Doppelten mit drin hat und jedes Mal einen Call zu diesen Servern macht:

amazon aws
https://ip-ranges.amazonaws.com/ip-ranges.json

microsoft azure
https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519

google digital ocean
https://www.digitalocean.com/geo/google.csv

google cloud
https://www.gstatic.com/ipranges/cloud.json

oracle cloud
https://docs.cloud.oracle.com/en-us/iaas/tools/public_ip_ranges.json

Wie zu erwarten ist es durchaus schwierig bis unmöglich all diese IP-Ranges in den Backend Einstellungen von Matomo einzutragen. Ich habe es geschafft. Am besten per Browser Inspektor vorher ein max-height: 500px; bei der Textarea einstellen.

Übrigens sind einige der von mir gesammelten IP-Ranges auch dabei, aber nicht alle. Von daher habe ich meine Sammlung bei mir hinten dran gehangen und auch nach Doppelten gefiltert.

Wenn jemand eine Idee hat, wie ich euch die 40.017 IP-Ranges zukommen lassen kann, dann her damit.

[editiert]
Es scheint etwas zu bringen. Aber erstmal 1 Woche, 1 Monat abwarten und dann nochmal nachsehen.

Ich habe jetzt zudem nochmal meinen Tracking-Code angepasst:

var _paq = _paq || [];
_paq.push(['trackPageView']);
_paq.push(['enableLinkTracking']);
_paq.push(['enableHeartBeatTimer', 10]); // ←HeartBeat all 10 seconds
setTimeout(function() { // ← Timeout 1 second
var u="//www.example.com/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', 1]);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
}, 1000); // ← Timeout 1 second
setTimeout(function() { // ← Timeout 2 seconds
_paq.push(['ping']); // ← Ping after 2 seconds
}, 2000); // ← Timeout 2 seconds
window.addEventListener('beforeunload', function(e) {
	_paq.push(['ping']);
});

Also mit 1 Sekunde Timeout, bevor die Matomo-Skript-Datei geladen wird. Damit fallen alle “1 Aktion 0 Sekunden” raus. 1 Sekunde später ein Ping und zudem HeartBeat alle 10 Sekunden sowie beforeunload (das allerdings nicht bei allen funktioniert). Am heutigen Tag waren nur noch 2 mit “1 Aktion 0 Sekunden” dabei. Zudem waren diese von Google und nicht Direkte Zugriffe. Das ist eine immense Verbessererung gegenüber Gestern mit sehr vielen “1 Aktion 0 Sekunden”, die allerdings fast alle von Google kamen. Darunter waren ein paar Sonderlinge, die immer ein und die selbe Page und nur diese besuchen.

Ich werde das jetzt vorerst wohl so laufen lassen. Sieht für den ersten Tag auf einer meiner Websites ganz gut aus. Mehr Infos nach einer Analyse, wenn der Monat November durchgelaufen ist.

Hier noch eine Info zum Timeout:

Matomo zählt die Zeit nicht ab dem das Matomo-Skript geladen wird, sondern ab dem Zeitpunkt, ab dem die Webpage aufgerufen wird. Es geht also mit dem 1 Sekunde Timeout keine Zeit verloren. Aktuell habe ich sogar 2 Sekunden Timeout aktiv bevor das Matomo-Skript geladen wird und es werden Viewer mit 2 Sekunden Verweilzeit getrackt. Alles darunter nicht.

Beispiel:

Seite - Einstiegszeit - Zeit auf Seite
Seite1 - 19:03:09 - 3 Sekunden
Seite2 - 19:03:12 - 6 Sekunden
Seite3 - 19:03:18 - 8 Sekunden
Seite4 - 19:03:26 - 2 Sekunden
Seite5 - 19:03:28 - 5 Sekunden

Meine Websites sind sehr unterschiedlich und nutzen alle den selben Tracking-Code. Zurzeit habe ich ein Timeout von 2 Sekunden aktiv. Dabei ist auf einer Website, bei der sehr schnell durchgeklickt werden kann, zu beobachten, dass einige Page-Views nicht getrackt werden (fortlaufende Nummerierung der Pages mit Lücken im Tracking-Log). 2 Sekunden sind also (bei mir) zuviel. Ich werde das wieder auf 1 Sekunde heruntersetzen. Dann werden nur die Page-Views unter 1 Sekunde nicht getrackt. 1 Sekunde Verweilzeit sollte bei echten Viewern, bzw. als wirkliches Page-View (und nicht nur sinnloses durchklicken / wegklicken) schon drin sein.

Ich habe die Cloud IP range Liste mal hier veröffentlicht: https://github.com/matomoto/cloud-ip-list

Wegen den schnellen Durchklick-Viewern habe ich jetzt etwas eingebaut. Wenn der Referrer gleich der Domain/Hostname der Webpage ist, dann wird das Matomo-Skript sofort geladen, wenn nicht, dann 1 Sekunde warten. Anders gesagt: Hat ein Viewer bereits eine Page der Website besucht, dann wird das Skript sofort geladen, wenn nicht dann 1 Sekunde warten. Damit werden die Direkt Views mit 0 Sekunden sowie One-Page-Views mit 0 Sekunden nicht mehr getrackt. Falls Viewer ein Browser-Plugin verwenden, dass immer den Referrer löscht, so macht das wenig aus, da dann eben nur die 0 Sekunden Time on Page Visits bei Multi-Page-Viewern nicht getrackt werden, sowie alles ab 1 Sekunde getrackt wird.

var _paq = window._paq = window._paq || [];

function matomoscriptloader() {
var u="//example.com/";
_paq.push(['setTrackerUrl', u+'matomo.php']);
_paq.push(['setSiteId', '0']);
var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s);
}
if (document.referrer.includes(window.location.hostname) === true) {
matomoscriptloader();
} else {
setTimeout(function() {
matomoscriptloader();
}, 1000);
}

Die Beobachtung zeigt, dass nun auch 0 Sekunden Time on Page Visits bei Multi-Page-Viewer - wie gewünscht - getrackt werden.

Update.
Da schon wieder Direkt Views mit 0 Sekunden sowie 0 Actions dabei waren, die eventuell durchgerutscht sind, habe ich es nochmals mit einem readyState spezifiziert und die Zeit auf 1100 Millisekunden gesetzt.

if (document.referrer.includes(window.location.hostname) === true) {
matomoscriptloader();
} else {
var matomoreadystate = setInterval(function() {
if (document.readyState === "complete") {
setTimeout(function() {
matomoscriptloader();
}, 1100);
clearInterval(matomoreadystate);
}
}, 100);
}

Hinweis: Damit das _paq.push in einer Funktion funktioniert, muss _paq in window verwendet werden:

var _paq = window._paq = window._paq || [];

So zumindest habe ich das irgendwo gelesen. Alter Tracking Code verwendet var _paq = _paq || [];.

Ich habe immer noch Direkt Views mit ohne Sekunden sowie 1 Page und 0 Actions. Dagegen ist wohl nichts mehr zu machen. Vielleicht liegt das an den Devices oder Betriebssystemen oder Browser-Plugins. Es ist iOS und Android dabei. Es sind auch welche mit ohne Page dabei.

Heute waren wieder eindeutige Bots dabei. Zwischenzeitlich hatte ich das Laden der matomo.js vor ein paar Wochen auf setTimeout mit 10 Sekunden gestellt. Also es werden nur Visits getrackt, die mindestens 10 Sekunden auf einer Entry Page sind. Beim Besuch weiterer Pages gibt es kein solches setTimeout und es wird sofort getrackt.

Die betreffenden Visits heute haben insgesamt 5 verschiedene Websites (One Pager) besucht mit jeweils gleichem Verhalten.
Wegen dem setTimeout von 10 Sekunden müssen diese hinzugerechnet werden.
Alle: Chrome 110.0 - GNU/Linux - Desktop

~06:30
IP: 192.186.0.0
United States
Direct Entry
1 Action - 4s

~18:30
IP: 198.20.0.0
United States
Direct Entry
1 Action - 5s
~07:20
IP: 149.20.0.0
United States
Direct Entry
1 Action - 5s

~20:30
IP: 216.213.0.0
United States
Direct Entry
1 Action - 4s
~06:30
IP: 216.180.0.0
United States
Direct Entry
1 Action - 4s

~18:30
IP: 168.91.0.0
United States
Direct Entry
1 Action - 3s
~06:45
IP: 148.59.0.0
United States
Direct Entry
1 Action - 4s

~19:00
IP: 139.180.0.0
United States
Direct Entry
1 Action - 5s
~02:45
IP: 167.160.0.0
United States
Direct Entry
1 Action - 3s

~14:30
IP: 142.147.0.0
United States
Direct Entry
1 Action - 3s

Es ist nur ein vages und kein eindeutiges Muster zu erkennen.

Chrome 110.0 - GNU/Linux - Desktop
United States
Direct Entry
1 Action - 3-5s

Diese Bots scheinen stetig die IP zu wechseln.

Es ist sehr unwahrscheinlich, dass dies natürliche Personen sind, weil dieses Muster auf 5 verschiedenen Websites gleich auftritt.

Weitere solcher Bots auf einer Website, die über mehrere Domains erreichbar ist.
3 verschiedene Domains.
Alle Chrome 110.0 - GNU/Linux - Desktop.

~01:30
IP: 162.244.0.0
United States
Direct Entry
1 Action - 4s

~02:45
IP: 168.91.0.0
United States
Direct Entry
1 Action - 4s

~07:00
IP: 149.20.0.0
United States
Direct Entry
1 Action - 5s

Es hat den Anschein als wenn diese Bots das setTimeout abwarten.

Neue Erkenntnis: Headless Browser (Chrome) werden seit letztem Jahr(?) nicht mehr im User Agent erkenntlich gemacht und sind folglich nicht mehr darüber identifizierbar. Es werden aber weitere Daten bereitgestellt, mittels denen diese Headless Browser identifizierbar sind (JavaScript).

Hier mehr Infos dazu und ein JavasScript Code zum Erkennen dieser Headless Browser:
(experimentell)

An Alle, die dem Thema hier noch folgen eine neue Info:

Habe nun nach ewig vielen selbst-programmierten Einstellungen ein “Bist du ein Mensch”-Banner vor die Website gesetzt. Wenn dieses mit Ja beantwortet wird, wird das Tracking aktiviert, ansonsten nicht. Die Besucherzahlen sind auf einer viel frequentierten Website um 90 % gesunken. Das bedeutet, es gibt mindestens 90 % Tracking-Rauschen. Zu beachten ist dabei, dass in meiner Matomo-Instanz Do-Not-Track aktiv ist. Zu beachten ist auch, dass vom Webhost serverseitig die Besuchszahlen (ohne Bots) schon vorher doppelt so hoch waren wie in Matomo. Also 50 % blockieren das Tracking sowieso (DNT ist aktiv) und von den restlichen 50 % sind scheinbar 90 % keine Menschen.

Die mit diesem “Bist du ein Mensch”-Banner getrackten Viewer sind dem Verhalten nach echte Menschen. Es gibt zwar weiterhin diese “Direct Entry - 1 Page - wenige Sekunden” Viewer, aber die scheinen echte Menschen zu sein.

Aber, es kam die Vermutung auf, dass diese nicht erkennbaren Bots die Matomo Tracking-Daten aus dem Matomo Tracking-Code Snippet extrahieren und eigenständig Tracking-Daten an Matomo senden. Dass die Bots also diese Daten eigenständig verwenden und damit das “Bist du ein Mensch”-Banner umgehen:

    var u="https://matomo.example.com/";
    _paq.push(['setTrackerUrl', u+'matomo.php']);
    _paq.push(['setSiteId', '1']);
...
    g.src=u+'matomo.js

Das wäre echt fies.

Versteh ich das richtig: Diese Bots erkennen, wenn der eigentlich erwartete Matomo Standard-Trackingcode individuell verändert wurde, hier: um Dein Mensch-Banner? Und dann machen sie diesen individuellen Teil einfach mal unwirksam, egal was der vorher bewirkt hat?

Wenn die wirklich so schlau sind, könnten sie doch sicher auch ihren eigenen Code einfügen? Und was verhindert dann noch, dass sie damit die Datenbank direkt verändern (wozu auch immer)? Das wäre ja der nächste logische Schritt.
:thinking:

So ungefähr in diese Richtung ging die Überlegung.

Also diese Art von Bots kann JavaScript, was herkömmliche nicht können. Einige dieser Bots sind darauf programmiert, dass sie wie ein echter Mensch wirken, also wie ein echter Mensch durch das Internet surfen, extra deswegen um nicht als Bots erkannt zu werden. Diese Bots wurden aus dem Grund eingeführt, um Websites daraufhin zu prüfen, ob sie Bots einen anderen Content ausliefern als echten Menschen. Bei Bots, die erkennbar sind, ist das möglich und wird wohl auch gemacht.

Die Überlegung war nun, dass diese Bots gar nicht das Website-interne Matomo oder Google Analytics Tracking nutzen, sondern nur erkennen, welches von beiden in der Website eingebunden ist. Nachdem sie es erkannt haben, laden sie (in diesem Beispiel) entweder die matomo.js von ihrem Server selbständig in die Website, oder nutzen die bereits eingebundene. Dann greifen sie die URL für die matomo.php ab und die Tracking-ID. Den Rest haben sie sowieso (wie Website-Url und dergleichen). Anschließend basteln sie einen eigenen Url-Query String mit all den erforderlichen Daten und senden ihn an die matomo.php.

Das ist schon ziemlich weit hergeholt und nur ein vage Vermutung. Möglich ist es.

Was mittlerweile Fakt ist: Die Anzahl der getrackten Visitors ist bei meiner meistbesuchten Website um 90 % gesunken, seitdem ein “Ich bin ein Mensch”-Check Popup eingebunden wurde, bei dem nur nach erfolgreichem Check das Tracking aktiviert wird. Das bedeutet, entweder springen 90 % wegen des Popups gleich ab, oder 90 % bestehen es nicht. Die verbliebenen getrackten Visits sind dem Anschein nach Visits von echten Menschen. Für ein paar wenige Ausnahmen besteht die oben erwähnte vage Vermutung.

Nehmen wir an, Deine vage Vermutung stimmt. Dann ist die Frage:
Wozu machen die das?

Als Geschäftsmodell, wie Du es schon beschrieben hast? Denkbar. Sie könnten dann wohl auch im Auftrag von Seitenbetreibern einen höheren Traffic vorgaukeln, um z.B. deren Site für Werbetreibende attraktiver erscheinen zu lassen. Wenn das ginge, hätten wir aber ein ernsthaftes Sicherheitsleck. Abgesehen davon, dass sie per Javascript PHP aufrufen können müssten.
Andererseits könnten sie den js-Tracker auch gleich durch einen php-Tracker ersetzen, wenn sie es schon mal drauf angelegt haben (s. https://github.com/matomo-org/matomo-php-tracker).
Alles nicht trivial, aber KI wirds schon programmieren…

Aber wozu machen die das bei wildfremden Seiten? Bringt ihnen selber ja nichts, wenn sie deren Statistik manipulieren.

Da hast du was falsch verstanden oder bringst etwas durcheinander.

Diese human-like Bots werden nicht von den Website-Eigentümern, sondern von Firmen betrieben, die Websites überprüfen, und zwar ungefragt. Von denen gibt es einige. Was deren Geschäftsmodell genau ist? Keine Ahnung. Eventuell Sicherheitsrisiken erkennen, Betrug erkennen, Listen erstellen, Rankings, Daten sammeln.

Somit kommt PHP-Tracking nicht in Frage, weil diese Firmen kein PHP Skript auf der Website installieren können. Sie können nur JavaScript nutzen.

Diesen Firmen geht es also darum mit Bots, die wie ein echter Mensch wirken, Websites zu überprüfen, ob diese Websites den Bots einen anderen Content als den echten Menschen anzeigen. Falls dem so ist, wird das als Betrug gewertet.

Zudem werden Websites vermutlich mit verschiedenen Betriebssystemen und Browsern getestet, was alles in das Daten-Sammel-Ranking einfließt.

Die von dir erwähnte Sache würde nur einen Sinn ergeben, wenn nicht Matomo, sondern GA von den Websites genutzt werden würde um Einfluss auf das Suchmaschinenranking zu haben.

Es gibt bereits Clouds, die einen Service anbieten, bei dem die IP alle paar Minuten gewechselt wird. Auf solchen Clouds können solche human-like Bots installiert werden. Damit wäre es Website-Eigentümern möglich, die Visits auf ihre Websites betrügerisch zu erhöhen. Der Aufwand dürfte aber in einem schlechten Verhältnis stehen.

Bei der Nutzung von Matomo würde es nur den Traffic betreffen. Da gibt es Ranking-Firmen, die den Internet-Traffic an den Internet-Knoten überwachen. Ob allein erhöhter Traffic einen Einfluss auf den Erfolg einer Website hat ist schwierig einzuschätzen.

Dein Argument mit den Werbetreibenden betreffend: Die meiste Website-Werbung funktioniert per JavaScript. Die Werbefirmen unterscheiden zwischen Visits / Clicks / Pays. Alles drei sollte in einem guten Verhältnis stehen. Die Bots würden nur Visits und Clicks erzeugen, aber keine Pays, und somit die Statistik/Reputation verfälschen. Zudem wird auch Storno statistisch erfasst. Also würden Fake-Pays auch nichts bringen. Es würde also keinen Sinn ergeben. Außer bei reiner Visit-Werbung (ähnlich Straßenwerbung). Aber darauf sind die Werbefirmen trainiert, dass sie solchen Betrug erkennen.

Meiner bsiherigen Ansicht nach sind es human-like Bots, die auf die Sicherheit der Websites aus sind.