With the proliferation of martech implementations on your digital properties, implementing a data layer is important, but there’s a right way and a wrong way to do it. And, even if you have set up your data layer correctly in the beginning, having multiple teams each making changes to your site could unexpectedly cause errors that need to be found and resolved quickly. This article will cover some data layer best practices to protect the quality and integrity of your data. But, first let’s review.
What is the Data Layer in Web Analytics?
The data layer is a JavaScript object that contains all the information you want to collect in a web analytics or tracking tool and stores it for later retrieval. It’s basically a repository for variables and the corresponding data that your analytics will use to report on page, product, transactional, and user data. The data layer standardizes the data that is going to all of your tracking libraries and third-party tags, so your martech can pick up consistent key-values and provide accurate data.
The Best Practices for Building a Dynamic Data Layer
The best practices for building a data layer include having a good grasp on who the stakeholders are and what their objectives might be, planning carefully, executing with an eye for detail and future requirements, and then monitoring and maintaining your implementation. Let’s dig into these steps individually.
Step 1: Who are the stakeholders?
Before any project begins, it’s important to consider who the stakeholders are to make sure you get buy-in and consider what the objectives of each team might be. Typically, the information from a data layer is important to:
- Marketing professionals, who often request vendor tags
- Analytics experts & business executives, who rely on that data collection
- Developers, who are the owners of the overall data and tracking implementation
Step 2: Planning
One of the most important things you can do is to thoroughly plan what the data points that you’re going to expose through your data layer are and how you’re going to do it. Websites are increasingly complex with a multitude of data and tracking requirements. Start by simplifying the process. Think of the data in a more understandable way and then create technical specifications and deliverables that will help maintain data models and the information’s accuracy.
What are the page types?
First, divide up your site by page. What kind of page types will contain what types of objects and data points? In an ecommerce example, you might have landing pages, product pages with filtering and sorting capabilities, a check-out flow with things like possible abandoned carts, and thank you pages with conversion tracking. Page type division is a common way of breaking a site down from when you’re first developing a site, so stakeholders will already be familiar with this method of breaking down and organizing a site.
Define naming and formatting conventions
The planning stage is the time to think about what standards you want in place for now and the future. Most data layers are built to W3C specifications, which strive to make websites work on all browser types. When you’re building your data models, take some time to consider the following:
- Naming conventions: For example, under the W3C specs, object properties in your data layer should use no spaces, not start with a number, nor have special characters. They should also use camel casing to differentiate words (e.g. dataLayer).
- Structured data models: curly braces in the JavaScript indicate the start of objects; use square brackets for arrays.
- Logical structure: group things together logically
Step 3: Development
So, at this point you might be asking, “How do I actually do this technically?” The answer is, you should use what you’re already using. HTML, CSS stylesheets, and JavaScript make up a website. But the server language, such as PHP, will vary, so the process of building a data layer will vary depending on which server language is being used. The developers should use whatever object-oriented programming languages they already know and use that to build the data layer object on the back end. Create your properties and sub objects, and fill them in with your data.
Use JSON
Instead of cobbling together a bunch of different front-end JavaScript snippets using strings and concatenation and trying to generate front-end code with back-end code, standardize the output into one concise object using JSON (JavaScript Object Notation).
Doing so frees up developers to worry about other things, and marketers and analysts can draw from the data layer to push data into Adobe or Google Analytics without heavy back end development.
Trigger Events
We’ve talked about page types and things that are going to happen on page load, but now we need to think of actions or events on the page, which we should consider beginning at the planning stages.
The data layer comes in on page load, but may need to add values in the case of an event (such as a cart action). In many cases, an event warrants a server-side response, and the data then needs to be pushed into the data layer. In that case, you’ll need to add another bit of functionality to the code to either update or augment the data layer.
Page Load Timing
Another thing to consider in both planning and execution is when you need the data to appear.
If you’re doing A/B testing or using an audience manager, you might need the data right away, so you would put the data layer object at the head of the document. Other tools like Adobe Analytics might fire at the bottom of the page, in which case you’re safe to load the data layer object later.
The general rule is to decide when you need access to the data layer and expose it before you need it.
Web Page Caching
As traffic on your site grows, the load on development servers increases, so you’ll need to start utilizing caching to maintain performance (page speed).
The challenge with caching is that it adds an extra layer of complexity to how you implement your data layer by impeding its dynamic nature.
For example, when the browser initially makes a request for a web page, the web server will dynamically create the page and data layer before serving it to the client. But once that page is cached, then the data layer is cached along with it and therefore no longer dynamic but static. Caching could therefore create unexpected behavior like having one user or visitor’s data used for every visit to the page.
How can you accommodate caching while still providing a dynamic data layer? The answer is to separate the data layer into chunks, deciding what is cache-able (static) and what isn’t. Anything cache-able can still be built normally on the server side. Anything dynamic would need to be called like an event and added to the data layer via a mechanism like an AJAX call.
Common Errors
- Not properly planning and structuring the data model and trying to piece together strings and concatenate them.
- Not following naming conventions, not using commas, leaving unenclosed values and extra spaces.
- Improperly formatting data layer values. Is it a string, is it an array, is it a sub-object? Make sure you format appropriately.
Key to addressing these errors is to ensure you’ve properly designed your data models from the beginning. If you’ve done so correctly, you should be able to compare the production data against your data models to ensure proper implementation.
Step 4: Data Governance
The last part of data layer best practices is the maintenance and monitoring of it. Your website and the data layer are going to change, so how do you maintain the data, improve it, and track it over time?
First of all, you’ll need to stay up to date with your documentation so you have a model to validate against. In addition, an occasional spot check of the data layer in your developer tools can help you verify at a page-by-page level whether or not the data layer is functioning as expected.
Of course, the data layer is a site-wide implementation, so spot-checking here and there won’t be sufficient to fully verify your data layer is functioning as expected. When testing, you need to be able to verify:
- The data layer is populating correctly on page load
- The data layer is populating correctly on each triggered event
- The right key-value pairs are present within the data layer and in the right format
Ideally, you would test all of these areas each time you updated your site, given that any update could result in unexpected conflicts that lead to a broken data layer.
Because of the magnitude of testing required to maintain your data layer, automation will be your best friend. You can use an automated tool like ObservePoint’s Technology Governance solution to automatically monitor your data layer, setting up regular scans and alerts for when errors crop up.
Conclusion
So now that we’ve briefly gone over the best practices for implementing a data layer, you can use this diagram to remember all the steps necessary to keep your data layer free of errors and full of the data you need.
