Google Tag Manager

The beauty of #GTMTips, at least how I’ve envisioned them, is that they can be really simple or crazy complex. The important thing is that the idea is conveyed clearly enough. That’s why so many of these tips have originated from discussions in our Google Tag Manager Google+ community, the Product Forums, and in private email correspondence with people asking for help. Today’s tip, for example, originated from a back-and-forth with Süleyman Okan, so thank you for the inspiration! Read More…

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. Read More…

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: Read More…

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! Read More…

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. Read More…

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. Read More…

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! Read More…

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. Read More…

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. Read More…

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. Read More…