Most Common Problems with Element Visibility Trigger and troubleshooting – Google Tag Manager Part 1

by Furqan Mahmood

Among the many tracking items site owners require, one we have to mention is the Element Visibility. Imagine you have a promotional banner or a specific form you want users to see. You can’t always rely on page load as this does not provide an accurate user view of your site. Well, this is where the Element Visibility Trigger comes in.

However, implementing this feature is not always straightforward and some issues may arise. In this article, we put together some problems (and solutions to solve them) that you may encounter implementing this feature.

Much has been written about Element Visibility triggers on the web and there is plenty of information available in Google Tag Manager’s documentation about this powerful trigger. Beyond doubt, this trigger is packaged with Awesomeness! and praising Google Tag Manager for adding this feature wouldn’t be biased. Not only does it eliminate the need for adding a custom script to achieve the functionality of firing a trigger when the element is visible in the viewport, but it goes beyond that promise by triggering on the dynamic elements appearing on DOM.

Before going deep into the discussion and exploring the debugging and troubleshooting part of the Element visibility trigger, let’s talk about what this trigger is for and discuss its mechanics and how you can configure it.  To do this,  we’ve divided this article into two parts. 

This first part is for those who are unaware of the power of this trigger or those who wanted to refresh their memory about the trigger configuration and its specification. In a later post, I’ll look at troubleshooting and identifying common problems with the Element Visibility trigger

Part1: What is The Element Visibility Trigger in Google Tag Manager and how does it work?

Element visibility triggers fire when an element selected in the settings is visible in the browser’s viewport. The browser’s viewport is the area visible in the browser window and is, therefore, viewable by the user. So, think about the multiple scenarios where an element in the browser is active and visible in the browser viewport. Example:

Elements available on page load
A hero slider on a landing page is available on the first fold of the page and you want to fire an event or some remarketing pixel whenever a slide with a special promotional message is visible to the user.

Page scroll
The user scrolls to the second fold of the page where there is a static banner available and you want to fire an event to count these impressions. Or, when the user scrolls down to the bottom of the page where a footer is visible and you want to track the user engagement when the user reaches the bottom of the page.

Dynamically loaded elements on the DOM
This means, whenever there is a new HTML element added in the DOM dynamically against any asynchronous call on the page – for example, a survey form appears after the successful lead generation form, or a rating form appears after the successful e-commerce transaction to measure the impression. Or, tracking dynamically added DOM elements in a Single Page Application.


To be honest, there are numerous scenarios where the trigger could be utilized in the day-to-day activities of a digital marketing practitioner, a tracking implementation specialist, or, AdTech or MarTech professional, but I tried to come up with real-time scenarios people can relate to.

Without going into deep discussion let’s look into the configuration of the Element Visibility Trigger.

Element Selection method.

There are two attributes by which the DOM element could be selected to fire the Element Visibility trigger, element ID or CSS selector. Whenever the DOM element with ID or CSS selector is visible on the viewport, it will fire the trigger.

There is a difference between selecting ID and CSS selector methods:

ID
This selects a single element based on the value on the ID attribute, you can add multiple IDs separated by commas to fire this trigger.
For example:
#promotion-banner, #footer

CSS selector: You can add multiple CSS selectors, comma-separated, and it would fire whenever the element with a CSS selector is visible on the viewport.

For example:
.header, .footer, a.banner etc

When should the trigger fire?

There are options to determine the firing frequency of the trigger. Let’s briefly discuss each of them: 

Once per page
The trigger would fire only once, whenever the first element is visible with the selected ID, or CSS selector is available on the page’s viewport. Keep in mind, no matter if there are multiple elements present on the page that share the same ID or CSS selector, the trigger will only fire once, when the first element appears on the viewport. This is true even if you have multiple elements with the same IDs and the CSS class in the viewport or on the page.
Similarly, if you have multiple IDs (#promotion-banner,#another-banner) and CSS classes in the CSS Selector field (.header,.banner,.footer). The trigger will only fire once on the page – when the first element appears in the viewport, even if other elements are available on the page. 

Once per element
This option is self-explanatory. The trigger will fire only once if an element with an ID appears in the viewport. Here it’s important to note, if there are several elements with the same ID appearing on the same page, the trigger will only fire on the first element that appears in the viewport.
Whereas, in contrast to ID, in CSS selector, every time an element with the same CSS selector appears on the viewport, it will fire only one time for that particular element. For example, if the header, content, and footer part of the page share the same CSS class that is .grid, any element that appears with .grid CSS selector, the trigger will fire only once for that element.

Every time an element appears on the screen
This means whenever an element appears on the viewport with the same CSS selector or ID, it will fire every time. For example, the header part will fire a trigger the first time, and, if the user scrolls to the bottom of the page and then scrolls back to the header, the trigger will be refired on that same element.

Advanced Configuration

Minimum Percent Visible 

This allows you to set the visible area of the element where the trigger should fire. This is set as a percentage with a default value of 50. For example, if you set 50, then whenever 50% area of the element is visible in the viewport, the trigger will fire. See the image below:

Set Minimum on-screen duration 

This allows you to specify how long the element should be visible on the viewport before this trigger fires, with the value specified in milliseconds. It is important to note this would calculate the cumulative time visibility on the page. For example,  suppose you have selected 10,000 milliseconds and the user sees 5000 milliseconds and scroll down the page, and then scrolls back to the same area of the page and the element is again visible for 5000ms. Only when the cumulative visible time reaches  10,000 milliseconds will the trigger fire. The image below shows how to set the minimum on-screen duration.

Observe DOM changes 

This is the most powerful feature for element visibility, and my favorite as well, because it enables us to fire on elements not present in the DOM when the page is rendered in the first place. It enables you to fire on the dynamically added elements in the DOM.

The classic use case would be when the Form is submitted successfully and a <div> dynamically appears against the asynchronous submission of the form and a customer satisfaction or survey form appears after the e-commerce transaction is completed successfully.

Concluding Remarks

After praising the Google tag manager trigger and briefly discussing its configuration and features, we’ve come to the end of Part 1. Look for Part 2 in the coming weeks where I’ll discuss troubleshooting –  which I know is the part most of you are here for!

Furqan Mahmood

Analytics Implementation Specialist

With more than 7 years experience working in the competitive environment of Web Development and Digital Agencies, Furqan is known as a team player as well as a solution provider.

See more posts from Furqan