Earlier this year eConsultancy reported that Tag Management System (TMS) adoption is set to reach 50% by 2017. Hindsight may reveal this estimate to be somewhat pessimistic if the growth of TMS adoption fails to abate.
Driving this trend, Google Tag Manager became a fundamental part of the ConversionWorks service offering. 2014 is set to become the year of the TMS and, as we hope, the year of Google Tag Manager (GTM). In this post I reference GTM but the content is equally applicable to any TMS.
But why is Google Tag Manager adoption rampant? There are many reasons, but the main one is that it's easy. This is both good and bad: good when done well and for the right reasons; bad when done carelessly. Based on my experience with GTM, this article will describe a couple of key points (non-exhaustive) that will help you get your GTM (or TMS of choice) right... or at least better!
This article will be divided in two main sections: Naming and Coding advices to be used in your Google Tag Manager settings/configuration.
If you've used GTM for real, then you may have found that the number of tags, rules and macros can grow very quickly into a hard to manage mass of tracking stuff.
Therefore, you should build your tags, rules and macros to aid maintenance, helping you to manage your GTM implementation far easier. Easier for you (whatever your role), easier for developers, marketers and testers.
Easier means less risk, less time, and less money wasted on tagging. Yes, wasted. Tagging does not have a direct impact on your bottom line in the same way as optimisation does, so tag less (write less code) and move on quickly to something more important!
In the meantime, consider how tags, rules and macros are used on your pages:
Most General => Most Specific
Macros => Rules => Tags
Whilst tag re-use is recommended as much as possible you will find that your macros are used most generally of all with rules consuming macro output to fire tags in the most specific use cases.
For this reason, you should name your tags, rules and macros to help with organisation. Here are 4 helpful heuristics to guide your naming strategy.
If you have existing naming conventions within your team, use them. The familiar naming structure will help you find the tags, rules and macros you need. This extends to case and white-space usage. The naming semantics are addressed next.
As mentioned above, tags are the most specific GTM assets. You can use this property to group tags such that the rules and macros related to these tags are easily found. In the examples below, see how the use of the naming convention aids finding (and therefore managing) related tags, rules and macros.
The conventions used below is Functional area - Tag type - Tag function
Search by site function (homepage tags)
Search by tag function (click tags)
Search by tag type (GTM tags)
Here are additional sample tags using this convention:
The conventions used below is Functional area - rule function
Search by site function (rules specific to homepage tags)
Search by rule function (rules using the URL in conditions)
The default set of macros hints at sensible naming:
Continuing the theme when extending auto-event tracking macros clearly shows the meme in use here:
This is by no means intended to be an exhaustive list of tag, rule and macro naming scenarios - just an illustration. Feel free to mold, tweak and grow these conventions but make sure they are used rigorously. Employing GTM police, the effective assignment of roles and responsibilities, and manic adherence to process may be the subject of a future post...
Consider this little adage when building your GTM implementation:
Tell me, and I will forget.
Show me, and I may remember.
Involve me, and I will understand.
(Confucius, BC 450)
Use your peers to review your work (and vice versa). Learn from each other. Make each other aware of changes, ideas, plans or issues and involve the team to build a Borg-Collective-like understanding of your GTM system.
If you find yourself in this situation you need to have a careful think about your commenting practices:
Apply comments to container versions - use them to your advantage by relating container version numbers and names to sprints.
It's an old adage that the best software has little or no code. Adding code adds complexity, risk, time and expense.
"Should we calculate the value of a transaction including a discount and member bonus in a macro? It seems cool, quick and easy to do this in GTM...
Yes, it does seem cool, quick and easy, but it's very wrong. Don't embed business logic in the measurement layer that should rightly reside in the business logic layer of your app. Treat GTM as if it were (and it is!) an architectural layer in your software system. Ask the measurement layer to do measurement things - no data operations, no presentation operations and no business logic - measurement only.
I've seen custom HTML tags used to fix tracking issues caused by poor markup; this is also wrong. If you have a set of links on a page that require meta data for use in tracking pixels when clicked, decorate the links using helper methods in the presentation layer. Don't use a custom HTML script in GTM to scan your page DOM to do the link decoration; this is slow and fraught with risk. Every time you change the site you'll chase the change in GTM and more than double the required testing. It's expensive to throw good money after bad in this manner.
Don't patch your site using tracking tags!