Logging von Google Analytics Requests via Google Chrome für sendBeacon/beforeUnload


Heute wirds mal etwas technischer. Über die Durchschnittliche Verweildauer in Google Analytics und anderen Webanalyse-Systemen habe ich schon viel geschrieben, sie stimmt in einer Standard-Installation nicht. In einem meiner Kurse sagte dann mal ein Teilnehmer, dass man doch einfach messen könne, wenn der Nutzer den Tab schließt, zum Beispiel mit beforeUnload. So ein Trigger ist schnell gebaut, hat aber auch Nachteile. Zunächst einmal ist das nicht zuverlässig, denn ein Benutzer kann auch einfach den Tab wechseln und nicht schließen, engagiert sich aber trotzdem nicht mit den Inhalten meiner Webseite, so dass die ermittelte Time on Site nicht richtig ist. Insbesondere auf mobilen Geräten sehe ich es eher selten, dass Nutzer ihre “Tabs” schließen. Aber darum geht es heute nicht, das ist mindestens einen weiteren Beitrag wert. In diesem Artikel geht es vor allem darum, wie wir überhaupt den Einsatz von onbeforeUnload messen debuggen können.

Das Problem: Unser Logging verschwindet, wenn der Tab geschlossen wird

Hintergrund: Wenn ein Nutzer einen Tab schließt oder im gleichen Tab eine andere Website aufruft, dann kann ich zwar das Event abfangen, aber im schlimmsten Fall verlangsamt das die User Experience, da in der Regel ein Get Request geschickt wird. Geht der Nutzer nur auf eine andere Site, dann sehe ich im GA Debugger zwar was vorher geloggt wurde; aber sollte der Nutzer den Tab schließen, dann ist auch meine Console weg. Natürlich kann ich im Echtzeit-Bericht von Google Analytics schauen, ob mein beforeUnload-Event ankommt, aber Debugging ist etwas anderes. Der Google Tag Manager Debug Mode hilft hier auch nicht, denn das beforeUnload Event ist nur ganz kurz zu sehen, wenn wir den Tab schließen.

Nutzen wir dann noch sendBeacon, dann wird es noch komplexer, denn der Google Tag Assistant kommt damit gar nicht klar, wahrscheinlich weil sendBeacon POST Requests sendet und keine GET Requests. sendBeacon hat aber den großen Vorteil, dass wir nicht die User Experience beeinträchtigen.

Die Lösung: Logging vom GA Debugger in eine Datei schreiben

Abhilfe schafft hier ein kleiner Hack. Wir starten Chrome mit einem Logging im Terminal und lassen uns dann zum Beispiel live die Logdatei ausgeben. Hier muss der GA Debugger immer noch aktiviert sein, denn er schreibt weiterhin brav in die Console, nur dass wir in der Datei sehen können, was er reingeschrieben hat, auch wenn der Tab schon geschlossen wurde.

Mit diesem Code starte ich meine Live-Ansicht des Loggings; der Parameter -f für tail bedeutet lediglich, dass ich immer sehen will, wenn an das Ende der Log-Datei etwas angehängt wird:

tail -f Library/Application\ Support/Google/Chrome/chrome_debug.log | grep -B 11 -A 30 ‘dimension1’

Ich nutze danach grep, um nur die relevanten Zeilen zu bekommen, denn Chrome loggt einiges mit; in diesem Fall schaue ich mir 11 Zeilen vor und 30 Zeilen nach dimension1 an (das kann natürlich auch irgendetwas anderes sein, ich weiß nur, dass bei mir die Dimension1 immer drin ist  ). Und dann starte ich Chrome im Logging-Modus, hier der Befehl für den Mac:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome -enable-logging –v=1

Ich habe das auch noch in einem Video zusammen gefasst:

 

Wird mein Content gelesen? Sichtbarkeit von Elementen messen!


Im September 2017 hatte ich noch darüber geschrieben, dass die Scrolltiefe ein besserer Indikator dafür wäre, ob ein Inhalt gelesen wurde als die reine Sitzungsdauer, die eh Quatsch ist. Einen Monat später veröffentlichte Google dann eine neue Funktion im Google Tag Manager, einen Trigger für die Sichtbarkeit von Elementen (in der deutschen Version der Release Notes fehlte der Hinweis). Damit lassen sich einige Nachteile des Scrolltiefen-Ansatzes kompensieren, vor allem die Einschränkung, dass nicht jede Seite gleich lang ist und “75% gelesen” nicht immer bedeuten muss, dass der Inhalt auch bis zum Ende gelesen wurde (75% wurde deswegen gewählt, weil viele Seiten einen immensen Footer haben und die Nutzer daher nicht zu 100% runterscrollen). Eine Seite bei mir hat so viele Kommentare, dass sie mehr als die Hälfte des Inhalts ausmachen.

