TMS Best Practices: Get the Data Layer Right

Over the past year or so, I’ve had the opportunity to see some “do’s” and “dont’s” when implementing a tag management system. I thought today I’d share some thoughts on the most important item on the “do” list: Every good TMS implementation I’ve seen is supported by a carefully planned, well-documented data layer.

The initial sales pitch used by the various vendors – and by marketing folks to their IT departments – is often that a TMS will solve all their problems. Among other things, a TMS can do the following:

• See any piece of data in the DOM
• Bind to any DOM event
• Replace all your tags with a single tag

Companies often assume that these three things mean you’ll never need to engage your development team again. While a good tag management implementation will definitely make the lives of marketing and IT folks easier, this just isn’t true. And if you try to make it true by relying exclusively on what you can see on the page and in the DOM, you’re likely to give yourself major headaches at some point – because what you can see changes way more often than anyone realizes.

Developers are notorious (I speak from experience) for looking for ways to simplify code, make it more semantical, and remove things they think are no longer needed. In almost all cases, this is a good thing. But what is no longer needed for a functioning web application may still be mission-critical to your web analytics implementation. Consider the following code snippet:

Lets say you log into your TMS of choice, and you set up your add-to-cart tracking in the following way:

• Attach an on click handler to all links with class “add”.
• Find the parent <div> and use its “data-id” attribute as the product ID.
• Grab the nearest <span> with class “price”, remove the first character (dollar sign), and treat that value as the current price.
• Track an “add-to-cart” event.

That’s exactly what you bought a TMS for, right? To make your life easier – and boy, was it easy to set up that tracking for your new cart add functionality. But how quickly it can all go wrong:

1. What if your developer decides to change the markup for price, to separate the price from the currency. Now, according to your analytics data, your new price for this item is “.99”. Ouch!
2. Next, your developer decides that “data-id” is a poor name for your product IDs, because all your IDs start with “SKU-“. Wouldn’t it be better to use “data-sku” instead? Now you’re tracking cart adds, but not cart adds by product ID.
3. Finally, your development team loves HTML5, and they decide that <article> is more semantically correct than <div>. But your tracking depended on a CSS selector of “div.product”. At this point, your tracking is completely broken.

These are just a few reasons that I strongly recommend that my clients to create a data layer – that is, a catalog or dictionary for all the data points used by all your third-party tags. Your data layer should primarily be made up of a single JavaScript data object, and depending on the vendor you choose, this may be required.. But even if your tool doesn’t require it, you should do it anyway. A data object is a logical, semantical, code-based representation of all the key information we might want to know about a page when it loads:

• The page’s name
• Site-related information (site name, country and language)
• Visitor-related information (login ID, logged in or out)
• Any events taking place as part of the user loading the page (product view, internal search, etc.)
• If an e-commerce site, any product-related information (the product being viewed, all products in the cart, etc.)
• Any other information that might be required or useful to track the page via your analytics tool or any other third-party tags

In code, your data layer may end up looking something like this:

Having a good data layer in place makes your life much easier when using your TMS to implement your tags. You’re left with a simple mapping exercise to make sure that all the right data points end up going to the right tags, rather than having to use Firebug to find every possible piece of data you may want in the DOM, and then write code to access it correctly.

Let me leave you with 10 tips to build a data layer that works for you (and not the other way around):

1. Most importantly, document it. Create a shared, central document that shows each item in your data layer, how it is set, how it can be retrieved, and which tags use it.
2. Use a dedicated data object. In some cases, you may still rely on query parameters, cookies, or the DOM, but you should have high confidence these values won’t change. Having all your data in one place makes it less likely that a code change will ruin your data.
3. Make your data layer as granular as possible. For example, your page name may combine country, language, and a friendly page name. Separate those into 3 unique elements in your data object, and then use your TMS to combine them together. This preserves your flexibility if you ever change your mind.
4. Use terminology that makes sense to your organization. If you use the term “order ID”, you shouldn’t care that SiteCatalyst calls it “purchaseID” or DoubleClick calls it “ord”. Your TMS will take care of that.
5. Don’t overload or overcomplicate. If an element isn’t used on a page, either don’t include it in the data object for that page, or set it to an empty string. Values like “null” can cause problems in your code and yield strange values in your reports.
6. Use string representations of “true” and “false” rather than booleans. This might drive your developers crazy, but it’s much easier to check for certain strings than booleans in JavaScript (while very cool, the difference between “==” and “===” in JavaScript isn’t the easiest concept for non-developers to understand).
7. Consider setting numeric values like prices to strings. This may require some extra code in the event that calculations are necessary, but you’ll have fewer times when you need to calculate than when you’ll want actual strings, so it’s easier just to stay consistent.
8. Understand the trade-offs between using nested objects and arrays. For example, your developer might prefer an array of product objects to represent your shopping cart, but your TMS vendor may prefer several arrays of each product attribute (one for IDs, one for names, etc.). A single array of objects may be more semantically correct, but it’s much faster to loop through several arrays that have all their items in the same order. Your tool may make this decision for you – but know why you’ve chosen the approach you have.
9. Don’t be afraid of quick fixes – but don’t be afraid to “fix your fixes”, either. Sometimes you’ll be in a hurry and might need to rely on DOM manipulation or quick fixes for your tracking. Make sure these are clearly documented, and work to move that data into the data object as quickly as possible.
10. Hold everyone in your organization accountable. Make sure your data layer stays accurate over time, and that it remains the single source of truth for all your tags. If your data layer is accurate, your data will be accurate, too.

Getting your data layer right is the most important thing you’ll do when implementing your TMS. It’s what allows your development team to be website experts, without needing to be experts in every tag you might use. But it also forces marketers adhere to the centralization that was likely a key reason IT went along with the TMS in the first place. So get your data layer right – and keep everyone happy, all the way around!