How to create a Data layer

If you are working with Google Tag Manager, Adobes DTM (Dynamic Tag Manager), Tealium or any other tag management vendor, you will always feel like you have unlimited powers when it comes to deploying tags. A classic scenario is when someone from the marketing department sends you an e-mail and want you to implement a third party tracking pixel… and by the way, the campaign went live two days ago, so it´s urgent.

After you have double face-palmed a couple of times, you show the marketing department the strengths of a tag manager and deploy the pixel within 5 minutes and everyone is happy. But a few days after launch someone decides to move the confirmation page to another url, and the tracking pixel is now firing off at the wrong page.

facepalm

But how do you ensure that scenarios like these don’t occur every second week because there is a lack of communication between the departments or people are just too busy to remember the importance of data collection.

Well, it all comes down to one thing, re-think data collection with your CMS.

Many Tag management vendors all have their own data layer models, which basically do the same, with one single twist, they are tweaked for functions for the specific Tag Manager, which makes sense. If you look at Google, they have a function called “dataLayer.push”, which is commonly used for event triggers and AJAX applications. The same goes for DTM, here you have the “_satellite.track()” function to do the same.

But what if you think like me? Building a future proof data structure for your web applications should not be a vendor specific standard, it should be a universal standard that should be easy to use and easy for your developers to understand.

The good news are that there is a industry standard for a data layer it is present in form of a “W3C data layer” which Google, Adobe, Tealium, IBM etc. have been deeply involved in creating. The bad news are that not many companies or developers know of the W3C data layer or dare to go down that path, simply because they haven´t tried it before and don’t wan’t to live with the potential risk of not having done it the way the vendor specifies in the documentation.

If you already have a data layer in place, it is more than likely that you are not going to get involved in re-implementing the data layer with new variable names, which also makes sense, this post is addressed to people that are looking for implementing a solution from scratch.

A really good reason to use the W3C data layer is solely because of the extensive documentation of the object (data layer) and which convention needs to be used for the object that the developers needs to code. This makes it easier for the IT department to know what needs to be done and you don´t need to build up your own naming convention for every single parameter that needs to be sent.

Often when I speak to clients, they get the idea of the data layer, but they also see the challenges right after. In large corporations, it is not simple to have 12 different platforms coded entirely different and at the same time have them reference to the same type of object and define everything equally. I challenge that and say that it is possible, it´s just a matter of taking one small step at the time. Let me give you an example:

Every web analytics tool needs to collect a page name that is unique for the page. And to be honest, there is not anything more annoying than page names not being consistent in your data collection.

So the solution here could be to introduce a javascript object, in this case referred to as a data layer. Even if you don´t have a Tag Manager, this solution will be ideal to work with, because you are about to bring consistency into your data collection. So how does the data layer look like?

Well, first of all. It is important to look at your website structure and get a good understanding of how things are structured. Many CMS systems have a tree structure that is usefull. It is really rare that someone decides to switch the entire site structure, so it would be ideal if the page data layer had a reference to the CMS tree function, so that you as a developer don´t need to think about naming convention each time someone builds a new page. The only thing you need to focus on is the page convention that should be used. I mostly use pipes as separators ( | ) or forward slash ( / )

Here is a simple example of the data layer that you could start building today:

var digitalData = {

page:{

pageInfo:{

pageName: “consumer | products |car manufacturer 1”,

destinationURL: “http://mysite.com/products/carmanufacturer1.html”},

};

The information above is an example of a simple data layer where only the page name is being set with the url of the web page.

Ask your IT department to implement a structure that is somehow similar and only that information needs to be present, nothing more, nothing less.

If you are more interested in getting some more information about the W3C data layer you can always get more information through this link:W3C data layer documentation (official)