Today it’s going to get a bit more technical. I’ve already written a lot about the average time spent on Google Analytics and other web analysis systems, but it doesn’t work in a standard installation. In one of my courses, a participant once said that you could simply measure when the user closes the tab, for example with beforeUnload. Such a trigger can be built quickly, but it also has disadvantages. First of all, it’s not reliable, because a user can simply switch tabs and not close them, yet still not engage with the content of my website, so that the determined time on site is not correct. In particular, on mobile devices, I rarely see users closing their “tabs”. But that’s not what this is about today, that’s worth at least one more post. This article is mainly about how we can measure and debug the use of onbeforeUnload at all.
The problem: Our logging disappears when the tab is closed.
Background: When a user closes a tab or calls up another website in the same tab, I can catch the event, but in the worst case, it slows down the user experience because a GET request is usually sent. If the user only goes to another site, then I see in the GA Debugger what was logged before; but if the user closes the tab, my console is also gone. Of course, I can check in Google Analytics’ real-time report whether my beforeUnload event arrives, but debugging is something different. The Google Tag Manager Debug Mode also doesn’t help here, because the beforeUnload event is only visible for a very short time when we close the tab.
If we then use sendBeacon as well, it becomes even more complex, because the Google Tag Assistant cannot handle it, probably because sendBeacon sends POST requests and not GET requests. However, sendBeacon has the great advantage that we do not affect the user experience.
The solution: write logging from GA Debugger into a file
Relief comes from a small hack. We start Chrome with logging in the terminal and then have the log file output live, for example. Here, the GA Debugger still needs to be activated because it continues to write diligently to the console, but we can see in the file what it has written, even if the tab has already been closed.
With this code I start my live view of the logging; the parameter -f for tail simply means that I always want to see when something is appended to the end of the log file:
tail -f Library/Application\ Support/Google/Chrome/chrome_debug.log | grep -B 11 -A 30 ‘dimension1’
I then use grep to get only the relevant lines, because Chrome logs a lot; in this case, I look at 11 lines before and 30 lines after dimension1 (which can of course be something else, I just know that for me Dimension1 is always included). And then I start Chrome in logging mode, here’s the command for Mac:
/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -enable-logging –v=1
I have also summarized this in a video: