Warum die durchschnittliche Sitzungsdauer in Analytics kompletter Quatsch ist

Ich beschäftige mich seit über 20 Jahren mit Webanalyse, angefangen mit Serverlogfiles und heute mit zum Teil abgefahrenen Implementierungen von Tracking-Systemen. Die Möglichkeiten werden immer besser, aber nicht alles ist besser geworden. Denn ein Aberglaube ist einfach nicht totzukriegen, nämlich dass Time on Site oder die “durchschnittliche Sitzungsdauer” eine gute Metrik ist, beziehungsweise dass die angegebenen Werte überhaupt stimmen, Darum hier einmal schwarz auf weiß: In einer Standardimplementierung wird die Time on Site nicht richtig gemessen, egal ob in Adobe Analytics oder Google Analytics oder Piwik oder sonstwas. 

Warum die durchschnittliche Sitzungsdauer nicht richtig gemessen wird

Die Erklärung, warum die Zeitangaben nicht stimmen können, ist ganz einfach. In einer Standardinstallation von Google/Adobe Analytics/[place your system here] wird jedes Mal eine Messung durchgeführt, wenn der Nutzer eine Aktion auslöst. Er kommt zum Beispiel um 13:00 Uhr auf eine Website, und dann wird das erste Mal das Tracking-Pixel ausgelöst. Der Nutzer schaut sich ein wenig um und klickt dann um 13:01 auf einen Link, so dass er auf eine weitere Seite der gleichen Website kommt, wo wieder der Tracking-Pixel gefeuert wird. Nun können wir ausrechnen, dass er bisher 1 Minute auf der Website verbracht hat, denn wir haben zwei Messpunkte mit unterschiedlichen Zeitstempeln. Wir messen Zeit hier mit der zeitlichen Distanz zwischen zwei Seiten.

Auf der zweiten Seite, auf der er sich nun befindet, hält sich der Nutzer länger auf, denn hier findet er das, wonach er gesucht hat. Er liest einen Text, und um 13:05, also nach 4 Minuten, ist sein Informationsbedürfnis befriedigt, so dass er die Seite verlässt. Er war nun also insgesamt 5 Minuten auf der Website. Analytics weiß aber nur von der 1. Minute und wird auch nur diese 1 Minute in die Statistik aufnehmen. Denn beim Verlassen der Seite wird nichts mehr gefeuert. Wie oben geschrieben: Wir messen Zeit mit der zeitlichen Distanz zwischen zwei Seiten. Zeitliche Distanz zwischen 1. und 2. Seite: 1 Minute. Zeitliche Distanz zwischen 2. und Exit: Nicht messbar, denn es fehlt die nächste Seite. Und das ist den meisten Anwendern nicht klar. Die Zeit, die ein Nutzer auf der letzten Seite verbringt, wird nicht gemessen.

Kann Analytics nicht messen, wenn ein Nutzer die Seite verlässt? Nein, kann es nicht, egal welches System. Zumindest nicht in der Standard-Installation. Diese kann man natürlich anpassen. Ansonsten: Kommt ein Nutzer auf eine Webseite und schaut sich nur eine Seite an, dann wird keine Zeit gemessen. Auch wenn er 10 Minuten auf dieser einen Seite verbringt, es fließt nicht ein in die durchschnittliche Sitzungsdauer. Da ein Eine-Seiten-Besuch nicht selten ist, fehlen also ziemlich viele Daten.

Ist das denn wirklich so schlimm?

Macht das denn wirklich so viel aus? Ja, macht es. Häufig heißt es vom erstaunten Anwender, dass man mit den angegebenen Zahlen doch wenigstens einen Anhaltspunkt hätte. Was kann man mit einem Anhaltspunkt anfangen, der komplett falsch ist? Natürlich mag sich niemand gerne eingestehen, dass alle bisherigen Daten falsch waren und die darauf basierenden Entscheidungen ebenso.

Google Analytics Durchschnittliche Sitzungsdauer

Um die Unterschiede zu verdeutlichen, hier ein paar Datenpunkte. Bis August 2017 betrug die durchschnittliche Sitzungsdauer auf meiner Seite im Durchschnitt 1 Minute (rote Linie, hier im Vergleich zum Vorjahr). Ab dem August 2017 steigt die durchschnittliche Sitzungsdauer auf 5 Minuten (blaue Linie). Die Time on site hat sich verfünffacht und wirkt auch viel realistischer, da die meisten Inhalte auf meiner Seite nicht in 1 Minute gelesen werden können. Allerdings sind selbst diese 5 Minuten nicht die tatsächliche durchschnittliche Sitzungszeit, sondern nur eine Annäherung.

Wie kommt man zu besseren Zahlen?

Wie kommt es überhaupt, dass nun mehr von der Zeit gemessen wird? In einem anderen Artikel hatte ich über das Messen der Scrolltiefe geschrieben, und hier wird beim Erreichen von 25%, 50%, 75% und 100% der Seitenlänge ein Event gefeuert. Mit jedem dieser Event wird auch ein Zeitstempel mitgesendet. Scrollt ein Nutzer herunter, so wird also auch von der letzten Seite eines Besuchs eine Zeitspanne gemessen, und zwar bis zum Auslösen des letzten Events. Es ist nicht unwahrscheinlich, dass die Nutzer sogar noch mehr Zeit auf dieser Seite verbringen, denn vielleicht lesen Sie noch etwas im unteren Abschnitt, scrollen aber nicht mehr weiter.

