Better Scroll Tracking in Google Analytics
Think you’ve got scroll tracking nailed on your website?
Then let me ask you a question. Can you see a report that shows you average scroll depth per page within the Google Analytics interface?
If the answer is no, but you’d like to, then keep reading because I’m going to explain why the classic method of implementing scroll tracking in Google Analytics isn’t all that great and what to do about it.
Scroll tracking: The big issue
If you’ve followed other blogs and videos on YouTube then you probably implemented scroll tracking using Google Tag Manager’s auto events feature.
GTM has the ability to detect vertical or horizontal page scrolls automatically and can be set up quickly and easily to fire events at all the percentages you set (most often every 10 percent or at 25, 50, 75 and 100% marks)
Despite being easy to set up and what 99.9% of Google Analytics user do, there are a few drawbacks to this approach which you may have run in to.
Drawback 1: Event overload
Firstly, if someone scrolls all the way down your page you’ll fire 3 additional events, perhaps even 10 additional event if you are set up to track every 10%.
Drawback 2: Lack of fidelity
The second issue is fidelity. As an example, if your first trigger point is 25% and someone scrolls to 24%, you can report on them having scrolled to somewhere between 0 to 25% but not exactly where. That’s going to screw your average scroll depth calculation.
Drawback 3: Complicated reporting
Thirdly, and the key one for me, is reporting inflexibility.
Pulling a report showing average scroll depth per page, especially if you want this metric along side other page metrics involves exporting the event data and doing some maths in Google Sheets or Excel,
or running an SQL query in BiqQuery on the raw data. This isn’t something the average Google Analytics user in your business will be able to do.
In summary, even though the standard method of scroll tracking is easy to set up, I’m not sure how practical it is for analysis.
So what’s the solution?
What we really want is for average scroll depth to be its own metric in GA, just like bounce rate or pageviews. That way any user can easily add it to a report they are building without having to know any details of the underlying tracking method.
The good news is this is entirely possible, and I’m going to show you two ways to achieve it right now.
Method 1: Simple
The first method is a tweak on the standard method of scroll tracking. When each of the scroll events fires, send along a custom metric value equal to the spaces between your breakpoints.
For example, if your breakpoints are 25, 50, 75 and 100 percent, then each time a scroll event fires, the scroll increment is 25%. Therefore, we’d send a metric value of 25 to Google Analytics.
Once the tracking is in place, create a custom metric called Scroll Depth, and a calculated metric called Avg. Scroll Depth with these settings.
Finally create a custom report with Page as the dimension and pageviews, bounce rate and average scroll depth as the metrics.
The result is a scroll depth report with no complicated maths and easy to analyse.
Even though this method solves the complicated reporting issue of standard tracking, we still have the low data fidelity and multiple event issues. There’s also a problem is someone is already part way scrolled down the page and refreshes it. The previous scroll events won’t fire, causing data inaccuracy.
Method 2: Advanced
Method two is similar to method one. We still have a custom metric tracking incremental scroll depth, and a calculated metric doing the maths to calculate average scroll depth.
The two differences are how that incremental scroll depth is calculated and how it is transmitted to Google Analytics.
(*Aside: Technically my script triggers the event when a page is hidden, either by someone navigating away, closing the browser tab, or switching browser tab. This could in theory increase the number of events sent to GA if someone is regularly switched tabs. To minimise this I’ve ensured the script only fires if the scroll depth increment is 5%. If someone keeps switching tabs but isn’t scrolling on our page, no events will fire).
These modifications mean more accurate data and potentially less events, as normally they are only sent when the visitor leaves a page.
Here’s an example running on my website. As I scroll down the page no events are sent but the scroll depth is being recorded. As soon as I leave the page, either by navigation or changing browser tabs, an event is sent to GA setting the scroll depth metric.
This produces the same report as in example one, but the data is likely to be more accurate.
The way most people implement scroll tracking suffers from several drawbacks: loss of data fidelity, extra events, and the data is difficult to analyse.
By using a custom and calculated metric in Google Analytics, and sending the increment scroll depths when the page visibility changes, we achieve a more accurate and usable scroll depth report for analysing.