Event-Driven Data Layer (EDDL) Demo

Since posting about the EDDL (Event-Driven Data Layer), I’ve gotten a lot of questions about how this works. If you’re a user of Google Tag Manager, you’re likely already familiar. For everyone else, this concept might be a little foreign. For instance, on the surface it doesn’t seem as readable as the W3C. I want to take this opportunity to show you how the EDDL works using Search Discovery’s Data Layer Manager. Note: This won’t work if you have an ad blocker enabled. Disable it if you want to see a functioning example – I don’t run ads on my site.

Page Data

The first thing we’ll cover is how to load your page data. You might be used to creating the JSON object at the top of your page with the W3C recommendations. Fortunately, Data Layer Manager seamlessly integrates with Adobe Launch. All I did was press the “Install” button in the Extension catalog. For starters, I want to pass in data about my page.

"event":"pageData",
"page":{
  "articleName":"EDDL Demo",
  "articleCategory":"Data Layers",
  "authorName":"Jim Gordon"
}

I can get this information pretty quickly from the server so let’s go ahead and pass that into my EDDL. This is the code that actually makes stuff happen. It’s just appEventData.push([the above JSON]):

appEventData.push({
  "event":"pageData",
  "page":{
    "articleName":"EDDL Demo",
    "articleCategory":"Data Layers",
    "authorName":"Jim Gordon"
  }
})

Let’s use that as a starting point for our data layer below. Look familiar? It’s a JSON object – exactly like one you might see in a traditional data layer. This is what’s called the computed state. If you know how to access your browser’s console, you can type appEventData.computedState to retrieve this object (if Data Layer Manager is installed).

This will follow us around for a little bit while we build onto it. We’ll be building this entire thing with one function: .push(). We’re not explaining anything else to our development team – we’re delivering one function. That’s all we have to document. The page information isn’t enough, though. I want to collect more data about our logged in users, so let’s pass in some more parameters.

"event":"userData",
"user":{
  "userId":"12345ABCDE",
  "registrationDate":"7/11/19"
}

We want to add the above object to our data layer. Each time I pass information in I need to specify an event name – even if I don’t use it to trigger a rule in the implementation.

appEventData.push({
  "event":"userData",
  "user":{
    "userId":"12345ABCDE",
    "registrationDate":"7/11/19"
  }
})

Click here to push it into our data layer.

Our data is passed into appEventData’s computed state. We can even replicate the W3C recommendations with the EDDL! You might have also noticed that we passed an “event” parameter with each of those objects. While you might not do anything with the events, they’re required with each push. That’s so users don’t unintentionally augment the data layer object.

Not just that, but event handling is baked directly into DLM. In a perfect world, I might trigger all of my rules with data layer events. Let’s pretend that I’m done with compiling my page and user data. My company’s pageview is defined as the event that takes place after page and user data has completely propagated. I don’t know what order they’ll propagate, but my developers have configured the EDDL to trigger a completion event when the server stuff is all done. My rule event configuration looks something like this:

To trigger that event, I’ll simply push the following code to my data layer:

appEventData.push({
  "event":"pageLoadCompleted"
})

Click here to push it into our data layer.

Nothing was actually passed to the computed state. That’s because all I was doing was sending a signal to Adobe Launch that an event was triggered. Open your debugger (like Tagtician) and you’ll see that a Page Load Rule called “Page Loaded” fires when the “pageLoadCompleted” event is triggered. Click on it again with your debugger open to test it out.

That’s how an EDDL works. For posterity, let’s look at one more example.

Non-Pageview Stuff

We can handle pageviews. Wonderful – so can the W3C. The beauty of the EDDL is that the same coding pattern works with EVERYTHING. Signing up for email communication is important to our business. Let’s track it through the data layer to ensure our data is consistent. We want to know their hashed email address and the form name.

"event":"emailSignUp",
"data":{
  "hashedEmail":"12345ABCDE",
  "formName":"Marketing Communication"
}

Let’s build the rule.

Note: I could have named the event “Email Sign Up” instead of “emailSignUp”… but I thought about this half way through the article and didn’t feel like changing it.

And here’s the code I hand to developers… look familiar? In your documentation, you would ask the developers to run this code on a successful sign-up.

appEventData.push({
  "event":"emailSignUp",
  "data":{
    "hashedEmail":"12345ABCDE",
    "formName":"Marketing Communication"
  }
})

Click here to push it into our data layer.

Open your console and you’ll see I’m logging the Data Elements.

Putting it all together

Let’s do one more complete example. This one will be really tricky. We’re working with a single page app and need to track a click on a button, clear the variables before the next screen, then load the new page data. The documentation might look like this:

For every new screen, first load the following code:

appEventData.push({
  "event":"Page Initialized"
})

Then grab the data from the server:

appEventData.push({
  "event":"pageData",
  "page":{
    "articleName":"[article name]",
    "articleCategory":"[category name]",
    "authorName":"[author name]"
  }
})

appEventData.push({
  "event":"userData",
  "user":{
    "userId":"[user id]",
    "registrationDate":"[registration date]"
  }
})

When it’s finished, let us know with the following code:

appEventData.push({
  "event":"pageLoadCompleted"
})

Fire the following code when the user clicks on a CTA:

appEventData.push({
  "event":"CTA Click",
  "data":{
    "linkName":"[link name]"
  }
})

Pretend that a user clicks on a CTA and goes to the next page. I’ll log it all in the console so you can see how it all works.

Click here to push it into our data layer.

Okay, so what’s happening behind the curtain? First, the CTA rule fires. You’ll see the link name data logged in the console (I added a 0.25s click delay so the custom code had enough time to execute):

Each page, whether it’s a SPA or not, will start with a data layer reset. Even though it isn’t necessary on normal page loads, it doesn’t hurt anything. By doing this, I can keep documentation consistent even on hybrid websites:

Then our pageview fires (same one from higher up in the article). That’s it. The page loading instructions don’t change from site-to-site. It’s the exact same. Feel free to copy my documentation from above. The coding patterns do not change. Everything is event-driven… hence it being an Event-Driven Data Layer.

Final Thoughts

Both the DLM and GTM EDDLs are excellent. The integration of DLM into Launch is nothing short of stellar. Unless you already have a fully-engineered data layer (and everyone is trained on it), you should be using an EDDL. It’s intuitive, easy to communicate, and will be the standard for the foreseeable future. I used DLM for this article because this is more critical for Adobe Launch users. I will conduct a comparison between DLM and GTM’s data layer in a later article. They’re similar, but also have some key differences that are worth noting – specifically when it comes to QA. Until then, I hope this helped connect some dots!