Data Layers for Dummies…

A data layer is becoming a key component of implementing marketing technologies. They are coupled with the rise of tag management solutions (TMS) and allow for much easier, more reliable and rapid deployment of third party tags (marketing or otherwise) onto a site. This blog will explain at a high level what a data layer is, it’s purpose and benefits to an online organisation.

First off, there are many types of data layer out there, but for the sake of this explanatory blog I will focus on data layers used to facilitate the implementation of marketing technologies, such as analytics and ad serving tags. In the world of online marketing, these are the most common, and probably the most simple, so a good place to start.

At the most basic level, a data layer is a repository of data that loads as part of the HTML of the webpage. Most commonly for marketing technologies, data layers tend to be written in Javascript, which is what our examples will focus on. The data layer contains all the data needed by the different marketing tools that an organisation uses. For example, on a ecommerce thank you page, tools such as analytics or marketing tags will need ecommerce information such as product name, unit price, quantity etc. so that the relevant reports can be populated or attribution assigned. A data layer will contain all of this information in a centralised place which will be available for all these tools to use.

Before the widespread adoption of TMS’s and data layers, data required for marketing tags would often be scraped from the page HTML, and coded separately into each tag. If the page HTML changes at any point – which is inevitable for all websites – then all the tags that use HTML elements that have since changed must be updated, which is both time consuming and prone to error. On the other hand, a data layer is (usually) populated by the backend system so even if the page changes the data will remain constant. In this respect, marketing tags will be feeding from this centralised abstracted data layer rather than relying on scraping the HTML meaning the data is more robust and reliable.

In the following example, product and price information is outputted to the data layer.

Data Layer example


Data layers and tag management systems:

In the realm of marketing technology, data layers were introduced as part of the adoption of TMS’s. In brief, a TMS is a technology through which other third tags can be deployed to a web page. The TMS script is implemented on the page and then inserts the other tags based on rules you define within the TMS. For this reason it is often known as a container, or container tag. The ability to deploy multiple tags quickly and without extra code through one script has led it to become the standard in implementing third party tags to a website. Data layers emerged as a way of providing the tools within the TMS all the data needed for them to function. You can think of the data layer as an agnostic data repository which feeds through the TMS to the relevant tags.

The data layer feeds data to the relevant marketing tags through TMS platform:

Data layer tag management


How will this benefit my organisation?


1.It will save you time and money in the long run:
The process of hard coding data into marketing tags is, as mentioned above, time consuming and prone to errors. While there is some initial work in implementing a data layer on a site, in the longer term it will require much less technical maintenance, allowing your developers to focus on your website, rather than fixing broken tags.


2. Rapid tag deployment:
 Having a data layer in conjunction with a tag management system allows you to quickly deploy new marketing tags. If there is no custom scripting required for a particular tag, then these implementations can be done by a non-tech that is familiar with tag management and data layers. This frees up valuable tech resource and means your deployments are not dependent on development queues.


3.Makes your data more robust and accurate:
 As the data layer is populated from the back end system, rather than scraping from the HTML, there should not be any changes to the data when there are changes in the site. This will save your developers time in trawling through all the old tags to make sure they are still populating correctly and will ensure robustness and accuracy of data during site changes.


4.Creates consistency across all your reports:
Having one data repository means that all tags are feeding from one source. This means the same naming conventions are fed into all your tools, making any cross tool reporting much easier and generally relieving reporting headaches.



What do you have to consider when building a data layer?


1.It should reflect your  business requirements:
 The data layer is designed to capture all the data points you want to record or utilise on your website. In this respect they are a digital version of your business requirements. As such, it is critical that before you design and build a data layer, you have a crystal clear idea of your business requirements and how they should be captured. One of the most common ways of doing this is building a comprehensive measurement framework, which allows you to map all your KPIs and metrics.


2.It must be tool agnostic:
 You data layer will feed all your marketing technology tools, so make sure it is designed with as wide a scope as possible. Do not design your data layer just for one tool only, rather think of it as a strategic component to your measurement and activation activities.
 At the same time, make sure it’s relevant. There’s no point capturing data in there for the sake of it – but that won’t be the case as long as it reflects your business requirements.


3.It will require adjusting from time to time:
 Your data layer reflects your business requirements. When those change, you will need to update the data layer. It is not something that can just be forgotten, otherwise it will become irrelevant.


4.Governance is important:
You should be documenting the data layer, at minimum as part of a solution design document which shows what data points are collected and business rules/logic behind them. It is also highly beneficial to have  document outlining what the data layer is and what the process is to make changes to it.


by Sean Patterson