alloy.js. This user guide provides documentation for this implementation method.
The Experience Platform Web SDK is part of a collection of tools which make up the Adobe Experience Platform Edge Network. The Edge Network consists of the following components:
adobedc.net) and receives a single payload back for data and experience delivery.
On the server-side, a unified edge gateway and a common platform service framework help make it easy to deploy new capabilities into this real-time computing environment. This architecture:
A single consolidated edge system allows customers to manage their advertising, marketing, or personalization campaigns across all channels as an integrated experience. It also allows Adobe to deliver services with lower total cost of ownership for customers. The edge system is designed to accommodate most types of data, allowing you to map your own data model to be ingested by multiple Experience Cloud products.
The following video gives an overview of the Adobe Experience Platform Web SDK and Adobe Experience Platform Edge Network.
The Web SDK is not just a wrapper around existing libraries. It is a new library, written from the ground up to incorporate functionalities of existing libraries. Its purpose is to end challenges with tags having to fire in the right order, inconsistency with library versioning challenges, and better dependency management. It is a new way to implement the Experience Cloud and it is open source.
The Web SDK replaces the following SDKs:
In addition to a new library, there is a new endpoint that streamlines the HTTP requests to Adobe solutions. Before,
Visitor.js sent a blocking call to the visitor ID service, then
AT.js sent a call to Adobe Target,
DIL.js sent a call to Adobe Audience Manager, and finally
AppMeasurement.js sent a call to Adobe Analytics. This new library and endpoint can retrieve an ID, fetch a Target experience, send data to Audience Manager, and pass the data to Adobe Experience Platform in a single call.
The following video demonstrates Adobe Experience Platform Web SDK and Adobe Experience Platform Edge Network in action. The video example uses a single call to Adobe which sends data to Experience Platform, Analytics, Audience Manager, and Target.
During this session, I’ll be walking you through an end to end scenario, for the Adobe Experience Platform Web SDK. The Web SDK will send data, to our next generation Experience Edge Network, which will direct the data to Adobe Experience Platform, as well as experience cloud applications, like Adobe Analytics, Target and Audience Manager. By the end of this video, you’ll have seen, an Adobe Experience Platform Launch Rule, fire a Web SDK Beacon to the Edge, where that data will both populate into our applications, as well as receive a personalization response, from Adobe Target. Let’s get started.
To kick things off, we’ll start an Adobe Experience Platform Launch. Here, I’ll define my Edge configuration, in order to teach Adobe where to send data, from my Web SDK requests that have been made.
Here, I get the opportunity to configure the destinations, for my experience platform data sets, my Adobe Target client code, key settings for Adobe Audience Manager, and, of course, the report suites, that I need to send data to within Adobe Analytics.
From here, I can then move to my Launch property.
Within my Launch property, I can find the extension, for the experience platform Web SDK, and begin my configuration.
As you can see, the most important item, is aligning this Launch property, with the Edge configuration that I just defined previously. Here, I can ensure that all of the calls being made, from the Web SDK are sending data, to the correct destination, depending on which Launch environment I’m in. There are plenty of other settings in here, like privacy, identity and personalization as well.
Once I’ve told the SDK where to send the data, I’ll begin prepping the data for consumption, and Launch this is accomplished by defining a data element.
Think of a data element as Launch’s version, of a dynamic variable that can be used, in both rules and tags, so that data is properly formatted for your tag.
For the Web SDK, we need to format the data, as an XDM object, which is short for experience data model.
To do this, I simply find the preselected schema, that I defined within experience platform, and populate all of the fields that are necessary, in order for me to differentiate, this particular data element within Launch. As you can see, I have the option to use other data elements in order to populate this data, so I could find my page name, data element, for example, or I can also hard code any information, that we need to as well, by just simply entering the values right here within the UI.
Now that the data is formatted, I have to teach Launch, when and where to send this data, to the Experience Edge Network. To do that, I will create a rule in Launch, that fires at the top of my page.
This ensures that every single time, the Launch library is loaded, my tag will fire. You’ll notice I haven’t added any conditions to my rule, so that it ensures my tag fires globally. Now, the last step within my rule, is to actually send an experienced platform Web SDK event. I can reference my XDM data element that I defined earlier, and even check the check box, so that I can render visual personalization decisions. This is imperative for me to ensure, that personalization responses coming from Adobe Target, also are handled by the Web SDK and delivered to the page.
Once I publish my changes, I can head over to the webpage, to see the tag in action.
Here on the webpage, you’ll notice a few important things. First, when I load up the Ghostery plug in here, you’ll notice that there aren’t any trackers, identified on the page. This is because the only technology, that lives on this Luma website, is Experience Platform Launch. From there, we’re using the Web SDK, in order to fire calls server side, to Adobe Analytics, Target, Audience Manager and platform, using Experience Edge Network. However, if we switch over, to the Adobe Experience Platform debugger, you’ll notice that we have both Launch and the Web SDK, available on the site. We can even dig into the calls being made by the Web SDK, in order to identify all of the information, that is being sent into the Experience Edge. For example, we can see the URL, the page name, screen information and browser information.
We can go one step further, in order to apply what we call an Edge trace, where we are tracing what is actually occurring, behind the scenes in terms of that data being mapped, from Experience Edge to, for example here, Adobe Analytics. We can see the report suite ID, that we mapped within our Edge configuration, and then each of the different query parameters, that are being mapped from the web SDK call. For example, I can see that here’s my page name in URL, getting sent directly into Adobe Analytics.
Now, that’s helpful for Adobe Analytics, but next we want to see this in action, and the first place that we love to go, in order to show this technology in action, is thanks to Adobe Target. Now, I’ve set up a very simple target activity, which will personalize this homepage hero, and the text within it based on the type of products, that a visitor is interested in. As you can see, we have this woman, who is meditating on the home homepage. Now, if I instead click through to the men page, in order to show some interest in the different products, that exist on this page and then back to our Luma homepage, you’ll see that we have a personalized homepage hero, not only focused on an image of a man running, but also sharing information about the Luma Men Collection. Now, if I wanted to instead dig into, the women’s selection of products here on the Luma website, I can also take advantage of that same target activity, being delivered by the Web SDK and see a women focused image and text and personalization on the homepage.
To close the loop, we’ll want to analyze the success, of the Luma website and optimization program. We can first head into Adobe Analytics, in order to see the real time data associated, with my visits to the homepage, the men page, and the women page.
In addition, I can head on over into Analysis Workspace, where I can see a slew of data, associated with revenue, card editions and revenue, a fallout of different product information, conversion rates and even a product performance grid, where I can identify each of the key steps, associated with products and plenty, plenty more.
Finally, let’s hit into Adobe Experience Platform, and find the dataset in which I’m sending data. It’s the Pre-zero Luma Events dataset. From here, you’ll recognize, that we’ve had a bunch of ingested batches of data, over the past several days, plus we can even preview our data set, to show how data is being passed, from the Web SDK to experience Edge, all in the experience data model format, so that Adobe Experience Platform, can help users analyze and activate that data.
The Adobe Experience Platform Web SDK, delivers a streamlined approach to sending data, via the Adobe Experience Platform Edge network, to experience cloud applications and experience platform. As you saw, it both simplifies and expedites, the needs of the marketer for both analysis and activation, for delivering the experience business. -
To simplify your migration from any of the existing libraries to Web SDK, Adobe offers a streamlined upgrade path. This path allows you to migrate each individual page of your website to Web SDK without the need of migrating your entire website at once. You can use the Web SDK on a given page while existing libraries reside on other pages. Once you are ready, you can migrate those other pages as well.
AT.jsto Web SDK considerations
Before migrating pages that use
AT.js to Web SDK, make sure to enable the following Web SDK configuration options. These options ensure that the visitor profile is kept while navigating from pages with
AT.js to pages using Web SDK.
After migrating from
AT.js to the Web SDK, remove the
targetMigrationEnabled option from your configuration.