Solving Implementation Pain Points with Adobe Experience Platform Web SDK and Edge Network

[#1]

Author: Aaron Hardy

The implementation of marketing technologies on a website can be complex. Data is coming and going, personalization content is retrieved and rendered, and identities and segments are synchronized.

As Adobe has grown its portfolio of marketing technologies, our technical complexity has grown with it. Many of Adobe Experience Cloud offerings were acquisitions. Each product had its own JavaScript library, its own server endpoint, its own database, and its own method for managing a visitor’s identity. We acknowledged that each Adobe product needed to be integrated with other Adobe products.

With Adobe Experience Platform, our goal is to reduce the complexity of implementing Adobe’s technologies on your website by creating a more unified experience. Early first steps included a unified JavaScript library, unified data, unified requests, unified server endpoints, and unified cookies.

Let’s take a look at some of the specific pain points we’ve heard from our customers and how Adobe Experience Platform Web SDK (a JavaScript library) and Adobe Experience Platform Edge Network (a network of servers with which the SDK interacts) seek to solve them.

Pain Points And Solutions

Various Libraries And Documentation

As an Adobe customer, I’m required to find each product’s JavaScript library and accompanying documentation. I then have to figure out which versions of the different libraries work properly together and install each one on my website.

Each Adobe product had its own JavaScript library: appmeasurement.js, at.js, visitor.js, and dil.js. These are examples of “legacy libraries”. Some required you to install additional modules depending on desired functionality (e.g., AppMeasurement’s Audience Manager module). You had to go find instructions on how to install and use each of these libraries. These files and instructions were not co-located, leading to frustration and time wasted searching for needed information. Furthermore, you were required to go through the process of adding separate code snippets to your page for each library. Incompatible versions or improperly sequenced libraries would lead to bugs that were difficult to discover and debug. Each library also had a unique API and nomenclature you had to learn. Adobe Experience Platform Launch solved some of these problems, but there was still room for improvement.

Adobe Experience Platform Web SDK is now a single JavaScript library and is intended to provide identity, audience, analytics, and personalization capabilities. It supersedes appmeasurement.js, at.js, visitor.js, and dil.js. The documentation for the Web SDK is in a single location. If you are using Adobe Experience Platform Launch, you will use a single extension (named AEP Web SDK) for implementing these capabilities.

Debugging Difficulties

As an Adobe customer, I have a difficult time debugging my implementation because data is going to and from different servers, the JavaScript libraries are always minified, and I can’t see what’s happening with my data after it hits the servers.

Not only is the Web SDK a single JavaScript library, but communication related to identity, audience, analytics, and personalization capabilities can all occur within the same request to a single Adobe endpoint. This makes it simpler to discover what’s happening within your implementation. For example, when using your browser’s developer console to debug, you no longer need to filter network requests by b/ss for Analytics, demdex for Audience Manager, and delivery for Target. Also, using the same request and response for multiple capabilities reduces the likelihood of bugs or mismatched data across products.

Figure 1: Single SDK communicates with a single endpoint for multiple capabilities

Now, a single SDK communicates with a single endpoint for multiple capabilities.

Unlike legacy libraries, Adobe Experience Platform Web SDK is open source and can be found in the following public repositories:

• Adobe Experience Platform Web SDK Source
• Adobe Experience Platform Web SDK Documentation
• Adobe Experience Platform Web SDK Launch Extension Source

You’re welcome to follow along as we make changes or submit your own issues or pull requests. Both minified and unminified libraries are produced for use on your website to provide a more transparent debugging experience. The product roadmap is also public so you can see what features are on the horizon.

In addition, when using Adobe Experience Platform Web SDK, Adobe Experience Platform Debugger (a browser extension for Chrome and Firefox) provides new insight into what happens to your data as it flows not only from your web page and over the internet but also as it flows through Adobe’s servers to its destinations.

On-page Configuration Changes

As an Adobe customer, if I need to make any configuration changes, I have to change the code on my website. This often slows me down due to coordinating longer release cycles.

Unlike the configuration of legacy libraries, our web SDK limits the amount of on-page configuration to only what may affect the behavior of the SDK before the first request to the server is made. Any other type of configuration is done through an “edge configuration” that can be modified at any time through the Launch user interface. Through the edge configuration, you can configure Target client codes, Analytics report suites, ID syncing, audience destinations, and more. In some cases, once the SDK is installed, you can later purchase an Adobe product and enable it on your website without needing to modify website code. Publication of these edge configuration changes can happen right away rather than needing to incorporate website code changes into infrequent release cycles.

Waiting To Interact With Libraries

As an Adobe customer, I have to ensure that the JavaScript libraries have finished loading before interacting with them, which can complicate or slow my implementation.

Adobe Experience Platform Web SDK installation instructions provide a small snippet of code, called the “base code”, that you will paste into your website’s HTML (unless you’re using the Launch extension). This base code, when run, immediately establishes a global function you will use to interact with the SDK and then goes to work on loading the SDK asynchronously. This provides two important benefits:

• You can be sure the global function exists right away and you can use this global function to interact with the SDK even before the SDK has finished loading. Any interactions will be placed into a queue until the SDK finishes loading at which point the SDK will process the queue.
• Adobe Experience Platform Web SDK can be loaded asynchronously, which can cut down the time it takes to get valuable content to your users.

Library Hosting

As an Adobe customer, I don’t want to deal with hosting the various JavaScript libraries, especially when I’m prototyping.

Although managing your own hosting of Adobe’s JavaScript libraries gives you ultimate flexibility and control over how the files are delivered to your users, we understand that sometimes you’d rather not have to deal with the complexity. For that reason, we host our web SDK on a content delivery network (CDN) so you can load it directly onto your website for decreased time to value. The SDK’s installation instructions use this hosting method by default, but hosting the SDK on your own servers is also a supported option.

Lack Of Semantic Data Modeling

As an Adobe customer, names like “eVar21” and “prop42” mean little to me and I need to maintain internal documentation to keep track of how they map to my data. Let me provide meaningful names and structures for my data.

A core tenet of Adobe Experience Platform is to allow you to model your data using semantic terms. In other words, when a user is using a promo code on your website, rather than sending the promo code to Adobe’s servers on a field named eVar21, you set it on a field named, for example, promoCode. The structure and naming of the data fields are defined by you when you create a schema within Adobe Experience Platform. You’re encouraged to use building blocks (also known as XDM mixins) provided by Adobe for common use cases, but you can also create your own fields for specific needs. Rather than dealing with eVars, props, product strings, tracking codes, mbox properties, Audience Manager signals, and so on, you’ll be dealing with the schemas you build.

While using Adobe Analytics for reporting, some mapping to prior terminology (eVars, props) will still need to occur on the server. As you migrate from Adobe Analytics to Customer Journey Analytics for reporting and analysis, this mapping becomes no longer necessary.

Additional Client Libraries For Third-Party Vendors

As an Adobe Customer, I have to implement a client-side library for every third-party vendor to which I want to send data, which slows down my website.

By sending data to our edge network using our web SDK, you can soon leverage Adobe Experience Platform Launch Server Side. This new functionality will allow you to transform any data received by our edge network and send it to third-party vendors. This reduces the number of JavaScript libraries you need to implement on your website and increase performance in the process.

Performance Impact

As an Adobe Customer, I’d like to cut down on the number and size of files loaded and network requests made. I also want requests to happen sooner and faster.

Ah, yes, performance. We’ve worked very hard on this and have good news. Adobe Experience Platform Web SDK is a consolidation of libraries rewritten from the ground up to be smaller, leaner, and faster. Communication with the server is consolidated, resulting in reduced network traffic and latency.

Upcoming Features

Adobe Experience Platform Web SDK and our edge network already provide a significant set of features, but more is yet to come. Follow our progress on feature development on our public project backlog.

The Door To Adobe Experience Platform

We’ve discussed website implementation pain points and how our web SDK and edge network address them. There are also changes to Adobe Experience Platform Mobile SDK on their way which will address implementation pain points within mobile apps. Adobe Experience Platform Web SDK and Mobile SDK, along with our edge network, are merely a conduit by which data flows in and out of our experience platform. You can use our SDKs and edge network to send data to the products you already know and love. Additionally, you can unlock the potential of the rest of Adobe Experience Platform to transform how you store, analyze, share, and take action on your data. We invite you to learn more about us.

Follow the Adobe Experience Platform Community Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products. Sign up here for future Adobe Experience Platform Meetups.

References

1. Adobe Experience Platform
2. Adobe Experience Platform Web SDK Source
3. Adobe Experience Platform Web SDK Documentation
4. Adobe Experience Platform Web SDK Launch Extension Source
5. Adobe Experience Platform Debugger
6. Streamlining Client-Server Integrations with Adobe Experience Platform Experience Edge
7. Simplifying Customer Workflows with Adobe Experience Platform Web SDK
8. Meet Alloy.js and Never Tag for an eVar or Mbox Again

Originally published: Oct 8, 2020