Analytics

(Updated 21 February 2019)

The current version of Google Tag Manager was released in October 2014. With the release, we saw a brand-spanking new UI, a lot of new functionalities (revamped auto-event tracking, for example), plus a new terminology to cope with. We moved away from the programming-centric concepts of Macros and Rules to the more tactile variables and triggers.

It’s difficult to rank the changes. The new Auto-Event Tracking is perhaps most impactful, but the improvements done to triggers and variables, when compared to the previous version of GTM, require attention as well.

My fingers have been tingling to write this article. Ever since I implemented Enhanced Ecommerce on my blog a couple of weeks ago, I’ve been getting such an impressive amount of useful data that it’s mind-boggling.

In this article, I’ll walk you through the steps I went to implement the solution, along with examples of the data I can now access through Google Analytics’ reporting interface. As you might have guessed, if you’ve read my articles before, I implemented Enhanced Ecommerce with Google Tag Manager. Note, this is not a step-by-step guide, but should rather provide inspiration for you to think out-of-the-box when it comes to Google Analytics’ features.

Updated 27 March 2019

In the new version of Google Tag Manager, one of the most visible and profound changes to the previous version is how tags are fired (and blocked). First of all, there’s the obvious terminological distinction: we talk about triggers now, not rules. Second, triggers have become an integral part of the tag creation workflow, and as such have far more significance in the user interface than before.

The following text is a standalone article. It’s not an update to the guide I wrote for the previous GTM version: Google Tag Manager: Playing By The Rules, and many of the concepts covered therein are still valid.

One of the recurring problems in migrating to Google Tag Manager is how to make the transition as smooth as possible. Usually it requires that we agree with the developers on a time when the old code is removed, and at that moment we need to make sure the GTM tags point to the right UA code. This is, of course, only one use case for migrations, as some people do the entire migration in a staging environment, and some just don’t care if they lose a little bit of data along the way.

When our good friends in the Google Tag Manager developer team first introduced the Lookup Table Macro, we were excited. For many of us, it soon became the weapon of choice especially when used as a management and optimization tool for the container itself.

However, the macro wasn’t considered perfect. In fact, the most frequently heard request had to do with the core functionality of the feature itself: the macro should support operations, that is, predicate logic. It’s not enough to just have equal match lookups; people wanted support for operations such as “is x larger than y” or “does y contain x”.

If you use Google Analytics, Google Tag Manager, or any JavaScript-based data collection or analytics platform, have you ever stopped to wonder how they actually work? I mean, you obviously care about getting the data in, but are you taking the machinations of these tools for granted?

This is something I’ve been thinking about for a long while, because I’m not so sure that many who work with these platforms actually understand how the browser and the web page interact.

In the new version of Google Tag Manager, auto-event tracking has received a considerable usability upgrade. It might seem quirky at first, especially if you’re used to the old auto-event tracking method, but the logic behind the new setup is brilliant.

The most important distinction is that auto-event tracking isn’t something you control with separate tags anymore. Rather, it’s now entirely trigger-driven, meaning you activate and specify the auto-event tracking of your choice using tag triggers (triggers are what ye olde folk used to call rules).

I’ve written a completely revamped version of this toolset for Google Tag Manager V2.

Well, I just yesterday published the first of my GTM API tools (the Container Visualizer), and I vowed that I wouldn’t release the other tools for a number of reasons.

The reasons were good, in my opinion (especially the part about the tools being ugly as crap), but on the other hand I don’t want to keep anyone away from the amazing potential of the new API.

[UPDATE:] Quite a lot of people had trouble accessing the tool after I published this post. This should now be fixed.

So, AWESOME stuff. The new Google Tag Manager UI and API have just rolled out, and I can finally start revealing the stuff I’ve been working on :)

I’m not going to go into the new UI in this post. I just want to give a huge thanks to the GTM team for working on the UX with such dedication. The big problem with GTM so far has been that newcomers and non-developers (and why not developers as well) don’t get the flow of the tool. There’s no indication of “what to do next”, or “what’s taking place right now”. These are some of the things that have been remedied in this release.

I’ve noticed that setting up eCommerce in Google Tag Manager (and now the new Enhanced ecommerce) is very difficult for many. I’m sure part of the problem is that eCommerce is for many users the moment that GTM forces you to take steps in to the developer’s domain, since it’s obvious that you’ll need to add some code to the web page.

This isn’t a tutorial on how to do eCommerce in Google Tag Manager. To get started, you’ll want to check out the official documentation. Sure, it might be inaccurate in places, and especially the translations are lacking, but dataLayer form and function is nicely described within.