The Data Layer: What Is It and Why Do I Need One?

August 7, 2018 Jason Call

As Simo Ahava puts it: “Data Layer is two marketers short of becoming a buzzword.” The internet is riddled with assertions of increased efficiency and data standardization through the use of a data layer.

But what actually is a data layer, and why is everyone talking about it?

If the data layer is a new concept for you, then this post is here to help you understand the key technical components of implementing and applying the data layer.

By the end you should understand what a data layer is and how making an investment in a data layer can positively impact your data collection practices.

What You’re Doing if You Don’t Have a Data Layer

Ever seen this before?

There are 6,829 marketing technologies out there, and the number is constantly growing. Of course your company will never use all of them, but according to Netskope, in mid-2017 the average enterprise used 91 marketing cloud services, and that number has likely grown in 2018.

These technologies all need data, much of which is common across technologies, such as page name, page type, visitor ID, visitor state, traffic source and more.

Unfortunately, without a data layer, each marketing vendor is responsible for capturing its own data. With one or two marketing technologies, this may not be too hard to manage—but what about with 10 or 20?

Let’s dive a bit deeper.

Vendor-Specific Data Collection

Marketing technologies gather data through the use of tags.

Tags can either be hard-coded or deployed dynamically by a tag management system. On page load and in correspondence with user events, variables contained within the tags are populated with values, which trigger responses by the marketing technologies (e.g. initiating a remarketing campaign or gathering analytics data).

A vendor-specific tag will produce a collection of variables that looks something like this:


Source: Digital Data Layer Strategies presented by 33 Sticks

“So what?” you may ask.

Relying on vendor-specific data collection has its issues. Here are the problems with this method:

1. The naming conventions are not very intuitive. When you have multiple teams across business units trying to work with less-than-intuitive variable names, things can get lost, forgotten or broken.

2. These variables only apply to one vendor. That means you would need to have a process of variable declaration and population for each and every marketing technology. Repeating this process is redundant.

3. Each marketing technology will have slightly different definitions of user events. As a result, the data they collect may be inconsistent across your martech stack.

4. Deploying 10 times the code will slow down your website. “A one second delay in page response can result in a 7% reduction in conversions” (Source: Kissmetrics).

Data Layer to the Rescue

Data Evangelist Justin Cutroni concisely explained the data layer as follows:

“A data layer is a JavaScript variable or object that holds all the information you want to collect in some other tool, like a web analytics tool.”

Isn’t that nice? A data layer expedites the data collection process by gathering data into one central location and then redistributing it to your various marketing technologies.

var dataLayer = {
“pageTitle” : “Receipt Page”,
“pageURL” : “/pages/checkout/receipt”, 
“pageCat” : “Checkout Pages”,
“PageCat2” : “”,
“tranID” : “17658726382”,
“tranTotal” : “34.95”,
“tranTax” : “0.00”,
“tranShipping” : “0.00”,
“tranShippingMethod” : “USPS”,
“tranCurrency” : “USD”,
“tranProds” : “249|398”,
“tranSKUs” : “249-32|398-12”,
“tranProdNames” : “Kids Onsie|Kids Lava Lamp”, 
“tranCategories” : “Kids|Kids”, 
“tranPayMethod” : “VISA”,
“visitorType” : “RETURN”,
“visitorState” : “Logged In”, 
“visitorFirstPurchDate” : “20111205”, 
“visitorFirstProds” : “822”

Source: Make Analytics Better with Tag Management and a Data Layer by Justin Cutroni

A Simple Data Layer

Remember what a vendor-specific tag would look like?


Now, compare the following data layer object:

            ‘pageCategory : Shop’,
            ‘categoryType : Holiday’,
            ‘memberStatus : Guest’

“How is this better?” you may ask. Let me show you.

1. The key-value pairs within the data layer are strings with intuitive labels. This means less confusion among developers and across business units.

2. The variables are vendor-agnostic. You only have to deploy this once, and then delineate within your third-party tool which variable corresponds with each metric. You might think to yourself, “Well this is just reversing the process! Instead of writing 10 different codes on 1 site, I have to configure 10 tools to match my 1 code.” That’s true, but consider this:

a. The data layer puts you in control, allowing you to work with intuitive naming conventions without having to learn vendor-specific coding.

b. If you use a tag management solution, you can configure all of those technologies within the TMS itself.

3. Using a data layer allows you to standardize data definitions, because data is only gathered once.

4. Now you have 1 code instance instead of 10, which means you have a faster website.

So what’s the ultimate result?

1. Increased data quality

2. An enhanced customer experience

3. Increased operational efficiency

Need I say more?

Populating Data Layer Variables and Values

Why Implement a Data Layer

One of the key arguments in favor of implementing a data layer is the way in which its values are populated, which allows you to 1) standardize data collection practices, and 2) avoid using DOM-scraping.

