Google Tag Manager

First of all, check out this article for an overview of how custom event listeners work in Google Tag Manager. The reason I’m writing this #GTMTips article is that I want to upgrade the solution slightly, and I want to bring it back into the spotlight. Why? Because it’s still one of the most effective ways to customize your Google Tag Manager implementation.

A custom event listener is a handler you write with JavaScript. It lets you handle any JavaScript DOM events, such as click, form submit, mouse hover, drag, touch, error, page load and unload, and so many more. It also lets you leverage the useCapture parameter which will prove very helpful if you have other JavaScript on the site interfering with GTM’s default event triggers.

Over the past few weeks, I’ve been coding like crazy. The three biggest outcomes of this frenzy have been this new blog design (switched finally away from WordPress and took the plunge back into the world static sites using Hugo), a new Google Sheets add-on for managing Google Tag Manager containers and assets, and a Slack integration in GTM Tools. In this article, I’ll quickly introduce the last two, as I’m writing a separate article about the site redesign.

I really like Google Optimize. It has a fairly intuitive UI, setting up experiments is easy, and there’s integrations for both Google Tag Manager and Google Analytics built into the system. It’s still a JavaScript-based, client-side A/B-testing tool, so problems with flicker and asynchronous loading are ever-present (though this is somewhat mitigated by the page-hiding snippet).

One issue with the Google Analytics integration is the difficulty of creating segments for sessions where the users were actively participating in the experiment. In fact, there’s no specific signal in Google Analytics that tells you the NOW the user is “experiencing” an experiment. You’ll find the Experiment Name and Experiment ID dimensions, yes, but they have one drawback:

Scroll depth tracking in web analytics is one of those things you simply must do, especially if you have a content-heavy site. Tracking scroll depth not only gives you an indication of how much users are digesting your content, but it also lets you turn meaningless metrics such as Bounce Rate into something far more useful.

If you’ve already been tracking scroll depth in Google Tag Manager, you’ve probably been using either Rob Flaherty’s brilliant Scroll Depth jQuery plugin, or Bounteous’ equally ingenious Scroll Tracking recipe. I’m sure you’ll be very pleased to know that Google Tag Manager just released a native Scroll Depth trigger, with which setting up scroll depth tracking will be a doozy!

Holy visibility, Batman! Visibility is a seriously undervalued aspect of web analytics tracking. Too often, we fall into the trap of thinking that “Page Views” actually have something to do with “viewing” a page. Or that tracking scrolling to 25%, 50%, or 75% of vastly different pages makes sense on the aggregate level. So you will be very pleased to know that the Google Tag Manager team (who have been on FIRE recently), have just published the Element Visibility trigger. And oh BOY what a trigger it is!

5 years ago, on 1st October 2012, this lovely video popped up in Google’s Analytics Blog:

It was accompanied by a blog post, which contained a brief look into many of Google Tag Manager’s key features, some of which are still relevant today.

Google Tag Manager is a free tool that consolidates your website tags with a single snippet of code and lets you manage everything from a web interface. You can add and update your own tags, with just a few clicks, whenever you want, without bugging the IT folks or rewriting site code. It gives marketers greater flexibility, and lets webmasters focus on other important tasks.

At this time, those of us who started using the tool immediately, or who had been beta-testing it, saw quickly what the key selling point of GTM was. It was a way to impact change on the website as quickly as possible, without having to wait for a release to be verified and pushed live.

Ever since the Lookup Table variable was introduced in Google Tag Manager, users have been craving for more. The Lookup Table does exactly what it promises: lookups. These are exact match operations, which are extremely inexpensive to perform, because they can only have a binary result: either the match exists in the data store being queried or it doesn’t. This performance stays constant even if the data store being queried increases in size. However, exact match has one significant problem: it’s exact match. Thus even though the Lookup Table variable is extremely useful, it’s missing the flexibility of, I don’t know, say, regular expressions. You will be pleased to hear, then, that Google Tag Manager has released a new variable type: the RegEx Table!

Last updated 20 April 2020: Clarified how lazy-loaded videos can be tracked with this trigger.

Let’s cut straight to the chase. Google Tag Manager has just released the YouTube Video trigger, which gives you native support for YouTube video tracking. And it’s great! Even though we’ve been more than satisfied with the excellent tracking scripts provided by e.g. Cardinal Path and Bounteous (with a small modification from yours truly), this is a no-brainer for native support in Google Tag Manager.

The steady increase in mobile use over the last years has introduced some new challenges for web analytics. It’s not just about mismatches in the tracking model (the concept of sessions is even more absurd for apps than it is for desktop browsing), but about something more fundamental, more basic. Think about it: if a visitor visits the website using a mobile device, there’s a significant chance of them losing internet connectivity and going unintentionally offline.

If you open the Google Tag Manager user interface and browser your tags, triggers, and variables, you might notice that the UI now has two new features:

1. Pagination, where only 50 results are shown per page

2. A quick search / filter bar at the top of each list, which lets you narrow the list down to results that match your query

Pagination might be a nuisance in large containers, but it was implemented to improve performance. Fetching the list of assets and rendering them on the screen can be a pretty hefty amount of API work, especially if the container is bloated. By introducing pagination, only 50 items are processed at a time, which speeds up the UI. However, being forced to plow through pages of assets can get tedious.