Google Tag Manager Best Practice: Avoid Pass‑Through Events

May 25, 2017

gtm-anti-pattern-pass-through-events

Using Google Tag Manager to deploy your Google Analytics code provides many benefits over coding your tracking into the webpage directly. However, if you’re not used to Tag Manager and some of the best practices around the tool, it’s easy to fall into some bad habits that prevent you from making full use of the tool. One such habit that we see often in the wild is an anti-pattern I’ve named “Pass-Through Events,” which is what happens when you implement Tag Manager by replacing all of your Google Analytics tracking calls with equivalent Tag Manager calls.

What Are Pass-Through Events?

A Pass-Through Event is a Google Analytics Event tag set up in Google Tag Manager in such a way that some other system is responsible for deciding when to fire the event, and for setting the Category, Action, and Label values. Tag Manager plays no role in firing the Event other than to “pass through” these values from the web page to Google Analytics—hence the name.

The most distinguishing feature of Pass-Through Events are GTM Variables with generic names like “Event Category,” “Event Action” and “Event Label.” These variables will pull values from similarly-named keys in the Data Layer, or occasionally from similarly-named HTML Data Attributes. They often, but not always, use a Custom Event with a generic name like “GA Event” as the firing trigger.

Pass-Through Events are most often seen when websites migrate from in-page analytics to Google Tag Manager. Rather than removing existing calls to Google Analytics from the page, existing call sites are re-written to pass the same information to Tag Manager instead of to Google Analytics directly. This strategy has the advantage of requiring little up-front work, and can often be accomplished automatically, even on extremely large codebases.

Unfortunately, it has no other advantages, and comes with substantial opportunity cost.

What Are The Downsides of Pass-Through Events?

In a nutshell, Pass-Through Events lose many of the benefits of Google Tag Manager.

Less Control Over Tagging

One of the most significant aspects of Tag Manager is that it puts Analytics implementation in the hands of the Analyst. Tracking can be updated on-the-fly, without needing to write a user-case, take a developer’s time, or wait to go through the standard code develop-deploy-release cycle.

Pass-Through Events are out of the Analyst’s control, and require developer involvement in order to modify. The presence of Pass-Through Events does not prevent an Analyst from implementing new tags, but existing Pass-Through Events cannot be easily removed or modified without changing the front-end website code.

No Separation of Concerns

Even though Pass-Through Events are routed through Tag Manager, they cannot be easily modified because there is a single tag for many different interactions. In a normal Tag Manager implementation of Google Analytics, one would use separate tags, triggers and variables for tracking an outbound link to a Social Network, a Download link for a PDF, and a UI click on the main navigation.

With a Pass-Through Event, all three of these user interactions are tracked with the same tag, the same trigger, and the same set of variables. A normal implementation could easily update the Event Tagging for Social Networks without impacting how PDFs are tracked, but Pass-Through Events would require a Herculean effort to update one without affecting the other.

Too Many Sources of Truth

A Pass-Through Event means that the logic to determine when a tag is fired, and what value is sent, is being processed somewhere outside of Tag Manager. If you’re lucky, it’s all in a single JavaScript source file. If you’re unlucky, the values on the page are produced by an opaque process that runs on the back-end web server (or possibly on several different servers!).

Implementing all of your tags in Tag Manager means that you only need to go to one place to understand all of the logic that decides when and how your Google Analytics data is sent. The presence of a Pass-Through Event means that you need to look at another system in order to get a complete view of when and how your tags are firing.

No Re-Use of Assets

Tag Manager can manage all of your tags, not just Google Analytics. By re-using the same triggers and variables, you track the same user interaction easily and consistently in Google Analytics, AdWords, DoubleClick, Facebook, Yahoo!, Baidu, comScore, or any other data collection platform you happen to be using.

But it’s much tougher to fire a remarketing tag specifically for people who clicked on the link to your Twitter profile or downloaded a PDF if the same trigger could also represent clicking on the main navigation, signing up for a newsletter, or applying for a job posting.

Pass-Through Events couple your implementation to Google Analytics specifically, rather than allow you to implement new tools at will.

Lack of Context

In order to understand your tracking, you need to keep track not just of what it’s doing, but also what it’s supposed to do. In order to communicate intent and context, Data Layer values and Google Tag Manager variables should be semantic values relevant to your website. A variable like “Event Action” does not communicate intent, because it has no semantic value. A variable like “Social Network Name” or “File Type” is semantic, and communicates intent.

If you look in Tag Manager and see a Google Analytics Event Tag with “File Type” as the Event Action, you understand what that tag is trying to track, and when you see that tag fire on the site you can tell whether it’s working properly. If you only see a variable named “Event Action,” it’s much harder to tell what it’s supposed to represent and whether it’s working well.

No Debug Panel

Tag Manager gives you access to a wonderful suite of tooling to let you explore and debug your analytics implementation. This includes things like Preview Mode and the Debug Panel so that you can examine your firing triggers and inspect the values of every variable during every Tag Manager Event. By necessity, these tools can only inspect the logic that happens within Tag Manager.

If a Pass-Through Event is sending the wrong value, you can only see that wrong value, but not any of the reasons why. If a Pass-Through Event isn’t sending anything at all, you have even less visibility into the problem. And if that Pass-Through Event isn’t firing when you expect it to happen, you’re unable to examine the Trigger to determine what exactly is causing it to fail.

Yes, you are “using” Google Tag Manager, but you are not able to take advantage of some of the most essential features that make it a powerful tool.

What Should I Do Instead?

The ideal situation is that the only Google Tag Manager code on your site is the snippet that loads Tag Manager. All tracking definitions should live inside of the Tag Manager tool. Realistically, most implementations need at least a little bit of on-page support, especially for Enhanced Ecommerce implementations that require passing extensive product information into the Data Layer. Still, Tag Manager provides the most benefit when the amount of on-page code is as small as possible.

The best practice is to remove hard-coded calls to Google Analytics tracking code entirely, and to recreate the same logic inside of Tag Manager. The Google Analytics logic shouldn’t just be transformed to cooperate with Tag Manager, it should be off the page and re-implemented. For complicated websites or complicated Google Analytics implementations, this can be a daunting task. We have some tips for migrating large codebases, which may help with the process.

While they should be avoided if possible, sometimes resource and timeline constraints mean that an automatic translation of on-page code to Pass-Through Events is the only realistic solution to avoid data gaps. But in these situations, there are still steps you can take to make sure that you don’t end up stuck with Pass-Through Events forever. By marking your Pass-Through Tags with distinguishing values (whether as a Custom Dimension, or by entirely re-writing the Category, Action, and Label), you can report on the continued use of Pass-Through Events, and iterate on your implementation until they are completely removed.