DOM-scraping is a method in which marketing tags collect values from the Document Object Model (DOM)—the

HTML structure—using Javascript selectors (tag name, ids and classes).

For example, a marketing tag could use Javascript or jQuery to pull the value from a form field and assign it to a variable:


       <input id=’form-field’/>


        s.pageName = document.getElementByID(‘form-field’).value;

Eliminate DOM-Scraping

DOM-scraping can be handy, because as long as a website’s HTML elements are well identified, values can be easily gathered from a page with some basic knowledge of Javascript.

But DOM-scraping is also problematic. If website structure changes due to a redesign or new release, analytics script that relies on Javascript selectors for DOM-scraping may no longer be able to pull the correct values into your variables.

Enter the data layer. The data layer’s centralized data is built separately from the DOM, using a combination of three methods:

1. Hard-coding variable values. Variables and values that don’t need to be dynamic can be hard-coded into the data layer.

2. Back-end variable population. When using a template-based CMS, values can be pushed from the CMS database into the data layer as the page is being built.

3. Front-end variable population. Using event listeners like onclick within HTML tags allows you to push values into the data layer when an event occurs:

<button id='button1' onclick='dataLayer.push({'event': 'button1-click'})' />

*Note: Front-end variable population may just seem like DOM-scraping in reverse, pushing data instead of scraping data. But as long as your company establishes protocol around pushing events into the data layer, the marketing technologies will always have the data they need.

Implementing a Data Layer Checklist

Below are some basic milestones that will need to be discussed among the developers, marketers and other stakeholders:

  • Decide on data layer structure and naming conventions (see blog post). 
  • Develop and deploy code to populate the key-value pairs.

a. Hard-code 

b. Back-end 

c. Front-end

  • Remove the vendor-specific code from your website pages, templates or header.
  • Update variable documentation, mapping your data layer elements to business/vendor requirements.
  • Perform regular audits for data layer quality assurance.

To learn more specifics about implementing a data layer using PHP check out the on-demand webinar “Best Practices for Building a Dynamic Data Layer” by Mike Plant and Jason Call.

ObservePoint and the Data Layer

ObservePoint is dedicated to ensuring that every facet of your web and mobile properties is functioning properly.

ObservePoint automatically validates and monitors analytics and digital marketing tags across websites and apps, helping enterprises be more efficient and confident in their data-driven decisions. Our platform can even be used to double-check that your data layer is properly formatted and loading.

You’ve made a large investment in martech. Don’t you want to make sure that it’s all working correctly? With ObservePoint you can shave down on QA time, and rest assured that the data you have is reliable.

To learn more about how to use ObservePoint to validate your data layer, check out the on-demand webinar “Best Practices for Building a Dynamic Data Layer” by Mike Plant and Jason Call.

About the Author

Jason Call

Jason caught the “digital marketing bug” over ten years ago when his music went viral, and he became the first unsigned artist to reach a million downloads on the internet. Since then, he has devoted his career to mastering analytics and providing actionable insights for hundreds of clients, spanning many industries and verticals.

LinkedIn More Content by Jason Call
Previous Article
Happy Birthday, UTM Methodology
Happy Birthday, UTM Methodology

Today’s UTM methodology—methodology you rely on every day to receive all touchpoint data—is over 20 years o...

Next Article
Why the Data Attribution Ecosystem Is Broken and How to Fix It
Why the Data Attribution Ecosystem Is Broken and How to Fix It

The status quo of data attribution currently looks like that mass of cords living in your basement that nee...

Get a Custom Pre-Recorded Audit