WTF is a Data Layer & Why Does it Matter?
December 7, 2020 -
Every website is based on information a user (owner) or company put together in order to sell products, services, or to share knowledge. It usually starts with an idea, moves to a drawing board, then to a wireframe, to a coding process, and finally, a website.
But that’s not the end. New pages will invariably be added. A new product, with a new ID, price, category, SKU, variant, a new service, job post or maybe there is a blog where posts are released weekly and it soon turns into a big site in a short amount of time. With that new product in place, you need buyers and the best way to reach them is to understand what they are doing on your website so you can not only remarket to them, but make your site better, bigger, and full of new features to convert new and regular visitors into buying customers.
But how would I know what someone is doing on my website?
Google Analytics (GA) comes into play here. With Google Marketing Platform (GMP) tools, you can track what users are doing on your site, like where they are clicking and what pages they are navigating. You can even track how long they spend in a specific location, what they see, and more. GMP also provides Tag Management (a.k.a. Google Tag Manager) so you can customize all the tracking you want.
This could be the perfect scenario – if all websites were static pages with no product updates, promotions, new designs, or features. But they’re not, so the most basic way to track all of this would be by using the IDs and Classes in the HTML tags.
Fortunately, the ability to quickly access information and update pages and/or whole sites with just a few clicks has significantly improved. And, with that comes the necessity for updating all tracking information previously set up in the tag manager.
The problem with that “perfect” world
Imagine the following situation.
XYZ company has a website that took some time setting up, but now everything is in place. Tag Manager has all the tags tracking user events, where they are going, where they are coming from, etc. Eventually, a new site design was proposed and many of the original pages were consolidated into one, some were excluded, and new ones were added. Now, tag manager, which was previously tracking all the information from the IDs and Classes can no longer find most of them. And, because of that Google Analytics is only receiving half the information or worse has stopped altogether.
To fix this, developers would have to work around the clock to update all of the tags previously capturing this information. And to make the situation even worse, the new design was coded by another team who decided to use a whole group of different IDs and Classes in the HTML.
If we could only have a single place with all that information….
Well, I present to you, the Data Layer!
How does the “Data Layer” work?
In simple words, the Data Layer is a structure separate from your website that holds general information about pages, products, forms, events, and Ecommerce to better understand your users and what they are doing.
What are the advantages of having a Data Layer?
Using the same scenario mentioned above, instead of the developers having to work around the clock to update all the tags with new IDs, Classes, and even create new tags due to new pages, they would only have to copy, paste and, maybe, update the Data Layer structure for a specific location. Either way, the may structure would be the same.
A product with a details page would have a specific Data Layer with all of the product information; Name, ID, SKU, category, price, and variant. Creating another product details page for a new T-shirt, in a world without the DL, would require also creating new tags in Tag Manager aiming all of the new IDs and Classes which if you’re lucky, would be the same as the previous page.
With the Data Layer, you can avoid fragile dependencies on web page source code. Which means, it wouldn’t matter if IDs or Classes were the same or not because all the product information would be held by the Data Layer. Therefore, all that needs to be created are variables in GTM to hold the information to be passed to GA, if those variables were not already created. ***sound of developers celebrating***.
Of course, a few updates in the Data Layer would be necessary such as the actual product information, but the architecture of the object would be pretty much the same. Still a winning situation.
Another benefit of using a Data Layer is that the structure can be used by different TMS’ so you can smoothly pass data into third-party applications. That also means, if you have GTM, Tealium, or Adobe, they can all take advantage of the Data Layer.
Furthermore, the variables in the Data Layer can be used as triggers. If for example, you want a specific tag to track a user action in a blog post only, you can set a Data Layer variable as “page type” to be “blog post” and use that to fire the event when the page type matches blog posts.
Can I still have a Data Layer or is it too late?
It’s never too late to start working on a Data Layer, though the sooner the better. A Data Layer is a structure that can be new to many developers and maybe a little intimidating to some of them. However, fear not as a Data Layer implementation sounds like a lot of work in the beginning it will pay off in the long run. Not only on the developers side, but for the analysts, marketers or whoever uses reports from GA to make business decisions.
I also have an App. Can I use the same Data Layer?
Glad that you asked!
Unfortunately, the data model for Apps and Web are different, so, in this case, if you have a real app (and not only a copy of your website in a mobile version) the Data Layer implementation will have to be different. HOWEVER, here’s an amazing product Google has been working on:
Google Analytics 4 (formerly App + Web) Property! ***fireworks***
Before this new property, (which is still in Beta version but is being heaviliy updated on almost a monthly by a dedicated team of developers), each group of data collected would have to be sent to a specific property.
No more separate properties and all the information you’re looking for would be in a one stop shop data place.
But you said two different Data Models. Which one will be used then?
In the future, Google’s idea is to use the same Data Model from Firebase (app Analytics) for Web properties as well. A few reasons for this are:
- Everything is event-based. That means a more user-focused environment to understand what users are doing on your website, rather than having page views and events dealt with separately.
- No more event category, action, and label. Now everything will be built on a more flexible data collection. Event and parameters.
So I can drop everything and go full dive into Google Analytics 4 (GA4)?
While I appreciate the enthusiasm, our recommendation (and Google’s) at this moment is to have both Analytics (Universal and Google Analytics 4) to ensure:
- You don’t lose your data. At the moment of this writing, GA4 is in Beta. That means, while heavily updated and with dedicated people working on this new property, it’s still on Beta version. There’s a lot of things to come and new features will be available in the future.
- You have an opportunity to reevaluate the current data architecture. Because the Data Model will change, it’s important to highlight that a different structure will be necessary when dealing with the Data Layer. No more page views and separate events.
- Short term structure. Right now, you probably have way more flexibility in GA Universal compared to the GA4 property; and that’s only logical. We’re comparing a structure that took years to be updated and modified to another that was just released – July 31st, 2019.
How hard is it to implement both of the Data Layers?
The best answer for that is: It depends. How knowledgeable is your developer team? How much do they know about Data Layer, it’s structure, load sequence, best practices, general rules, passing, events, and more? Can your team implement the proper Data Layer structure focused on your business KPIs and objectives in the short, medium, and long term? Can your team maintain future updates and keep up with the new releases, bugs, solutions, and problems that may appear?
If you answered no to some (or all) of these questions, it may be a good idea to put together a feasibility or a requirements plan before jumping into implementation. Especially since a project like this requires input and resources not just from your developers, but from marketing, the executive team, QA, etc. You may find the best solution for you is to bring in some outside help – Warning, shameless plug approaching – from a company like Napkyn…