Objectives

The Generic Digital Data Layer (GDDL) was created with the different stakeholders involved in data tracking in mind. The 4 basic pillars of the GDDL help to achieve these objectives.

Despite what the sales pitches of MarTech vendors want you to believe, a tracking implementation is seldom an easy and low-effort trajectory. Especially in large enterprises, where even the trivial task of implementing a marketing pixel often turns out to be a process that takes days, if not weeks. Let alone setting up an entire new data layer implementation.

Tracking implementations owe their complexity to the different objectives of the departments involved. Development is in charge of the website's performance and expects reliability and thoroughly testing. Marketing expects agility to cope with a fast changing marketing techology landscape. The management expects comprehensible and qualitative data that they can rely on. Legal expects that all tracking is compliant. And analysts want detailed data to answer every possible question they are asked.

The Generic Digital Data Layer (GDDL) is created with the objectives of all these stakeholders in mind. This resulted in the four pillars on which we built the GDDL framework: event-based, standardised, clear roles and transparent.

From page-based to event-based tracking.

To overcome the shortcomings of traditional page-based tracking, a change in mindset is required. Start thinking of website visits as a series of events occurring in a browser, instead of pages being shown. Browser events like: the load of a page, click on an element, visibility of an element, etc. Next, map these events to your business context and specific site components. You end up with a tagging plan that uses site components as a starting point, instead of pages.

It's clear that an event-based approach is future proof and makes the captured data more versatile for use throughout the organisation. Compared to the traditional page-based web analytics data structure, a time-stamped event stream is easier to integrate with other data sources and the ideal input for all kinds of data models.

The two biggest vendors in the digital analytics spehere are also moving toward an event-driven approach:

• Google has launched GA4, the succesor to Universal Analytics. With GA4, Google Analytics has completely overhauled the data model. It's now completely event-driven instead of page, session and user driven. The concepts of page, session and user are still present, but it's now up to the data analyst to define those concepts.

• Adobe has launched the open-source data standard XDM, together with Microsoft and SAP. The XDM (Experience Data Model) is considered as the foundation needed for enabling personalised user experiences. The XDM provides a data schema for both time-series (event) data and record (profile) data.

Unification and standardisation

We were looking for a solution that is universally applicable. The implementation should no longer be site-specific but standardized to be similar across websites. This provides the certainty that, when you are merging data from different platforms, a specific event is implemented the same way on every platform.

We started developing a unified data layer, based on the Customer Experience Digital Data Layer (CEDDL) standards defined by the W3C community. However, we quickly realized that these standards made the tag management maintenance more complex. None of the larger tag manager vendors has adopted this standard as their own data layer. They prefer to hold on to their own syntax. When you go for another data layer structure than the one documented by your vendor of choice, it will result in additional coding within the tag manager. Which results in a less accessible tag manager.

Besides this additional layer of complexity, the CEDDL standard is not ideal for an event-based approach. The CEDDL is one JavaScript object with nested variables. On a page where events might happen almost simultaneously, this could lead to the loss of information. The CEDDL can’t handle race conditions (perform two or more operations at the same time) but will process every event sequentially. Resulting in the possibility of one event handler overwriting the values from a prior event handler before it has been able to send that data.

Another thing that we wanted to prevent, is vendor lock-in. In many of the projects we work on, clients have a mixed landscape: one website uses Adobe’s LaunchTag Manager, while another department has a platform with Google Tag Manager on it. And even when only one tag management system is in use, the marketing technology landscape changes so quickly, that it is reasonably to take into account that the organisation may switch to another tag manager in the near future.

Implementing a decent data layer requires a certain investment, an investment that may prevent you from switching to another tag management system. Even if that new tag manager may be a more logic choice for the situation your company is in at that moment. Therefore, we wanted our solution to be vendor-agnostic.

Because of the limitations of the W3C CEDDL, we realized that it is not possible to create a generic data layer that is suited for every situation. Therefore, we decided to take another approach: create a framework that relies on standardized and generic events. And add a translator layer, that is capable of translating those events into the data layer structure requested by the tag manager vendor the client works with (be it GTM, DTM, Launch, Tealium, etc.). By fine tuning the data layer to the tag management system used, we gain on performance and limit custom coding as much as possible.

Clear roles and responsibilities

The last pillar that we took into account while developing the GDDL framework, focuses on the (all too often troubled) relation between IT and marketing. Too many tracking projects get stuck with those two parties pointing the finger at each other. This is often the result of miscommunication and diffused responsibilities.

Therefore, we clearly separated the tasks of the development team and the marketing team in our framework. According to our vision, each role should be able to focus on its own expertise. A developer does not need to know Google Analytics, just as a marketer does not need to know how history changes are handled in Angular.

Transparency

Transparency comes forward in many aspects of the framework:

• The GDDL is licensed under an open-source MIT license. This means that everyone is free to use, copy and modify the framework in anyway, as long as the original is referenced. This makes it transparent for companies interested in the GDDL: there are no obligations towards Stitchd in any way.

• The GDDL is well documented (cfr. this knowledgebase). Explaining not only the technical set-up, but also our motivations for creating and mainting the framework. This enables anyone to start off with the GDDL framework on their own initiative.

• The GDDL follows Jim Gordon's vision when he pleads for semantic tracking implementations: "Everything about your implementation must make sense to a junior analyst". The data layer must allow for a tag management configuration that allows the web analysts to have enough flexibility for proper and complete tracking and avoid misuse of the tag management system for scripting business logic (overusage of custom code); all logic should be doable with the basic set of selection rules offered by the tag management system. In other words: the tag management configuration itself should be transparent and comprehensible without too much prior knowledge.

• The same logic applies to the web analytics configuration as well: by limiting the amount of metrics and applying a structured approach for populating variables, we make the reporting environment easy to understand and work in.