Moving to AEP Web SDK in 2021

Hello world,

It has been a while since I have written on the implementation side.
I spent most of my last year learning the new rope of Adobe Experience Platform and the solution is quite a beast in itself. It is evolving fast and many that have written on it needed to change their text in the next months.

Busy learning and afraid of creating short-live content, I delay my come-back to the analytis / tracking community.

However, during that time I have seen so many people struggles with the new solutions proposed by Adobe.
Customer Journey Analytics vs Adobe Analytics, AEP Web SDK vs Legacy implementation, AEP Web SDK vs Launch, Launch vs Launch Server side?

Side note: I am using Launch, even though the official name is Tags now…. but I am not ready for that yet.

So many new elements have come during the last months on AEP Web SDK and I can understand that it is pretty confusing for newcomers. Imagine that on top of that, some people have to deal with GA 4….

My ambition during this article is to try to clear out some of that confusion, by giving you my opinion on the matter. This not the official Adobe recommendation so your representative may be giving you different information.
Also, it may be kind of short live as some new elements may come in the next months and make some of my arguments obsolete.

AEP Web SDK vs Launch (& vs Launch Server Side)

Starting with the easy one: Adobe Web SDK is not a version of Launch, or a Tag Manager. You will need a Tag Management System (TMS) to use the Adobe Web SDK. (And Launch is a good one 😉 )
The Adobe Web SDK is the data collection library that you will need to use for ingesting web data into AEP (especially Experience Event – we’ll come back to that).

It can also be used with legacy solutions (AA / AT) but with some limitations, and we’ll come back to that as well.

The AEP Web SDK work with a server layer that orchestrates several services around the Data Collection. I briefly explain some in this article (debugging AEP Web SDK).

The important thing to know is that Launch Server Side is actually using the data collected by the AEP Web SDK to transfer that data to the different endpoints you want, via the Server Side capability.

Some other elements to know about this is:

• Launch is free of use
• Launch Server Side requires a license (it costs money to Adobe to collect, modify, duplicate or/and redirect messages to other services)
• AEP Web SDK doesn’t cost anything for the requests:
  • If you send data to AA, these requets will be charge as AA requests (same for AT or AAM)
  • If you send only to AEP, AEP works with Data Storage and Audience size, so technically the hit doesn’t cost you much, the storage and the incrementing profile information stored is what cost you money.

These elements are quite disturbing when we are used to pay per hit, now each hit containing a different message size will not have the same cost.
But that is a different discussion…

AEP Web SDK replaces all legacy libraries

Yes but…

When it all started, the AEP Web SDK was supposed to be used for sending data to Adobe Experience Platform.
However, at the same time, for large Adobe customers, it is becoming quite an annoyance to deploy always more scripts on their website for a single organization (Adobe).
I mean, “Are trying to compete with Google or what ?”

Also, there are so many dependencies between libraries, ECID, AA, AA SSF, AAM, Target A4T, that it makes it quite difficult for large deployment of solution on client website. Especially as we are turning into an async environment and support there require a new generation of scripts (coming back to that).

So the Product Managers / Engineers (I guess) had a good idea.
What if we were to combine all of the libraries into one?
So we can make one library to rule them all (->the solutions).

This has been the main selling point for AEP Web SDK and, in my opinion, it was a mistake.

The reality crashes with the ~10 years of legacy code and use-cases development that the AppMeasurement (Analytics), at.js (Target), DIL code (Audience Manager), ECID Service, and the Adobe optin service have been built around.

The task was enormous (and it still is) and the expectation were/are too high.

The workload to migrate (I insist on that word) from the old libraries to the new one has been underestimated on most of the project and we will come back to that.

There are several limitations to using the AEP Web SDK vs the original libraries.
Some of these limitations are documented, some of them you need to read between the lines of what is supported to understand what is not.

The current status:

• AEP Web SDK can automatically mapped dimension to AA (link)
• AEP Web SDK can do personalization with Target (link)
• They also have developed their own consent different that the adobe optin (link)
• No clear documentation on how everything is playing out with Audience Manager (moving to RTCDP is the solution though)

This makes the implementation of AEP Web SDK to support all old use-cases pretty challenging.
But don’t get me wrong, for 90% of the customers, that will be good enough, but strangely I happen to deal with the remaining 10%.

AEP Web SDK is changing the game for data collection

Yes, and in a big way.

Changing to AEP Web SDK implies creating XDM schemas, before even starting data collection and during data collection if you do not want things to break (see that later).
It implies quite a preparation before you start with data ingestion in AEP. It is a new paradigm for visualizing the data and requires new skills on data structure. It also implies some understanding of how Platform works and its limitation…

There is already a good article from my colleague Benedikt Wedenik on the AEP Web SDK with the Adobe Client Data Layer. (Trio to a scalable implementation) I believe that this is the best example on what is possible with a good amount of preparation and execution, definitely worth a read.

To say the least, having an XDM payload ready at data collection time is quite an achievement, as such messages can be complex to create. It requires coordination with your website developers, but also quite some skills on JS to merge and edit objects.

Thankfully, a service is coming that will help you do some modification of your message to conform it to the XDM schema. This service (the mapper) will help you decouple the creation of the XDM and the data collection process.

Nevertheless, the switch in your mindset is important as several paradigms changed:

Your tracker is always there and flat

