Event-driven data layers with Adobe Launch

What's the story

The aim of this article is to give you insight and a few different options for integrating event-driven data layers (EDDLs), such as Google Tag Manager's dataLayer object with Adobe Launch; something that isn't immediately obvious out of the box. Loop Horizon have used event-driven data layers (EDDL) with a number of clients. In some cases, clients who are using Google Tag Manager, which is underpinned by the event-driven dataLayer object. In other cases, clients migrating away from GTM, usually to Adobe Launch, whose sites are heavily integrated with GTM's dataLayer. And in other cases, clients who are migrating to an EDDL from a customer experience digital data layer (CEDDL) (the old W3C-type data layer).

If you're reading this, we can assume a certain level of knowledge, but this article from Jim Gordon gives a nice overview of EDDL vs CEDDL. TLDR version though: an EDDL pushes data / objects into an array / queue; you can subscribe to these push event in order to trigger rules in your tag manager.

A CEDDL does not emit events (as it is an object rather than an array), instead relying on browser-level events (e.g. DOM ready) to prompt the tag manager to collect data. Data is passed into the data layer object, which is continually overwritten as new data becomes available.

Adobe Launch and the EDDL

Google Tag Manager natively integrates with an EDDL ‚ Google's dataLayer array. This dataLayer array underpins the entire tag manager. You can natively hook onto events passed to it, and any data sent with those events.

Adobe Launch does not natively integrate with an EDDL. This isn't a criticism of Launch, it's extensible and can be made to fit your needs easily. But this lack of a clear way of doing things, means it's easy to do things the wrong way (or at least in a sub-optimal way). That being said, it also means it's easier to customise Launch to the way you want to do things.

The easy(ish) option

Launch has extensions which expand the functionality of Launch designed to hook onto an EDDL.

Adobe Client Data Layer

This extension integrates with Adobe Experience Manager's Core Components, so if you're using AEM, it's a good option.

However, you can also link it to any EDDL you're running on your site, and it will give you a suite of event triggers, data elements and rule actions. It will also compute your EDDL array down to a single object, to all intents and purposes, creating a CEDDL giving you the best of both worlds; the ability to tightly control event triggering and avoid race conditions from the EDDL, and the ability to combine data from multiple events via the CEDDL.

Unfortunately, there are three key downsides that I found with this extension.

The first is that it seems to take over your data layer. It automatically creates an object called adobeDataLayer, and if the location of the data layer you want this extension to work with differs from that, it copies the adobeDataLayer object into your data layer.

This might not be an issue in most instances. But if you're migrating from GTM (for example), and want to maintain your usage of Google's dataLayer object (or if you just want to use dataLayer as your data layer location, because so many tools natively integrate with it), you can't really use the Adobe Client Data Layer extension. When we tested, using the Adobe Client Data Layer with Google's dataLayer array caused all the Google suite of tools to stop working; Google Analytics, Google Ads and so on.

The second issue is that it doesn't seem to be great at handling race conditions. The computed data layer it generates can be referenced via data elements but takes time to process. We found that, if your data layer has multiple events pushed into it in very quick succession potentially in an undefined order (that is to say, events may be pushed in A>B order or B>A order depending purely on how quickly certain resources load), there's every chance that data will be missed or referenced incorrectly.

And on the flip side; while you can reference data directly from the event object, see above if you need to combine data from multiple events together.

The third issue is that you cannot access the event name from the data layer; the one that triggered your rule in Launch. It's a minor point, but if you want to use multiple data layer events to trigger a single rule (for example, when your normal page view happens and when a user first consents to allow cookies), or you simply want to collect this information dynamically without having to hardcode it in each rule, there is no way to send information about which event triggered your rule.

