Adobe Web SDK (Alloy.js) Questions & Insights

At Adobe Summit 2020, Corey Spencer, Adobe’s Director of Product Management over data collection, opened the curtain on the latest set of technologies to come from his group.

His presentation, provocatively titled “With Alloy.js, never tag for an eVar or Mbox again,” revealed a great deal of the direction for Alloy.js and Launch Server Side Forwarding. It also raised a volume of questions sufficient to warrant the creation of a FAQ in the form of a Twitter thread.

Roughly half of this FAQ focused on questions regarding Alloy.js. In this post we’ll tackle just those Qs & As related to Alloy.js. Let’s dive in!

Q1:

Do I need Launch to use alloy.js?

Not as a tag manager. There is a Config ID which needs to be in the data stream (so the edge knows what rules to apply to it). That ID is created in the Launch UI but it is a new section separate from the tagging UI.

Q2:

So I will be able to deploy alloy.js anyway I want?

Sure. But Launch will make it super easy to map your client-side variables to XDM.

My take on Q1 & Q2:

TL;DR
      • Most companies will continue to use Launch with the AEP Web SDK extension to benefit from alloy.js.
      • Most Launch properties will transition from using these extensions:
        • Experience Cloud ID Service
        • Adobe Analytics
        • Adobe Target
        • Adobe Audience Manager
    …to using only the AEP Web SDK extension.
    • Search Discovery’s Data Layer Manager will continue to provide value and will ease the transition.

Discussion

While it will be possible to create a website tagging solution using only Alloy.js, most companies will use Launch as the TMS with the AEP Web SDK extension, which brings Alloy functionality into the Launch UI.

Launch makes alloy.js easy to use and it provides additional functionality that alloy.js does not provide.

For example, Launch detects browser events and user interactions that alloy.js does not (and should not) detect, Launch implements 3rd party tags that alloy.js does not (and should not) implement, and Launch manages development and publishing workflows whereas alloy.js does not.

With nearly zero overlap in functionality, Launch and Alloy.js make a great team.

So if Launch and alloy.js go together like peas and carrots, who would want to use alloy without Launch?

Here are a few scenarios where alloy.js without Launch makes sense: 

    1. Non-Launch TMS users – If your company uses a TMS other than Launch, you’ll be happy to know that you, too, can benefit from alloy.js.
    2. Online platform builders – If your company provides an online platform and you wish to include embedded measurement, alloy.js will suit your needs quite well. Since alloy.js supports multiple instances/configurations, your analytics and your customers’ analytics will be able to coexist without conflict.
    3. Minimalistic byte counters operating in low-bandwidth environments – Those needing the absolute leanest, fastest, most stripped-down implementations will be pleased to integrate directly with alloy.js.

Q3:

So the data has to be in XDM?

Currently yes. But think of XDM as a format, not a standard. You can use our suggested schema in XDM or create your own. If you’re old school AA, think of it as putting the SDR in the interface.
Here’s how to think about this – Alloy.js communicates between a web browser and the Adobe Edge Network. The lingua franca of this communication is XDM. XDM requests go UP from the web browser to the edge. XDM responses come back DOWN from the edge to the web browser.

What is this XDM of which you speak?
XDM is just a specialized JSON string. XDM is simultaneously strict and flexible.

STRICT – XDM specifies the structure of a JSON envelope. This basic structure must be followed.
FLEXIBLE – XDM provides the ability to handle your custom JSON within it.

Alloy.js handles quite a bit of data collection for you. Device, environment, and other technical properties are automatically included in the XDM that it sends to the edge.

Q4:

Does my client data layer have to be an “Adobe Data Layer”?

No. The data that hits our edge currently needs to be XDM. Your data layer can match our XDM if you want to keep it super simple, or you can map your data layer into XDM client side. Launch can help with that.
This one is tough to decipher. The word “currently” in the answer seems to portend some future functionality. I can’t wait to see what happens here.

Q5:

Do I have to buy Adobe Experience Platform to use the new web SDK?

No. The official name is Adobe Experience Platform Web SDK. The mobile SDK is the same (change web for mobile). Despite the naming convention, neither require Adobe Experience Platform to be purchased.
Here’s what’s cool about this answer: Beyond not requiring users of alloy.js to be users of Adobe Experience Platform, the subtext here is that alloy.js is a single library that will support you on your existing product set (Adobe Analytics, and/or Adobe Target, and/or Adobe Audience Manager) but also support you when you are ready to take advantage of Adobe Experience Platform.

Thinking about the names, “AEP Web SDK” and “AEP Mobile SDK,” I think it’s fair to predict that we will see a future with other SDKs that follow the alloy.js pattern. Remember how I described alloy.js above but replace “Alloy.js” with “AEP Web SDK”:

The AEP Web SDK communicates between a web browser and the Adobe Edge Network. The lingua franca of this communication is XDM. XDM requests go UP from the web browser to the edge. XDM responses come back DOWN from the edge to the web browser.

Now replace “AEP Web SDK” with “AEP Mobile SDK” and “web browser” with “mobile native app.”

Here’s my guess (and I really hope it comes true): In the future we might also see open source AEP SDK’s for NodeJS, Scala, Python, Java, C++ for Arduino (IOT).

Q6:

Do we need to use processing rules for AA?

Maybe. AA needs evars, so the data needs to be mapped. If you use our suggested XDM schema (not required) we can automap much of that. If not, you will have to use processing rules. And yes, we’re talking about a new UI for that.
Screen Shot 2020 05 13 at 11.25.48 AM
2008 called… They want their Processing Rules UI back.
This is another one to watch closely. There seems to be something in the works here. The tone also leads me to think that Corey shares our disdain for the Omniture processing rules UI. Yeah, I said “Omniture” – It hasn’t materially changed since the Adobe acquisition of Omniture in 2009.

Although there is a lot here that we don’t know, what we can take away is this: Data flows from the web browser through alloy.js as XDM to the edge. It flows through processing rules on its way to Adobe Analytics servers. From this, we should also assume that other AA processing (IP obfuscations, bot filtering, VISTA, DB VISTA, and Marketing Channel Processing rules) will continue to function as it does today.

Conclusion /(Praise for alloy.js)

Alloy is excellent at what it does. It communicates between your website and the Adobe Edge network, and it does this with a minimum amount of code and a minimum number of network interactions.

We should be very happy to say goodbye to Visitor.js, AppMeasurement.js, At.js, and Audience Manager DIL code. We will not miss the weight they add to our pages, or the synchronization headaches involved in getting them to play nicely with each other, or the sleepless nights spent wondering about version compatibility. In the very near future, with alloy.js by our side, we’ll only fleetingly reflect on that awkward time in our lives when it took four modules to do the job of one.

To keep up with all the latest Adobe developments, visit our Adobe Extensions page, or reach out to us!

Scroll to Top