After implementing dozens of Event-Driven Data Layers (EDDLs), I want to share some of my experiences. I want to be clear that while a data layer is critically important to a sustainable implementation, it doesn’t just fix everything. Like any development initiative, a data layer can even create frustration. I’m not going to talk about the W3C data layer. It’s outdated and even mentioning it risks validating its outdated design pattern. In the year since I’ve started talking about the EDDL, Data Layer Manager (DLM) has solidified itself as THE best way to deploy a data layer in Adobe Launch. So let’s talk about that… and about how you can avoid mistakes others have made.
Table of Contents
Not following the spec
It isn’t time for developers to get creative. It’s also the implementation analyst’s job provide detailed specifications with examples. The idea is to minimize data transformation effort when the data reaches reports. That means the data should be transmitted exactly as specified in the report. If it doesn’t make business sense to you (as a developer), ask the analyst. In every data layer implementation, I’ve had data values come from developers that was wrong. This could be for several reasons:
- They think there’s a lot of flexibility and we’ll fix it in Launch
- There are other priorities they would rather tackle (can be misinterpreted as being lazy… maybe some are?)
- They didn’t read the spec
In any case, this should be challenged. This often pushes back timelines. I recommend setting generous timelines for implementation. This is a partnership with our development team. We should be spending this time educating and building personal accountability with them. The long-term health of your data layer depends on you (yes, you) AND your developers understanding how this data layer works. Following the specification exactly means a higher up-front cost in exchange for long-term savings.
Forgetting to add an event
Data Layer Manager (DLM) requires an event to be part of all appEventData.push() call. You can’t use the data if it doesn’t have an event. Often analysts think “Well I am not triggering a rule with this push, so why do I need to add an event?” Fair question. I don’t have a good answer, but each push requires an event associated with it. In the example documentation I posted above, you’ll notice that there’s an event associated with User Detected. That doesn’t mean I’m triggering a server call. That just means I just want to leverage the data when I DO fire a server call. This is a huge mental hurdle for developers and analysts. Always remember to add an event.
Over-complicating it
The EDDL is new to Adobe Launch users. Adobe Launch primarily serves Enterprises. Enterprises move slow. Often implementation design patterns lag behind other, more agile companies. The flexibility of the EDDL can leave too many options. The most confusion I’ve seen is that there can be multiple appEventData.push() events that compose page-level data.
In the example above, these 3 variants do the same thing. Obviously, the W3C does not use DLM and cannot handle events. However, I wanted to show how you CAN structure the entire code snippet into a single chunk like you might be used to with legacy data layers. So why do we break up the calls? Using EDDL Variation 1 doesn’t make you wait for the server to return all of the values before actually populating the object. So if you want to use some data before the Page Load Completed event, you can. Nothing stops you from using EDDL Variation 2 if that makes more sense to you.
Biting off more than you can chew
Implementing a data layer doesn’t mean you have to do it all at once. I’ve seen a number of folks push back because they thought the initiative was too much work. It IS work. However, you don’t have to do it all at once. Break it up into phases. Do page-level stuff first and then think about tackling the rest later. This isn’t an all-or-nothing effort. By just implementing the page-level data, you’re learning. Developers are acclimating and you’re learning as you go. That’s a good thing.
Final Thoughts
My intent isn’t to be dismissive of problems people have with the Event-Driven Data Layer. Instead, I want to help you find ways to make this more achievable. It’s much more achievable than its inferior data layer predecessors and it will set you up for long-term sustainability. Dip your toe in, make sure your developer partners follow the guide, and hold them to high quality standards. You can do it – and please learn from this so you aren’t caught off-guard without an answer.
Also please reach out and hop on a call with me. Contact me on LinkedIn and I’ll be happy to set up an hour for us to chat. I have one of these calls at least once per month and I enjoy it.
I think my biggest complaint is with the events part. I see data layer structure and push conventions either try to make separate discreet calls for each event, (e.g. variation 1 in your image) or something along the lines of variation 2, where all of the payload is merged, EXCEPT the events.
Variation 1 – AA charges by the server call, so V1 isn’t very friendly to this approach. Also, depending on how variables are scoped and what you are trying to do in reports, there may be limitations to you in the reports, because of data being split up into multiple requests. Other report tools (e.g. UA) don’t really suffer from this sort of thing. But AA is a common tool many people touch. But should data layer standards bend to accommodate AA, or the other way around? Good question…
Variation 2 – This is more friendly to AA, but it in general, it’s less complete. V2 doesn’t _really_ indicate that the previous events actually occurred.
An example to illustrate my beef: Site registration. Registration form complete, where perhaps a login, registration, form complete, and page view can all happen at the same time (from a UX perspective). V1 gives you all the data, but has its caveats – potential server costs (or, since multiple requests to the server, also more potential for data loss due to random internet hiccups). potential report considerations, etc. V2 – well which event of those 3 would you put in the payload? Page Loaded Completed? Where is the indication that the registration was completed or the login happened?
To solve for this, I like to instead make “events” an object, e.g. “events” : {“registrationComplete”:true, “login”:true, “pageView”:true} this is more AA friendly, since it will merge events into a single payload with the rest of the data merged, and AA itself already accommodates multiple events at the same time in s.events. I think the main downside to this is it is not natively supported by GTM’s structure (GTM requires a single “event” : “string” to hook triggers to). For this, I usually just pop a generic/static “event”:”trackingevent” or whatever, and then have more granular Variables/Conditions eval the “events” object.
Well overall, I actually do think maybe Adobe needs to rethink its paradigm a bit. Websites have changed over the years. What made sense for full mostly static page load websites 10+ years ago doesn’t make as much sense for SPA driven sites of today (or for years now, really). The whole concept of a “page” is getting pretty outdated. But it’s hard to just write off a big fish.
Good points, Josh! One misconception of Variation 1 is that there are server calls with each event. There’s actually a single server call with Variation 1 that occurs on Page Load Completed. Website server calls (non-AA) might actually be reduced because we’re leveraging the data as it’s available as opposed to grabbing it at a different point.