Das 0 Sekunden Problem

Hallo Miteinander,

ich habe mich extra wegen dem benannten Problem angemeldet, weil ich glaube, dass nur die wenigsten von diesem Problem wissen, aber sich sicherlich schon gewundert haben.

Was ich mit “0 Sekunden Problem” meine, ist die Verfahrensweise von Matomo, wenn ein Benutzer nur 1 Seite aufruft. Diese Thematik ist im Grunde genommen schon uralt und gibt es schon seit ungefähr 4 1/2 Jahren. Es gibt zwar eine Lösung dafür, aber ob diese Lösung wirklich eine zufriedenstellende Lösung ist, bin ich mir nicht sicher.

Was sicherlich schon vielen aufgefallen ist, ist die Angabe von 0 Sekunden Besuchszeit, was an sich schon Fragen aufwirft, weil es 0 Sekunden eigentlich nicht geben kann. Dass Matomo so einen Wert ausgibt, liegt aber nicht an einem Fehler, sondern daran wie Matomo solche sog. One-Page-Visits behandelt, wenn der Tracker Code unverändert übernommen wird. Das gleiche Phänomen betrifft auch mehrseitige Aufrufe, bzw. die zuletzt aufgerufene Seite. Für diese letzte Seite gibt es überhaupt keine Angaben zur Besuchszeit.

Nachdem die Besuchszeiten nicht gerade unwichtig sind, hat die o.g. Praktik aber mitunter fatale Auswirkungen, weil dadurch die Berechnung der durchschnittlichen Verweilzeiten bis zu 100% “verfälscht” werden. Die 0 Sekunden Verweilzeit wird ja in die Durchschnittsberechnung mit einbezogen, so dass man keinen Taschenrechner braucht, um zu der Erkenntnis zu kommen, dass sich dies erheblich auswirkt.

Matomo bietet dafür aber eine Lösung an bei der ich mich aber frage, warum diese nicht schon standardmäßig aktiv ist. Diese Lösung besteht aus einer winzigen Ergänzung im Trackercode, die nichts anderes macht als in einem Zeitintervall zu prüfen, ob der Benutzer noch auf der Seite ist. Er pingt ihn, bzw. den Cookie an und lässt sich variabel in Sekunden einstellen. Ohne Zeitvorgabe beträgt das Intervall 15 Sekunden, was ich für zu lange halte und habe diesen auf 5 Sekunden eingestellt.

Die Konsequenz aus dieser Tracker Erweiterung sollte offensichtlich sein?! In meinem Fall hat sich die durchschnittliche Besuchszeit mehr als verdoppelt, eben weil es fast keine 0 Sekunden Aufrufe mehr gibt.

Dieses Thema könnte man jetzt noch erweitern, weil es noch weitere Aspekte gibt für die Matomo keine Lösung anbietet und zu Fehlertoleranzen führt. Ich hoffe aber, dass ich den Unwissenden weiterhelfen konnte.

Hi,

Zur Frage, warum Heartbeat nicht standardmäßig aktiv ist:
Bei Servern, die jetzt schon an der Leistungsgrenze arbeiten, wird die Vervielfachung der Anfragen deutliche Performanceverschlechterungen mit sich ziehen.

Mehr Details:

Dass es einen gut überlegten Grund dafür gab, schien klar zu sein und hab mich vielleicht unglücklich ausgedrückt. Allerdings und auch wenn es zu Lasten der Performance geht sollte man vielleicht bei der Bereitstellung des Tracker Codes nach der Installation darauf hinweisen, bzw. optional zur Auswahl anbieten. Ich bin wahrlich kein Newbie, aber es hat selbst mir einiges an Zeit gekostet dem “Übel” auf den Grund zu gehen.

Bei der Gelegenheit, weil für mich dieses Problem noch nicht gänzlich geklärt ist. Wie verhält sich Matomo bei prefetch/prerender Anfragen? Bekanntlich pushed Google das zuerst platzierte Suchergebnis in den Serps mit prerendering, wenn man Chrome benutzt.

Eine andere Art und Weise diese Anforderung zu erfüllen ist mit Hilfe der Messung der Scrolltiefe in die Seite hinein mit dieser Technik: Scroll Depth for Piwik - tracks how far users are scrolling
Jede 10 % Scrolltiefe werden entweder als Event oder Goal getrackt (je nach Setup) und somit bekommt man ein sehr detailliertes Bild über das Interaktionsverhalten auf der Webseite, die meiner Meinung nach noch mehr Aussagekraft als nur Heartbeat gibt.

Die Messung der Scrolltiefe ist auch als “enhancement” auf github erfasst: Ability to track page scrolls, and create goals based on how far users scroll down the page · Issue #12243 · matomo-org/matomo · GitHub

