Deployment, implementation, install, variable, trigger?! What are all of those and why should I care?
Good question! After all you most probably are a person which has much on his hands, but let me explain.
Having a good understanding of the basic terminology can help you understand how the tool works or at least helps you make better requests. If you are an entrepreneur you are already juggling many things: finances, sales, business development, etc. Thus you might need to contract someone to handle different parts of the activity, like marketing (I can definitely help you with that, see my full list of services). As you already know communication is the cornerstone of any business undertaking and knowing how to ask what you need can dramatically improve the efficiency of the work. Here the terminology can come and play a BIG role.
For example, a general, fuzzy request, like: “I want to see what users do on the website” won’t get you very far. Asking “I would like to have a conversion for all the people who reach the /success page on the website” is way better. You see how different those two approaches are? This is just the asking part, but there is also…
The response. Which for a request like the one above can be: “We can definitely set that using a GTM tag, with a trigger for page URL contains “/succes” and domain containing yourDomain.com”. Understanding what the other person says can be the difference between setting a proper tracking which will help you take better decisions or simply following irrelevant, unavailing data.
I hope you got the sense of why it’s important to understand this information, so let’s see:
Note: I’ll take a moment to mention that much of the definitions below are taken from the Google Support documentation. I wanted to have the most precise information, thus I went directly to the source. I do realize that you could have accessed this data by yourself but for the sake of simplicity, accessibility and because no GTM series would have been complete without it I decided to write them down in this article for you!
We’ll start with the basics and we’ll first look at the fundamental structure of a GTM account.
The GTM account “represents the topmost level of organization” (Source). There are specific account-level settings you can access by visiting the “Admin” tab in your GTM account. Similar to the Google Analytics platform, you can choose which people do have access to the account at this level (Keep in mind that users added at this level will have permissions over the underlying containers as well!).
Also, at this level you can adjust the account name and settings for security, like the 2 Factor Authentication, which I strongly recommend you to activate!
Below this level there are the…
One account can have multiple containers and they come in different “shapes and flavours”. There are specific containers for different platforms, currently there are 5 different container types:
For example you can have one single account (i.e. Your Business) and two nested containers, one for the Website (Your Business Web) and one for your AMP pages (Your Business AMP).
GTM components live inside the container defined above.
Google is defining tags as being snippets of code that execute on a page or mobile app. Tags can serve a variety of uses, but most of the tags used in tag management systems are designed to send measurement information from your site to a third party.
Tags are made of two parts: Tag configuration and Trigger, we will talk about the latter below. The tag configuration is the part where you define where the information is sent and what information is sent.
I will create a future article about how to set up Google Analytics on your website using GTM, but basically you have a predefined tag type called “Google Analytics: Universal Analytics” where you input your GA ID (UA-….) and select the Track Type (which would be “Pageview” for your first implementation).
Keep in mind that there are also other types of tags, some of them not being predefined as the GA one. For those you will have to input the code manually.
Before going further we’ll make a stop and talk about GTM Templates. They are similar, in look and feel, with the “built-in” tag types (like the GA we’ve talked about). The major difference is that they are created by third parties, and not by Google, which can raise some security risks, so use them with precaution!
Templates help users by offering a more “standardized” way of implementing the code in your website. They are a great feature and I strongly recommend them.
In one of my future articles we will talk about how to implement Cookiebot in your website to make it GDPR compliant using the Cookiebot CMP Template.
If you are curious to learn more about templates, I recommend you to read Simo Ahava’s article on this subject.
The trigger or triggers tell your tag when it should deploy the code inside (the one defined by us above).
GTM comes with some “out of the box” triggers, like the “All Pages” (which is a great option if you want to deploy your code site-wide) and some build-in triggers that you have to define. The majority of the triggers that you will use will be created by you, because… well… not all websites are the same and the tracking architecture that you are using must be tailored for your website.
We’ll look at a simple trigger. Let’s say that after your user registers to the newsletter he is redirected to the page /success. To setup a trigger matching this requirement we must follow the following steps:
Here we will start to enter the more techy side of things, but don’t run, we’ll keep it simple! 🙂
“A variable is a named placeholder for a value that will change, such as a product name, a price value, or a date.” is the way Google defines them. If you have a technical background you can think about them as key-value pairs, if not just think about them as dynamic values (like the product price).
Variables really show their true value when you are dealing with data that is constantly changing. Think about: product price, color, country of sale, user age, etc., literally anything can be sent using a variable.
It’s a little bit more difficult to explain the process of how this happens and how you can use this functionality but I will create a future article specifically on this. What you should know at this point is that there are built-in variables (i.e. Pages, Utilities, Errors, Clicks, etc.) and custom variables (the ones that you might need a developer’s help to set up properly).
We won’t delve much in the details of the Data Layer because the information usually gets too techy, too quick and it’s beyond the scope of this article.
For now just keep in mind that you might need the help of a developer for any tasks related to the data layer.
Basically the Data Layer is “a JavaScript object that is used to pass information from your website to your Tag Manager container.” (Source: Google). In non techy terms think about the data layer as a “place” which holds data that can be accessed and used in GTM.
Having a data layer greatly helps the tracking architecture creation and implementation process, and it’s also recommended by Google as the method to use when sending data from your website to GTM.
If you are familiar with the development jargon you might recognise some of those terms. Basically they were borrowed from the development process because they describe the process pretty well.
Disclaimer: This terminology is not default, thus some of you might use different terms to define the same thing.
This is the moment where the marketing specialist, together with the technical team comes up with a proposal for the tracking architecture. Also this phase sees the actual construction of the tags, triggers, variables and anything else needed to match the request.
At the end of this phase all the tags are set and await the next phase which is the…
The goal of this phase is to make sure everything is set up properly and works as intended. In order to make this possible multiple tools are used and depending on the case the audit is run multiple times.
The most important GTM feature used in this phase is called the “Preview” mode. It allows you to check if the tags are working properly. Also, the tools allows the user to debug the source of the problem if any arise.
This tool is often used in the development phase in order to identify the proper variable names and values for the triggers.
After everything was checked the natural step is to make sure everything is live on the website. Until this point everything was happening inside the GTM environment. The Preview tool was creating a sandbox version of your website where the tags where showing like active, without any code really ending up in your website.
The deployment process is pretty simple, you just have to click “Submit”, give the new version a name and a description (I do recommend not skipping this step, especially if you are working with a team in the same account) and click “Publish”. All the tags are now live on your website.
As mentioned in the step above, when you publish the tags a new version is created. A version is a snapshot of a container configuration at a particular time (Source: Google). The versions offer a great way of seeing the historical changes made to the account and also offer a quick way to revert back to any previous setup.
This was an overview of the most common terms you’ll probably encounter in the GTM environment. Also, this will lay a basic understanding of the Google Tag Manager tool for future (more in-depth) articles on this subject.