Warum, könnte die Frage nun lauten, wird nicht einfach jede Sekunde ein Event ausgelöst, solange der Nutzer auf der Seite ist? Dann hätte man doch eine genaue Sitzungsdauer. Technisch ist das tatsächlich möglich, aber bei Google Analytics zum Beispiel erlaubt die kostenlose Version maximal 10 Millionen Hits pro Monat (Hit = Server Call), bei Adobe wird jeder einzelne Hit abgerechnet. Ich dürfte mir bei Google Analytics pro Tag also 333.333 Hits erlauben, und wenn wir von einer tatsächlichen durchschnittlichen Sitzungsdauer von 6 Minuten (360 Sekunden) ausgehen, dann dürfte ich weniger als 1.000 Nutzer täglich haben, damit mir nicht der Saft abgedreht wird. Und damit haben wir noch nichts anderes gemessen. Selbst bei der Scrolltiefen-Messung wären bei vielen Seiten schon so viele Server Calls ausgelöst, dass man sich das schlichtweg nicht leisten kann. Hier kann aber zumindest bei einem Random Sample von Nutzern gemessen werden, um zumindest eine Annäherung zu erhalten, die diesen Namen verdient.

Warum überhaupt die durchschnittliche Sitzungsdauer verwenden?

Diese Metrik wird häufig dann verwendet, wenn keine “harten” Conversions existieren, zum Beispiel wenn Awareness eines der Marketing-Ziele ist und zunächst einmal nur Nutzer auf die Seite kommen sollen. Vielleicht wird aber auch nur deswegen viel Zeit verplempert, weil die gewünschten Informationen nicht gefunden, aber dringend benötigt werden (schon mal einen Treiber auf hp.com gesucht?); mit anderen Worten, vielleicht ist eine kürzere Zeit sogar besser?

Wie immer ist es eine Frage, wie gut segmentiert wird. Bei hp.com wäre eine Metrik wie “time to download” gut, bei einer reinen Content-Seite wäre die Scrolltiefe gepaart mit der auf der Seite verbrachten Zeit ein guter Indikator dafür, wie gut mit dem Content interagiert wird. Dazu müsste noch einbezogen werden, wie viel Inhalt auf einer Seite vorhanden ist. Dies kann zum Beispiel mit Custom Dimensions abgefrühstückt werden. Mein Lieblingsspruch dazu: Jede Minute, die ein Nutzer auf der Seite meines Kunden verbringt, kann er nicht auf der Webseite seines Marktbegleiters verbringen.

Spannend ist die echte durchschnittliche Sitzungsdauer aber auch, weil das Konzept von holistischen Landingpages immer weitere Kreise zieht. Da Google zum Teil auch Signale erhält, wie lange jemand auf einer Seite war (zum Beispiel durch Rückkehr auf eine Suchergebnisseite), sollte es auch jeden Suchmaschinenoptimierer interessieren, wie lange jemand tatsächlich auf einer Seite war und welche Teile des holistischen Contents tatsächlich gelesen wurden (schließlich wird der Content ja für Nutzer geschrieben und nicht für den GoogleBot… oder? 🙂

Fazit

Die durchschnittliche Sitzungsdauer oder Time on Site in jedem Analytics-System liefert in einer Standard-Installation falsche Zahlen, was den wenigsten Anwendern klar ist. Abhilfe schafft hier das Auslösen von Events, zum Beispiel zum Scroll Tracking. Wie so oft: A Fool with a Tool ist still a Fool. Solange man sich nicht damit auseinander setzt, wie ein Tool etwas misst, darf man sich nicht wundern, wenn die daraus gewonnenen Schlüsse falsch sind. Das gilt für Analytics genau so wie für Google Trends oder Similar Web 🙂

3 Antworten auf „Warum die durchschnittliche Sitzungsdauer in Analytics kompletter Quatsch ist“

  1. Für selbst gehostetes Piwik ist die Lösung mit einem Heartbeat z. B. alle 5 Sekunden recht einfach umzusetzen, ohne in solche Fallen zu tappen wie die Kostenschranke bei GA (war mir übrigens gar nicht klar, dass es diese gibt).
    Der als Webseite angegebene Link führt zu meinem Beitrag darüber.

  2. Danke für den Link. Wie gesagt, bei einer Standardinstallation ist es halt nicht dabei. Und so toll ich Piwik auch finde, selbst hosten bei einer Seite mit vielen Hits ist schon etwas aufwändiger (eine kleine Instanz bei AWS reicht dafür nicht) und eben auch mit Kosten verbunden, insbesondere bei einem Heartbeat.

    Den Heartbeat alleine finde ich ehrlich gesagt auch nicht so sinnvoll, denn was sagt er aus? Dass der Tab noch offen ist. Ob der Nutzer tatsächlich mit dem Content interagiert, das bleibt offen. Daher finde ich meine Lösung etwas sinnvoller, da ich zwei Fliegen mit einer Klappe streichle 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.