Erfahrungsbericht matomo Tracking Rauschen

Deutschsprachiges Forum (German)
14

Was soll Screaming Frog bringen? Das ist doch selbst ein Bot (Spider). Eine neue Instanz von matomo fange ich erst gar nicht an. Wenn mir einer sagt, wie ich die Daten dieser Bots aus matomo extrahieren kann, dann kann ich sie gerne hier veröffentlichen.

Also mir geht es weniger um eine Lösung nur für mich, sondern um eine Lösung für default. Diese Bots werden ganz sicher nicht nur meine Websites besuchen, also die sind ganz sicher nicht nur auf mich angesetzt.

Keine Expired Domains. Nagelneue Domains. Mit Wörtern, die teils relativ neu sind, aber nicht gänzlich unbekannt, und tatsächlich neuen Wörtern, die es vorher noch nicht gab.

15

Den Frog gibt es nicht nur als Crawler, sondern auch zur Analyse der Logfiles in denen alle Zugriffe protokolliert werden.

Ich hab schon genügend Seiten gesehen, die keinen Traffic haben. Sorry, aber ich vermute da eher einen Einzelfall bei dir. Deswegen ja mein Vorschlag mit der Logfileanalyse

16

Ich sehe das nicht als Einzelfall. Das würde sehr gezielte Überwachung bedeuten. Also dass ich von irgendwem ins Visier genommen worden bin. Bei aller Paranoia und auch möglichen Umständen schließe ich das allerdings aus.

Ich habe jetzt mal sporadisch eine (gekürzte IP) nachgesehen. Sie führt zur Firma “DataCamp Limited”. Über diese wurde bereits viel geschrieben. Traffic von dieser Firma wird als “high​ fraud risk ISP” (betrügerisch) eingestuft.

Auf den betreffenden Websites nutze ich keinerlei CDN, sowie keinerlei Third Party.

Die Frage ist nun, wieso matomo solche IPs nicht auf der Blacklist hat?

17

Welche IP ist das denn ?

18

156.146.49.0
der gesamte Range von 0-255
https://scamalytics.com/ip/156.146.49.0
die verwenden sehr viele IPs:

19

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.

20

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.

21

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?

22

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.

23

Nur zur Info: Das ist glaube ich was

unter anderem macht

24

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.

25

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.

27

[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.

28

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.

29

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

30

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.

31

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 || [];.

32

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.

33

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.

34

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)