Nach Update extremer Besucherverlust (laut Statistik)

kilian · December 10, 2020, 8:28am

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.

edvsb · December 10, 2020, 10:58am

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.

Lukas · December 10, 2020, 11:04am

Hallo,

Vielleicht verstehe ich da was falsch, aber der Tracker verwendet doch weiterhin GET solange man setRequestMethod nicht verwendet.
Oder verstehe ich hier was falsch?

edvsb · December 10, 2020, 11:21am

Hallo Lukas,

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]

Wie gesagt, die Doku widerspricht sich da etwas.

kilian · December 10, 2020, 11:24am

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?

edvsb · December 10, 2020, 11:27am

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.

Lukas · December 10, 2020, 11:29am

Hallo,

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:

github.com

matomo-org/matomo/blob/14da2559292afb32241f65760c614142d26238d2/js/piwik.js#L5979-L5987


/**
 * Enables send beacon usage instead of regular XHR which reduces the link tracking time to a minimum
 * of 100ms instead of 500ms (default). This means when a user clicks for example on an outlink, the
 * navigation to this page will happen 400ms faster.
 * In case you are setting a callback method when issuing a tracking request, the callback method will
 *  be executed as soon as the tracking request was sent through "sendBeacon" and not after the tracking
 *  request finished as it is not possible to find out when the request finished.
 * Send beacon will only be used if the browser actually supports it.
 */

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)

github.com

matomo-org/matomo/blob/14da2559292afb32241f65760c614142d26238d2/js/piwik.js#L5509-L5525


/**
 * Set request method. If you specify GET then it will automatically disable sendBeacon.
 *
 * @param string method GET or POST; default is GET
 */
this.setRequestMethod = function (method) {
    if (method) {
        configRequestMethod = String(method).toUpperCase();
    } else {
        configRequestMethod = defaultRequestMethod;
    }

    if (configRequestMethod === 'GET') {
        // send beacon always sends a POST request so we have to disable it to make GET work
        this.disableAlwaysUseSendBeacon();
    }
};

Lukas · December 10, 2020, 11:31am

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.

edvsb · December 10, 2020, 11:36am

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”

Lukas · December 10, 2020, 11:46am

Hallo,

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:

edvsb · December 10, 2020, 11:49am

Wie gesagt, muss ich erst wieder suchen. Hatte die letzten Tage so viele Seiten offen…

Eine ist z.B. das setRequestMethod hier: https://developer.matomo.org/api-reference/tracking-javascript

Die Erklärung ist nun ja nicht mehr wirklich stimmig, wenn alwaysUseSendBeacon per default an ist.

edvsb · December 10, 2020, 11:51am

Da steht das mit dem sendBeacon. https://github.com/matomo-org/matomo/blob/4.x-dev/CHANGELOG.md Ist auch richtig, widerspricht sich aber mit dem Hinweis zu setRequestMethod. Der eine sagt default GET, der andere POST.

Lukas · December 10, 2020, 11:55am

Ich habe jetzt einmal

erstellt um die Beschreibung etwas klarer zu machen.

kilian · December 10, 2020, 11:58am

ich habe jetzt mal testhalber die folgende Zeile eingefügt:

_paq.push(["setRequestMethod", "GET"]);

(nach var _paq = _paq || [];)

Bin gespannt, ob das was ändert.

melbao · December 10, 2020, 1:22pm

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.

kilian · December 10, 2020, 2:12pm

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.

edvsb · December 10, 2020, 2:24pm

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.

edvsb · December 10, 2020, 2:34pm

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

kilian · December 10, 2020, 3:34pm

Interessant!
Also erst einmal mit “GET” weitermachen…

Offtopic:

das habe ich bei mir per htaccess rewrite auch gemacht. Denke nicht, dass da ein Blocker drauf anspringt.

edvsb · December 10, 2020, 3:58pm

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.