Unify Your Adobe Experience Platform Services with Adobe Experience Platform Web SDK
On the front-end, however, customers increasingly expect simpler and more unified digital experiences across web and mobile. To fulfill this expectation, the industry must once again evolve the way it delivers and analyzes user data.
To play our part in this transformational shift, we recently launched Adobe Experience Platform Web SDK, a client-side JS library that replaces four SDKs that Adobe Experience Platform customers had to implement individually to synchronize user identities, personalize content, and send audience segments to third-party destinations.
In this post, we help customers prepare to migrate to Adobe Experience Platform Web SDK. We also describe a few common scenarios and provide practical recommendations to streamline your transition to a simpler, better-performing implementation.
Revolutionizing customer implementation with a single solution
Currently, Experience Cloud solutions (i.e. Adobe Cloud Identity Service, Adobe Analytics, Adobe Target, and Adobe Audience Manager) require multiple libraries, where each sends server calls to separate endpoints. In contrast, Adobe Experience Platform Web SDK consolidates solution-specific requests into a single payload for a seamless and much more simplified implementation. (See figure below.)
To achieve this smoother workflow, Adobe Experience Platform Web SDK collects website event data in a simple name-value pair as part of your implementation. It is then sent directly into Adobe’s new Data Platform and can later be configured to power different Adobe solutions.
In Adobe Analytics, for example, the notion of tagging an eVar or prop on a webpage will be eliminated since all events will be sent as key-value pairs and eventually mapped to eVars and props — either via processing rules (initially) or eventually in Adobe Experience Platform Launch.
To deploy the Adobe Experience Platform Web SDK, we recommend utilizing Adobe Launch. However, this library can be deployed as a stand-alone library or using any Tag Management system.
Simply put: Adobe Experience Platform Web SDK is an exciting new approach that enhances how many of our Adobe solutions operate, resulting in the following advantages for IT teams:
- Improved page performance from consolidated libraries
- Seamless data streaming into Adobe Experience Platform
- Fewer issues around data discrepancy across solutions
- Efficient library versioning and dependency management
- Semantic tags that fire correctly and are easier to understand
- Lower-cost implementation changes
- Increased visibility and confidence in your data
- Updated technologies for modern browsers and Single Page Applications
- Improved Privacy controls
Although after a decade of deploying individual Experience Cloud libraries, shifting to this new SDK may be tricky to even conceptualize. So, before jumping into the actual implementation, let us first take a step back and brainstorm what your current Adobe implementation strategy might look like in this new unified future.
Brainstorming your migration to Adobe Experience Platform Web SDK
Before moving forward with migration, we recommend holding a planning session in which your team conducts a high-level audit of your current Adobe solution deployments.
During this session, make sure to collect key metrics and note the visitor profiles garnered across different solutions, as well as potential redundancies (e.g. revenue is tracked in both Adobe Analytics and Adobe Target).
To help you navigate the session, here are a few questions you should answer:
- Which Experience Cloud solutions do you have deployed today that you are using to execute on your Adobe implementation strategy?
- What are the critical KPIs that you currently map to each individual point solution (e.g. revenue tracking or lead form-submissions)?
- Which events (offline or onsite) are you currently not tracking that are on your wishlist?
- What is your current privacy or consent strategy for the regions you operate in?
Documenting those answers will better position you to think about a unified deployment strategy, decouple your site tags from belonging to a specific Adobe product, and begin considering how your privacy strategy will be carried over to the Web SDK migration.
Now that we have reviewed what to start considering with the migration to the Web SDK, let us dive into the potential pre-requisites of such a migration.
Preparing to migrate to Adobe Experience Platform Web SDK
While no two customer implementations are exactly the same, there are some general prerequisites that will apply to all customers in order to migrate to Adobe Experience Platform Web SDK:
- Access requirements: Adobe Experience Platform customers can start using Adobe Experience Platform Web SDK, which is already available in Experience Platform Launch.
- Migrate your data layer to XDM schema: The primary requirement is to migrate your existing page data layer to Experience Data Model (XDM) — the fundamental format in which Adobe Experience Platform ingests data.
- Request an Edge Configuration ID: Every Adobe Experience Platform Web SDK implementation will require an Edge Configuration ID. There is also a self-service tool called Edge Configuration that will soon become available within Adobe Experience Platform Launch. Below are some example screenshots of said tool, (note that these interfaces are subject to change).
With these three prerequisites, your setup will be ready to leverage the new and improved features of Adobe Experience Platform Web SDK.
Customer migration scenarios
In this section, we will review a few migration scenarios that customers might find themselves in, along with recommended next steps so you can begin deploying the Adobe Experience Platform Web SDK.
Scenario 1: Customers currently using Experience Platform Launch
As mentioned earlier in the prerequisites, this data layer must first be migrated to the XDM schema. This process can be done seamlessly in Experience Platform Launch. All customers need to do is install the Adobe Experience Platform Web SDK extension and select the “XDM Object” data element type, which allows you to map your existing data elements to the XDM schema (see screenshot). This will “migrate” your data layer to the new format.
Scenario 2: Customers currently using Dynamic Tag Management (DTM)
Most customers are migrating from DTM to Experience Platform Launch. In this case, we recommend the following steps for migration:
- Continue with your current DTM for migration.
- Once the DTM-to-Launch migration is complete, install the Adobe Experience Platform Web SDK extension to convert all the data into XDM format.
- Disable Adobe Analytics, Experience Cloud ID Service, and Adobe Target extensions in Experience Platform Launch to begin leveraging your new all-in-one SDK.
Scenario 3: Customers using a 3rd Party Tag Management System (TMS) or customers not using a TMS
If you are using any TMS other than DTM or Adobe Launch, or even the legacy Adobe implementation (hardcoded on the page), here are some key points for the migration:
- As with the other scenarios, the data layer must be translated into the XDM schema.
- The legacy VisitorAPI.js, AppMeasurment.js, and AT.js files need to be replaced with the new alloy.js library.
Scenario 4: Customers deploying Adobe solutions for the first time
If you are new to Experience Cloud and starting your implementation from scratch, we highly recommend beginning with Adobe Experience Platform Launch, and then installing Adobe Experience Platform Web SDK.
Additionally, it is better to follow XDM schema from the start to avoid additional conversion work within Adobe Experience Platform Web SDK.
Helping our customers every step of the way
Adobe Experience Platform Web SDK is set to completely upend how developers currently implement Experience Cloud solutions. To guide our customers through this important transition, keep an eye out for upcoming blog posts to help you swiftly navigate these game-changing enhancements.
To get you started, we have complemented our SDK release with an updated debugging tool that will allow customers to easily audit their new implementation. This tool is backward-compatible with current non-Web SDK deployments and is ready for download at Adobe Experience Platform Debugger.
- Simplifying Customer Workflows with Adobe Experience Platform Web SDK: https://medium.com/adobetech/simplifying-customer-workflows-with-adobe-experience-platform-web-sdk-4e54fe134f4a
- Streamlining Client-Server Integrations with Adobe Experience Platform Edge Network: https://medium.com/adobetech/streamlining-client-server-integrations-with-adobe-experience-platform-experience-edge-1caaef887172
- With Alloy-JS, Never Tag for an eVar or mbox Again (Adobe Summit session video): https://www.adobe.com/summit/2020/with-alloy-js-never-tag-for-an-evar-or-mbox-again.html
- Adobe Experience Platform Web SDK Technical Overview: https://www.youtube.com/watch?v=kvqXSrzJMQ0
- Adobe Experience Platform Web SDK on GitHub: https://launch.gitbook.io/adobe-experience-platform-web-sdk/
- Adobe Experience Platform: https://www.adobe.com/experience-platform.html
- Dynamic Tag Management: https://docs.adobe.com/content/help/en/dtm/using/c-overview.html
- Edge Configuration ID: https://docs.adobe.com/content/help/en/experience-platform/edge/fundamentals/edge-configuration.html