Analytics

Autocomplete search is a tricky thing to track. The underlying logic is that when the user starts feeding characters into a search form, the search suggests results based on a limited input. If the user is not satisfied with the results, they can continue adding characters to the search, thus increasing the accuracy. Often there’s also the option to revert to a regular search with what they’ve already written. Tracking this logic in tools like Google Analytics is difficult, because there’s really no way to know if the search was successful.

With the release of the latest Google Tag Manager API version, it’s time to release the new version of GTM Tools. Most of the changes have been done under the hood, with the entire codebase refactored for improved stability.

I released the first toolset in October 2014, and quickly released an updated UI a few months later. Aside from a few bug fixes and stability improvements, the tools have remained largely unchanged since then. Now with the new API version, it was time to update the tools again.

Google Tag Manager has a very nifty programmatic API that lets you do almost anything that’s also possible within the GTM UI. I’ve used the API a lot, most notably for my GTM Tools, which might be getting a new release soon, too!

The API was recently updated to its second release version (V2), and in this article I want to go over the additions, removals, and changes that the new version introduced.

I’ve always been proud to avoid the typical headline clickbait of “Ultimate guide to pigeon care”, “All you need to know about the Great Vowel Shift”, “Did you know that you’ve been smoking peyote wrong your whole life?”. I’m ready to make an exception now by adding a BIG WHOPPING NUMBER to the title. You see, the amount of knowledge one can accumulate about anything they do on a daily basis is mind-blowing. It helps if you write a blog about the topic, since creative output is a great way to organize your thoughts. It also helps to be active in community support, since problem-solving is an excellent way to accumulate new skills and to hone the edge of your existing talent.

A couple of years ago I wrote an article on tracking interactions with the SoundCloud widget via Google Tag Manager. When a platform provides a JavaScript embed API, it’s surprisingly easy to track interactions with the player. You’ve seen this with YouTube, with SoundCloud, with JWPlayer, and now you’ll see how to do this with the Mixcloud player.

If you don’t know what Mixcloud is, well it’s a hugely popular streaming service for DJs, podcasts, radio shows, and other published radio media. Since they offer a handy embed solution for any show you like, it makes sense to start tracking if people are actually using the widget, right?

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:

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!

This article is a collaboration between Simo and Dan Wilkerson. Dan’s one of the smartest analytics developers out there, and he’s already contributed a great #GTMTips guest post. It’s great to have him back here sharing his insight on working with Accelerated Mobile Pages (AMP).

So, we’re back on AMP! Simo wrote a long, sprawling AMP for Google Tag Manager guide a while ago, and Dan has also contributed to the space with his guide for AMP and Google Analytics. Both of these guides touched upon a subject that might be one of the reasons to stay away from AMP for now: Client ID matching across AMP, your regular website, and any caches or CDNs that serve the AMP version.

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.