A guide to Google Tag Manager for non-tech people

Google Tag Manager is probably one of the most underutilized, misunderstood and misrepresented tools on the web. Beneath all its marketing emphasis, there exists a highly flexible tool that is only limited by one's creativity.

I'm leaving my developer hat at the door for this one as I try to explain in a simplified way, how Google Tag Manager actually works and hopefully spark some ideas on how it can help you leverage it to its greater potential.

The case for Google Tag Manager

Google Tag Manger has become almost synonymous with Google Analytics. Most Google Analytics implementations are done through Google Tag Manager but there remains a lack of understanding why. I believe that some of this narrow perception is due to how Google markets Google Tag Manager and pushes it towards Google Analytics. That is quite understandable because Google Tag Manager is most commonly used with Google Analytics and demonstrates a lot of its functionality through it. But even tough it greatly complements working with Google Analytics it is not bound to it. It actually has nothing directly to do with Google Analytics nor analytics in general. To its respect it is very much a standalone tool.

Interestingly, its ease of use and graphical interface has just enough fluff for developers to not see it as a development tool, while on the marketing side it requires a lot more technical understanding to be used in a more justified and fulfilled way. Based on this it really shouldn't be perceived as a marketing or analytics tool, but more in line of a utility. It's like a Swiss army knife that can provide solutions for many different problems and is readily available.

Tags and tiny robots

Before we can get to what Google Tag Manager actually does, we need to understand what a"tag" means in this context. A tag is a snippet of code; the same kind of code used to build webpages. Code snippets by themselves are just text. For people with less technical knowledge they look like a cat walked over the keyboard, but to a machine they make a lot of sense and provide instructions. When a machine follows these instructions it means the code was executed.

Google Tag Manager provides a dashboard where these code snippets are created and managed. When Google Tag Manager is enabled on your webpage it allows these code snippets to inhabit your code without the need of modifying your webpage's actual source code.

How is this so powerful? Well, these code snippets can provide additional functionality or modify the current one.

Adding, removing or modifying functionality on a web page commonly requires a developer to make changes to the source code and deploy these changes so they can be seen. Depending of the scale of the webpage, even minor changes can be time consuming as the process of updating might need several steps to be made first. That is far from saying that bug fixes and updates should be made via Google Tag Manager, but it can prove invaluable to be aware of the alternative approaches it provides when working on less foundational aspects of your product.

This is as technical as we'll go, I promise.

For the sake of simplicity you can picture these tags/code snippets as tiny robots. So in simple terms, Google Tag Manager creates a tunnel to the webpage through which these tiny robots come and do their work. But these tiny fellas don't have the confidence to come through the tunnel alone and start frolicking around. They need a bit of a guidance.

Of triggers and ninjas

Triggers are special code snippets that listen and look for specific actions to occur. Once they occur, the triggers cause the tiny robots to start working. Creating triggers in the Google Tag Manager dashboard is definitely one of its hallmarks due to the ease and versatility of creation. There are virtually limitless things on what a trigger can be; from a user clicking a button to a certain image being visible on screen. Having this ability means that automated reactions to different user actions and states can be set in place without the need of developers updating the source code.

Think of triggers as ninjas that accompany the tiny robots through the tunnel but remain hidden in the shadows. Every tiny robot has an accompanying ninja and many robots can share the same ninja. Each ninja has been trained for a specific stimulus and once it detects it, it notifies its partnered tiny robots to start working.

Let's envision a real world example that demonstrates all of this:

Jane is a developer for a startup that is building a web application. She enabled Google Tag Manager on their web application from the get go, as they wanted to have Google Analytics integrated. She created a tiny robot ninja pair for this. The ninja is trained to detect when the web application is loaded. Once loaded the ninja notifies its tiny robot buddy and that specific robot opens a phone line with Google Analytics.

During the last phase of the development, Danny the product manager suggest they add the Intercom support widget to the web application. Jane sees no problem with this, grabs the tiny robot from Intercom's developer guide and adds it to the web application via Google Tag Manager. The Intercom tiny robot is paired with the same ninja that accompanies the Google Analytics tiny robot as both need tos tart working when the application has loaded. Job done.

As the web application is published and some time passes Danny finds out that some users are struggling on the payment form page. He can't tell which, but knows that there are some. Jane suggest creating a tiny robot-ninja pair that inhabits the payment form page. The ninja is trained to detect when a user has been on the payment page for more than 2 minutes - a  fair assumption of a user being stuck. On notice the tiny robot uses the existing phone line to Intercom to pop open a live chat dialog for the user so they may talk with customer support. Danny is thrilled as Jane has this setup and tested in less than 20 minutes.

Hopefully you're starting to see a lot more potential in Google Tag Manager. It's far from being just an analytics tool as it provides an approachable utility with which you can enrich and manipulate your webpage. A developer with an open mind and creativity can see the broad extent this could be taken; from prototyping new features to adding remote configuration, personalizing the user experience or just plain hot fixing a bug when they don't have access to the source code. That said, most of these approaches are not communicated or documented. For better or for worse really, as careless usage can lead to performance problems, security risks, additional bugs or maintenance issues. Importantly, it's not about trying to fit a square peg into a round hole. It's more in line of fitting different shaped pegs through a huge round hole.  

A layer of data and mailboxes

There's one last feature that can't be ignored when working with Google Tag Manager. The famous data layer.

I was reluctant to include it because even though it can greatly enhance the core utility, it is the most technical feature of all. So with all due respect to its potential, I'll do my best and keep it brief.

In a nutshell, the data layer provides a standardized way for a developer to send data from the webpage back to Google Tag Manager. The data is not stored but can trigger certain tags to run. The main feature mostly comes from the fact that the tags have access to the data that was sent. The best known example for this is sending specific analytics data through the data layer and having a Google Analytics tag run to forward that data to Google Analytics.  

So our tunnel, through which the tiny robots and ninjas pass, actually has a built-in postal service with an office. On the webpage side there's a mailbox that a developer can use to send messages to the postal office. The office is occupied by a very pedantic clerk who upon receiving a message destroys it immediately. Needles to say this setup seems bonkers at best. However, ninjas can be employed in the post office that check every message before the clerk destroys it. Every post office ninja is trained to only react to a specific message and once it encounters it, it notifies its tiny robot and gives it a copy of the message contents before handing the original message over to the clerk. This allows the tiny robot to use the message contents.

Honestly, I'll keep it at that. As much as I would like to geek out on all the possibility this provides, it would quickly become too technical. There are a lot of other intricacies that Google Tag Manager includes, some more technical than others,which I leave as a surprise to the curious. ;)

Keep an open mind

I hope my quirky analogies help you understand Google Tag Manager better or even spark some wild ideas. It's a shame this tool isn't presented and enhanced in a broader sense so it could provide friendlier interfaces to more conceptual solutions without the need of having deeper technical knowledge to work around the existing options.

If you're a developer, don't right it off as a marketing tool but get to know how it works and what it enables. Help your team mates understand and leverage it better. If you're a product manager, get to know the concept behind it and get a developer to help out when trying out new ideas. In my view a product-developer pair is ideal for getting the most out of Google Tag Manager.

Most of all, keep an open mind and don't limit yourself to how a tool is presented. Some of the best products have evolved from the creativity of its users.

Now go create some tiny robots and ninjas.

P.S. Want to chat more about your tech venture and how we can help? Get in touch at sales@dlabs.io.