The Event-Driven Data Layer

17 Jul 2022 » Data Layer

I have been a bit lazy and I have not addressed this topic for some time. I have read a few articles, but I was not sure what I wanted to write about. However, in the last few weeks, I have been involved in an initiative with a customer, where they are replacing their existing static data layer with an Event Driven Data Layer (EDDL). This has given me the final push I needed to learn it and decipher it for you.

Some background

As usual, I will start by explaining where are we coming from and why we are in the current situation.

On-page code

When I started working as an Adobe Analytics consultant in 2012, we were still using s_code H.24 and putting all the code on the page:

var s = s_gi("myrsid");
s.pageName = "Home Page";
s.events = "event1";
s.prop1 = "Not logged in";
s.eVar1 = "D=c1";
s.t();

This was very painful. Any issues with this code meant that the reports would be wrong until a new website release fixed it, which rarely was a priority.

Tag managers

Fortunately, tag managers started to become the norm. In my very first post on this blog, I encouraged my audience to use a tag manager. Any changes needed in a marketing tag could be managed independently of the website code. This opened another can of worms, but that is not today’s topic.

One issue still remained: the data that had to be sent to Adobe Analytics still had to come from somewhere. A quick and dirty solution was to scrap the page to read the values from the HTML. I saw this very often, where the data elements were CSS selectors or JavaScript snippets using jQuery or Document.getElementById(). While it may initially work, any changes in the HTML can potentially break the Analytics data.

Data layers

The solution was to build something that would become the glue between the data source and the Analytics code. This is what a data layer is: a JavaScript data structure which contains all the information needed by the marketing team. The most important feature of this data structure is that it is (or, at least, should be) completely independent of the HTML. Therefore, if the design team decides to change the look and feel of the website, the data layer can stay the same or require minimal changes.

My 8th post was precisely a brief introduction to data layers and why it is important to have one.

The Customer Experience Digital Data Layer

While any data layer structure should work, the W3C tried to put some order by creating a standard: the Customer Experience Digital Data Layer (CEDDL). When I first saw it, I immediately became a firm advocate for it: I recommended it to my clients and I wrote two blog posts on the matter (part I and part II).

However, the reality is that it never really took off. Some clients implemented it and found it very difficult to manage. The W3C did not follow up with an updated standard. The main problem with the CEEDL is that it is completely static and it has to be built at the top of the page. This makes it very difficult for websites that load the pages in stages:

  • As an example, many e-commerce websites load the cart after the page has loaded. Since the CEDDL includes the cart information in digitalData.cart, the web server needs to call the e-commerce engine to retrieve the cart information and populate the data layer with it, adding complexity to the server implementation. The same applies to user identification and digitalData.user.
  • Click events are very cumbersome to manage with CEEDL. There is a normative Event Object (digitalData.event), but the standard does not say how to populate it. I even thought that the intention was to add all potential events that could happen on the page.
  • Almost by definition, SPA websites and CEEDL do not mix well.

It was clear that a new solution was needed.

The Event-Driven Data Layer

While I cannot be 100% certain, this concept started with this blog post from Jim Gordon. What I can say for certain is that I first knew about this concept through Jan’s blog post on that topic. However, as I said at the beginning, I did not initially pay too much attention to this proposal. Now I think I am in a position to say that I understand it.

I am not going to explain it in full. My goal is to provide a quick summary of it. I would describe the EDDL as a JavaScript object that has only one function, push(), used to add more data to the data layer. This function has the following benefits:

  • You do not need any more to get all the data at the top of the page. As you get more information about the web page, you push it into the data layer. In the example above about the cart, once the cart information is retrieved, it is added to the data layer.
  • You can add listeners to the data layer and, for every push(), evaluate whether you need to do something about it. For example, once you get all the information about the page, you can send it to Adobe Analytics.

But not only this, I am seeing a clear trend regarding EDDL:

  • My Adobe Analytics colleagues are actively recommending it to our clients, in place of CEDDL.
  • I sponsored a few years ago a hackathon to build the Adobe Client Data Layer extension (ACDL), which is Adobe’s version of the EDDL concept.
  • Our clients are showing more interest in it and, in some cases, implementing it.

With all of these in mind, I can finally say that I recommend you to move to this new data layer. I know it is not a simple task, but you should start planning for it.

 

Image by rawpixel.com

Related Posts