•Tags
In this section we will walk through seven key Google Tag Manager concepts.
|
Hint Remember, before you begin, it is a good idea to read through the First Steps section in the Google Tag Manager Help Centre documentation. |
Accounts
An account is the top-most level organization in Google Tag Manager. An account really just describes your company. If you were managing multiple websites for multiple clients you would have one account setup for each client.
Users
Users are created on accounts. You might have multiple users of your account, some of those users can be given permission to only view the account while others can be given permission to configure the containers and tags attached to that account. If your account has multiple containers you can choose which containers that users can access. We recommend that you think carefully about who has access to your container in your Google Tag Manager strategy while paying attention to the risks of using Google Tag Manager.
Containers
The container in Google Tag Manager can be thought of as your website. It is a container for all of the tags that you want to deploy.
Tags
The tag is the block of code that we want to run on our website. Google maintains a list of certified tags; you can think of these as tags that Google supports through the Google Tag Manager interface. The great thing about these types of tags is that the code part is hidden from you. Instead, Google Tag Manager provides you with a simple configuration template. If the tag that you want to deploy onto your website is not a certified tag you can normally deploy the tag as a “Custom HTML Tag” instead. This means that you paste the block of code provided by the tag service directly into the Google Tag Manager user interface. It is a good practice to the contact tag providers to confirm that your tag works with Google Tag Manager and whether they have any best practices for deployment. The tag provider is the original source of the block of code and is generally the organization that is receiving or processing the data. In most cases the tag provider will be evident in the block of code.
Triggers
The circumstances that the tag will fire under are contained in triggers. For example, a tag that tracks conversions from an inbound marketing campaign should fire only when an order has been completed.
Variables
Sometimes you will want your tags to fire based on things that are happening on the page or attributes of things on the page. Something that is happening on the page could be an error message. An attribute of the page could be the page URL or the title of an article that is displayed on the page. Your tag might also want to know these attributes or things that are happening to provide additional information. Things that are happening on the page or attributes of the page can be accessed through what Google calls a variable. Within a variable we tell Google Tag Manager what we want to grab from the page and the data is returned into the variable.
We can use variables within a tag (a bit like a mail-merge) or trigger to provide additional data to the tag or trigger.
In short, tags exist in containers and tags fire based on triggers and variables provide data to triggers or tags.
In other words, you might want to fire a DoubleClick conversion tag that fires when an order is completed (the trigger) and provides the order number (variable), order value (variable) and quantity of admissions (variable) to your DoubleClick reporting.
Previewing and Publishing
Whenever you make changes to your container you are making changes to a draft version of that container. When you are happy with those changes, you have two options: preview or publish.
•Preview: When you preview a container, your latest changes are live only in your current browser session. Nobody else will see those changes. The preview mode also has a debug option, which we will cover that later in our troubleshooting section.
•Publish: When you publish a container, your latest changes are live. All new visitors to your website will be operating under that version. If you want to test your changes before making those changes live you should preview the container instead.
We recommend that you always preview your changes before publish them. You can share a preview link with other people via email; this link will allow their current browser session to view your website in preview mode, too.
