Leserengagement über die Scrolltiefe messen in Matomo und Google Analytics

Schon in den vorhergehenden Beispielen ging es um die Frage, wieweit ich das Leserengagement erfassen kann, wenn der Besucher nur eine Seite besucht – as bei Blogs bekanntlich häufiger der Fall ist. Im dritten Teil geht es nun das Messen der Scrolltiefe.

Content-Messen in Matomo

Um das Funktionieren dieser Methode zu verstehen, stellt man sich einen längeren Text in aufeinander abfolgende Textblöcke vor. In HTML bedeutet das, dass ein Text in eine Folge von Containern zerlegt wird (selbstverständlich gilt das für alle Arten von Content wie Bilder, Videos etc.). Jeder dieser Container wird dann gekennzeichnet.

Für diese Methode gibt es eine eigene Terminologie: Der Contentnamen (content-name) bezeichnet den Textblock als ganzen, die Contentteile die einzelnen Container (content-piece). Impressions bezeichnen dann die Häufigkeit der aufgerufenen einzelnen Teil, Interaction die Interaktion des Besuchers mit den jeweiligen Elementen (Klick auf Video, Bild zur Vergrößerung).

Matomo hat schon in der Grundinstallation einen Report Inhalt im Bereich Verhalten, allerdings werden dort ohne vorherige Anpassung der Technik keine Daten gesammelt. Erste Voraussetzung für das Datensammeln ist eine Erweiterung des Trackingcodes von Matomo um folgende Zeile: 

 _paq.push([‚trackVisibleContentImpressions‘]);

Alternativ könnte auch der Code “trackAllContentImpressions” lauten, aber damit erfasse ich gerade nicht die einzelne Abfolge von Textteilen. Aber genau das möchte ich ja wissen, ob der zweite, dritte Container meiner Texte erreicht werden. Dazu wird der ganze Text als Container mit dem Tag data-track-content ausgzeichnet und dem Container mit dem zusätzlichen Tag data-content-name=”XXX” eine bezeichnung verpasst. Die einzelnen Untercontainer erhalten nun spezifische Auszeichnungen mit einem weiteren Tag: data-content-piece=”Teil1”. Ähnlich wie im Event-Tracking stehen Name und Teil in einem hierarchischen Verhältnis, d.h. unter dem Namen stehen die jeweils above the fold erreichten Teile. Sicher wird Teil 1 häufiger erreicht werden als der letzte Teil.

Auch hier stelle ich mir die Frage, wie ich die Container dimensionieren soll. Ich selbst orientiere mich an den Zwischenüberschriften, die jeder strukturierte Text haben sollte. (Einen langen Fließtext wird im Internet kaum jemand lesen wollen.)

Alternative – Scrolltiefe messen mit JavaScript

Die Erstellung solcher Container ist manuell oder auch mit dem Tag Manager aufwändig. Eine interessante Alternative bietet Sebastian Offers in seinem Blog. Er misst das Leserengagement mit Hilfe eines Scripts, das den Umfang (letztlich angezeigte Höhe im Browserfenster) des gesehenen Textes in Verhältnis setzt zur Gesamthöhe und daraus den prozentualen Anteil errechnet. Das Skript erfasst dabei Leseschritte in Prozentstufen, die ich als String frei wählen kann. Nur würde ich größere Lesefortschritte messen als in dem Beispiel angegeben (also 15 – 30 – 45 % usw.). Das Skriptbeispiel steht hier: https://www.analytics-sem-tutorials.de/piwik-analytics/matomo-scroll-tracking/ 

Scrolltiefe messen mit dem Google Tag Manager

Google Analytics bietet über den Tag Manager eine mittlerweile relativ komfortable Option, die Scrolltiefe – ähnlich wie bei Sebastian – in % zu messen. Dazu muss ich zunächst die drei integrierten Scroll-Variablen aktivieren.

 Als Triggertyp wähle ich Scrolltiefe und gebe dann die Prozentsätze ein (s.o. 15 – 30 – 45 % usw.). 

