Google Tag Manager

Information, support and resources for how to use Google Tag Manager.

‍

Introductory Section

What is Google Tag Manager?
How does Google Tag Manager Work?
How many containers should you have?
Identify the right workspace
Understand Website Structure/Anatomy

Consistent Processes

‍

Specific Solutions

Note: Have you been struggling with something that isn't covered here? Have you found a better way of doing something? This is designed to be a growing section, but aimed at covering common solves that are required in GTM.

What is Google Tag Manager?

Google Tag Manager (GTM) is a tag management solution that acts as a middleman between a website and marketing/analytics tools.

‍

‍All you need to do is to add your tracking codes to GTM and then configure rules when they should be activated(on page load, click, form submission, etc.).

Out of the box, Google Analytics offers plenty of metrics. But to make really good and thoughtful decisions, you need to track much more: interactions (e.g. clicks, form submissions), sales, etc.

This means that more tracking codes must be added to a website. And usually, this is not just a “one-time project”. You need to constantly add new tracking codes and modify/remove the current ones.

That’s where the developer (and the IT department) becomes a bottle-neck. Since he/she is working on his own tasks/projects, marketing/analytics tasks often are a B priority, therefore you and your team have to wait. And wait a bit more. And more.

‍

Tip: Google Tag Manager also lets you test your tracking tags to make sure they are triggered when you load a page or click a particular button. Another great benefit: you can change your tags and the way they work without actually changing the source code of your website. Instead, you just edit tags in the GTM user interface and publish changes with a click of a button.

‍

How does Google Tag Manager work?

For very beginners, there are three concepts to understand: tags, triggers, and variables.

A tag is a piece of code that must be fired on a website under certain circumstances. It can be a tracking code, some piece of code that changes the text or a particular website element, or even code that changes the color of the browser’s address bar, you name it. When you create a tag, you basically instruct Tag Manager to “do this”, “do that”, “track page views of this visitor”, “track this click and send to Google Analytics”, etc.

A trigger is a condition when a tag must fire. Should a tag fire on all page views? Or maybe on certain clicks? How about successful form submissions? All of these examples are triggers. When a particular condition (or a set of conditions) is met, a trigger is activated and all the tags (linked to it) are dispatched.

A variable is the final member of this trinity. Variables are little helpers that can be used in tags, triggers, or even in other variables. A variable can:

hold a single piece of data (like page URL, website domain, product ID, text of a link, etc.)
hold a set of data/settings (GA settings variable contains multiple settings related to GA, like Tracking ID, Display Advertising settings, etc.)
be a complex function (but this one is too advanced for beginners, therefore, let’s skip it, at least for now), etc.

A good way to understand the relationship between these is through the example below;

‍

How Many Containers Should You Have?

Say, you have 3 websites. How many GTM containers do you need here? One? Two? Three?

The reality is that there is no universal answer. One container might work, two or three containers might do the job as well. The real answer is: it depends.

‍

Think about the websites first

When it comes to deciding the number of containers, I always think of the structure of websites.

Are those 3 (or insert any other numbers) websites very similar (regarding content, structure, etc.)? Or are they quite different?

If you have three websites that are very similar and, say, the main difference is localization (language), then I’d recommend using the same GTM container on all three websites. Because, most likely, you’ll be tracking the same things on all websites.
If you have three websites that are totally different in terms of their content, structure, functionality, e.g. an online store, a blog, and a support page, I’d recommend using separate containers for each website because (probably) each one of them will have pretty unique tags, triggers, and variables.

Several different websites

By using the same GTM container on several different websites, your trigger conditions will contain more rules, more exceptions. It will be more cumbersome to ensure that a particular tag fires only on one website (e.g. only in your online store) and not the others. Your list of tags, triggers, and variables will grow faster and soon will become more complex to manage.

Eventually, the container might even exceed its maximum size of 200kb and you will be forced to either get rid of some items or migrate to separate containers.

By using separate GTM containers, you’ll notice a smoother tag management process. There will be fewer tags/triggers/variables, triggers will be less complex (with fewer conditions and exceptions). It will be easier for you to find particular container elements (rather than browse hundreds of entities).

If there are more differences than common things between tracking implementations of each website, you should go with separate containers for each site.

Several similar websites

On the other hand, I don’t always recommend having separate GTM containers. What if the websites are pretty similar? Here’s what the process looks like if each website has its own GTM container (even though they all are being tracked with the same Google Analytics Property, same Facebook Pixel, etc.):

You configure particular changes in container A.
Then you need to copy the same changes to containers B and C. You can try to do that manually (big nope), export a part of the container or use the tools like gtmtools.com or GTM Copy/Paste extension.
And this will happen every time you implement a change. Far from an efficient and agile work process!

But if you had one GTM container across all three websites, one single change would be applied to all three websites instantly.

Of course, sometimes you will want to fire a tag only on one website but the scale of such “unique” tracking implementations will probably be pretty low.

