This is the third in a series of blog posts on Google Tag Manager. Read Part 1. What is a Container Tag? and Part 2. Google Tag Manager Series: 2. An Overview. At iProspect, we have been using multiple vendors for container tags since 2010. This series focuses specifically on Google’s new Tag Manager, providing an overview of the tool, helpful tips, hints, and learnings.
When beginning a Google Tag Manager implementation, it is always important to think about organisation. Every implementation starts with just one tag, however, between Google Analytics standard code, advanced code (like events), DoubleClick floodlights, and Adwords conversion tags, the inside of the container tag can become quite complex.
If care is not taken throughout implementation and during updates, container tags can often become highly confusing. This contradicts using a container tag to simplify your tracking setup. Whether there are two tags or 100 tags in your container tag, this blog post will explain how to best organise the inside of a Google Tag Manager account.
Naming Conventions:
Everyone has a naming convention that they like to adhere to. There are no right or wrong naming conventions out there – the key is consistency. At iProspect, we believe that any developer or analytics specialist should be able to go into the container and instantly understand the tags they are looking at. We favour longer tag names that explain the tag rather than using complex keys or omitting information.
If there are different sites within one container, we state the site. If there are different markets or brands we state these as well. For Google Analytics we include if it is standard code, an event, a social interaction etc., and include a brief description. For DoubleClick we include the activity ID, site section, and page description.
An example of Google Analytics:
[site] – [Country] – [Tool] – [Type] – [Description]
Its practical execution:
iProspect – UK – Google Analytics – Classic Code – Site Level
iProspect – FR – Google Analytics – Universal Code – Roll Up
iProspect – DE – Google Analytics – Event – PDF Download
iProspect – ES – Google Analytics – Event – All Events
Rules should also follow a naming convention as there will often be many rules within one container.
An example of our rule naming conventions:
[Site] – [Country] – [Macro type] – [All page/sub site description] – [Page description]
Its practical application:
iProspect – UK – URL – All Pages
iProspect – ALL – Event – Game play – Game over
At the simplest level, macros tend to only need a [type] and [description] as a naming convention.
To help organise our implementation, at iProspect we have built a tool that forces the delimiter, spacing, and case of each name, ensuring consistency between agency members who are creating a tag. If Google Tag Manager were to develop an API, we would also set up an audit to sense-check the naming of tags, rules, and macros, in the same way we already do for events, social interactions, and custom variables in Google Analytics.
The Code:
The following are a few useful tips for organising the code in an implementation:
The Container Tag:
On the container tag, it is good practice to include what it is, which container it is, and where it goes. For example:
<!– Google Tag Manager: iProspect Sites –>
<!– Please do not edit or delete. Place after the opening body tag –>
[code]
<!– End of Google Tag Manager Code–>
Adding in a description of the container instantly identifies which container tag it is, without the need to find the GTM ID in the code and match it with the GTM ID within container settings. This becomes particularly useful when you manage more than one container.
Tag Comments and Code Naming Conventions:
For the majority of sites, the inbuilt tags such as Google Analytics, or Adwords Conversion Tracking should be sufficient. Since the inbuilt tags only need set information and customisation to work they don’t need to have a naming convention other than the tag’s name and any macros and rules used within it.
Occasionally however, these tags may not have the options required and in such situations a custom HTML tag may be used instead. For example, on a site where dataLayers cannot be deployed, custom HTML may be used to fire an event on a button click. There are two ways to organise custom tags.
In each tag, if a custom HTML tag is used, it is best practice to clearly state what each part of the code is doing, or what information is being captured. This is particularly useful if JQuery is being used instead of a dataLayer to pick up information.
For any named functions or variables included in the code, include a prefix of “gtm_” to prevent overwriting code already on the page. For example:
<script>
//When any link with PDF in it is clicked, fire a Google Analytics Event
$(‘a[href$=”pdf”]’).click(function(){
var gtm_download = $(this).text();
_gaq.push([‘_trackEvent’, ‘iProspect’, ‘PDF Download’, gtm_download]);
});
</script>
This isn’t needed if the variables are declared in a local namespace; however it is good practice as a safety-check.
Publishing Process:
It is always best to describe the container you are currently working on using the notes feature. State if the container is in draft or live.
Our organising methods may be quite regimented, however iProspect’s current ‘largest’ container tag has 245 tags, 169 rules, and 12 macros. As can be imagined it is important to ensure that conventions are adhered to, no matter the size of the site or implementation.
Contributor
Rachel Sweeney is Digital Specialist, Web Analytics & Conversion Optimisation at iProspect.
