What is Adobe Experience Platform Web SDK?

In the past, each Adobe product functioned with its own JavaScript library, server endpoint, database, and visitor identity management system. This led to a scattered and often confusing array of instructions, documentation, and installation processes. However, with the introduction of the Adobe Experience Platform Web SDK, these disparate elements have been unified into a single JavaScript library, bringing together identity, audience, analytics, and personalization capabilities under one roof.

The Web SDK communicates with Adobe's Experience Platform Edge Network, a network of servers designed to handle and respond to the data and requests the SDK sends. This unified approach drastically simplifies debugging and makes managing data across different Adobe products more efficient.

The Web SDK also introduces semantic data modelling, allowing users to name and structure their data more meaningfully and intuitively. This feature significantly simplifies the process of keeping track of data mapping.

All these features and advancements make the Adobe Experience Platform Web SDK a significant leap forward in providing a streamlined, user-friendly, and efficient way of implementing Adobe's marketing technologies on a website.

👉 Click here to check out how Saxo improved their page load time with 46% by migrating to Web SDK

Benefits of Web SDK over AppMeasurement.js

The Adobe Experience Platform Web SDK significantly improves over the previous standalone JavaScript library, appmeasurement.js. The primary benefits of the Web SDK can be broken down into the following categories:

1. Unified Library:

One of the most notable advantages of the Web SDK over appmeasurement.js is unifying various Adobe product libraries into a single JavaScript library. Previously, appmeasurement.js was just one of many libraries, including at.js, visitor.js, and dil.js, each associated with a different Adobe product. With the Web SDK, these are consolidated, simplifying the implementation process and reducing the possibility of bugs and compatibility issues.

2. Simplified Debugging:

Debugging is made simpler with the Web SDK. Instead of tracking data going to and from different servers with individual JavaScript libraries, the Web SDK enables data related to identity, audience, analytics, and personalization capabilities to occur within the same request to a single Adobe endpoint. This feature allows for more precise tracking and debugging of data.

3. Open Source and Transparent:

Unlike appmeasurement.js, the Web SDK is open source. This transparency allows developers to follow along with changes, submit their issues or improvements, and understand the workings of the library in more detail. Furthermore, minified and un-minified libraries provide a more transparent debugging experience.

4. Asynchronous Loading:

The Web SDK provides asynchronous loading, which can reduce the time it takes to deliver valuable content to users. This feature significantly improves over the traditional synchronous loading of libraries like appmeasurement.js, which could slow down website performance.

5. Semantic Data Modeling:

The Web SDK allows for semantic data modeling, enabling users to use more intuitive and meaningful names for their data fields. This approach contrasts with the system used in appmeasurement.js, which often requires users to keep track of less intuitive names like "eVar21" or "prop42".

6. Improved Performance:

The Web SDK consolidates libraries rewritten from the ground up to be smaller, leaner, and faster—the reduced network traffic and latency lead to improved website performance.

7. Future-Proof:

The Adobe team is continuously working on new features and improvements for the Web SDK, ensuring it stays relevant and beneficial in the long term.

In conclusion, the shift from appmeasurement.js to Adobe Experience Platform Web SDK represents a substantial step forward in simplifying the implementation and management of Adobe's marketing technologies on a website.

Why migrate to Web SDK?

There are two primary factors to consider when deciding whether to migrate. The first is the evolution of Adobe Solutions and the new Adobe Experience Platform. The second one is the external technical landscape with the death of third-party cookies and Apple's ITP.

Evolution of Adobe Solutions

Just as with the previous releases of new JS libraries, the development of the early Alloy.js (code name for Web SDK) came from ensuring that the JS files were using the most up-to-date technologies and, at the same time, trying to reduce the redundancy of functions that were shared across the different legacy JS files.

In parallel, Adobe worked on the Experience Platform (AEP), which is the foundation for solutions, Adobe Customer Journey Analytics (CJA), Adobe Journey Optimizer (AJO) and Adobe Real-Time Customer Data Platform (RTCDP).

