A few years ago when Tealium first began recommending data layer implementations to its clients, there was a little bit of uncertainty. Would marketing teams be able to convince IT that it was worth the effort to put a data layer on the web page?
A data layer is a standardized way of exposing uniform data on a website for collection and distribution to technology providers that support your online initiatives. Combined with a tag management system, it simplifies the communication process between a website and services vendors by providing a translation layer to those who may define that data in their own terms.
While a data layer can add a bit of effort upfront, it will save everyone a lot of time and headache in the long run, especially because measurement is no longer dependent on site design. We at Tealium have always recognized and advocated that a properly-defined data layer would create an important data foundation for organizations, so we’re happy to see that the World Wide Web Consortium (W3C) agrees and is now promoting a standard data layer definition. Today, we see many new Tealium clients who already have a data layer in place.
In addition, it’s refreshing to see that many leading consultancies are now also advocating the addition of a data layer and providing advice on getting it right. However, as we have seen through the years, there are many different techniques for building a data layer. For this reason, Tealium supports any data layer structure.
If you’re thinking of building a data layer for your organization, here are a few best practices, general insights and advice to consider based on our own experience:
Laying the groundwork here, what is the goal of your data layer?
The goal of the data layer is to take something from your CMS or e-commerce engine and put it in the page source for JavaScript (JS) to use. Typically that “something” is the products being viewed or purchased and all the information you have about those products or pages being visited.
What is JavaScript going to do with that data layer?
The tag management system (TMS) will take that data layer, massage it and run your tag vendor library code in the browser. For example, the data layer is used to build the products variable for Adobe SiteCatalyst.
How can you make your data layer robust, error free and easy to implement?
As with any coding exercise, keep it as simple as possible. Choose good variable names that make sense to anyone who will look at it at some point in the future.
How to keep it simple
The first simplification is to keep the structure “flat.” Tealium recommends a flat data object that is one layer deep. A flat data layer enables quick access to your data without having to write code to get to it (i.e. looping). There is also no chance to cause JS exceptions when looking for a child data item when the parent object isn’t there. Your data layer is just an object of name/value pairs. These name/value pairs will be sent to your tag vendors. Don’t try to make it anything more than it needs to be.
Sample of simple flat structure
var utag_data = {
page_name : “home”,
page_type : “content”,
page_level : “level-1”
}
Sample of more complex multi-level structure
var other_data = {
page : {
name : “home”,
attributes : {
type : “content”,
level : “level-1”
}
}
}
In this example, if you try to reference “other_data.page.attributes.level” in your code, you have to check to make sure your other_data.page object has “attributes” object in there. It might not. If you reference “utag_data.page_level,“ you may get “undefined,” but you won’t get an exception that you’re referencing a child of a parent that doesn’t exist.
It’s also unclear when you’re writing your code where to get data. Is the value you’re looking for going to be under the “page” object or under the “attributes” object? Keeping it simple ensures that your development doesn’t deviate from the standard.
The second simplification is to just narrow things down to a few data types. You should only need to use arrays and strings to accomplish what you need.
Tealium recommends the use of strings and arrays. Specifically, if you use arrays, be sure to use arrays of strings. Why? Because if someone asks, “should I use ‘19.99’ for my price or 19.99 for my price?”, the answer is what you told them already, which is to always use strings in all cases. Most likely, you’re not actually doing any math on these values, you’re just passing them along to your tags as-is. In addition, let’s say that someone accidentally puts in a “$” or a “,” in your price value. Will your data layer break? Not if it is contained in quotes. For example:
// ideal price : [“19.99”]
// not ideal, but a good TMS can still work with this price : [“$19.99”]
// this won’t work at all – a syntax error price : [$19.99]
For you seasoned JS coders out there, you’re probably familiar with Doug Crockford, a notable programmer who popularized the JSON data format based on JavaScript. Some of his recommendations can seem a bit strange to someone who considers themselves an experienced developer, but his goal is to build some rules to help the inexperienced coders write something that won’t get them into trouble later. This is the essence of the recommendation here.
Use a consistent naming convention
Which convention? You might save yourself a few bugs if you go with “lowercase” and “underscores.” For example, let’s say you standardize on “Camel Casing” – most likely you’ll have some who will go with “productID” (upper-case “D”) and others who go with “productId” (lower-case “d.”). I recommend always using lower case with underscores so it always will be “product_id” and there is no question about it. There is no room for interpretation with this standard. Also, for the non-technical audience, this convention is more readable.
You want to empower the marketing team to be able to help troubleshoot the data layer. Keeping it simple and readable (“flat”) will do that. You also want to make the data easily accessible, which is also accomplished with the flat structure. Lastly, you want a data layer that is easy to maintain, not open to interpretation or containing confusing standards – using strings and an all lower-case naming convention will help
Of course, you may be thinking that you like W3C’s way of doing things. The W3C standard works too. Tealium has an extension to flatten it for you and make it easier to use. Ultimately, the main thing you get is a standard. That alone could be a good enough argument to follow it.
Ultimately, a standard data layer is going to make everyone’s life much easier. Having a standard that makes it simple for all stakeholders is going to provide the most value for all involved.
