Migration › Knowledge Base › Why Web SDK
Why Web SDK
For fifteen years, collecting Adobe Analytics meant shipping a small factory to every visitor's browser. AppMeasurement read your variables, assembled the hit, and trucked it to Adobe's collection servers, on the user's device, on every page.
The Web SDK retires that factory. In its place is a thin client, alloy.js, that does one job: gather your data into a single structured message and hand it to Adobe's Edge Network, which does the assembling server-side. The same one library now speaks for Analytics, Target, and the Experience Platform, where you used to load three.
Technically, the shift is from a client-side beacon (the old b/ss/ calls) to a JSON payload sent to a datastream-configured Edge endpoint[5]. Your variables travel as either structured xdm or familiar data.__adobe.analytics keys; the Edge translates and routes them.
For your migration: this is why you're not just swapping a script. The reason the effort is worth it is everything it unlocks, one beacon, faster pages, server-side enrichment[T5], and the same data feeding CJA, Real-Time CDP, and server-side Event Forwarding later, with no re-tagging.
Migrate. The Web SDK is the on-ramp to CJA, Real-Time CDP, and server-side forwarding, treat AppMeasurement as end-of-life, not a parallel option to keep alive.
The factory that lived in the browser
For fifteen years, collecting Adobe Analytics meant shipping a small factory to every visitor's device. AppMeasurement read your variables, ran doPlugins, compiled the hit, and fired it to Adobe's collection servers, all client-side, on every page, for every user. It worked, but it meant heavy libraries, multiple beacons, and logic scattered across the browser.
What the Web SDK changes
The Web SDK replaces that factory with a thin client, alloy.js, whose job is to gather your data into one structured message and hand it to the Edge Network. Assembly, identity, enrichment, and routing all move server-side. One library now does what AppMeasurement, the Visitor API, and at.js did separately, and it speaks JSON to a datastream-configured endpoint, not pixels to b/ss/.
Why it's worth the effort
The migration is not a like-for-like swap; it's a move onto the platform everything else plugs into. The same payload that feeds Analytics today feeds CJA tomorrow with no re-instrumentation, enables server-side Event Forwarding to GA4 and Meta without new page tags, and powers Target personalization from the same beacon. Fewer scripts also means faster pages and fewer points of failure.
The honest framing for stakeholders: this is infrastructure work whose payoff is optionality. You're not chasing one feature, you're removing the ceiling that AppMeasurement put on everything downstream.