Das sehe ich jetzt aber als Ergänzung um das Tracken noch weiter zu differenzieren und sehe da auf den ersten Blick keinen unmittelbaren Zusammenhang zu meinem Thema. Muss mir das aber noch mal genauer ansehen.

Derzeit quält mich aber noch immer die Frage, die der Support unbeantwortet ließ. Was die wenigsten wissen, ist der Umstand, dass Google in den Suchmaschinenergebnissen prefetching betreibt. Das reduziert sich zwar auf das oberste Suchergebnis, aber egal ob nun Heartbeat aktiv hat oder nicht, ergeben sich durch das Prefetching eine nicht unerhebliche Zahl an ge-fake-ten Besuchern. Google macht ja kein DNS prefetching, sondern auf die gesamte Seite nebst allem, was im Header definiert ist. Sowohl in den Server Access Logfiles als auch in Matomo sehen solche Zugriffe so aus als wäre das ein regulierer Zugriff, ist es aber nicht. In Matomo fällt das dadurch auf, dass solche Zugriffe meist nicht mehr als 6 Sekunden dauern. (bei aktivem Heartbeat und kurzen Refresh Zeiten)

Wer also glaubt er hätte eine große Anzahl an Zugriffen, der irrt, aber gewaltig, was dann auch noch verschlimmert wird, wenn man in den Suchergebnissen ganz oben steht.

Es gäbe zwar eine Lösung dafür, aber bei der Lösung spielt Google mit Chrome nicht mit, weil sich Google schon vor Jahren dazu entschieden hat anders als beim Firefox keinen entsprechenden Header bei solchen Prefetching Zugriffen zu definieren, was sich dann auch nur auf den FF und Apache Server reduziert.

Hallo,

Ich bin mir nicht sicher, ob Prefetching so funktioniert, wie du es beschrieben hast. Auch muss man auf jeden Fall zwischen Log Analytics und dem JS Tracking code unterscheiden.
(Von https://css-tricks.com/prefetching-preloading-prebrowsing/)

Man kann den Link zu einer Webseite so machen:

<link rel="dns-prefetch" href="//example.com">
oder
<link rel="preconnect" href="http://css-tricks.com">

Dann macht der Browser den DNS resolve bzw. die SSL Verbindung schon vor dem Klick.
Beides hat aber keinen Einfluss auf Matomo.

Weiters kann man, wenn man sicher weiß, dass die example.css später auf der eigenen Seite gebraucht wird, den Browser sagen, dass er sie schon mal laden soll und dadurch ist sie später schon im Cache

<link rel="prefetch" href="example.css">
oder 
<link rel="preload" href="example.css">

(ersteres ist eine Empfehlung, zweiteres eine Vorschrift an den Browser)

Das hat somit auch keinen Einfluss auf Matomo.

Nun gibt es aber auch prerender und das ist schon deutlich problematischer.

<link rel="prerender" href="https://example.com">

Damit sagt man dem Browser, dass er diese Seite im Hintergrund von Vollständig aufbauen soll. Dadurch wird sie vollständig geladen und auch Matomo wird ausgeführt.

Aber zum Glück gibt es eine Möglichkeit zu erkennen, ob eine Webseite nur prerenderd oder richtig aufgerufen wird.

Und Matomo unterstützt diese Erkennung seit vielen Jahren:

https://github.com/matomo-org/matomo/issues/2496

Ich sehe also kein Problem, warum Matomo falsche Besucherdaten anzeigen soll. (Zumindest mit dem JS-Tracking)
Bei Log Analytics könnte das anders sein, aber ich wüsste nicht wie Matomo erkennen sollte, das eine Zeile im Log nun von einem Preload Request kommt.

Ich muss mich korrigieren. Es geht nicht um prefetching, sondern prerendering, aber wenn Du schreibst, dass Matomo der trackCallback Funktion erkennen kann, ob ein Zugriff nun ein prerender Zugriff ist, warum funktioniert diese Funktion dann nicht? Ich habe Unmengen dieser Zugriffe!

Wie ich darauf komme? Ganz einfach. Ich hab den Intervall für das Heartbeat sehr kurz auf 5s eingestellt und wenn ich unzählige Zugriffe mit einer max. Sitzungszeit von 6s habe, kommt man unweigerlich zu dem Schluss, dass dies ein Zugriff ist, der nicht real sein kann, bzw. durch das prerendering entstanden ist.

Richtig oder falsch? :wink:

btw. Was ist der Unterschied zwischen Matomo JS-Tracking und Log Analytics? Meinst du mit Letzterem das Loggen des Servers?

Unter Log Analytics meine ich das Tracken von Nutzern durch Importieren von Apache/Nginx logs.