Every website is based on information a user (owner) or company put together in order to sell products, services, or even share knowledge. It usually starts with an idea, moves to a drawing board, then to a wireframe, to an actual coding process and, finally, a website creation.
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 best accommodate them to convert new and regular visitors into buying customers.
But how would I know what someone is doing on my website?
Google Analytic (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 and features. The most basic way to track all of this would be, for example, by using the IDs and Classes in the HTML tags.
Fortunately, not only has the Internet and online access become better compared to 30-40 years ago, but how quickly we can access information and update pages and/or whole sites with just a few clicks has significantly improved. And, with that, the necessity for updating all tracking information previously set up in the tag manager.
The problem with all 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, 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?
The Data Layer is a piece of javascript you will add to the website. It’s main purpose is to hold all of the main information from the pages where it’s implemented. With that javaScript object, even if you update the site design and structure, as long as the Data Layer is still there, the data GTM captures and passes to GA shouldn’t change.
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.
For example:
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 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 win 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 may be a little intimidating to some of them. However, fear not, as a Data Layer implementation, in the beginning will sound like a lot of work, but it will pay off in the long run. Not only on the developers side, but on the analyst, marketers or whoever uses the reports from GA to make business decisions because they are going to have more and better structured data.
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.
App + Web Property! ***fireworks***
Before this new property, which is still on Beta version but having heavy updates almost monthly with a dedicated team of developers, each group of data collected would have to be sent to a specific property.
That means:
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) to Web properties as well. A few reasons for that are:
- Everything is event based. That means a more user focused environment to understand what users are doing in your website, rather than having pageView and events dealt 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 the App + Web?
While I appreciate the enthusiasm, our recommendation (and Google’s) at this moment is to have both Analytics (Universal and App + Web) to insure that:
- Don’t lose your data. App + Web, at the moment of this writing, 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.
- Give you 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 App + Web 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...
