Simplifying Customer Workflows with Adobe Experience Platform Web SDK

[#1]

Authors: Aaron Hardy, Joe Khoury, Justin Grover, and Jenny Medeiros

This post is how Adobe Experience Platform and Adobe Experience Cloud are simplifying your implementation with an all-in-one JS library, Adobe Experience Platform Web SDK.

Currently, Adobe Experience Platform customers need to implement multiple JavaScript libraries on their website to interact with services within Adobe Experience Cloud. Each library has its own documentation and must be implemented individually, resulting in a complex workflow.

In keeping with Adobe's mission to push our customers forward with innovative tools and services, Adobe Experience Platform Web SDK is a unified solution designed to greatly simplify our customer's implementation efforts. It provides a single endpoint to streamline HTTP requests to Adobe solutions, empowering Adobe Experience Platform customers with a higher-performing website and improved visibility over their workflow.

This post gives an overview of Adobe Experience Platform Web SDK, our architectural approach, how it compares to the current workflow, and what's next for this exciting library.

Streamlining our customers' implementation with a unified web SDK

Adobe Experience Platform Web SDK (Project Name: "Alloy") enables customers to interact with various capabilities within Adobe Experience Cloud to stream data into Adobe Experience Platform that synchronizes identities, personalize content, automatically track links, and send audience segments to third-party destinations.

Currently, Adobe Experience Cloud customers implementing Adobe Cloud Identity Service (ECID), Adobe Analytics, Adobe Target, and Adobe Audience Manager must fetch and install the following four libraries within Adobe Experience Cloud:

• Visitor.js
• AppMeasurement.js
• AT.js
• DIL.js

They must also read separate documentation on each library to understand how they should be used and how they integrate with each other. Adobe Experience Platform Launch simplifies this installation process but the customer must still configure four different extensions.

In the current implementation, each library sends a server call to a separate endpoint before the data reaches Adobe Experience Cloud solutions.

Figure 1: Diagram of Adobe Experience Cloud customer’s current workflow.

Adobe Experience Platform Web SDK streamlines this workflow. Customers will only have to implement one Adobe Experience Platform Launch extension to retrieve an ECID, fetch and render personalized experiences, update audiences, and pass data into the data lake – all in a single call. Customers not using Adobe Experience Platform Launch will be able to implement the same functionality by installing a single library on their website.

Figure 2: Diagram of the customer’s workflow using Adobe Experience Platform Web SDK.

In this new workflow, the customer's website makes fewer requests to the server and stores fewer cookies. This benefit coupled with the significantly reduced library code size leads to an overall improvement in performance. Furthermore, with only one library on their website, customers can gain a better understanding of their implementation and be more confident in their data.

Our approach to building Adobe Experience Platform Web SDK

To create a unified SDK for Adobe Experience Platform, we had to bring together the different teams behind each product. This approach enabled the creation of a single, cohesive codebase that translates into improved stability and reliability for our customers.

We built Adobe Experience Platform Web SDK using a component-based architecture, in which the code for each component is largely independent yet allows the components to coordinate with each other through robust integration points. This system empowers each team to work on their respective components with minimal disruption to others, while also enforcing proper cross-component integration to speed up development and reduce overall maintenance costs.

Figure 3: High-level view of Adobe Experience Platform Web SDK’s architecture

The architecture also uses a lifecycle hook system so each component can properly initiate and respond to important system events. For example, in the case of a new customer loading a website, the workflow within Adobe Experience Platform Web SDK would run as follows:

• When the page loads, the "data collector" is notified that the customer would like to send event data.
• The data collector creates a payload and triggers a lifecycle hook (onBeforeEvent).
• Each component receives the payload and can choose to augment it. For example, the Identity Service component can add an ECID retrieved from a cookie.
• The data collector sends the request to a single endpoint, enabling multiple actions (e.g. populate a response with personalized information) and also collect data for Adobe Experience Cloud solutions and Adobe Experience Platform.
• The response returns to the data collector, triggering a lifecycle hook (onResponseReceived), and the process of each component augmenting the payload repeats.

Figure 4: Example workflow using Adobe Experience Platform Web SDK

Lastly, we designed Adobe Experience Platform Web SDK with privacy and performance in mind. It's asynchronous by default to speed up loading time and prioritizes single-page applications (SPAs) from the start. It also supports opt-in workflows to respect end-users privacy preferences.

Adobe Experience Platform Web SDK is faster and more transparent than current libraries

Adobe Experience Platform Web SDK is fully open source, which provides customers with greater visibility and enables them to conduct their own security review. Furthermore, published builds will be offered in both minified and unminified formats, allowing customers to thoroughly understand the code while it's running in their environment and improve their ability to debug implementation issues that may arise.

To demonstrate how Adobe Experience Platform Web SDK compares to the current Experience Cloud implementation, consider the same scenario of an end-user visiting a webpage for the first time. In this demo, the customer is implementing Visitor.js, AppMeasurement.js, DIL.js, and AT.js; and their page is configured to only trigger an Adobe Analytics call. See the following image:

Figure 5: Console showing webpage assets and Adobe Analytics server call before opt-in

The end-user hasn't consented to all data purposes, barring the use of the main ID library: ECID. This forces the webpage to assign the end-user with a "fallback ID." Once the user opts-ins, ECID assigns another ID, resulting in the end-user having two different IDs. The webpage then makes a number of server calls and generates an equally large number of cookies to pull personalized information from Adobe Experience Cloud solutions.

Figure 6: Console showing webpage assets and server calls after opt-in

With Adobe Experience Platform Web SDK, the ECID library does not block the collection of personalized data. By leveraging an asynchronous implementation, any commands dependent on the end-user's privacy preferences are queued in memory within the SDK. Once the end-user provides their preferences through opt-in, these commands will either proceed or be aborted.

To execute the accepted commands, Adobe Experience Platform Web SDK triggers a single payload bundled with the ECID and personalized information collected from Adobe Target and Adobe Audience Manager (see image below). This optimized workflow leads to fewer IDs assigned to the same end-user and a dramatic reduction in requests and cookies sent between the webpage and server.

Figure 7: Console showing webpage assets and calls (left) and the resulting payload (right)

Challenges

Replacing multiple libraries with a single solution creates a few privacy challenges. For example, if a website visitor opts out of one solution, it's difficult to isolate that preference without opting out of the others since all the libraries are in one place.

To solve this problem, we brought in all Adobe Experience Cloud engineering teams to brainstorm a standard opt-out solution. This solution needs to properly coordinate the customer's opt-out preferences without disrupting the SDK or breaking any privacy concerns.

Another ongoing challenge is deciding on a technical solution to the migration of data lingering on end-users' devices. Not all data will be automatically transferred, but we have identified key data that will be migrated, such as Visitor IDs previously stored in cookies.

What's next?

While we're proud of our progress with Adobe Experience Platform Web SDK, it's still early in our development journey. Currently, we're working on evolving the opt-in feature to provide more granular control over the specific purposes the end-user can choose to accept.

Also, to ensure data consistency across Adobe solutions, the upcoming Adobe Experience Platform Web SDK beta will only support sending data that has already been structured to match Adobe Experience Data Model (XDM) schemas. Subsequently, we'll provide customers with an intuitive user interface with an XDM mapping feature to ensure any website data not matching an XDM schema can be properly mapped to one before reaching Adobe Experience Platform. This "flexible schema" empowers customers to structure their data in the way they understand it, rather than follow a prescribed structure.

With Adobe Experience Platform Web SDK currently under development and more innovations on the way, we're excited to continue streamlining our customer's workflows and enhancing the way they interact with Adobe Experience Platform.

For a detailed guide on how to use Adobe Experience Platform Web SDK, check our documentation. To stay up-to-date on its development, visit the GitHub repository.

Originally published: Sep 12, 2019