Skip to content
All Blogs

The truth about data layers

The truth about data layers

I recognize that my writing of a blog post that exposes the truth about data layers is a bit contradictory to my background and approach to client-side analytics historically. For background, my history at both Stratigent and Ebiquity has immersed me within some of the largest and most complex analytics deployments in the US and Europe. Along the way, we also founded and built Ensighten, a tag management system (TMS), within Stratigent and spun that out as a separate company.

TMS like Tealium, Ensighten, or others all boast the ability to manage your tags in one place without the need for technical experience. They are positioned as technologies that better enable Marketing to collect data about their customers and ultimately drive better personalization and targeting; all without the need for tagging the pages with each, individual tag. However, there are two things that I think are important to bring to the forefront:

  1. While tag management centralizes all your tagging into one location, you will still require technical expertise to implement enterprise-level tagging - the "pre-built" tagging templates won't be customizable enough for tags beyond those that simply need to be deployed with an account ID
  2. Tag management requires a data layer in order to make it efficient and anything more than just a middle-man

So, what is a data layer? A data layer object, which is commonly developed in JSON, can be implemented server-side or client-side and ultimately you populate that object with information throughout a visitor's session on your digital touchpoints. When Ensighten was being built, we realized very quickly that tag management would deliver on the value proposition more efficiently if there was a way to capture in-session details in one place to use across all the tags being deployed. The thinking was very simple: collect once, use many. This is where the data layer was born, and why all tag management technologies emphasize the need for a data layer. Tealium refers to the data layer as the following:

"The Data Layer is the foundation of your Tealium solution and will serve as the one true definition of your data across all digital assets and customer interactions. The data layer comprises all of the various data elements that will be collected across your site and the visitor interactions and events that will be tracked."

TMS vendors are dependent upon the data layer, and it makes sense given that without a data layer you are forced to scrape details from pages during the client-side session. That in and of itself makes it prone to error as pages are updated and the experience changes. From my perspective there are four truths about data layers that I want to call attention to:

  1. While it was originally designed to facilitate the efficiency of tag management, it has become a burden to many organizations during the implementation process
  2. You are basically creating a "tag" to build a data layer to ultimately then integrate with other tags
  3. The ability to maintain a consistent version of a data layer on both mobile and web is a challenge
  4. Security, privacy, and control should be considered when building a data layer

The first data layer we built at Stratigent was back in 2008, and at the time it was indeed a faster and more efficient way to structure data for tag management. However, times have changed and the sheer complexity in the number of tags, the features within those tags/systems, and the environments themselves have basically turned the data layer into a monster to manage. In my last couple of years at Ebiquity we saw several clients struggle with building a data layer and allocating a budget to do it properly. When you forgo the data layer, everything within your TMS slowly falls apart and all features boasted within the solution of your choosing are left unused or underutilized.

Over time, I noticed the irony in the effort required to build a data layer and realized that it wouldn't be sustainable long-term. As a client, you purchased a TMS in the hope of removing the manual effort for capturing data and sending it to technologies within your marketing stack. Now, as the complexity has increased, clients find themselves having to invest significant dollars to get their environment "TMS-ready" for the ideal implementation by building the data layer. As a result, the tagging efforts that were "removed" by the promises of TMS have simply shifted to the efforts required to centralize and store the session-level data within your data layer object for usage by the TMS.

Given that the mobile device is now key to cross-channel personalization, it would only make sense that TMS and the data layer should operate the same way across both web and mobile (hybrid and app) channels. However, the struggles as you try to shift this approach to mobile become even more messy. The sheer number of mobile development frameworks can render the data layer object useless, and the coding required to embed within the app makes it even more prone to error. I've seen so much wasted effort and money during mobile implementations to finesse a TMS SDK and data layer object; especially when you are consistently releasing updates to the mobile apps in the marketplace. As a point of reference, one of my prior clients spent $250K just to build a data layer for one app across both iOS and Android.

Vendors will offer you the option of using their own taxonomy for building a data layer, within their UI, but clients need to be wary of how they choose to implement in order to maintain control and ownership of the data. In my prior life, we always promoted the use of an "independent data layer" controlled by the client in order to avoid vendor lock-in and the need to potentially have multiple versions of the object across your tech stack. Frankly, if you're having to build it multiple times, then it's way more trouble than it's worth. However, governance really should be a consideration given the constraints being put into the marketplace by GDPR, CCPA, and others.

Ultimately, what this comes down to is data accuracy and control while ensuring that efforts are focused in the right areas. Budgets are limited, and the money is much better spent focused on data activation versus data collection. The manual effort required to build a data layer leaves the door open to human error and data inaccuracies as the web and mobile channels are updated and changed.

This is one of the key differentiators for Celebrus, and one of the many reasons I chose to join the team to convey this message into North America in my new role. Times have changed, and the approaches that made sense years ago simply don't meet the challenges of today's marketplace. Change is difficult and admitting that there are better ways to do things that contradict your historical approach can be a challenge to articulate internally.

However, there are better ways to capture your digital data, in a unified data model across web and mobile, without the need for tagging or a data layer. Celebrus can redefine your approach, and we'd welcome the opportunity to show you the power of our platform and how we can shift your focus and effort towards data activation.