Data layer is an important component for any Web Analytics implementation. Without it, web developers will have a hard time organizing the data before passing them to the relevant channels (tag management system, database, etc).
Implementing a data layer is simple and effortless, and you might already have something similar in place but just don’t know it yet.
In this article, we will explain in-depth what exactly is a data layer, how we can use it and what do we need to look out for.
If you’re new to analytics, we have some articles to get you started:
Without further ado, let’s jump right in!
What Exactly is a Data Layer?
Data Layer is a data structure which holds all information that we want to pass from our websites to other applications.
Before we go any further, here’s a sample Data Layer.
Nothing too fancy huh?
Why Do We Need a Data Layer?
Without a Data Layer, what happens is that, we define data as and when we need to pass them over to another application. Functionality-wise, there is nothing wrong with this approach.
But as the need to pass data around increases, it can be a very messy affair. Before long, you will be having trouble keeping track of the data used, and worse, standardizing the data.
Having a proper data structure allows us to have a clear overview on all the data used and also ease data management.
As Data Layer is generic, it can be used by any tool that benefits from having a structured data storage on your website!
Take for example, today, we are using Google Analytics. Two months from now, due to the need for more complex tagging, we decided to switch to Adobe Analytics. Does that mean we have to re-work our Data Layer? NO! Remember, Data Layer is generic and tool-agnostic! Therefore, it is important for us to put in more effort in planning out the Data Layer.
What Goes into a Data Layer?
Understanding how Data Layer can help us is one thing, using it is another.
Now that we fully understood why we should be using a Data Layer, we need to now learn what goes into the Data Layer.
W3C standards is very useful in this case. You can find it at https://www.w3.org/2013/12/ceddl-201312.pdf .
In the PDF, you can find examples on how the data are structured. Take a look at the data structure below.
Inside digitalData, we have many sub-categories for other data. The most common ones across all analytics projects are:
Depending on the business nature, tagging requirements can differ slightly. In addition to the sub-categories listed above, we personally recommend the following too:
- digitalData.form (For forms such as application forms, contact-us forms, etc)
- digitalData.tool (For tools such as branch locator, financial service calculator, etc)
- digitalData.onclick (For all sorts of clicks such as button clicks, link clicks, etc)
- digitalData.video (As the name suggests, for video attributes)
Customization of the Data Layer is up to us and our preferences. There’s no right or wrong, as long as we structure and categorize our data properly in a disciplined manner.
What Else Should We Look Out For?
By now, you should be all ready to create your own Data Layer! But before you leave, here are some pointers we have that will make your life easier:
Always make sure that the data stored is granular
What do we mean by that? Take for example, we want to capture data that is made up of several individual pieces of information. In this case, an address.
In an address, we may have the following:
- Block number
- Street name
- Zip code
Do we store all these information in a single digitalData.address.name, or do we separate them out into digitalData.address.block, digitalData.address.street, digitalData.address.city, …?
The right answer is to separate them out.
We can easily piece the information by combining different elements of the Data Layer, but we cannot easily split the entire string into the individual element.
So keep in mind, always store data in granular form.
Ensure consistent naming convention
We cannot stress enough the importance of consistent naming convention. “Naming” and “naming” might look the same to us, but to some analytics tool, they are 2 completely different piece of data.
We want our Data Layer to remain as simple as possible, both in readability and maintenance. So instead of “going wild” by populating data in any format according to our mood, we need to have a game plan beforehand.
Below are some “best practices” to help us develop our own naming convention standards:
Do not use special characters
Some analytics tools just simply cannot handle special characters. Things like @, $, #, & are just no-no. Chinese characters are even worse, so don’t think about it.
So the next time you think about populating a value like “$1.50“, do yourself a favor and use “1.50” instead.
Stick to lowercase
As mentioned earlier, some analytics tools treat “Hello” and “hello” as 2 separate pieces of data. Therefore, the best way is to ensure all data are in lowercase.
This is so sooooo recommended, that Adobe Analytics (DTM) even has an option to do just that for you.
No redundant whitespaces
As we can see in the screenshot above, just below the option “Force lowercase value“, there’s an option in Adobe Analytics (DTM) to “Scrub whitespace and linebreaks using cleanText”. Same reason, a value with extra whitespace is treated differently from a value without.
[Advanced] Ensure data are not “duplicated”
For an e-commerce website, we can expect tons of data related to product names. It can be tempting for developers to pull the product names straight from the pages without a care for the world. Why would that be an issue?
As we all know, a product can appear on many different webpages, such as home page, product page, campaign page. And on each of this different pages, the name of the same product might differ slightly.
On the home page, it might be called “Fabuex Washing Powder“.
On the product page, the name is “Fabuex Washing Powder – Soft Edition“.
On the campaign page, it can be “Fabuex Washing Powder – Your Trusted Brand“.
If we simply use these product names for analytics purposes, what we will have are 3 different pieces of data referring to the same product. That’s not desirable at all!
Therefore, it is extremely important for data standardiazation to avoid such a scenario.
If done right, Data Layer will make your analytics journey much easier. Do spend a little more effort on firming up the framework to setup a proper Data Layer, and the reward will be immense!
Setting up analytics is only the beginning. Troubleshooting is the main bulk of the pain. With a proper Data Layer, troubleshooting will be much simpler.
If you do not have a Data Layer yet, go ahead and build one now!