By Yasen Lilov

Page Depth Tracking is one of the essential components you can implement to gather a better insight of how users consume your content.

After the recent Google Tag Manager update, Google introduced a couple of new features that provide native support for the tracking of user engagement and allow you to measure real engagement beyond just time spend on page and pageviews per session.

Back to blog home

The benefits of measuring scroll depth are numerous and the metrics that are available once implemented provide insight on the effectiveness of your content. Having Scroll Depth Tracking allows you to answer questions like "Do visitors read my content?" with more confidence and avoid guessing only based on time spend on page for example. When you have an understanding of how far visitors scroll through your content and you add the time spend on page, you can paint a better picture of how engaging that content was. Additionally, you can analyse drop offs at certain stages and understand where visitors lose interest.

Having Scroll Depth Tracking implemented is one of the essential things you need to get right and with the recent developments from Google, it cannot be easier.

The GTM update introduced Element Visibility and Scroll Depth triggers as well as built-in variables. Previously, in order to implement Scroll Depth Tracking in Google Tag Manager, you had to either get your hands dirty with some JavaScript or use a plugin like the one developed by Rob Flaherty: Scroll Depth jQuery Plugin

Either way the setup required a few modifications in GTM like creating a custom HTML tag to execute the script, custom variables to capture values, a trigger and an event tag to send the data to GA. Even though the setup is fairly simple, things are now even simpler because of the update!

In the next few lines I am going to go through the two and show some examples of how to use the new set of triggers and variables to better understand user engagement.

Scroll Depth Trigger

With the new trigger, there are new built-in variables that will be populated with a data layer push when the scroll depth trigger fires:

Scroll Depth Threshold: A numeric value indicating the scroll depth that caused the trigger to fire. For percentage thresholds, this will be a numeric value (0-100). For pixels, this will be a numeric value representing the number of pixels specified as the threshold.

Scroll Depth Units: Either ‘pixels’ or ‘percent’, indicating the unit specified for the threshold that caused the trigger to fire.

Scroll Direction: Either ‘vertical’ or ‘horizontal’, indicating the direction of the threshold that caused the trigger to fire.

Once these variables are available and being populated, the only thing that needs to be done is to pass the one we need – ‘Scroll Depth Threshold’ (gmt.scrollThreshold : ‘value’ – in the data layer) to Google Analytics with an event tag.

This is how this is achieved in Google Tag Manager:

1. The Trigger

Scroll Depth Trigger

Once you select the trigger type – Scroll Depth, you can specify when it should fire, based on vertical and horizontal scrolling. Adding the conditions in this example is achieved by simply putting the different percentage points, separated by a comma, when the tag should fire. Additionally, you can specify on which pages the tag should fire – All Pages, or specific pages based on a met condition, like in the example below:

Scroll depth trigger on specific pages

2. The variables

For the variables, all you have to do is to go to Variables > Built-in Variables and tick the following:

Scroll depth variables

For the purpose of this example however, we will only need Scroll Depth Threshold.

3. The Scroll Depth Tag

To wrap everything together, all that needs to be done is to configure an event tag that will pass the data to Google Analytics.

Scroll depth event tag

And that is it. There is no need for an external jQuery plugin, custom tags and additional triggers. The whole setup required one trigger, one built-in variable and one event tag. Scroll Depth Tracking – as simple as it gets!

However, there are a few known bugs to consider before going further with this native implementation. The first bug, has to do with page refresh and was mentioned by Simo Ahava at the end of his article. The issue has to do with how the browser handles page refresh. In cases where you have scrolled to the bottom of a page and you refresh that page, the trigger fires all of the thresholds at once after the page loads again.

Additionally, there are some issues with websites that utilize AJAX for dynamically changing/adding elements to a page. In such cases, the trigger tends to fire multiple times while loading the page and the user hasn’t even begun to scroll.

Element Visibility Trigger

If you want to take your scroll tracking a step further and make it more precise, Element Visibility Trigger comes into play! It allows you to track specific elements and pass data when they were seen, instead of just percentages.

The element visibility trigger fires a tag when a specific element (or elements) becomes visible in the viewport or visible by style (i.e. non-hidden). For reference, the viewport is the user’s visible area of a web page and it varies by device.


With that cleared, let's take a look at the features of the the Visibility Trigger.

Element visibility trigger

Lets jump into what each one does:

Selection Method:

The element visibility trigger can fire based on the visibility of one or multiple elements. You can select elements by ID or CSS Selector.

  • ID: Selects a single element based on the value of an element’s ID attribute.

  • CSS Selector: Selects one or more elements based on a specified CSS selector pattern.

When to fire the trigger:

  • Once per page: The trigger will only fire once per page. If multiple elements on a given page are matched by the ID or CSS selector, the trigger will only fire the first time one of them is visible on that page.

    If the page is reloaded, the trigger will reset and may fire again if the selected element is visible.

  • Once per element: The trigger will only fire once per selected element per page. If multiple elements on a given page are matched by a CSS Selector, this trigger will fire the first time each one of them is visible on that page.

  • If IDs are used as selection method, this option will typically function the same way as the Once per page option. If multiple elements on a page have the same ID, only the first matched element will fire the trigger.

    If the page is reloaded, the trigger will reset and may fire again if the selected element is visible.

  • Every time an element appears on-screen: The trigger will fire every time a matched element becomes visible. For example, if the trigger is set to fire based on the visibility of an element of ID “carousel”, and the user scrolls down the page, bringing element “carousel” into visibility, the trigger will fire. If the user then scrolls back up the page causing “carousel” to once again be below the fold, and then scrolls back down, the trigger will fire again.


  • Minimum Percent Visible: Specify how much of the selected element must be visible on screen (by percent) before the trigger fires. By default, elements must be 50% on screen for the trigger to fire.

  • Set minimum on-screen duration: Check this box to specify how long a selected element must be visible on screen before the trigger fires. By default, this option is not enabled, and the trigger will fire as soon as a selected element becomes visible. You can set values in milliseconds to set a specific time that the element should be visible before the tag fires.

  • Observe DOM changes: Enable the trigger to track matching elements that appear as the DOM changes. Really useful for dynamically inserted elements, this would allow their track when they become visible.

So let's see how the configuration will look like in Google Tag Manager. We will use the example below and fire the tag when the element “#owl-wrapper-outer” is visible.

Visibility example

1.The Trigger – Once Element Visibility is selected, we can go ahead and configure it in the following way:

GTM visibility trigger

2. The variables:

Similarly for the variables, all you have to do is to go to Variables > Built-in Variables and tick the following:

Elements visibility variables

3. Change the The Scroll Depth Tag

The configuration of the event tag that will pass the data to Google Analytics needs a small change:

Elements visibility tag

With this configuration the Event Tag will only fire when the logo carousel is visible and the data that is passed to Google Analytics will contain information about what percentage of the carousel was visible and for how long.


These two new triggers now offer a native solution in Google Tag Manager, and when the few known caveats are considered, can enrich your data to understand your users better with a really easy to do setup.

The Element Visibility Trigger especially, has the potential to really take your tracking to the next level. With the ability to track interactions that matter and being able to track them in dynamically changing conditions, this trigger can be really versatile!

If you need help with any of these new GTM features , please get in touch with us here.

Share this article