Google Tag Manager

Last updated 24 August 2022: The instructions in this article are no longer that useful, as you can simply use the native JavaScript Element.closest(selector) method instead of the {{Find Closest}} trick described in this article. Browser support for closest has thankfully improved a great deal since this article was originally written.

Google Tag Manager provides us with a bunch of handy triggers, designed to make capturing user interactions on the website much easier. These triggers are part of a paradigm called auto-event tracking, which comprises the Click, Form, History, and JavaScript Error trigger types.

One of the biggest fears I have as a Google Tag Manager user is a broken release of the website (or app) on which I have deployed GTM. Far too often, lack of proper communication practices within an organization lead to a release being pushed out without thoroughly testing how this release impacts any existing tracking solutions.

Luckily there are ways to mitigate this. The most significant and impactful precautions you can take are all about process:

I recently published a #GTMTips guide called 10 Useful CSS Selectors, and it was very well received. Inspired by the feedback, here’s the next instalment. This time, we’re going over some useful JavaScript tips and tricks that you can use to make your Google Tag Manager deployment even more efficient. I’ve written a lot about JavaScript in this blog, and I intend to keep on doing so in the future. As always, if JavaScript is somewhat of a mystery to you, I strongly recommend you take the Codecademy (free) course on JS, and take a look at the other available web technology tracks while you’re there!

Without a doubt, the possibility to leverage CSS selectors in Google Tag Manager’s trigger conditions is one of the most useful features of the platform. It gives you an amazing amount of flexibility, especially when combined with GTM’s click and form triggers.

Essentially, CSS selectors let you test an HTML Element against a selector string. This check verifies that the element matches the given selector. In practice, this would mean that when you use the click or form trigger, you can check if the Click Element or Form Element built-in variables match a specific selector, allowing you to confirm that the action happened on the correct element. I’ll explain this with more detail further down.

A while ago, the Google Tag Manager team published one of my favorite feature releases in the history of GTM: Workspaces. I was so thrilled by this release that I went ahead and published a guide on how to implement and leverage this new feature.

Workspaces is a very comprehensive feature in Google Tag Manager. This is because it changed the entire underlying data model. We no longer work directly with a single container draft. Instead, our work is done in a cordoned section of the container, protected from changes made to other workspaces until such a time that we choose to sync the latest container version to our workspace, or vice versa.

READ THIS (26 Aug 2019)!! Unfortunately, the update I made in 2016 contained code that was incomplete and broken. I nevert noticed this until it was pointed out to me almost three years later. At this point, I don’t have a working backup of the solution, so unless some internet archive / cache service manages to surface the code, this article is basically lost.

UPDATE 20 December 2016: I made some fixes to the solution - be sure to grab the latest code snippet from below!

Google Tag Manager recently published support for Accelerated Mobile Pages (AMP). This support comes in the form of a new Container type in Google Tag Manager.

When you create an AMP container in GTM, you are actually setting up an external configuration for AMP, which leverages AMP’s own analytics module. As befits Google Tag Manager, creating the configuration is done in the familiar Google Tag Manager user interface, and you have (almost) all the tools of regular Google Tag Manager at your disposal.

Single-page sites (or single-page apps) typically have just one page load. When navigating the site, subsequent content is either uncovered from the DOM, where it’s been in a hidden state, or loaded from the server using HTTP requests that do not invoke a new page refresh. This behavior, however, has some implications for Google Analytics tracking, especially when configured via Google Tag Manager.

The crux of the problem is this: When you create a Google Analytics tracker, the URL of the page (without a possible #hash) from when the tracker was created is sent as the value of the Document Location field with every hit that uses this tracker. This is used for a number of things, most significantly attributing the session to the campaign specified by URL parameters such as gclid (AdWords) or utm_source, utm_medium.

Google Analytics’ Site Speed reports are pretty darn great. They report automatically on various milestones in the process the browser undertakes when rendering content. These reports leverage the Navigation Timing API of the web browser, and they are (typically) collected on the first Page View hit of a page.

And this is all fine. As I said, it’s a great feature of Google Analytics, and lends itself handily to spotting issues in the quite complex client-server negotiation that goes on when your web browser requests content from the web server.

What better way to celebrate the 50th #GTMTips article than, well, a really useful Google Tag Manager tip?! This tip is so useful and simple; it encapsulates everything that I had in mind when starting this series. The tip is about restricting scope of Custom HTML Tags. This is an important concept, because it’s possible that you’re stuffing your page’s global JavaScript namespace with all sorts of junk, and thus inadvertently causing conflicts.