Ich könnte auch Pixel als Maßstab nehmen, das halte ich allerdings für weniger anschaulich. Im Trigger gebe ich noch eine zusätzliche Bedingung ein z.B. dass der Tag nur aktiviert wird, wenn z.B. im Seitenpfad “/blog/” oder “/aktuelles/” steht (sonst arbeitet er alle Seiten durch). Zuletzt richte ich einen Event-Tag ein, mit der Kategorie “Scrolltiefe”. Unter Aktion stelle ich dann {{Page Path}}, um zu wissen, welcher Beitrag gerade getrackt wird. Im Label kommt die Variable {{Scroll Depth Threshold}}% zum Zuge. 

Nach Prüfung des Tags kann ich ihn veröffentlichen. 

HeartBeat bei Matomo und Google Analytics – Korrektur der Absprungraten

Fortsetzung des Beitrags: Der (un)heimliche Leser – Messung des Besucherengagements in der Webanalyse

Ziel des Einsatzes des HeartBeatTimers ist das genauere Messen der Besuchszeit und Reduzierung der Absprungrate. Hierzu löst eine JavaScript Funktion immer nach Ablauf einer definierten Zeit ein Ereignis aus. Je kürzer das Intervall des auslösenden Ereignisses eingestellt ist, desto genauer kann ich die Besuchszeit messen. Bei Einstellung 1 (bzw. 1000 Millisekunden bei Google), wäre eine sekundengenaue Messung möglich. Allerdings hat diese Einstellung zwei (Matomo) bzw. einen (Google) erheblichen Nachteil. Der gemeinsame Nachteil ist der, dass die Absprungrate quasi auf 0 gesetzt wird und somit keinen brauchbaren Wert mehr liefert. Bei Matomo kommt hinzu, dass die Last des eigenen Servers deutlich ansteigen dürfte und die Seitenladezeit entsprechend verlängert.

Wann soll ein HeartBeat ausgelöst werden?

Daher muss ich mir zuvor die Frage stellen, welcher Wert hier eingestellt werden soll. Die bislang gemessene durchschnittliche Besuchszeit ist hier kein guter Maßstab, da sie pauschal für alle Seiten gilt. Ich beabsichtige aber nicht, die Performanz der Datenschutzerklärung zu messen, sondern die Seiten, auf deren Inhalt es mir ankommt, weil sie den Unternehmenszielen hinsichtlich Branding, Leadgenerierung, Bewerbungen oder Verkäufen dienen. Auch die Verweilzeiten auf der Startseite ziehen häufig die durchschnittlichen Besuchszeiten nach unten, da Besucher häufig weiterklicken. 

Im Prinzip muss man abwägen, ob die Absprungrate als wichtiger Wert weiterhin gemessen wird, oder ob die genaue Messung der Besuchszeit im Vordergrund steht. Spiel die Absprungrate als Messwert eine Rolle, würde ich den HeartBeat nicht unter 15 Sekunden setzen, etwa die doppelte Zeit, die nach einem ersten Eindruck der Seite schon eine nähere Beschäftigung mit der Seite anzeigt.

Für Blogs und umfangreichere Contentseiten veranschlage ich entweder eine durchschnittliche Lesezeit, die mir als Ausgangsparameter dient. Hier kann ich nun bestimmen, dass ich nach einem Viertel oder einem Drittel der Lesezeit, einen Herzschlag auslöse. Sehr elegant wäre selbstverständlich, die Wortzahl seitenweise zu messen und daraus eine seitenvariable Besuchszeit zu definieren. Oder ich setze die Zeit, die zum Lesen der ersten Abschnitte ansetze, die nach dem Prinzip der umgekehrten Pyramide die wesentlichen Inhalte enthalten.

HeartBeat bei Matomo

Hierzu fügt man folgende Codezeile in den Trackingcode ein:

_paqpush([‘enableHeartBeatTimer’]);

In diesem Falle löst die Funktion ein Ereignis aus, wenn der Besucher nach mindestens vergangenen 15 Sekunden den Tab wechselt.

