Why You Need a Data Layer for Web Analytics Implementation Success

July 10, 2019Jason Case

I’m often asked about data layers for web analytics implementations. Clients want to know what a data layer is and how they can build one, but the discussion gets muddy when they bring in their IT / development teams. During this step I usually hear, “Why does my development team recoil when I bring up the idea of building a data layer, and how can I convince them to buy in?”

The question that is often not addressed early on in the discussion, and the one that is key to getting buy-in, is: What is a data layer, and why do I need one?

Let’s dive in!

What Is a Data Layer

A data layer is a JavaScript data structure (typically an object or an array of objects) within the website rendered code that, ideally, holds all of the data you want to process and pass from your website (or other digital platform) to other applications or reporting tools.

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.” Click & Tweet!

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. You can write fancy javascript code that finds information on the page and allows it to be sent to a third-party tool. However, with this flexibility also comes a great amount of unreliability. This is due to the DOM values constantly being in flux by web developers changing the site and not always following a strict naming practice, and marketers making their own changes to get the best SEO results.

“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” Click & Tweet!

Let’s say you want to collect the order transaction data and send it to Google Analytics. If you use DOM scraping, you’ll end up writing javascript that looks through the order confirmation page to find the order total, products purchased, product SKUs, etc. What happens when you redesign your order confirmation page? Did you stop collecting data in Google Analytics? This is one of the biggest drawbacks of relying on parsing the page to locate the data you need instead of having a data layer in place. If you had the data layer in place, it is independent of the design and layout of the page and thus would allow you to continue sending reliable data to Google Analytics during this page redesign.

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?

Let’s say you are a current Adobe Analytics user. Without a data layer, your development team will often place JavaScript directly into the page or tag management system that searches for HTML elements it can use to populate reports such as page names, channels, or article titles. (Note: Each of these snippets of JavaScript together add a large amount of size and weight to your page code which will ultimately slow down your page load speed.) If you decide to populate a report with the name of the author for an article page then your developer can easily add another snippet of JavaScript that finds this value and passes it to Adobe Analytics. This seems fairly simple, right?

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.” Click & Tweet!

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.

Please feel free to reach out, or comment below, with any data layer related questions. I’m happy to help!

About the Author

Jason Case

As Director of Analytics Implementation at Blast, Jason leverages his vast experience in web analytics and software development to mentor and lead a team of problem-solving savants. Jason has spent the last 10 years finding creative answers to complex questions utilizing Adobe Analytics and various development languages along the way. As a certified expert in Adobe Analytics for development, business, and architecture and an expert in Javascript Jason is able to understand clients’ pain points and produce creative technical solutions. His solutions resolve current issues and enable easier success in the future — by helping them make data-driven decisions, improve processes, and EVOLVE their organizations.

Connect with Jason on LinkedIn. Jason Case has written 2 posts on the Blast Digital Customer Experience and Analytics Blog.