Adobe Experience Platform Web SDK overview
IMPORTANT
At the end of April 2024, the Adobe Experience Platform Web SDK will be removing support for all versions of Internet Explorer.
The Adobe Experience Platform Web Software Development Kit (SDK) is a client-side JavaScript library that allows customers of the Adobe Experience Cloud to interact with its services through the Adobe Experience Platform Edge Network.
Adobe offers two methods to implement the Web SDK:
- The Web SDK tag extension. See the tutorial on how to implement Adobe Experience Cloud with Web SDK for more information.
- Manual implementation using the Web SDK JavaScript library.
This user guide includes instructions on interacting with the Experience Cloud solutions through both the Web SDK JavaScript library and the tag extension, where applicable.
Experience Platform Edge Network edge-network
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:
- Experience Platform Web SDK: A JavaScript library and a tag extension which help you simplify the deployment of Adobe technologies.
- Experience Platform Mobile SDK: An extension to the v5 mobile SDK which allows you to use the new deployment methodology.
- Edge Network Server API: A server-side API which you can use for various data collection, personalization, advertising and marketing use cases. The Server API can be used on servers, IoT devices, set-top boxes, and various other devices.
The Edge Network is a framework for low-latency data collection, pluggable computing, and rapid data activation across all addressable channels. It provides a single consolidated SDK for every channel (web, mobile, server-side), which sends data to a common Adobe domain (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:
- Decreases customer time to value
- Ends the need for “point” integrations
- Improves performance compared to the old libraries
- Decreases costs
- Increases the speed of innovation
- Creates sustained competitive advantages for Adobe customers
A single consolidated edge system allows you to manage your 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.
Video overview video
Watch the video below for an overview of the Adobe Experience Platform Web SDK and the Edge Network.
Transcript
If you’re one of those people who has to get data to Adobe Solutions, or even non Adobe solution, you’re aware of the last four big trends happening.
First, the trend around performance. Everyone’s getting hammered to have the higher performing apps in higher performing sites, milliseconds matter. The next is privacy. The same teams that are in charge of getting data where they’re supposed to be in dealing with performance are also being told to deal with privacy and changing laws, and make sure that the company doesn’t get sued. And then there’s changing technology, the browsers are changing and deleting third party cookies. And of course, the simplicity of data is getting harder to manage. There’s more and more solutions that require data. So this is why we’ve created the new Adobe Experience Platform Web SDK and Adobe Experience Platform Edge Network. It’s the biggest change in data collection and personalization, since the first eVar, which was back in 1998.
So it’s about time for us to shift things a little bit when it came to data collection. Now our objective was simple and simple as in quotation marks because it’s supposed to sound simple, but I can guarantee it wasn’t. The first is we wanted to create one Adobe JavaScript library to replace all of the current ones. And yes, you heard that correctly, to replace at measurement at.js, the visitor ID, all of our JavaScript libraries, replace them with one JavaScript library, not just push them together and squish them together, but really rewrite it from scratch, have one Adobe beacon, have one data stream, have one server side destination, one place that you’re sending your data, not lots of different domains and lots of different endpoints, but one that’s first party manage for all of your Adobe application and Adobe Experience platform and third party use cases to give you total control of your data from the first millisecond to the last.
This is a radical change. And let me express it a little differently. If you’re again or that person who has to get data into Adobe Solutions, you’re used to managing four or five JavaScript libraries. In this representation, what we’re saying is that the sources or channels of data, would be a web SDK, a Mobile SDK or server side API, but that the data that you’re streaming to Adobe should be use case for solution agnostic. That means you should never be tagging a website for an eVar or Embox, or any other felician proprietary schema. Just sending name value pairs, we call this XDM. XDM is our format for name value pairs, but sending name value pairs to one edge network. It’s the one of the largest globally distributed, edge networks in the world. We’ve been doing this since before it was an industry. We handle Disney plus and the apple keynotes and the Super Bowl and World Cup and everything else, one of the largest networks on the planet for collecting data. We’ve never told you about it because we’ve never given you access to do anything on it before.
But today we’re changing that, you’re sending one stream of data to this first party domain managed single endpoint. So it’s sending data to you. And we’re just enabling it. And then we are using this globally distributed edge network to remap and adjust the data to the format’s required for Adobe Solutions and sending it to those solutions in real time. And so this network data goes from in the case of websites, you can follow that top line, it goes from websites and in a solution agnostic format, name value pairs, directly to the platform, audience manager, target or bi directional, meaning the payloads for personalization are coming back through there and analytics if you’re using what we would suggest for name value pairs, you can use whatever you want, an XDM, but if you use what we suggest we can map those things on the fly to common Adobe Analytics variables and then allow you to use processing rules to change anything else you need to deliver.
So instead of spending a ton of time, wrangling code on the site, you’re actually sending easy to understand streams of data to one endpoint, and then mapping it server side to the different destinations and formats that it requires. So if you’ve got, you know, 500, or 5000 sites that need eVar seven turned to eVar 14, you do it in one place at the edge instead of going in to launch and doing it each individually. Now, this new JavaScript library, this SDK, as well as our Mobile SDK, and forthcoming server to server API’s all managed with a launch and make it really easy for you to manage all of this. And what this means is faster performance. Our new web JavaScript library is 80% smaller than using our traditional JavaScript libraries and 70% faster. In fact, you’re not going back and forth with user IDs, you’re able to just quickly add the IDs either on the browser or being forwarded from the edge. It’s privacy is baked in to the first millisecond, we don’t do anything until you tell us to do it across all of the technologies that use this new web SDK. So many technologies are trying to cram consent in from some other direction. And we have a baked in from the beginning.
It’s all first party domain managed. And so if third party cookies are being deleted, it’s not going to affect your first party ID with Adobe. And we’ve simplified everything, you’re sending a simple, easy to understand data stream and then formatting it from the edge. There’s more. So if you’ll notice when I talked about these things about our simple plan one, there’ll be JavaScript library, one Adobe container type, one data stream to one-server side destinations, first party domain, and then all Adobe applications, the Adobe Experience platform and third party use cases. Now I kind of just talked about that really quickly. But we just showed you how we can go and have these streams of data, go to one network and then go to these other Adobe Solutions. And that solves Adobe’s data collection. But your data collection as a customer is much bigger than that. Because you could have dozens if not hundreds of endpoints, that you’re trying to send data to as quickly as possible. Maybe it’s another application for analytics. Maybe it’s your own data lake, maybe it’s some sort of messaging service to tell people what’s going on. And so instead of just solving it for us, we took the same framework of launch and actually put it on top of this edge network. And our goal is to solve all of your other endpoints, all of your data collection, think of this as data collection as a service, be able to send it to any endpoint, all through launch. And because it’s built through launch, launch server side, will also have the ability for you to build your own extensions and for our partners to build extensions.
It’s an open and extensible framework or an ecosystem or platform for sending data wherever it needs to go. And that’s a huge important message, is that when it comes to the flexibility of sending data where you need to, we’re not a Blackbox, we’re opening up this revolutionary technology so that you and us and our partners can all build on top of our new edge network. We are announcing at Adobe, a single web SDK, a JavaScript library that does all of the work more effectively than the current analytics, audience manager target, and ECID libraries. It sends data in name value pairs, which we call XDM, but XDM is just a format for name value pairs. Think of it as our wrapper around JSON. We’re sending name value pairs to one endpoint, which is first party managed, the Adobe Experience Platform Edge Network. It is one of the largest edge network data collection networks on the planet, san to compliant, real time optimized and at the edge, you’ll be able to format data directly to the platform to Adobe analytics to audience manager and to target with better and easier to use consent, better performance, first party domain ID across all of our solutions, as well as a steady, easy to understand, semantically sound data stream that’s agnostic to any of these solutions. You’re turning things on server side. And we now are announcing launch with server side features for taking that same stream of name value pair data and remapping it to any other endpoint. It’s an open and extensible framework for others to build extensions as well. So thank you so much for this. If, again, you’re one of these guys or girls are like I forgot to get data into these systems. What we just said, is a big deal. We think it’s the next big step for enterprise data collection.
There’s a lot of other companies that are trying to solve one or two or maybe three parts of your real data collection needs. We’re here to solve all of it, from the first millisecond, every millisecond after that, a company that’s been around here doing this for decades, and we’ll be here in the future and make sure that we’re committed to your success. Thank you. -
Libraries replaced by the Web SDK sdks
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:
Visitor.jsAppMeasurement.jsAT.jsDIL.js
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.
Transcript
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. -
Migrating from existing libraries to Web SDK migrating-to-web-sdk
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.
Migration of AT.js to Web SDK considerations 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.
IMPORTANT
The following Target features are not supported when migrating from at.js to Web SDK:
After migrating from AT.js to the Web SDK, remove the targetMigrationEnabled option from your configuration.
recommendation-more-help
ad108910-6329-42f1-aa1d-5920a2b13636