The data layer is a key part of most modern web analytics implementations, but it seems there are not many resources to explain it to a less technical audience, or perhaps to someone who is technical but new to working with it. Let’s start with the basics:
What is it? In the world of the W3C data layer (more on that in a minute), the data layer is a JSON object.
To break that statement down, W3C is the World Wide Web Consortium. They provide standards for the web that align architecture and design principles so that the web can work well and continue to grow. (This may seem unnecessary because it seems like the internet “just works”, but if you weren’t around for the wild west days where there were vast differences between what different browsers supported across the web, standards are most welcome and necessary.)
JSON is JavaScript Object Notation. JSON is a way to organize and structure data objects in a human-readable way. It answers the questions “What is this item called, and what is its value?” For example, to take a somewhat amusing example from the W3C’s full documentation, how easy would it be (without knowing anything about the data layer) to answer the question of which product we are viewing here?
digitalData.product[n].productInfo = {
productID: “rog3000”,
productName: “Rogaine”,
description: “Hair Regrowth”,
productURL: “http://site.com/r.html”,
productImage: “http://site.com/rog300_large.png”, productThumbnail: “http://site.com/rog300_thumb.png”, manufacturer: “Pharma”,size: “300ml” };
Pretty simple to see, right? It’s easy to look at this and see the items and what they represent. Contrast this with something like s.eVar47= “rog3000” (which is how the productID piece of this would look if it was hard-coded and assigned to Adobe Analytics conversion variable 47), and you can see how much more human readable this format is.
Why is it? There are many advantages of the data layer, but here are a few. The data layer allows for a simple place to funnel all the data about your website into an organized format that can later be referenced by analytics tools, marketing tags, and more. This helps ensure that you are passing the same data across tools, and gives the flexibility to assign the product name to, say, variable 37 today but variable 40 tomorrow. (Not that I recommend bouncing around which variable you are using without a very good reason, but that’s one example.)
In the past, with hard-coded implementations, you would need to do things such as specify that it was a particular variable number associated with the product name value, and your development team would have to make that adjustment if things ever changed. Using a data layer also allows you to more easily send data to multiple analytics tools (for example if you have both an Adobe Analytics and a Google Analytics implementation running, they can both reference the same set of objects on the site).
As websites evolve, tasks like updating a manual variable assignment get more cumbersome and error-prone, and introducing inconsistencies generally ends badly in terms of data quality. The data layer takes all that out and provides an easy (and again, human-readable) reference point.
Using the data layer with a tag management system (things like Google Tag Manager, Adobe’s Dynamic Tag Manager [DTM], Tealium, Signal, Ensighten, etc.) allows the analytics team to make adjustments like this without waiting on a formal release or involving a development team. It also allows the development team to keep the analytics data flow consistent during major redesigns of the site. It’s easier to see the requirements and they are more meaningful, versus less human readable lines of code that have to continue to be explained and defined. There’s plenty of defining that goes on when creating a data layer as well, but the starting point is much more understandable.
How are objects referred to within the data layer? The path to an object is referenced with dot notation. In the below example digitalData object, to refer to the pageType, I would refer to digitalData.page.category.pageType. This is the type of notation that a tag manager would use.
digitalData.page.category = {
primaryCategory: “FAQ Pages”,
subCategory1: “ProductInfo”,
pageType: “FAQ”};
Is it always called “digitalData”? There are many names for the data layer. The W3C standard name is digitalData, but tag managers like Tealium use utag_data, you will see dataLayer with Google Tag Manager, etc., plus you may see companies that use their own custom names.
Where can I see the data layer? You can open your browser’s console and enter the name of the data layer (see above for common ones), and you will get back a list of key/value pairs within a structure. Some of the data layer may also be visible in the page source depending on many factors, but the console is the most direct and accurate way to see the current values.
To get back the value of only a specific item, you can enter the dot notation format. In the example a few paragraphs up, if I were to enter digitalData.page.category.pageType in the console, I would get back “FAQ”.
How does it fit into the analytics ecosystem? Here is a very basic example of the way the data layer can power an analytics implementation (taking into account the fact that I am not a graphic designer by any stretch of the imagination):
Where do I go from here? Learn more about the specific analytics solutions you are working with and explore how the data layer is set up on your site. This training will vary significantly by tool.
I did not go into JSON arrays since this is a basic intro, but they are very important since they are often used for the products that are being viewed (as one example), and that is very important for most web analytics solutions. It would be good to go through the whole JSON section from W3Schools.
Hope you are able to take some newfound understanding of the process flow and use it to further your web analytics journey!
Update: if you’ve read this and are still asking the question, “Why can’t I just use CSS selectors for everything?”, please read this colorful response from Jim Gordon’s blog: https://jimalytics.com/implementation/data-layer-or-css-selectors/
Beautiful summary of the data layer, thanks for writing this!
LikeLiked by 1 person
Thanks so much! I enjoy your posts on Digitial Data Tactics as well. I have a post on s.products in the works that will reference yours. 🙂
LikeLike