You used to have a s object available that you could add or remove dimensions or event to it.
With the AEP Web SDK you do not have such tracker available.

You are using Alloy to send data but managing the data is done in a separate way (here again, I can only recommend the approach discussed here).

Having an Event-Driven Data Layer approach is definitely worth consideration as it should make your life easier when dealing not with variables but with complete objects.

Empty strings are ignored

In Adobe Analytics, whenever you were sending empty strings (“”), they were cut directly at data collection time. That was an easy thing to do in case you wanted to avoid capturing some elements.

In AEP Web SDK, empty strings are just strings so you will end up sending (meaningless) data to AEP via this technique. You will need to clearly up your game on managing your implementation objects.

AEP Web SDK does provide some cleaning capabilities if part of your XDM object is having a null value. But I would not count exclusively on that and try to stay clean beforehand, by not adding irrelevant object.

Sending unset dimension are ignored

An element that was also nice in AA is that you could send whatever you wanted through that beacon. If it was not configured in Adobe Analytics admin interface, it would not have been captured.

With AEP, if you are sending elements that are not defined in your schema, it will make the call fail at ingestion time.

Promise me everything will be fine

AEP Web SDK has been written around promises structure. Therefore, you can make it live in an async world quite easily.

However, it makes it using quite challenging to newcomers in JS implementation.
OK, I am not the top notch JS developer, I abhor the language, but I do not think that I am that bad at writing JS or understanding it. Nevertheless, working with promises require some mindset change and even if it solves the callback hell, it creates a chain of hell :D.

When do you switch to AEP Web SDK ?

“OK Julien, you are not really selling it right now.”
I believe that expectation management of what AEP Web SDK is capital to understand when to use it and when to wait for your organization to move. That will lower deception when switching and giving you more appreciation of the work required before migration (XDM schema, Upskills your implementation team, platform training, etc…)

AEP Web SDK is a great library, you can see the potential; Event Merge ID, Server Side, BYOID, Personalization on the edge, we’ll cover them later. Nonetheless, I believe, AEP Web SDK should be used primarily on the use-cases that implement Adobe Experience Platform.
If you want to send events to AEP, this is the way to go.

Moreso if you have a connection with Target and you want to take advantage of the “Personalization on the edge” that is coming. It should provide the capability to realize real-time personalization based on several data points from the user profile. This will be powerful and performant. Making real-time testing scenarios (Next Best Offer, Next Best Action) just click away.

AEP Web SDK is the future for Adobe solutions driven by Platform, using it to fuel the legacy solution is not something I would recommend.

I know that some people will bring the value of the ~300 ms gain on the loading of the library (vs all the old ones), or the coupling of the different solutions made easier via promising.

In my opinion, this is not seeing the detailed use-cases that the legacy libraries are covering and underestimating the change from sync to async move.
I cannot guarantee that you will not have something not supported or not documented (hello merchandising eVar”) on the Web SDK for your old solutions use cases. And this is not because the team is lagging behind or just having a good time, I can tell you that they have a lot on their plate and I rarely have seen so much new cool features coming that regularly.

That being said, for the legacy libraries, you will always find support, and these libraries are not expected to be deprecated any time soon.

Improvement Path for AEP Web SDK

After all that, there are some elements that I wish AEP Web SDK will bring in the next future that will allow even a better experience for some (major) use-cases. Again, my opinion.

The team is working really hard and in a very transparent way (check out their public GitHub: https://github.com/adobe/alloy/projects/5) for developing the AEP Web SDK.
So I am going to list them, and from there you can deduce if your use-case is supported or not:

• Augment AEP Web SDK information with the Target experiences returned (idea submitted)
• Enable capability to send Profile Information (currently we can only send to Experience Event dataset for legal compliance concern)
• Support Adobe Opt-in module (They have developed their own consent system)
• Support capability to send Pixel tracking (no need for a body message for AEP – AAM & Default Tracking use-case)

AEP Web SDK Future is bright

Reading all of that, you may be wondering if you should move to AEP Web SDK at all.
The answer is yes! Definitely, when moving to Platform because there are so many important use-cases that the AEP Web SDK will be able to solve with Adobe Experience Platform.

The potential of that library is immense and I will list some of the awesome things that I know this library is solving or I heard are coming very soon (again you can check their public roadmap):

• Server Side Forwarding: This is a basic as I already discussed it but you need to have AEP Web SDK to enable this feature. This is going to be used in few years. How much gain from onsite implementation you will get.
• Bring your own ID : You will be able to use your own ID for data collection, no need to generate an ECID anymore. (!!!)
• Personalization at the edge : Leveraging AEP Data Science capability on the edge (!!)
• Data Mapping tool : A service that will provide modification capability before data land to the AEP Platform.
• Event Merge ID : This will come at some point and will provide the desire merging option we are all waiting for.
• Server Side Web SDK : A version of the library to generate Server Side tracking.

I am not a PM or have any close relation to people developing the tool, I just follow the community so I cannot provide any date or commitment on how exactly these features will turn out to be, but the fact that they are working on it, it means that they are on the right track. 🙂

Summary

This article is a tentative to explain to you what is the AEP Web SDK and for which use cases you should consider moving to it, in my opinion. As you can see, for me, it is quite easy to answer the question to move to AEP Web SDK or not (using AEP or not). In any case, if you happen to implement it or not, AEP Web SDK is a great library and you should definitely starting looking into that beast.