Web SDK vs AppMeasurement

AppMeasurement is the legacy JavaScript library that sends data to Adobe Analytics alone; the AEP Web SDK (alloy.js) is its successor - a single library that sends XDM-structured events to the Adobe Experience Platform Edge Network, which then routes them to Analytics, CJA, Target, and other services from one beacon.

What actually changes

One library replaces several. Web SDK consolidates AppMeasurement, the ECID visitorAPI, and at.js for Target into one file with one round-trip - typically faster and far simpler to reason about.

Payloads become XDM. Instead of setting s.eVar12 and s.events, the site sends structured XDM objects; server-side mapping decides what lands in which Analytics variable. The implementation's vocabulary shifts from Adobe's variable slots to your own schema.

Collection routes through the Edge Network, usually on a first-party CNAME domain - which changes how you debug (Edge traces rather than /b/ss beacon inspection) and how consent is enforced.

Migration reality

A Web SDK migration is not a library swap. The data layer usually survives; everything between it and Adobe changes: processing rules or data-prep mappings replace in-page variable assignments, identity moves to the identity map, and every report must be reconciled against the old implementation during a parallel run. Teams that skip the parallel run discover differences in production, attributed to "the migration" forever after.

Frequently asked questions

Does the Web SDK require Adobe Experience Platform?

Web SDK data flows through the AEP Edge Network, but it can serve traditional Adobe Analytics alone via the Analytics upstream. Full AEP (datasets, CJA, Real-Time CDP) is where the architecture pays off - which is why Web SDK migration and CJA adoption are usually planned together.