Most Common Problems with Element Visibility Trigger & Troubleshooting – Google Tag Manager Part 2

by Furqan Mahmood

A couple of weeks ago I posted Part 1 of this article, it focused on what the Element Visibility Trigger in Google Tag Manager (GTM) is, and how it works. It’s not necessary to have read the first part, but it might give some context to part 2.

Part 2: Debugging and Troubleshooting Element Visibility Trigger

By now you have realized that this is one of my favorite GTM triggers because it gives you the power to fire tags with element visibility.

Let’s say you are a marketing or AdTech professional and you are using the Element Visibility trigger to fire an event hit to Google Analytics whenever the user sees the promotional banner on-page. But, you are caught with some unforeseen issues with the Element Visibility trigger -it’s not firing on the banner visibility – so you need to debug the banner.

Don’t worry, we are here to explain to you the most common issues we see during the event configuration, and how to debug and resolve them.

However, there could be multiple reasons why the trigger is not firing on the page even though the element is visible on the viewport so let’s discuss them one by one.

Specifying ID in place of CSS or vice versa

Using CSS selector (.) dot, in place of ID (#) when the selection method is “ID”.

Wrong

Right

Similarly, if the selection method is “CSS selector” and you have added “#header, #footer” it won’t work for this selector. You have to add it with the correct CSS selectors representation, leading with (. dot)  “.header, .footer”.

Also, note that it will include all of the common cases of parent-child selection, multiple class selectors on a single element, (normally the most common use cases where the trigger fires on the wrong element).

For example,

  • Parent child selector:
    The CSS rule for targeting the child element through its parent selector is valid here. Suppose you want to target the instagram widget which is inside the footer, for example, div .footer > .instagram-widget
  • Multiple classes on one element:
    In the real world scenarios, there are multiple classes shared by one element and that’s how you apply the styling through the combination of the classes on that particular element. The same technique applies here as well. For example, a banner with multiple classes should be declared without spaces, whereas in the HTML the classes are declared with spaces. For example, suppose you have a banner wrapped in a div element with multiple CSS classes:

<div class=”banner promotion-banner footer”>…</div>


The declaration of the above CSS selectors for this element would be specified as “.banner.promotion-banner.footer”.

Wrong

The above image shows the wrong declaration, there are spaces among the CSS classes which are actually used for the selection of one element. This is the incorrect way to declare one element with multiple CSS selectors, the trigger will not fire with this element.

Right

Element visible on viewport but not firing the trigger

You probably won’t be caught with this issue very often, but it is worth mentioning because it can drain your hours if you don’t know the solution. If you do, you may be able to fix this issue on the fly. I’ve caught it recently and believe me, the simple CSS property does the trick for me.

Suppose there is a banner on the page with dimensions of 240×240 pixel height which is wrapped in an anchor tag (<a>). The trigger is supposed to fire whenever it is visible on the viewport, but it’s not firing even though the banner is viewable by the user.

Now, right-click on the element you are debugging and click Inspect, (shown in the image above). Make sure the element is selected and has the same CSS selector configured in the trigger.


Referring to the above example in the image below, the anchor tag has 0x0 as the dimension despite being viewable in the viewport. Thus, the trigger is failing to fire. The key point is, you have to make sure the element you have bound with the trigger is displaying height and width in the modal box of the DOM element.

In the above image, the banner enclosed in the anchor tag is showing 690×0 pixels in the viewport of the DOM. This means the element has 0 height in the viewport and therefore, is acting as an invisible item.

This could be resolved by small tweaks to your CSS, by adding display: block; property on the anchor elements. After that, you should make sure the elements are visible in the viewport and are displaying their accurate width and height. See the image below that shows a little CSS tweaking:

The key point here is to make sure the DOM element you have specified in the Element Visibility trigger occupies at least 1px height and width in the viewport.

Similarly, if you are binding an empty div and placing it between the end of the article and the start of the comment section so you can track if the user reaches the end, make sure to assign both height and width of at least 1px and verify it through the Inspect element. This will ensure it is visible in the viewport and can fire the Element Visibility Trigger per your needs.

These are a few examples of things we normally see going wrong with the Element Visibility trigger. Let us know if you have caught more issues and of your experience with Element Visibility trigger in the comments.

Concluding Remarks

The utilization of the trigger always depends on your marketing and tracking needs. However, this trigger lets you do really cool stuff like allowing you to properly track scroll to the specific elements on the page, not based on the page percentage. It also allows you to track the elements that appear on the viewport based on the dynamic changes in the DOM. The cherry on the top is that it allows you to measure the impressions of the elements like banners, forms, and dynamically loaded content viewable by the user, along with the actual time the user viewed the element.


The key point to note here is, whichever element selection method you use, as you are scraping it from the page, the implementation will become very fragile. It will break your tracking if the onsite code has been updated (like ID) or CSS classes of the elements are changed during an update or revamp of the website. However, you can cope with this by focusing on the key elements and interactions that matter to you. In short, you simply can not throw the baby out with the bathwater since visibility of elements is the most important factor for user interactions and measure engagement measurement.

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