Lots of questions about the new Adobe Web SDK (alloy.js) bouncing around. I’ll try to answer a few.— coreyspencer (@coreyspencer) April 8, 2020
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!
Do I need Launch to use alloy.js?
So I will be able to deploy alloy.js anyway I want?
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
- Search Discovery’s Data Layer Manager will continue to provide value and will ease the transition.
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:
- 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.
- 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.
- 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.
So the data has to be in XDM?
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.
Does my client data layer have to be an “Adobe Data Layer”?
Do I have to buy Adobe Experience Platform to use the new web SDK?
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”:
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).
Do we need to use processing rules for AA?
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.