Die Digital Analytics Association ist Geschichte – und keinen interessiert es

Ein bisschen überraschend war das schon. Ich hatte mit Jim Sterne vor kurzem noch gemailt, als es um den deutschen Ableger ging. Die DAA hatte meinem Webanalyse-Buch auch ein Geleitwort gespendet. Ein bisschen schade ist es schon.

Wer es nicht weiß: Die DAA war früher die WAA, die Web Analytics Association, und sie hat die meistgenutzte Definition von Web Analytics geschaffen. Zwar war diese Definition schon lange nicht mehr auf der Webseite zu finden, aber das hat die meisten Wissenschaftler, die die Zitate aus anderen Papern kopieren, nicht interessiert.

Wie aber kann es sein, dass trotz der Wichtigkeit von Daten eine solche Organisation aufgibt? Es könnte zum Beispiel daran liegen, dass viele zwar Google Analytics & Co installiert haben, aber die Daten gar nicht genutzt werden. In meinem letzten Paper, das leider noch nicht öffentlich ist, kam heraus, dass den meisten Anwendern auch gar nicht klar ist, dass das Einbinden des GA-Codes nicht ausreicht, um datengetrieben zu arbeiten. Und vielleicht liegt es auch ein bisschen an der DAA selbst, dass sie es nicht geschafft hat, die eigene Relevanz deutlich zu machen.

Ich war zuletzt nur noch aus Nostalgiegründen Mitglied. Dabei hatte ich meinen Studierendenstatus ausgenutzt, um die Mitgliedsbeiträge etwas zu senken.

Die Website ist bereits nicht mehr erreichbar.

Werden meine Texte gelesen? Analytics-Implementierung im Detail


Zum Jubiläum der Website Boosting (60. Ausgabe!) gibt es hier einen Deep Dive, wie man einen benutzerdefinierten Bericht zu den bis zum Ende gelesenen Texten erstellen kann. Dies ist eine Ergänzung zu meiner vierteiligen Serie “Webanalyse: Wie aus Daten Taten folgen”, in der 60. Ausgabe findet sich der 3. Teil. Grundsätzlich hatte ich über das Thema auch schon einmal hier geschrieben im Vergleich zur Scrolltiefe. Dies ist ein Beispiel dafür, wie benutzerdefinierte und berechnete Messwerte verwendet werden können.

In dem Screenshot wird pro Seite angegeben:

  • Wie viele Wörter ein Text hat
  • Wie häufig eine Seite aufgerufen wurde
  • Der Anteil der Aufrufe, der zu einem Ausstieg geführt hat
  • Die Anzahl der Sichtbarkeit des YARPP-Elements (YARPP steht für Yet Another Related Posts Plugin, welches ähnliche Artikel am Schluss eines Artikels anzeigt. Ist dieses Element auf dem Bildschirm des Nutzers sichtbar, so wird davon ausgegangen, dass der Artikel über dem Element zu Ende gelesen wurde)
  • Der Anteil der Sichtbarkeit des YARPP-Elements mit Hinblick auf alle Seitenaufrufe
  • Die Anzahl der Klicks auf einen YARPP-Link
  • Der Anteil der Klicks auf einen YARPP-Link in Bezug auf die Sichtbarkeit des Elements

Welches Problem wird mit diesem Bericht gelöst?

  • Wird ein Text seltener zu Ende gelesen als andere Texte, dann scheint dieser Text nicht so interessant geschrieben zu sein.
  • Die Länge des Textes könnte ein Prädiktor dafür sein, ob ein Text zu Ende gelesen wird; wird aber ein kürzerer Text nicht zu Ende gelesen, so könnte das ein noch stärkeres Signal dafür sein, dass der Text optimierungswürdig ist.
  • Werden die Links zu ähnlichen Artikel nicht angeklickt, obwohl sie sichtbar sind, so scheinen sie nicht relevant zu sein.

Erstellen der benutzerdefinierten Dimension und Messwerte

  • In Analytics auf Verwaltung (links unten) gehen und dann in der Property-Spalte auf Benutzerdefinierte Definitionen klicken.
  • Zunächst auf Benutzerdefinierte Messwerte und dann auf den roten Button Neuer Benutzerdefinierter Messwert klicken
  • Einen verständlichen Namen auswählen (z.B. “YARPP Seen”)
  • Der Umfang (Scope) ist Treffer (Hit)
  • Der Formatierungstyp ist Ganzzahl (Integer)
  • Die restlichen Werte können leer gelassen werden
  • Auf Speichern klicken.
  • Den Prozess noch einmal wiederholen, dieses Mal für die “YARPP Clicks”. Die Einstellungen sind dieselben.

Der erste Eintrag sollte nun den Index-Wert 1 haben, der zweite Eintrag den Index-Wert 2, es sei denn, es wurden schon einmal benutzerdefinierte Variablen definiert.

