.png)
This post—the first in a series of technical data layer management posts—details the terminology and context surrounding Event-Driven Data Layers (EDDLs). Learn what the data layer is and why to push Event Objects to the Data Layer. Subsequent posts will cover step-by-step implementation examples.
Table of Contents:
- What is the Data Layer?
- The evolution of the Data Layer
- What does an Event-Driven Data Layer look like?
- What is an Event Object?
- Why do we push events?
You’ll get a lot out of this post if you’re
- A Web App Developer being asked to implement an Event Driven Data Layer, or
- An Adobe Launch implementer or manager who’s moving to EDDL, or
- Someone interested in our Apollo analytics management system who needs to socialize EDDL concepts within your organization.
Implementing a best practice EDDL via Apollo or ala carte requires some new ways of thinking. We hope this post can provide context to help demystify and justify the differences of EDDL from the status quo.
What is the Data Layer?
The “data layer” is an industry term that is meant to describe a central place or mechanism that may be used to facilitate the communication of information (data) from one piece of website functionality to another. In application, it most often depicts a globally scoped JavaScript object or array that is used to communicate information from a website application to a tag manager.
The data layer concept came into being shortly after the advent of Tag Management Systems (TMS) and DOM Scraping. Starting around 2011, Tag Management Systems vastly (and quickly) broadened the scope of what data could be collected to feed analytics and marketing platforms. The TMS revolution enabled users to pull any data they wanted from a page using the practice of “DOM Scraping.”
This was good news! However, if I were to choose a movie title to describe the practice of DOM scraping, it would be Errol Morris’s 1997 film, “Fast, Cheap & Out of Control.” The main problem with the TMS/DOM scraping model of implementation is that it (most) often happens without communication between the website application developer and the TMS user. Without clear lines of communication, DOM scraped data collection is a ticking time bomb waiting to blow up an organization’s trust in the data. Simply changing the color of a button could break an analytics tag, which is nuts, but definitely a reality if you aren’t DOM scraping well.
The evolution of the Data Layer
There have been many different patterns used in the implementation of data layers, none of which are governed by any recognized standard.
The earliest data layers were entirely home-grown. They were most commonly just a flat object at window scope with various key-value pairs. The general consensus among implementers was, “As long as the application knows where to put data and the TMS knows where to get it, then the problem is solved.”
Though most of the problem was solved, as application architectures became less monolithic and as more and more data layer consumers entered the playing field, organizations found themselves creating multiple data layers with disparate key names, simply because they weren’t aware that the work had already been done. The need for common practices became evident.
An early contender for standardization was the 2013 recommendation for a Customer Experience Digital Data Layer which was floated by a working group of the World Wide Web Consortium. This effort, the W3C Customer Experience Digital Data Layer (CEDDL), was published in October 2013 and never advanced past version 1.0 of the “recommendation.”
The effort and the document were valuable in helping to cement the idea that the concept of a data layer is good (at the time, there was no broad acceptance of that tenet). Many organizations tried, with various levels of success, to implement data layers based on the W3C CEDDL recommendation. In the end, the recommendation has failed to provide a solution that works well on modern websites.
At about the same time that the WC3 CEDDL recommendation was being written, Google Tag Manager was introduced, and with it came the GTM data layer. The GTM data layer used a markedly different design pattern—one that is now commonly referred to as an Event-Driven Data Layer or EDDL. It is worth noting that Google engineers were involved in the development of the WC3 CEDDL recommendation, but the engineers behind GTM saw a different (and better path).
Aided largely by the introduction of the Data Layer Manager Launch Extension, Event-Driven Data Layers have become the industry best practice for Adobe implementations using Launch in addition to implementations in the Google space using GTM. The event-driven model works in other contexts, too, including mobile, POS, and loT, which makes it even more attractive as a general data model.
NOTE: As we continue in the blog series, unless mentioned otherwise, the term “data layer” will specifically refer to an event-driven data layer (EDDL).
What does an Event-Driven Data Layer look like?
From the standpoint of a front-end developer, an EDDL exists as a JavaScript Array (of Event Objects) exposed at window scope. There is also some management code that (typically) wraps the push method of the array in order to detect and act upon new event objects being added.
As a developer writing code to interact with this array, one must NEVER assume exclusive ownership of the creation and modification of this array. One should ALWAYS assume that there are others interacting with the array and that it may or may not exist at the time that your code needs to reference it. With this in mind, when first establishing a reference to the data layer (named appEventData below),
DO THIS:
<br>// Establish a reference to the data layer named “appEventData”<br>var appEventData = window.appEventData || [];<br>
DON’T DO THIS:
<br>// Don’t do this !!! You may be overwriting an existing variable. <br>var appEventData = [];
What is an Event Object?
As a front-end developer, the word “event” can mean many things. In the context of an EDDL, you will probably hear people ask you to push an event to the data layer. This translates to pushing an event object to the data layer array. An event object is simply an object with a key of “event” and, optionally, a payload. See below.
// Example of the most basic EDDL event object
<br>var simplestEventObject = {<br> "event" : "Simple Event"<br>};<br>// Example of an EDDL event object with payload<br>// The structure of the payload is arbitrary (sort of)<br>var eventObjectWithPayload = {<br> "event" : "Page Load Started",<br> "page" : {<br> "name" : "home page",<br> "title" : "Welcome to Acme Corp!"<br> }<br>};
The examples above are for the sake of illustration only. Technically, these are just objects at this point. They will become EDDL event objects once they are part of the data layer array. The payload exists as any (one or more) top-level keys in addition to the “event” key. Generally, the payload can be anything that can be serialized into a JSON string (if you can run it through JSON.stringify, without losing data, then it’s OK).
Why do we push events?
Now that we have a couple of objects, let’s add them to our data layer. This is done exclusively using the push method of the data layer array. See below:
// ...continuation of examples above.
<br>appEventData.push(simplestEventObject);<br>appEventData.push(eventObjectWithPayload);
Another way to accomplish the same end would be to pass both objects in the same call.
// ...same thing done another way
<br>appEventData.push(simplestEventObject, eventObjectWithPayload);
Feel free to use the push method any way that you like, but avoid manipulating the array in any other fashion.
- DO add data using push.
- DO NOT modify the array using pop, splice, or concat.
- DO NOT modify an array item directly.
The rationale for this guidance is that EDDL management code (almost always) wraps the push method as a way to trigger processing when new data is added to the array. Most EDDL management code is not watching for mutations of the array caused by other methods.
When we push an event object to an EDDL, we are both adding data and triggering a notification to EDDL consumers. EDDL consumers are most often tag managers such as Launch or GTM but they may be anything that is listening for the notifications.
1. Data layer push with event only (no payload)
As a front-end developer, you may be called upon to push an event without a payload that may be used by an EDDL consumer to trigger some functionality (i.e., create and send a tag to a third party). This is pretty simple to do. In the example below, we will define the event object within the push.
var appEventData = window.appEventData || [];<br>appEventData.push({"event" : "Page Load Completed"});
2. Data layer push with event and payload
As a front-end developer, you may be called upon to push an event that includes a payload. In this scenario, the pushed event object not only communicates that something happened, but it also conveys some context about the event.
var appEventData = window.appEventData || [];<br>appEventData.push({<br> "event" : "Form Started", <br> "form" : {<br> "id" : "F_6543",<br> "name" : "Apply for Financing"<br> }<br>});<br>
Keep an eye out for future posts in our EDDL Guide, wherein we’ll get really technical and include implementation how-tos, advanced considerations, Launch and DLM activities, Google Tag Management activities, and advice on structuring payloads and troubleshooting.
