“Data Layer” Tips

I’d like you to read an article written by Josh West about TMS Best Practices: Get the Data Layer Right, in which he makes a case for having a dedicated mechanism for surfacing data (the “data layer”). Go ahead, I’ll wait.

Back?

I like this quote:

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.

Josh writes “in almost all cases”, when we all know that he means “always”, of course.

10 Tips for building a Data Layer

The “Data Layer” as Josh describes it is a single Javascript object sitting on every page that holds meta information such as page name, language of page and other page- & site-related data. It also holds customer meta data, such as customer ID or whether the visitor is currently logged in or not. Product-related and any other valuable data also sits in the object.

Now I think this is very good practice, whether you use a TMS or not.

Of the 10 tips Josh lists, I’d like to highlight these:

“1. Most importantly, document it” — this is indeed the most important part of it. I wouldn’t even call it a tip, it’s a necessity!

For your friendly marketer, documenting the data layer means they need to be explicit, which helps them understand what they’re doing. For you, the developer, documentation helps you understand what data you get. It also helps you make sure you are not taking any shortcuts.

If you build a data layer, and you do one thing, do this! Document!

“4. Use terminology that makes sense to your organization” — being a developer, I trust I can say that you can cope with abstraction and you know that there’s a difference between the name of a variable and the value in it. That makes me think that you will be able to understand the nomenclature that your friendly marketer or other business users use much more easily than the other way round.

Let them have it their way, it makes life so much easier.

“3. Make your data layer as granular as possible” & “5. Don’t overload or overcomplicate” — those two are hard.

Finding the right balance here will take time and effort. It will also take a lot of communication with your friendly marketer or other stake holders.

This sounds like one of those “*sigh* … more paper work coming up” things. But I think all of those 4 points I mentioned here have one big thing in common, and it is this one big thing that will make or break your efforts: explicit simplicity.

What I really like about the data layer idea is that it formalises what data is being made available. This helps everyone, from the users of that data (web analytics and others) all the way to the back-end developers.

Think about it: you’ll have documentation that will help you both up- and down-stream! How good is that?

Data Layer & Context Data Variables

The next great thing with a data layer is that even without a tag management system, it will make your life a lot easier!

Remember Context Data Variables & Processing Rules?

If you build a data layer that essentially is a Javascript object, it is easy to add a method exportIntoContextDataVariables() to it that takes all the data and assigns it into Context Data Variables.

You could even build your data layer so that it is made of Context Data Variables.

Do that properly and your page code will essentially be three lines: one that loads the s_code.js file, one that assigns your data to s.contextData and one that calls s.t().

Don’t forget that doing so puts the responsibility into the hand of your friendly marketer. They have to put Processing Rules into place and make sure data gets tracked properly. That might or might not be a good thing.