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: