The Event Driven Data Layer revolution

Hello world,

This article is coming quite late into the game, because a lot of things have already been said or done with Event Driven Data Layer (EDDL). Lots of questions have been asked and the community has been going quite wild on this for some months (a year now?) on this topic.

If you are on this page and didn’t read about this article from Jim Gordon : https://jimalytics.com/tag-management/the-event-driven-data-layer/,
I suggest that you pause now and take time to read his article.

That is a nice explanation on what has been requested by the community and what are the advantages from the EDDL.
And while you are at it, you can read this as well : https://jimalytics.com/data-layers/top-event-driven-data-layer-mistakes/

Reality Check

It took me quite some time to get used to this logic, I am not a big fan of array, in general but this one is special.
The additional method that will get your Data Layer State is actually the only thing that you really need.

As of now, EDDL is coming more and more in the discussion with clients. If you didn’t face it yet, you will soon. The reality is that EDDL is the future, if not the present (and you are living in the past).

This will take time to adapt, it packs lots of advantages but it comes with some challenges and that is what I call the revolution.

Technically, it won’t be as such but for the way you will approach your data, it may be just that.

Challenges ahead

There are some challenges that consultants and clients needs to consider when switching to the EDDL logic.
All of the advantages of the EDDL will not bypass all of their challenges so it would be better to be prepared before you are implementing it.

What is a Page View ?

Yes… that is the first question you want to answer before you implement the EDDL logic on your website.
It is pretty obvious isn’t it ? Or is it ?

For a long time time, the page view was associated with a page / DOM event or a specific call to it.
So the event where either

• DOM ready
• Window Loaded event
• a call to the tool (s.t(), _satellite.pageBottom(), ga(‘send’, ‘pageview’), etc…)

The big idea of the Event Driven Data Layer is to take advantage of the asynchronous nature of the nowadays web. So thinking in term of Page event is not really relevant anymore.

Of course, most of the elements that you track are still bound to either a page or a click event but you don’t have to bind it with these events. You may want to track later because you want to add information from the backend service, or you want to go faster because you don’t have lots of stuffs to track within your page view in this page.

At the end, it actually boils down to send the tracking when you are ready, a.k.a when you have receive the information that you want.

The big thing about the EDDL is that you can do just do that. What if you create an event that tells you when you are ready to fire the event.

If you really want to go fancy about it, you may want to ask your IT team to develop a promise queue when they are feeding your Data Layer array and when all of these promise resolve, then, and only then, you fire your tracking.

Which Event do I track ?

With the Event Driven Data Layer, you may be considering that you need to define each event in the data layer.
Therefore, the IT should implement a new data layer event for each of the click tracking that you want to do ?
The answer is probably not.

You can still track all of the events that you used to track with the DOM listener event (click, focus, etc…). That is still an option.
I would even say that if your main goal is to track the click itself, and set an event to it. That should be the main way to do it. No need for over-engineering.

You need contextual information for that event, either re-use the element already set in the previous page load event, or if you have cleaned your variables (s.clearVars()), you can re-call the latest data layer state.

A more technical approach should come if you expect your event to change the data layer state.
In that case, you should align with your IT and define the way that this event is generating a datalayer.push() method and what is being pushed inside.

That ensure a really good tracking behavior because you are waiting for the datalayer state to be changed to fire that event. It avoids race condition and even if you want another tool to listen to that interaction but populate more information to it, you can rework the event with the data layer and dispatch a window event with the information you want with it.

In which format do I want to track ?

In my humble opinion, I think that the W3C format for the data layer is not exactly matching what the customers want today. And this is one opportunity that the re-implementation of the new datalayer format is bringing.

If you are a bit like me, you are screaming regularly about the state of your current data layer, this is the opportunity you always wanted to improve it.

At this state, I will suggest that you do something that most of the other consultants may not recommend, but have a look on the XDM format from Adobe.

Better : Read about it, look at how the tracking is done with the AEP Web SDK, and then imagine tracking your information in that format.

XDM format is not that complicated on itself, it is a JSON format like any other, it is just the implication to the way AEP interpret the data that makes it more holistic that other format (in Adobe world).

Having your new data layer following an XDM format type would really simplify your world when you will need to integrate the AEP Web SDK, but I guess it will also help you re-define what you really want to track.

How can I use the Event Driven Data Layer on my website ?

OK, I convinced you to look into this, but you may say :

“Julien you talk big but how can I implement that stuff ? Do I need to explain the whole principle to my dev team and figure it out on my own ? “

I didn’t want to bring that question first because I obviously have stake in place in that discussion. As of now, you have 4 different ways to implement an EDDL logic on your website:

1. You write you own EDDL logic with your IT
2. You use the Launch Extension provided by Search Discovery.
3. You use Google EDDL Open Source script
4. You use the Adobe Client Data Layer

I won’t be talking about point 1 and 2 in details, for several reasons: The 1st point is about building your own EDDL and on that note, if you chose that, you probably are smarter than me and already have a clear picture of what you want to achieve. The 2nd point, I am not very familiar with it, especially because a paid version of the extension is available and I don’t have access to it, so I won’t be able to give a fair review to it.

Google EDDL

For the point 3 (Google EDDL), you can directly go to their Github repository and copy paste the code to use on your own website.
The Google Event Driven Data Layer is very flexible, it allows you to encapsulate any array into the Event Driven logic.

Usually the definition of the array looks like this:

myArray = myArray || [];
myHelper = new DataLayerHelper(myArray);

Then you can realize different operations such as :

myArray.push({"foo":"bar"}); //push data to the array
myArray.push({"key":"value"}); //push data to the array
myHelper.a // will return {"key":"value","foo":"bar"}

// you can directly push from the helper:
myHelper.b.push({'data':{'foo':'bar2'}})

// you can get the state of the EDDL by calling the getState method
myHelper.getState() // will return {"key":"value","foo":"bar2"}
// or directly an element
myHelper.getState("foo") // will return bar2

// you can listen to change when instantiating the Helper
function mylistener(event){
console.log(event)
}
var helper = new DataLayerHelper(myArray, mylistener);

That is mostly it, you have some more options available directly from the API but it is mostly minimal and very flexible.

Adobe Client Data Layer (ACDL)

The Adobe Client Data Layer has been launched quite recently and, for the moment, is only working for objects called adobeDataLayer. This limitation has been lifted with the 1.0.1 version, the Adobe Client Data Layer is providing API methods that are a bit more advanced and secure for you to use.

If you have AEM 6.4, you can directly have the Adobe Client Data Layer in the core components of AEM. If you don’t have AEM, you can go to the Github repo and download the script there.

The usage looks a bit like that :

window.adobeDataLayer = window.adobeDataLayer || [];
//your scripts loaded ....src="adobe-client-data-layer.min.js"

adobeDataLayer.push({"data":{ "foo": "bar"}}) //push some stuffs
adobeDataLayer.push({"data":{ "key": "value"}})
adobeDataLayer.getState() // returns {"data" : {"foo":"bar", "key" : "value"}}

// Like Google EDDL you can look for a specific element state
adobeDataLayer.getState("data.foo") // will return bar

// you can set event listener as well
adobeDataLayer.addEventListener("myEvent",function(){console.log(adobeDataLayer.getState())})

These methods are just a pick of what is available from the adobeDataLayer object. A lot more is available and you can find a very good wiki here. I will probably do a blog post on it and with some best practices, because this type of call that I demonstrated may not be the best practice to follow.

Which one to use ?

From the 2 EDDL that I just showed here, I will recommend using the Adobe Client Data Layer and from me you may have already expected this, but I will give you several reasons for it:

• Publish date : Google EDDL has its last commit in 2014 where the ACDL has been created in 2020. In 6 years, a lot has happened in the web and as good as Google EDDL is (and it is), it may not cope with all of your use-cases.
• Availability : ACDL is available directly in AEM 6.4 (or later) in the core component. ACDL will most probably be available in Launch in some sort at some point.
• Security & Simplicity : Google EDDL is very flexible but it comes with the price that you need to realize the extra code to adapt everything to your use-case. I find the ACDL actually way more elegant on the API level. Also the fact that the inner logic is hidden make it more secure on the front end side. It contains a bit more methods and they are easier to be called.
• Thought for the future : ACDL has been created to work with AEP and especially with AEP Web SDK in mind. Using the XDM is compatible with ACDL and I would even recommend it.

That being said there may be few reasons you want to use the Google EDDL.

• Size : Google EDDL is about 5 Kb where ACDL is about 50 Kb. The difference is significant but as it can be meaningless if you load it asynchronously. Then it shouldn’t block any resources for your pages.

I hope you have now a better idea on what the Event Driven Data Layer revolution is bringing on your company (tracking) and what choice you do have in order to use it.

Let me know if I miss anything or if I was still unclear on a specific topic.