Yeah, that’s a mouthful — and often the reason why discussions about data layers go awry. Everyone seems to define data layers slightly differently, and this can make discussing them even more challenging.
“In short, a data layer is code that allows you to know the details of the page as well as information about the visitor.”
In short, a data layer is code that allows you to know the details of the page as well as information about the visitor. It allows your developer to have easier access to accurate values. Below is an example of what a data layer might look like on a clothing retail site:
Every third-party analytics and marketing tool vendor has a different way of sending and collecting data, as well as different expectations on when and where their tags should be placed. There are a plethora of ways for your developer to get access to your site’s data, and each system and developer will likely do it somewhat differently. With a data layer as part of your digital analytics implementation, your team gets to decide which values should be applied, instead of hoping your developer grabs the correct values for you through other means.
Why Do You Need a Data Layer
The reason every site should have a data layer, is that it provides a level of reliability and flexibility that other options do not offer when surfacing data about your site and its visitors.
Increased Data Reliability
There are two primary methods most companies use to collect data into analytics and marketing tools: data layers and DOM scraping. Implementing a data layer takes time up front, but provides a reliable method for your team to control data values that are being captured into reports. DOM scraping involves looking at your page’s HTML attributes and copying data for reporting from their values.
For example, you may set your page name to the title of your page that displays in the browser title bar, or to some version of the URL. You could look for a breadcrumb to capture page hierarchy or site sections. You could listen for a button click in order to capture a separate action that occurs on your page. In essence, you can rely on what your web developers built to track the majority of your data.
“The primary beauty of using DOM scraping is that it allows you a great amount of flexibility in tracking as you do not have to get IT involved for many changes…However, with this flexibility also comes a great amount of unreliability”
You can tell your developer to collect the article name from all content pages and pass it into a certain report. Without a data layer, how they choose to obtain that value can cause inconsistencies in your reports. They might get different versions of the article name due to using different letter cases on the page, or the name may change slightly due to your marketing team deciding some other version made your content clearer. Every time your SEO team wants to change the URL to improve search results, or modify the HTML on a page to better align the content visually, you are at risk of your data failing to be captured accurately, or at all. This means that you are more likely to have gaps in your data, or worse, unknown breakages that no one realizes have occurred and cannot be fixed until a development resource can be obtained to hunt down the issue and fix it.
If you use a data layer, you greatly decrease the chances of site changes breaking your analytics reports by accident. Your analytics reports become more reliable, restoring trust in your data and giving you the ability to make data-driven business decisions.
How Does a Data Layer Provide Flexibility?
This is all fine and good until your marketing team decides that they want to switch to Google Analytics or Mixpanel. What’s the problem? You should just be able to send the same data to another vendor, right? It sounds easy, but it can become a complete nightmare if your current web analytics implementation is not built in an agnostic manner, allowing you to easily switch providers.
Using a data layer for your web analytics implementation adds flexibility because it allows your developers to write vendor-agnostic code. Agnostic code is built generically, and the goal is to have no direct ties to a specific third-party vendor. If you work in an environment where you expect to consider competing vendor technologies, versus your current choices, then you are almost certainly going to enjoy the level of flexibility provided by a data layer.
Planning Your Data Layer Architecture
As you can see, a well-built and maintained data layer can save you a lot of heartbreak and loss in the future. It is key that you work with your development team at the beginning to make sure you architect the best solution for the data you want to collect. A poorly envisioned data layer can cause many issues down the road.
“…a well-built and maintained data layer can save you a lot of heartbreak and loss in the future.”
It is important to plan out what you want to collect and how that data will be built and maintained in the future. You want a fairly simple way to modify these values because there will come a time when you need to add new pages/URLs, or modify values due to changes in your goals or business plans. A robust data layer will allow you the freedom to make these changes later on without having to restructure your data layer architecture every time.
Implementing a Data Layer is Worth the Time and Effort
Data layers take time to plan and implement. It is a large, front-loaded effort, but I promise it is well worth the time you and your company will invest. It will take time to create a schema that you agree on, and after deciding on your data layer architecture, the development team will need to decide how to populate a data layer on every page with those values.
It is common for this to take 1-2 weeks to plan and then 2-4 weeks to implement. This is what we see on average for planning, but it depends greatly on the complexity of your platform and the availability of your development team.
Blast’s Data Layer Recommendation
We believe that all companies that would like to accurately capture data should be doing so with a data layer.
The benefits far outweigh the initial costs. We recommend that you implement a data layer that is dynamically built on every page. We also recommend that you use events to trigger any tracking of interactions that occur after the initial page load, instead of relying on DOM scraping. You can learn more about an Event Driven Data Layer on Jim Gordon’s Blog. He does a great job of explaining the benefits of an EDDL and outlines the implementation steps.
Plan For the Future: Increase Reliability, Decrease Difficulty
There are several key reasons why you need a data layer on your site. Ultimately, you should choose to have a data layer integrated into your web analytics implementation because it will increase the reliability of your data and decrease the level of effort to maintain and modify your implementation in the future. Increasing data accuracy while reducing future costs is always a good thing.
Originally posted by Jason Case.
If you enjoyed reading this article, you might find this post interesting too.
Digital analytics, optimisation, data science or programmatic expert, and looking for a job?
Check out our latest live vacancies here
Digital agency looking to expand your team with top-tier talent?
Send us your jobs here
Get in contact with us!