Every Tag Management Solution (TMS) has its own specifications, tips, and rules. At Cardinal Path, through working day-to-day with different TMS’, I have discovered that what really sets them apart is the User Interface and some specific rules, configurations and settings.
TMS’ tend to work the same way when it comes to the collection, implementation and configuration of tags on web pages. It’s the blue layer:
This is where a consultant can apply some techniques, methods and magic! It’s where you can boost the tool to a near-perfect solution. If you’d like to learn more about why you might want to enhance your TMS, read this.
The foundation of a successful Digital Analytics implementation has two pillars:
- A data layer: a data layer is the best way to communicate with a TMS. I call it the “truth’’. It’s usually a JSON format JavaScript Object.
Google’s definition: “A data layer is an object that contains all of the information that you want to pass to Google Tag Manager.”
- HTML5 Custom Data Attributes (data-*): are usually data attributes that contain information about the element and what we need to track when a visitor interacts with it. I call it, the “truth cousin”.
The blogosphere contains countless posts on how to hack, tweak and listen using, for example, CSSSelectors combined with ElementIDs, classNames, href attributes and many other DOM elements attributes. Yes, we can still use those techniques to implement some tags but it’s far from a successful implementation.
Why not use ElementIDs, classNames, hrefs (elements Attributes)?
Some Element Attributes, for example the ElementIDs, can be helpful in pointing to the right element; they are pretty similar to the custom HTML5 data elements. They are also pretty specific and can point to the right element in the right page.
However…
IDs are very specific:
An ElementID is specific, but maybe too specific for a something like a registration button. For different versions of the website, you will have to make the same tag again and again because the ID is different while the button is the same, it just sits on a different place on the page or on another page. But when it comes to the business logic we know that it does the same thing.
Below is an example where an ID is different, but the action is the same: it’s a link to the “/web/link/signin”.
To respond to the question “who clicks on the Sign In button?” we would need to make many tags for the same thing.
When you need them, IDs often don’t exist: 95% of the page elements do not have an element ID.
There is no “Business/Analytics” context:
It’s always better to have some context around what you are tagging, even when it’s an ID. Many developers do not employ this good habit or – they have their own context that usually does not match our Digital Analytics context.
Imagine you have these kind of IDs on your website, and you need to make a change to a listener for all those fields.
Did you get tired from typing this in your Tag Management System listeners? Even when using the copy/paste?
Using IDs (example using the Signal TMS):
Now, using HTML5 Data elements, look to the context and readability:
ElementID are “third party tags”:
Conducting a digital analytics implementation based on the element IDs is like building a castle on top of your neighbors foundation. IDs are used by developers and developers often change them for a lot of unknown reasons. At least when you are using HTML5 data elements you know your implementation is safe. This is key to a robust implementation.
Here is an example of how you can add an HTML5 element (data-da-event) to a registration link, then through your TMS, point to the good element using a CSS Selector, as follows:
You’ll still need to use Analytics Tags, however, and this solution can be full of unpleasant surprises.
The best solution — a combination of HTML5 Custom Data Attributes (data-*) and a data layer — will not just help you avoid implementation surprises, it will give you critical Governance and Data/Tag quality.
There are a lot of tempting tweaks and hacks out there, but most are short term fixes and when it comes to your organization’s valuable digital data, why mess around? The data asset justifies taking a longer term view that ensures high quality and consistent data that members of your organization can trust and rely upon to make business critical decisions.
Useful Resources:
- Custom HTML5 data compatibility (97%!): http://caniuse.com/#feat=dataset
- data Layer: http://www.w3.org/2013/12/ceddl-201312.pdf