All these solutions depend on the Web SDK as the data collection method. So, if you are considering any of the solutions within the AEP stack, it will require that you migrate. From a project perspective, you're in a much better position to show quick ROI for the investment in these solutions if you're already using the Web SDK instead of having to migrate as part of a deployment of, e.g. RTCDP.

Over time, the vision is that AEP will replace the current solutions like Adobe Analytics and Adobe Target.

External technologies

Working in digital marketing is more challenging than it used to be, as external technologies constantly complicate our lives. The death of 3rd party cookies has been underway for several years now, and Apple is continually pushing updates to their ITP to increase privacy for their users. This has started many conversations around cookieless tracking and server-side tracking.

The Web SDK is a way to better future-proof your data collection while respecting users' privacy. With the support of Event Forwarding to destinations server-side and the possibility of keeping cookie IDs based on a server-side cookie, you're in much better shape to tackle the challenges that will and will certainly come.

New features to benefit from with Web SDK

1. Ability to use first-party IDs to generate longer-lasting ECIDs.
2. A tighter integration between Adobe Analytics and Adobe Target does not rely on stitching separate network calls.
3. Faster sharing of audiences from Adobe Real-Time CDP to Adobe Target.
4. Real-time data transformation and mapping in Datastreams using Data Prep.

What is required by my team to migrate to Web SDK?

The migration to Adobe Experience Platform Web SDK is relatively straightforward and requires minimal changes to existing implementations. No updates are needed to your existing data layer, meaning you don't have to involve your IT team.

We recommend a few prerequisites - they aren't required, but they will benefit you in the long run. Depending on which solutions you're using within the Adobe Experience Cloud, there are different things to consider. We'll cover the most common solutions.

Adobe Analytics

You need to ask yourself whether you're getting value from the current implementation (i.e. are you acting on the data you're collecting?). If not, get rid of it so you don't have to take the time to migrate it.

1. Ensure your Solution Design Reference (SDR) is up to date. There's no point in migrating variables if they are not used anymore. If you don't have an SDR, now is the time to create one.
2. While updating your SDR, you should also clean up your variables in Adobe Analytics - disable them if they are irrelevant or not used anymore.

Adobe Target

1. Review your mbox and profile parameters and ensure they are still required.
2. Update your SDR so that you have a column that lists your Target parameters.

Most of the migration is done within the UI of Experience Platform UI. From a high-level perspective, the steps required are:

1. Creating and defining an XDM Schema
2. Configure a Datastream
3. Install the Web SDK Extension in Adobe Tags (former Adobe Launch)
4. Create data element for XDM variables
5. Duplicate existing rules and update them to make use of Web SDK Extension
6. Add the necessary services (e.g. Adobe Analytics) to your Datastream
7. Test and Validate
8. Clean up by removing legacy extensions and rules

If you involve a partner like Accrease, we can lift 95% of the tasks without you or your IT team's involvement. The only time you or your IT team would have to be involved would be in step 7, validating and coordinating the release of the migration.

We don't use Adobe Launch as our Tag Manager Solution

Even if you're not using Adobe Launch, you can still migrate to Adobe Web SDK, which is still recommended due to the benefits mentioned above. With that said, the process may be smoother with Adobe Launch.

At Accrease, we are deep specialists within Adobe Technology, so if you're using another Tag Manager, there may be better teams to do the actual Tag Manager work. However, we are happy to spar and guide you in deciding whether to migrate and what to be aware of.

We've already done several migrations with other clients if you're using Adobe Launch.

Remember, Adobe Launch is free if you're using Adobe Technology. Migrating to a free Tag Manager Solution could reduce your current cost.

What happens if I don't migrate?

Nothing. Adobe is not forcing anyone to migrate - at some point, we expect that you eventually will have to migrate, but nothing indicates this as of the date for writing this.

If you're like most other companies, you're part of conversations where things like load speed and server-side are being discussed. If so, migrating will address some of the concerns typically raised during those conversations.

If you're considering investing in Adobe Experience Platform together with Real-Time CDP, Customer Journey Analytics or Adobe Journey Optimizer, then the Web SDK will be a requirement, and you will be better positioned for success if you're already using Web SDK.

Don't forget to check out our recording of how to migrate to Web SDK 👇