Komfortabler scheint mir die erweiterte Funktion, die angibt, nach welcher Zeitspanne ein Ereignis ausgelöst wird. Dazu wird die Zeit in Sekunden angegeben, nach der der HeartBeatTimer ein Ereignis auslöst.

_paqpush([‘enableHeartBeatTimer’, 30]);

Der numerische Wert gibt die Zeit in Sekunden an, nach der ein Ereignis ausgelöst wird.

Bei stark frequentierten Seiten kann der HeartBeatTimer zu einer gewissen Serverlast führen, v.a. wenn die Daten regelmäßig in kurzen Abständen auf den Server geschrieben werden. In dem Falle empfiehlt sich ggf. ein Cronjob, der am frühen Morgen den Datentransfer erledigt. Die Korrelation HeartBeat und Absprungrate ist auch Thema in meinen Matomo Seminaren.

Der HeartBeat bei Google Analytics

Auch bei Google gibt es den HeartBeat, der ein Event auslöst. Unter Absehen der älteren Versionen sieht der ergänzende Code für Universal Analytics so aus:

<script>
setInterval(function() {
ga(’send‘, ‚event‘, ‚HeartBeat‘, ’30s‘);
}, 30000);
</script>

wobei die Kategorie ‘HeartBeat’ natürlich auch anders benannt werden kann, z.B. ‘Intervall’, die Aktion lautet dann ‘30s’. Dies entspricht der Funktionsanweisung 30000, die das Intervall in Millisekunden angibt.

Wer den Google Tag Manager verwendet, kann als Trigger den Timer verwenden, der auf allen Seiten ausgelöst wird:

GooTimer Triggersgle Tag Manager - Einrichten des

Und sodann folgenden Event-Tag einrichten, dem dann dieser Trigger zugeordnet wird:

Google Tag Manager - Einrichten des Event Tags

Mir kommt es hier mehr um die inhaltliche Lösung an, die Absprungraten und Leserengagement in ein möglichst realistisches Verhältnis bringt. Eine detaillierte technische Anleitung für den HeartBeat Event bietet folgende Seite, die auch Codebeispiele für die ältere Google Analytics Bibliothek (_gaq.push) enthält: https://dg.agency/blog/ga-time-on-site-why-its-broke-and-how-to-fix-it/

Die ausgelösten Ereignisse stehen in dem Report Verhalten=>Ereignisse unter der jeweils vergebenen Kategorie.

Berechnung der Absprungrate in Matomo

Der HeartBeatTimer löst zwar ab einer gewissen Verweildauer eine Messung aus, die aber nicht als Event die Absprungrate beeinflusst. Also auch wenn der Besucher 10 Minuten auf einer Seite verbleibt und dann geht, ist das ein Absprung. Um die „wahre“ Absprungrate zu messen muss ich in Matomo also die Besuche segmentieren, die die Besuchszeit „0“ haben und auf die Gesantzahl der Besuche prozentual beziehen.

Demnächst mehr…

Der (un-)heimliche Leser – Messung des Leserengagements in der Webanalyse

Vor kurzem las ich in dem Newsletter von 121watt (07.07.2020) folgenden Passus: “Ob dein Content sein Ziel erreicht und gut bei deiner Zielgruppe ankommt, kannst du anschließend anhand verschiedener Kennzahlen überprüfen. Eine niedrige Absprungrate gepaart mit einer langen Verweildauer sprechen zum Beispiel dafür, dass sich deine Nutzer intensiv mit deinen Inhalten auseinandersetzen und du ihre Bedürfnisse richtig adressierst.”

Selbstverständlich wissen Alexander Holl und sein Trainerteam es besser, als ihre plakative Aussage hier vermuten lässt.. Denn Absprungrate und Verweildauer sind sehr grobe Kennzahlen für das Besucherengagement. Für mich gaben sie einen Anlass, über das Messen des Engagements, die die Besucher Seiten-Inhalten widmen, etwas detaillierter zu schreiben.

Read More