(My old colleague Andrew would disagree, but his innovative solution is nonetheless subject to race conditions, as it relies on Adobe Analytics to reference back to the data layer array, if another event has triggered between the event name you're interested in and Analytics processing that event, you lose the data.)

EDIT: after posting this article, my old colleague Michael Schubert contacted me to let me know that using "event.message.event" in custom code / the launch interface allows you to access the event data from the Adobe Client Data Layer.

Google Data Layer

Hot off the press (it's still in beta at the time of writing) is this new extension from Adobe.

It's very similar to the Adobe Client Data Layer extension, but it looks to solve the downsides we found:

1. It leverages Google's own helper function, so it doesn't break Google tools using the dataLayer

2. Though we have not tested extensively, from the documentation it looks as though this extensions handles race conditions better (that being said, some recent testing we did indicated that this extension missed pushes to the data layer that happened in quick succession)

3. You can access the event data, we've tested and printed the event data to console to prove this out

All in all, this new extension looks an impressive new addition to Adobe Launch and a great option, especially if you already utilise Google's dataLayer object.

Data Layer Manager

This extension from Search Discovery happily integrates with any EDDL you may happen to use including Google's dataLayer without overwriting it or making other tools that integrate with your data layer unusable.

It's not as prone to issues with race conditions as some other extensions. It has what the extension calls context aware data elements, which know whether to get the data you want directly from the object that was pushed or from the computed data layer object.

However, unlike the new Google Data Layer extension, it doesn't make the event level data available. It also doesn't allow data layer validation without upgrading to the paid version of the extension. Lastly, it doesn't meet some of the more nuanced use cases I'll cover below.

The hard(er) option, build your own

Given the options above, why would you want to build your own EDDL processing tool? For most use cases you wouldn't. But eventually (and eventually may come faster than you'd think) you could come up against an issue that the above extensions cannot solve.

And at that point, if you've integrated our entire Launch implementation with one of them, you're going to have an issue; the extensions are not extensible in turn.

Here are the reasons why I've built my own.

It's not a back box

By building our own EDDL processing tool, we have direct access to the code it is extensible. None of the extensions give that level of access and understanding. Everything listed below stems from the fact that we have full access to modify the tool we built; the ability to make it fit the requirements, and to meet those requirements from a central location rather than having to employ clunky work-arounds and take on technical debt.

Validation

We built a JSON schema document for one of the data layers we created. We wanted the ability to validate objects passed on to the data layer, and return any errors to the developer console.

This was to make the deployment process easier; to give developers the tools (errors in the console and the schema document) to fix issues themselves, removing a potential bottleneck.

We / our clients didn't want to spend thousands of pounds a year enabling validation.

The answer build your own EDDL processing tool.

Access to event data

As mentioned earlier, we wanted to have multiple events trigger a single rule in this case, the view event from the data layer and changes to consent, so that we wouldn't miss anything when the user initially consented to allow analytics to collect data.

We also wanted to know which of those two events had triggered the data to send.

Prior to the recent addition of the new Google Data Layer extension, the extensions available did not gave enough flexibility or access under the hood to deliver this.

You guessed it, build your own EDDL processing tool.

The ability to send events wherever you like

We had multiple third-party vendors passing data to the data layer, and to maintain ease of use a strict implementation standard of: do not add new rules to the Adobe Launch user interface (UI) unless you absolutely have to.

The Adobe Launch extensions enforce their own extension-specific 'event' trigger to use in the UI. This does not give the flexibility to pick what event type you'd like (custom event, direct call rule etc) or sufficient access under the hood to understand how to access the events by other means; it therefore severely limits your ability to split events into type.

For example, we wanted to process all objects sent to the data layer as events in one location (a <div> element on the page), but filter a subset of them (specific to user consent) in another location (a different <div> element), so we could include multiple data layer events a single rule without:

• Having to fire on every event sent by the consent platform (double firing the rule in most cases)
• Add consent-specific rule conditions that would break the firing of the standard data layer event
• Add a second rule with identical tags, breaking the implementation standards

By building own EDDL processing tool, we could emit custom events to multiple div element on the page, one for the standard data layer events and another for the filtered subset of consent level event, thus allowing us to avoid double firing or having multiple rules to do the same job. That way, we were able to keep the Adobe Launch UI as simple and easy to use as possible.

The ability to process data in multiple ways

The Adobe Launch extensions provide a computed data layer object from your EDDL, to give the best of both worlds (EDDL and CEDDL).

What if you want multiple computed objects though, each serving a different purpose? One main computed object, one flattened object, one to drive product string creation, one to re-format data to new Google Analytics 4 standards, one to package up your data layer and send it to a server-side endpoint...

It would be achievable via the Adobe Launch extensions, but would be clunky, and require a range of rule and data elements to achieve. There would also be potential concerns about race-conditions and missing data.

By building our own EDDL processing tool, we were able to output all the computed objects we needed from a single rule; a range of underpinning utilities to run the whole implementation.

Only process the events you want

Because we had full access to the code, we were able to create lists of events pushed on to the data layer and do different things with them.

Only want to validate the events in your schema and ignore events from third-party vendors? No problem—just provide a list of events to validate and only pass those to the validation script.

Want to process a subset of events to a different div element on the page to allow filtering without requiring rule conditions and setting up multiple rules? Easy.

Want to process different events go different computed objects on the page? You got it.

Handling data processing

Some of the Adobe Launch extensions handle race conditions gracefully and re-process historic data on the data layer array very gracefully. But by having access to the underlying code of our EDDL processing tool, we could determine exactly how it did this. This made de-bugging much easier.

For example:

• We were able to ensure that processing the computed data layer objects happened before the events were emitted, making it more likely the computed data layer object would be up to date

• We were able to log the last event processed by the event listener and stop it from processing that event again in error as we loaded the script into the page—this allowed us to run our event listener script before our re-processing script to better avoid missing data

There are other examples, but the point is—when you know how the data layer is being processed under the hood, it makes it much easier to determine where issues are coming from when they occur.

Wrapping up

To recap, now you should hopefully have some more information about how to leverage an EDDL using Adobe Launch, and some thoughts on the approach you might want to take.

At Loop Horizon, we've deployed new event-driven data layers for a wide range of clients, and worked with others already utilising one.

For some, we've used the Adobe Launch extensions to integrate with their EDDL. For others, we've built our own EDDL event listener. The key consideration has always been: what approach would be the most appropriate for the client—do they have experienced tag management resource; do they have complex use cases; and so on?

The same considerations should inform your own decision about how best to proceed. Please get in touch if you would like to talk to us about:

• Data layer development and event-driven data layers
• Adobe Launch and key extensions / utilities for handling EDDLs
• Google Tag Manager
• Data layer validation
• Consent / cookie management platforms
• Analytics Adobe, Google (including migration to GA4)

Terms used in the article

EDDL - Event-driven data layer

CEDDL - Customer experience digital data layer

TLDR - Too long didn't read