🥳 You have completed all topics in the Handbook. Click here to claim your certificate!

Technical Marketing Handbook

3. The Data Layer

The Data Layer is a globally accessible construct on the web page, which is designed to store data that can be utilized by a tag management system (TMS).
  • 8 min read

As soon as you start working with a tag management system, you’ll inevitably confront the term Data Layer.

It’s a difficult concept to pin down. But as a technical marketer, it’s one of the key instruments to understand if you want to manage the tags and marketing scripts running on a web page more efficiently.

There are many definitions of the Data Layer, so it’s perhaps easier to focus on what it’s not and what problems it solves.

Think of a web page as comprising layers. 

The presentation layer is what the user sees and interacts with. It typically includes mainly HTML (the content) and CSS (the styles). 

The business logic (or experiential) layer is what governs the user experience of the web page.

Example

For example, button clicks, form input fields, content accordion toggles, videos, etc. would be controlled by the business logic layer. The language of this layer is predominantly JavaScript, although there are many things in HTML and CSS that can control the page experience, too.

And then you have the Data Layer. It’s not as clearly defined as the previous two layers, as its main utility is in the niche realm of marketing technologies. The reason it’s separated from the other two layers is that it’s not supposed to be involved with the presentation or the business logic of the web page.

The purpose of the Data Layer is to be a single, well-known structure on the web page that can be utilized for passing information to and from marketing technology tools, especially tag management systems (TMS).

Example

Instead of the TMS having to scrape e-commerce data from the presentation layer, such as when the user is shown a “Thank You” page with a receipt, the same information could be duplicated in the Data Layer by the site developers.

The TMS can then access this information without having to worry about changes in the presentation or business logic layers messing up the data collection.

The Data Layer and the TMS

Many TMS are built with a certain type of Data Layer in mind.

Two common approaches are a set Data Layer object and an event-driven Data Layer, with the latter more popular than the former.

The main purpose of the Data Layer is to allow the site and the TMS to pass information from one to the other.

For example, here is a fairly typical page initialization Data Layer that is added to the page HTML template before the TMS is loaded:

// Initialize the Data Layer
window.dataLayer = window.dataLayer || [];

// Add the page initialization metadata to the Data Layer
window.dataLayer.push({
  event: 'pageInit',
  page: {
    url: 'https://www.teamsimmer.com/',
    title: 'Online courses in technical marketing',
    id: 'lp1_a'
  },
  user: {
    loginStatus: true,
    id: '91e41dee-2b33-4705-bdd5-b0abc5509a09'
  },
  environment: {
    type: 'live',
    dlGenerated: 1683955875477
  }
});

The key-value pairs (for example event: 'pageInit') that are added to the Data Layer are then consumed by the TMS, and they become available as some type of references within the TMS itself, for example as variables that tags can utilize.

The code example above is of an event-driven Data Layer, such as that used by Google Tag Manager.

The value of the event key ('pageInit' in this case) can be used by the TMS as a rule trigger. The TMS “listens” to these Data Layer interactions, and tags can be configured to fire when the 'pageInit' event is added to the Data Layer.

When the tag then fires, it can pull in the page.url and page.title keys, along with all the data nested in the user object. The environment.type value could be used to determine whether to collect the data to a “live” analytics tracker or to a “staging” or “test” tracker.

In summary, this single JavaScript dataLayer.push() call can not only fire tags but also populate them with data from the Data Layer. The event-driven Data Layer thus combines both the message transfer system and the triggering system into a single, operational logic.

The other type of Data Layer, a set Data Layer object, separates the two systems. With this approach, the Data Layer would be populated just as above, but the triggering logic would be operated with some other method unrelated to the Data Layer itself.

Ready for a quick break?

Take a short break – that’s what all your layers require to digest the information in this Topic.

Prescriptive vs. descriptive approaches

Since the Data Layer is all about collecting and forwarding data between two systems, adopting a naming convention is vital.

Having a predictable and well-documented approach to naming things in the Data Layer will prevent many issues down the line.

There is no agreed standard for how to name things in the Data Layer, so the type of schema to adopt mostly depends on the company doing the deployment. Their expertise and understanding of the various marketing technology integrations added to the site will determine the shape, size, and functionality of the Data Layer.

