Adobe Experience Platform Web SDK

Last year, in April, I opined that a big change was coming for all of us who work with Analytics, Target, or Audience Manager. That change has been in the making for some time. I remember how Bret and Ben dropped some subtle hints some time ago in London. They were clearly exited, and, as I see now, rightfully so!

I’ll dive into the Web SDK over the next few months, and I’ll keep writing about it as I go. Today, I want to draw some lines into the sand: what is the AEP Web SDK? What is it NOT? What is the Experience Edge? How does it all fit together? And are we all going to be working with AEP exclusively in 2021? Hint: probably not.

Bigger Picture

“Platform” or “Adobe Experience Platform”, or “AEP” will be the talking point this year, and likely beyond. It is a big subject, with a lot of different aspects. There are connections to almost any other Adobe application that you may currently be using. So you’ll hear about it, whether you want to or not.

With an impact that big, I think we will inevitably see a lot of myths and half-truths, with some added wishful thinking.

So, let me set the frame for us.

Wait… “for us”? Who is “us”?

Good question! Thank you!

If you work with anything related to Adobe Analytics, Adobe Target, Adobe Audience Manager, or any of the Core Services that are used with those (such as ECID or Launch), then you are part of “us”. Welcome to the family! It’s good to see you!

For “us”, AEP will have two big “streams”, two directions that we’ll have to watch, or that we will want to travel, at some point.

First, AEP comes with the “AEP Web SDK” and there is the “Edge Network”. Both of those will change how we collect data, how we tag our sites.

Secondly, some of the AEP Application Services will provide functionality that is relevant for “us”, such as “Customer Journey Analytics” (CJA), “Real-time Customer Data Platform” (RT-CDP), or “Offer Decisioning” (which doesn’t seem to have an abbreviation so far).

The AEP Application Services shall not be the subject here, but the Web SDK and Edge Network shall.

So I have narrowed it down, but there is still ample space for myths, so let’s take the chopping knife and dissect this thing further.

What is the AEP Web SDK?

In the simplest terms, the Web SDK is a Javascript library that enables you to track data. It replaces AppMeasurement.js (AA), at.js (AT), DIL.js (AAM), and Visitor.js (Experience Cloud ID Service), meaning it handles everything that these four used to handle.

If you are currently using any of those 4 above (or, God forbid, their predecessors s_code.js or mbox.js), moving over to the Web SDK will reduce the number of JS libraries that browsers will have to load on your site. You will also get better control over the timing of the different things that AA, AT, AAM, and ECID do.

The Web SDK comes in the form of a file called alloy.js. A lot of people call it “alloy”. The official name is “AEP Web SDK”, but most people who say “alloy” mean the same thing.

The Web SDK can not only send data to “the big 4”, and render Target Experiences, it can also be used to send data into AEP, receive data back, and do whatever is needed, such as render Experiences.

What is it NOT?

The Web SDK is most certainly not a tag manager. It will not replace Launch, or any other TMS that you would currently be using. The Web SDK will very likely be deployed via a TMS on your site.

The Web SDK is not solely for people who use Platform, either. You can use the Web SDK to send data to AA, AT, and AAM.

The Web SDK is not “server-side tag management”. It is very much a Javascript file that goes into all the pages on your site, usually delivered by classic, client-side tag management.

What is the Edge Network?

The Edge Network is the second part of all this new stuff.

AppMeasurement.js, at.js, DIL.js, and Visitor.js all contact different servers. They use different end points, different edge nodes.

As an example, on my site, the Analytics beacons are sent to ags055.sc.omtrdc.net, whereas the Target calls go to adobeinternalags055.tt.omtrdc.net.

For the Web SDK, engineering built a unified edge network. All calls go to the same endpoint, no matter what type of call they are, usually to edge.adobedc.net.

The great thing about that: you can have a single call send some data, then distribute that data properly, receive things back, and do what’s needed. All in one call.

I think this is where a lot of people start thinking “oh! Server-side tag management!”

They’re not wrong, but this aspect is not necessary for the utilisation of the Web SDK.

The software running on the Edge Network is able to do a lot of things with the data you send through. It can forward data to others applications (such as AA, AT, AAM), synchronously or asynchronously. It can call services and enrich the data (such as IP-based geolocation lookups or device lookups), or to handle consent. It can take data back from other applications, and it can send data back to the client (the visitors’ browser or mobile device).

Essentially, the Edge Network is a modern infrastructure that replaces the old end points, just like the Web SDK replaces the old Javascript libraries.

What is “XDM”?

The Experience Data Model (XDM) is a pretty important part of the setup.

You know how Analytics sends data as eVars, props, and events, all encoded as parameters on the beacon URL. And Target sends mbox parameters, similarly encoded on the URL, or as part of the payload.

Well, for the Web SDK and Edge Network, things have been standardised. There is now one way to send data, and that one way is XDM.

XDM is simply a format that tells you how to send data. The format has some standard values, and there are so-called “mixins” that extend the standard.

For the scope of this article: XDM is the format that Web SDK uses to send data to the Edge Network.

Now does that mean you need an XDM format data layer?

Well, it would be cool…

But since you’re unlikely to have such a data layer, the Web SDK Launch Extension can help read elements from your data layer into XDM format.

Where does Launch sit in all this?

Launch has two jobs, now.

You may have noticed a change in the UI last week or so, when the top left started to show a drop down, defaulting to “Client side”

This is what Launch has always been doing: manage Javascript that will eventually end up in your web site, or rather in the browsers of your site’s visitors.

You can use Launch to deploy the Web SDK, just like you deploy Analytics, Target, or any other application right now: there is, of course, a “AEP Web SDK” Extension.

You will also use Launch to bring it to life, using Data Elements, Rules, and Actions as you usually would.

The second job Launch has, now, is to manage what happens to data that has been sent to the Edge Network.

I think the UI and modalities of this are not quite ready yet for prime time, but the idea is that there will be a UI, in Launch, that will allow you to pass data on, or trigger things to happen, very much like it is done client-side.

For now, if you have licensed Platform, you can set up a bunch of things in Launch so the Edge Network knows where to send your data.

Does this matter to me if I do not have Platform?

Yes!

The Web SDK can be used to send data into AA/AT/AAM, even if you haven’t licensed AEP.

My colleague Aaron Hardy has written a post about how the Web SDK is a much better library than the traditional ones: Boosting Website Performance with Adobe Experience Platform Web SDK and Edge Network

Does it matter right now? Is there any urgency?

No.

Before you decide to migrate, you should check the Progress on use cases that can be found on the Web SDK github.

Since the Web SDK does things differently, it will make sense to play around with it before you tackle any big migration projects.

If you want to read a bit more, I can recommend Simplifying Customer Workflows with Adobe Experience Platform Web SDK, which talks about some design decisions, as well as Exploring the Impacts to Adobe Analytics when Migrating to AEP Web SDK, which talks about some of the thoughts behind a migration.

That’s it for now, and I’m looking forward to diving into this over the next months!