Sollte auch die Anzahl der Wörter eines Textes erfasst werden, so ist dazu eine benutzerdefinierte Dimension notwendig. Der Prozess ist ähnlich, hier wieder einen passenden Namen auswählen und den Umfang Treffer. Auch hier muss der Index-Wert für diese benutzerdefinierte Dimension in Erinnerung oder notiert werden, da er später im Google Tag Manager verwendet werden soll.

Implementierung im Google Tag Manager

Sind die benutzerdefinierten Definitionen und Messwerte implementiert, so können nun Werte in diese Variablen geschrieben werden. Dies geschieht mit dem Tag Manager. Zunächst einmal muss das Element ausgewählt werden auf der Seite, bei dem der Trigger der Sichtbarkeit ausgelöst werden soll. Die dazu notwendigen Schritte sind bereits in diesem Artikel beschrieben. Dann wird der folgende Trigger konfiguriert:

Der Trigger feuert einen Tag, der nun auch noch konfiguriert werden muss:

Wichtig ist in diesem Schritt, dass die Einstellungen überschrieben werden, da nur so ein Messwert als benutzerdefinierter Messwert (im Screenshot Custom Metrics) übergeben werden kann. Hier muss dann der Indexwert gewählt werden, der in dem Schritt oben von Analytics definiert wurde. Der Wert des Messwerts ist hier 1, da für jede Sichtung der Zähler um 1 nach oben springt.

Die Variable Scroll Depth Threshold ist nicht notwendig, eventuell muss sie zunächst konfiguriert werden. Dieser Schritt muss dann noch einmal wiederholt werden für die Klicks auf einen YARPP-Link und gegebenenfalls für die benutzerdefinierte Dimension der Anzahl Wörter pro Text. Diese können aber bereits in den Google Analytics Einstellungen übergeben werden, die als Variable definiert werden. In meinem Fall sieht die Konfiguration so aus:

Wie man schön sehen kann, ist an meiner Konfiguration einiges speziell, aber der WordCount wird in eine benutzerdefinierte Dimension mit dem Indexwert 7 übergeben.

Erstellen des berechneten Messwerts

Damit eine Ratio beziehungsweise Conversion Rate angezeigt werden kann, wird ein berechneter Messwert erstellt. Dies sind die Spalten “YARPP Seen CVR” und “YARPP Click CVR” in dem Beispiel-Bericht im ersten Screenshot. Hinweis: Es kann etwas dauern, bis die benutzerdefinierten Messwerte hier sichtbar sind! Das heißt, dass dieser Arbeitsschritt eventuell erst nach einigen Stunden oder sogar erst nach einem Tag durchführbar ist.

In dem Screen Verwaltung in der ganz rechten Spalte findet sich der Eintrag Berechnete Messwerte. Hier auf den roten Button Neuer Berechneter Messwert klicken und dann im folgenden Screen die folgenden Einstellungen übernehmen. Es reicht, die ersten Buchstaben des Variablennamens einzutippen, Analytics vervollständigt die Namen. Dies ist die Einstellung für die Click CVR:

Für die Seen CVR wird die Formel {{YARPP seen}} / {{Seitenaufrufe}} verwendet.

Erstellen des benutzerdefinierten Berichts

Zu guter Letzt wird nun ein Bericht erstellt, so wie er im ersten Screenshot oben zu sehen ist. Unter Anpassung (links oben) und Benutzerdefinierte Berichte kann ein neuer Bericht erstellt werden. Hier werden alle gerade benutzerdefinierten und relevante ab Bord verfügbare Metriken ausgewählt und dazu die passende Dimension ausgewählt. Leider kann hier keine sekundäre Dimension bereits ausgewählt werden; dies muss dann manuell geschehen, wenn der benutzerdefinierte Bericht aufgerufen wird.

Das wars! Weiteres wertvolles Wissen zur Webanalyse gibt es in meinem Buch “Einführung in die Webanalyse”!

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.

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

Das optimale Tracking-Konzept oder Der Segeltörn ohne Ziel


Wie oft habe ich beim Thema Tracking-Konzept schon den Satz gehört “Lass uns einfach alles tracken, wir können uns doch später Gedanken machen, was wir eigentlich brauchen. Aber das Tracking-Konzept kann natürlich schon geschrieben werden!”

Stellen wir uns einmal vor, wir wollen mit einem Segelboot einen Törn unternehmen und wir sagten “Keine Ahnung wo wir hin wollen, lass uns doch einfach alles mitnehmen, was wir für alle Eventualitäten benötigen könnten”. Unser Boot würde sinken bevor der Törn begonnen hat. Wir wüssten nicht, ob wir Wasser und Konserven für einen Tag oder mehrere Wochen mitnehmen müssten, ob wir Winterkleidung oder Sommerkleidung benötigen und so weiter. Aber um auf Nummer Sicher zu gehen, kaufen wir einfach den ganzen Segelbedarfsladen leer, irgendwas davon werden wir schon brauchen. Und haben nun mehr, als das Schiff an Last ertragen kann. „Das optimale Tracking-Konzept oder Der Segeltörn ohne Ziel“ weiterlesen