Tag: gtm

Posted on

Logging of Google Analytics requests via Google Chrome for sendBeacon/beforeUnload

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:

Posted on

Is my content being read? Measure the visibility of elements!

In September 2017, I wrote that the scroll depth would be a better indicator of whether a piece of content has been read than the pure session duration, which is nonsense anyway. A month later, Google then released a new feature in Google Tag Manager, a trigger for the visibility of elements (the note was missing in the German version of the release notes). This compensates for some disadvantages of the scroll depth approach, especially the restriction that not every page is the same length and “75% read” does not always mean that the content was read to the end (75% was chosen because many pages have an immense footer and therefore users do not scroll down 100%). A page on mine has so many comments that they make up more than half of the content.

What does element visibility mean?

In simple terms, this feature means that a trigger is triggered when an element of the page becomes visible on the user’s screen. The element only needs to be uniquely named, so that only this one element with this name can trigger the trigger. On my site, for example, I would like to know how many users have scrolled down so far that they have finished reading the respective text with a high degree of probability. This is probably the case when users see the reference to the similar articles that are created in my blog by the YARPP plugin. In most browsers, it is possible to select an element with the mouse and then examine the element with a right-click/CTRL click on it, so that we can then see exactly what that element is called.

This trigger can now be set up in the Tag Manager, which looks like this, for example:

In addition, an event is set up, and we have tracking based on the visibility of an element.

Does that really make a difference?

Yes. In my article about a year of experience with Scalable Capital, just under 30% have read at least 75% of the content, but just under 70% have seen the YARPP element. The page consists of almost 80% comments (it is frightening enough that only 70% of the short article saw the element). For other articles, the new measurement of the visibility of elements in Google Tag Manager is not so dramatic; so the article about my bad experiences with the Vorwerk Thermomix is apparently too long for the Thermomix interested party: 26.1% see the YARPP recommendations, 22.3% scroll down to 75%.

Can I turn off the scroll depth now?

No. Of course, you can do whatever you want, but since the session duration becomes more accurate by triggering events, we want to measure not only the time of those who made it to the defined element, but also the time of those who bounced before, for example at 25%. So even if at first glance it looks like we could save 4 events, we should leave these events in to improve the data quality.