Was bedeutet die Sichtbarkeit von Elementen?

Ganz einfach erklärt bedeutet dieses Feature, dass ein Trigger ausgelöst wird, wenn ein Element der Seite auf dem Bildschirm des Benutzers sichtbar wird. Das Element muss nur eindeutig benannt werden können, so dass lediglich dieses eine Element mit diesem Namen den Trigger auslösen kann. Auf meiner Seite möchte ich zum Beispiel wissen, wie viele Nutzer so weit runtergescrollt haben, dass sie mit hoher Wahrscheinlichkeit den jeweiligen Text zuende gelesen haben. Wahrscheinlich ist das der Fall, wenn die Nutzer den Hinweis auf die ähnlichen Artikel sehen, die in meinem Blog durch das Plugin YARPP erstellt werden. In den meisten Browsern ist es möglich, ein Element mit der Maus zu markieren und dann mit einem Rechtsklick/CTRL-Klick darauf das Element zu untersuchen, so dass wir dann genau sehen können, wie dieses Element heißt.

Im Tag Manager kann nun dieser Trigger eingerichtet werden, das sieht zum Beispiel so aus:

Dazu wird dann noch ein Event eingerichtet, und schon haben wir ein Tracking auf Basis von der Sichtbarkeit eines Elements.

Macht das wirklich einen Unterschied aus?

Ja. Bei meinem Artikel über ein Jahr Erfahrung mit Scalable Capital haben knapp 30% mindestens 75% des Inhalts gelesen, aber knapp 70% haben das YARPP-Element gesehen. Die Seite besteht zu knapp 80% aus Kommentaren (es ist schon erschreckend genug, dass bei dem kurzen Artikel nur 70% das Element gesehen haben). Bei anderen Artikeln fällt die neue Messung der Sichtbarkeit von Elementen im Google Tag Manager nicht so dramatisch aus; so ist der Artikel über meine schlechten Erfahrungen mit dem Vorwerk Thermomix anscheinend zu lang für den Thermomix-Interessenten: 26,1% sehen die YARPP-Empfehlungen, 22,3% scrollen zu 75% runter.

Kann ich die Scrolltiefe jetzt abschalten?

Nein. Natürlich kannst Du tun, was Du willst, aber da die Sitzungsdauer durch das Auslösen von Events genauer wird, wollen wir nicht nur die Zeit derjenigen messen, die es bis zu dem definierten Element geschafft haben, sondern auch die Zeit derjenigen, die vorher, zum Beispiel bei 25% abgesprungen sind. Auch wenn es also auf den ersten Blick so aussieht als ob wir uns 4 Events sparen könnten, sollten wir zur Verbesserung der Datenqualität diese Events drin lassen.

Wird mein Content gelesen? Scroll-Tiefe pro Artikel als Conversion


Im September 2017 hatte ich noch darüber geschrieben, dass die Scrolltiefe ein besserer Indikator dafür wäre, ob ein Inhalt gelesen wurde als die reine Sitzungsdauer, die eh Quatsch ist. Einen Monat später veröffentlichte Google dann eine neue Funktion im Google Tag Manager, einen Trigger für die Sichtbarkeit von Elementen (in der deutschen Version der Release Notes fehlte der Hinweis). Damit lassen sich einige Nachteile des Scrolltiefen-Ansatzes kompensieren, vor allem die Einschränkung, dass nicht jede Seite gleich lang ist und “75% gelesen” nicht immer bedeuten muss, dass der Inhalt auch bis zum Ende gelesen wurde (75% wurde deswegen gewählt, weil viele Seiten einen immensen Footer haben und die Nutzer daher nicht zu 100% runterscrollen). Eine Seite bei mir hat so viele Kommentare, dass sie mehr als die Hälfte des Inhalts ausmachen. „Wird mein Content gelesen? Scroll-Tiefe pro Artikel als Conversion“ weiterlesen