Final words

To sum up, every time you face the situation with several websites and you need to decide how many GTM containers are needed, think of how different/similar those websites are.

What kind of tracking are you planning to implement on those sites? Will tags/triggers/variables be quite similar on all three websites? Or, contrary, quite unique for each one of them?

If those websites are quite different in structure/functionality and you plan to track different things on each one of them (e.g. e-commerce tracking is planned only for website A), then you should go with a separate GTM container for each site.
On the other hand, if those websites are quite similar and you plan to track the same things across all of them, it will be easier to utilize a single container (because all the changes will be immediately applied everywhere).

‍

Identify the Right Workspace

Before you can start setting up your tags and triggers you need to first identify which workspace in GTM to create them in. Fortunately GTM has a straightforward account structure;

Account (most often 1 per client)
Container (generally specific to an individual domain)

Below is a screenshot of the Clarendon Homes GTM account structure we can use as an example to understand the workspaces:

‍

‍

As you can see they have a number of containers within their account, each of which is allocated and in their case, named, according to the different domains they have in the business.

Tip: If you’re not confident in your understanding of website structure or terminology, jump to the next section here, for a guide on website anatomy.

If I was therefore wanting to create a tag or trigger for Anambah Rise, I would need to ensure that I’m making my changes in the container that is assigned to that domain, which in this case would be www.anambahrise.com.au, or container ID: GTM-ND7VW64.

Tip: It’s important to become familiar with the Container IDs as you will be referring to these more frequently than the actual container name.

So what if it wasn't named that clearly, or if I wasn't even sure if they had a GTM container on their page? Is there a way to check? The answer is YES and this is generally the first method I would recommend to actually determine which workspace to use.

Finding the Google Tag Manager (GTM) container on a website

There are two ways that you can do this, the first is the most user friendly, while the second is sometimes quicker and easier once you know what to look for.

Using a browser extension to scan the page
Viewing the page source

‍

Using a browser extension to scan the page

There are a number of different add-ons that you can use and as long as it can do the following task and give you the information you need there is no right or wrong choice. The one that I use and recommend is Google Tag Assistant Legacy

Once you have downloaded the extension and enabled it, you should see the icon appear in your extension bar as per the below screenshot;

‍

From there, navigate to the website that you are wanting to track, once the page has loaded, you want to click on the extension and first select ENABLE and then RECORD, you may need to refresh the page after having done that before it will return the information.

Once refreshed, if it has successfully identified a container, you will notice that the extension preview changes based on the number of containers identified

You can then click the extension again to open it and it will display a list of the containers it has identified. It will include both Google Analytics and Google Tag Manager codes so you want to make sure that you’re referring to the GTM container, outlined in the example below:

You simply just need to then locate in GTM the container that matches the container ID referenced in the tag analysis.

Viewing the page source

The second method of identifying the right container is to view the page source of the website you’re wanting to tag. Simply navigate to the landing page, right click somewhere on the page and click ‘view page source’

This will take you to a new page that looks something like this:

From there the process is straightforward, simply hit command/ctrl + F to enable the Find function, and search for “GTM”

‍

‍

This will automatically take you to the second of the page source that contains the GTM script and within it the container ID as per the screenshots below:

‍

Tip: The browser extension approach can actually show you if there is an issue with the container in the way that the script has been placed on site by the developer, whereas the page source approach could return the ID of a container that has been incorrectly placed on the site and unless you are familiar with what to look for in the script, to determine if it has been placed down correctly, there is no way of knowing from the script and ID alone if it is presenting.

‍

Understanding Website Structure

Because we’ll be referring to it alot, let’s be clear on the anatomy of a website, included below is the anatomy of a URL which relates to the way a website is structured:

What’s a Domain:

Before domain names were invented, you needed to type in the IP address for a given website to access it. Today, domain names act as a placeholder for the complex string of numbers known as an IP address. So, instead of typing in a series of numbers like 32.222.46.1 you type in hostgator.com into your browser.

‍

What’s a Subdomain

A subdomain is an add-on to your primary domain name. Essentially, a subdomain is a separate part of your website that operates under the same primary domain name.

To create a subdomain, you must have a primary domain name. Without a primary domain name, there’s no way to add a subdomain onto it.

‍

What’s a Subfolder

Another common distinction you’ll need to make when it comes to subdomains is the difference between a subdomain and a subfolder. With a subfolder, you’re adding a folder to your existing domain.
So, instead of creating a new subdomain for your blog like “blog.mysite.com,” you’ll use a subfolder instead “mysite.com/blog.”
A subfolder is a way to organize your site more easily. Think of it as creating categories for your blog and blog posts. If you have a sports website, you could create subfolders for each sport you cover. So, you’d end up with a URL structure something like the following: “sports.com/basketball,” “sports.com/football,” “sports.com/hockey,” and on and on. Each page could operate as its own separate sports-specific blog with each page filled with unique content about that sport.