However, sometimes marketing technology vendors place specific requirements on not only the values in the Data Layer but also the general structure as well.

For example, one vendor might require a shopping cart to be represented like this:

items: [{
  item_id: 'shirt_123',
  item_name: 'My shirt',
  price: 10.00,
  quantity: 1
}]

Another vendor might require this:

contents: [{
  id: 'shirt_123',
  value: 10.00
}]

These represent the vendors offering a prescriptive schema for ordering things in the Data Layer. Their integrations can make use of the Data Layer directly if the contents are in this format.

The other approach is a descriptive one, where instead of complying with the vendor recommendations above, the Data Layer takes a more generic approach, such as this:

cart_items: [{
  sku: 'shirt_123',
  name: 'My shirt',
  price: 10.00,
  quantity: 1
}]

In this case, the final schema is somewhat similar to the vendors’ requirements but still different enough to not directly work with either. In this case, the TMS needs to include transformations (using variables) that take this item in the Data Layer and map it to the format required by each vendor.

Which approach you go with really depends on how important these integrations are to you. If almost all of your tags have to do with marketing vendors that all have the same prescriptive schema recommendation, the modeling the Data Layer after this might be a good idea.

Prescriptive approachDescriptive approach
Easier to deploy.More difficult to deploy.
More difficult to integrate other vendors.Easier to integrate other vendors.
Requires transformations for vendors who do not support this schema.Requires transformations for most if not all vendors.
Transformations might be more complicated because the starting point is skewed towards the schema vendor.Transformations are likely to be simpler because the starting point is a generic data structure.

However, the generic descriptive approach is often better. All TMS support transformations, and having a generic Data Layer that is not beholden to any specific vendor schema makes it easier to add additional tools and services as integrations later.

Following a single vendor’s schema too strictly might make it difficult to integrate other vendors whose platforms require the data to be in a vastly different format.

Key takeaway #1: Separate layer for semantic data

The Data Layer should be kept separate from the presentation and the business logic layers of the site. Its purpose is to store information that is not directly linked to the HTML elements or other functionality of the page. The contents of the Data Layer can certainly mirror the content on the page. For example, on a receipt page the Data Layer can repeat the information the user sees about their purchase. But the two layers are kept separate – changes in one should not affect the other.

Key takeaway #2: Event-driven Data Layer is the modern approach

The event-driven Data Layer, popularized by Google Tag Manager, is an approach where the Data Layer both includes the semantic information relevant to the page and the actions the user takes and instructs the TMS when to utilize this information to fire the tags. As new information is made available, it is added to the Data Layer event queue, where the TMS can then pull the data and act on it as it becomes available.

Key takeaway #3: Prescriptive vs. descriptive Data Layer

Some vendors integrate directly with the Data Layer to minimize the tagging overhead of setting up data collection in the TMS. In these cases, the vendors often prescribe a specific schema for the content in the Data Layer. While this makes it easier to work with the vendor, it does place additional overhead on getting the developers to follow the schema exactly rather than work with something more generic. A descriptive approach allows the tagging team to build the Data Layer in a generic way, and then use the TMS to map this data into the format each vendor requires.

Quiz: The Data Layer

Ready to test what you've learned? Dive into the quiz below!

1. What is the defining feature of an event-driven Data Layer?

2. How is the Data Layer related to other layers on the web page?

3. What is a prescriptive schema for the Data Layer?

Your score is

0%

What did you think about this topic?

Thanks for your feedback!
Next up
Data And Analytics

Unlock Premium Content

Simmer specializes in self-paced online courses for technical marketers. Take a look at our offering and enroll in one or more of our courses!

Enroll Now
  • Simmer® Exclusive
  • Task-based learning
  • Digital Certificate after completion
  • Helpful Community
  • Lifetime Access
Copyright © 2024 Simmer
Contact Us | Privacy Policy | Consent Settings
0/27 Topics completed

Good going!

Complete all topics to claim your certificate.

Next Chapter

Online course

Server-side Tagging In Google Tag Manager

Learn everything you need to know about server-side GTM in our flagship course!

Learn more