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.
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.
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.