Make Launch Better: The Web SDK Extension

If I could have anything in 2024, I would like for Adobe to completely redo their Web SDK extension in Launch (Data Collection Tags). This article is not an instruction manual on how to use it. In fact, I’d like to just forget about that for now. Some friends and I were discussing AEP implementation best practices and how there probably won’t be anything universal and fool-proof for a while. Makes sense – every organization has different needs, this stuff is brand new, use cases are still emerging, etc. Then I listed out the 5 or 6 ways someone could send data from a data layer to AEP and it kinda dawned on me that we’ve got a bit of a problem here.

The problem isn’t that we’re missing best practices or solid recommendations. The problem is that the extension doesn’t provide an intuitive way to send the data to AEP in the first place! Forget about variance in the organization process – we need to solve for THIS! This would help EVERYONE! And I have some ideas to help get it started.

Too Many Options

You have like 5 or 6 realistic options to send data to Web SDK:

1. Create an XDM Object Data Element for every single rule and use case
2. Create a single XDM Object DE and conditionally populate every field with other DE’s
3. Create a template XDM Object DE and augment with Variable DE + Merge DE
4. Map your data layer directly to the schema (skip the Data Element step altogether)
5. Send your data layer directly and map in data prep
6. Screw it… everything’s custom code

None of these options jump out at me – and they all seem viable. I could literally make a case for any of these. My personal preference is option 3, but I won’t die on that hill. If I’m new to AEP, I’m struggling to find the best way to send a server call. I love the flexibility of sending data to AEP, but we need a more obvious “state-sponsored” push.

So what’s the problem with 6 ways of doing it? Just pick 1, right? It’s obviously harder than that. Each method has its own pros/cons – but let’s think deeper than that. Within each method there are use cases where you have to deviate from the standard. So instead of solving problems for 6 types of implementation methodologies, you’re now solving for exponentially more problems because each method will have its own nuance to manage. All of that said, in a perfect world I’d update the Web SDK extension to allow merging of any number of XDM objects within the rule (like a Merge rule action). This gives users the flexibility to create layers of data to squish together and keeps the mental workflow in 1 place instead of 2 or 3 different places.

Old Design Patterns

In the extension, there is an option to Enable click data collection. This sounds important. Why wouldn’t I click it? I want to be able to track click data. Well, turns out this enables click tracking on all anchor tags, area tags, outbound link, and download links. Sounds convenient, right? Maybe in the Adobe Analytics world, where you were setting a bunch of variables with doPlugins. For whatever reason, this feature made its way into the Web SDK extension (likely for AA users) which forces people to use custom code to modify the XDM object that’s sent to AEP. So now you have a bunch of different design patterns (extension toggle, custom code, etc.) to achieve the same outcome. Toggling this option should require written consent. We need to move on from Adobe Analytics design patterns.

Final Thoughts

My post from last month talked about the AEP mindset. What I LOVE about AEP is how it’s packaged and forces decisions users make closer to where you achieve business value. I don’t want to spend 20 hours debating how I should send server calls – or how I should track clicks. The longer I spend in the phase, the less time I have to actually create value with data. That’s why this matters… like… a lot. This isn’t a feature request, but instead an Adobe-advocated workflow to get data from point A to B. The current extension checks EVERY SINGLE BOX one might want to check when building out an implementation. It’s like all of the switches and dials of an airplane cockpit. We’re happy that the functionality is there, but desperately needs architecture centered around the user.

“Jim, why don’t YOU just build it?”

The obvious answer here is that this is fundamental to an implementation. Trusting some third party to build an extension to manage it is irresponsible. I mean, when was the last time I pushed an update to Tagtician? Hasn’t been since the birth of my last kid. At the end of the day, Adobe is investing heavily into AEP – and Adobe Launch needs some of that investment. Where would I prioritize that investment? 2 very specific, consequential places:

1. ACDL extension (yes, I know it was built by ACS)
   • Make this Adobe’s official recommendation (along with using an EDDL)
   • Add integrations with other Adobe tools to make it more turnkey
   • Make it prettier and more intuitive
2. Web SDK extension
   • Pick 1 implementation method and design an intuitive workflow around it
     • Allow other methods, but deprioritize them in the interface
   • Deprioritize other edge case features in the interface

Pretty please?