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.
Pain Points And Solutions
Various Libraries And Documentation
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:
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
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.
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.
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.
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.