Hallo zusammen,
nach dem - ziemlich aufwendigen - Update auf 4.0.x bemerke ich einen ziemlich drastischen Besucherabfall. Statt bisher 7.500-8000 Besuchen am Tag waren es gestern 7.300, dann 7.000 und gestern 6.400, also locker 15% weg.
Bei der Umstellung auf die neue Variante gab es erhebliche Probleme, da die Installation auf einem Shared Hosting liegt und ich etliche Kommandos per SSH-Shell einpflegen musste. Dadurch wurde ein etwa halber Tag nicht verzeichnet.
Ich frage mich jetzt, woran es liegen könnte. Hat jemand vielleicht eine Idee?
Ich habe keine Zweit-Statistik und kann daher nicht sagen, wie die tatsÀchliche Besucherzahl ist. Vielleicht hat jemand Àhnliche Erfahrungen gemacht und kennt eine Lösung?
Edit: Ein Verdacht liegt auf dem Google Core Update vom Dezember. Da gab es ein paar Ranking-Verschlechterungen. Diese gelten aber ausdrĂŒcklich nicht fĂŒr bestimmte Unterseiten, die weiterhin Top-Rankings haben und DENNOCH niedrigere Besucherzahlen verzeichnen. Also keine vollstĂ€ndige ErklĂ€rung dafĂŒr.
Ich fĂŒr meinen Fall habe auch einen Besuchereinbruch. Kommt aber sicherlich auf die Webseite und die Art der Besucher an. FĂŒr meinen Fall schiebe ich das auf das AddOn âNoScriptâ, denn die neue Request-Method POST, die der Tracker da nun nutzt, wird von dem AddOn per default blockiert, also zumindest bei mir und ich habe keine eigenen Regeln erstellt.
Core-Update wĂŒrde ich ausschlieĂen, denn das brachte einen Abfall, aber Tage vorher. Der andere Einbruch kam direkt mit dem Update von Matomo.
Vielleicht verstehe ich da was falsch, aber der Tracker verwendet doch weiterhin GET solange man setRequestMethod nicht verwendet.
Oder verstehe ich hier was falsch?
leider nein, siehe meinen anderen Post. Seit dem Update auf 4.0.3 nutzt er POST, auch hier im Forum und ĂŒberall anders. Laut Doku sollte es GET sein, ist es aber nicht mehr. Ich muss âsetRequestMethodâ explizit als GET setzen, sonst geht es nicht.
So wie ich das verstanden habe, hat das wohl auch was mit âalwaysUseSendBeaconâ zu tun, das nun standardmĂ€Ăig aktiv ist / sein soll. Die Doku, Dev-Doku und Changelog widersprechen sich da leider etwas.
Siehe auch Changelog 4.0.0: #13681 JS Tracker: enable alwaysUseSendBeacon by default [by @tsteur]
danke fĂŒr die Infos!
Ist das Problem mit âsetRequestMethodâ = GET bei dir denn behoben?
Spannend wĂ€re natĂŒrlich, wie viele Leute NoScript installiert haben. Oder schlĂ€gt Adblock usw auch darauf an?
Nein, AdBlock springt nicht drauf an. mit GET ist das Problem bei mir weg, allerdings nicht mit der 4.0.4, wie sie ausgeliefert wurde, da trackte er gar nicht mehr. Habe dann die aus Github installiert, mit der ging es. Wie das nun mit der 4.0.5 ausschaut weiĂ ich nicht, die lasse ich erst mal weg.
Wie viele das AddOn nutzen ist natĂŒrlich die Frage, daher auch der Hinweis auf das mögliche Besucherumfeld. Meine sind eher aus dem Bereich Webmaster / Seo. Fraglich aber auch, ob ncht andere Browser wie Opera etc, das blockieren.
So, jetzt habe ich es auch verstanden. Matomo 4 Àndert nichts an der defaultRequestMethod. Matomo sendet prinzipiell Requests weiterhin per GET.
Aber Matomo verwendet nun standardmĂ€Ăig ein neues Browserfeature um die Daten an den Server zu senden: navigator.sendBeacon(). Damit können Anfragen âim Hintergrundâ gesendet werden, was dazu fĂŒhrt, dass Webseiten durch Matomo viel weniger verlangsamt werden und trotzdem dieselben Daten getracket werden:
Wenn man das neue Feature nicht will, kann man es mit disableAlwaysUseSendBeacon deaktivieren.
Es gibt aber nun auch das Detail, dass sendBeacon immer POST requests senden muss und keine GET requests senden kann. Das fĂŒhrt also dazu, dass solange der Browser sendBeacon unterstĂŒtzt, Matomo die Daten standardmĂ€Ăig per POST sendet.
Wenn man niemals POST requests haben will, kann man es mit setRequestMethod setzen, was auch sendBeacon deaktiviert (aber erst seit Matomo 4.0.4)
Ich bin mir etwas unsicher, was NoScript damit zu tun hat. Wenn jemand Javascript deaktiviert, dann wird der Aufruf mit und ohne sendbeacon nicht getrackt.
Wo genau widerspricht sich die Dokumentation (mit dem, was ich beschrieben habe)? Dann könnte ich das anpassen.
Danke Lukas, genau so stand das auch irgendwo in den Untiefen der Doku, habe es nun auf die Schnelle nur nicht mehr gefunden.
Die widerspricht sich an mehreren Stellen, nur ich finde es gerade nicht mehr. Das war teils normale Doku, teils hier im Forum, teils im Bug-Tracker.
Die Request-Method ist laut Doku GET. Das stimmt aber nicht mehr, denn wenn alwaysUseSendBeacon aktiv ist, was es nun ja ist, geht er in den POST ĂŒber. Und da steht dann irgendwo die andere Doku, der HInweis, dass man das eben mit âdisableAlwaysUseSendBeaconâ abschalten kann. Diese Methode ist in der Doku der JS-Api allerdings gar nicht erwĂ€hnt.
Mein NoScript blockiert in dem Fall gar kein JS an sich, das lĂ€sst es alles zu. Es blockiert aber alle anderen möglichen Angriffsversuche. Vielleicht wertet das AddOn die Tatsache, dass es ein POST-Reuqest mit etlichen GET-Parametern ist, ja als âAngriffsversuchâ aus. In meinem Fall ist da nur âXSSâ aktiviert, also âVerdĂ€chtige webseitenĂŒbergreifende Anfragen bereinigenâ
Wenn du mir die genauen Links schickst, kann ich es anpassen. Es ist gut möglich, dass in den Mengen an Matomo Dokumentation etwas nicht angepasst wurde.
disableAlwaysUseSendBeacon fehlt auf jeden Fall in der JS-Doku:
Hallo, also bei einer meiner websites zeichnen sich fĂŒr Dezember auch weniger Visitor an, hochgerechnet, ca. 10-20%. Dazu die Infos, dass die Besucherzahlen im MĂ€rz-April sich fast verdoppelt hatten. Womit das zusammenhĂ€ngt, weiĂ ich nicht genau. Die Anzahl der Visitors ist fĂŒr mich nebensĂ€chlich. Es geht mir mehr um die Details. Wenn allerdings Visitors mal mehr mal weniger gefiltert werden, verfĂ€lscht das alles. ⊠da kann mans auch gleich ganz abschalten, bevor man falsche SchlĂŒsse zieht.
ich vermute jetzt mal, es liegt an Adblocker-Add-Ons auf Nutzerseite. Vermutlich dĂŒrfte es bei einem sauberen Browser ohne Addons perfekt funktionieren. Ich teste das aus und melde mich, wenn ich Ergebnisse habe.
Das habe ich eben erst gemacht. FF mit NoScript, aber eben Scripte erlaubt blockiert. Chrome ohne NoScript erlaubt den POST, mit NoScript auch dort nicht mehr. Und da gibt es ja mehrere AddOns, die da genutzt werden können.
Auch heiĂt mein Matomo weder Matomo noch Piwik, ist ein frei erfundener Name, also auszuschlieĂen, dass ein Blocker hier auf den Namen reagiert.
Habe auch mal versucht, den POST ohne die ganzen angehÀngten Query-Parameter zu senden. Wird dennoch blockiert. Vielleicht hat der ja auch ein Problem mit dem sendBeacon()???
AdBlock Plus selbst blockiert hier nichts, nur Werbung.
Interessant, habe es gefunden, was genau NoScript da blockiert. Witzigerweise in einem 6 Jahre alten Post von Mozilla. Es ist in der Tat die sendBeacon-Api, denn die wird als âPINGâ gewertet und den blockiert das AddOn
No, so wirklich OT ist das nicht. Könnte ja auch zu Sperren fĂŒhren, wenn da nun POST mit einer langen Query kommt. Der AdBlock Plus könnte sperren, tut es auch, wenn man den erweiterten Trackingschutz aktiviert und das tut er dann per Query-Auswertung, nicht File-Name. Irgendwas erkennt er daran. Einfach was wirres senden, oder Base64 kodiert und schon erkennt er es nicht mehr WĂ€re eventuell sogar ein Feature-Request wert, also dass die matomo.js die Query einfach verschlĂŒsselt und dann die matomo.php wieder entschlĂŒsselt.
Ich selbst habe hier sogar den Vorteil, das alles selbst zu testen oder gar selbst zu machen, denn ich arbeite mit dem Matomo-Proxy-Script und speichere die eigentliche matomo.js lokal zwischen, kann da also manipulieren. Daher hatte es mich auch verwundert, dass der Post-Request blockiert wird, denn im Grunde bleibt der auf der Domain und ist wie jedes andere Formular auch. Einen externen POST hÀtte ich auf Grund von CORS etc noch verstanden.
