Introduction – Why We Use Adobe Analytics
In the modern digital landscape, understanding user behavior is not just a nice-to-have; it is a competitive necessity. Adobe Analytics is one of the most powerful and widely adopted enterprise analytics platforms available, providing organizations with deep, real-time insights into how users interact with their digital properties.
To implement tracking efficiently across websites and applications, Adobe provides a tag management system called Adobe Experience Platform Launch (now commonly referred to as Adobe Tags or Adobe Data Collection). It enables developers and analysts to deploy and manage analytics tracking without constantly modifying website code.
For client-side web tracking, there are two libraries for implementing Adobe Analytics: the legacy AppMeasurement.js library and the modern Alloy.js (Adobe Experience Platform Web SDK).
This blog post will compare the different approaches to implement analytics tracking in detail – what they are, why they are used, and how they compare against one another. How to implement tracking with each is covered as separate blogs.
Note: The Adobe Analytics configurations like enabling props, eVars, events, marketing channels, classifications, and others remains same irrespective of the way used to implement tracking.
AppMeasurement.js
- What Is AppMeasurement.js
- AppMeasurement.js is Adobe’s original JavaScript library for client-side Adobe Analytics tracking. It has been the backbone of Adobe Analytics implementations for well over a decade and remains widely deployed across enterprise websites and applications today.
- AppMeasurement.js instantiates a global analytics object, typically named s. This object exposes properties and methods that allow developers to set tracking variables and fire data collection requests to Adobe’s servers (also known as the Analytics beacon).
- When AppMeasurement.js is loaded on a page, it creates the s object and makes it available globally. Developers then populate properties on this object (such as eVars, props, and events) and call a tracking method to send the data to Adobe Analytics.
- Why & When Is AppMeasurement.js Used
- AppMeasurement.js became the standard for Adobe Analytics because it provided a direct, relatively simple way to send data into Adobe Analytics report suites. It offers maturity and stability as it has been refined over many years and is battle-tested in production environments at scale.
- Despite being considered a legacy approach, AppMeasurement.js is still fully supported by Adobe and continues to be a valid choice, particularly for organizations not yet ready to migrate to the Adobe Experience Platform Web SDK.
For Detailed Implementation Steps for Appmeasurement.js, refer the article: How to Track Web Data in Adobe Analytics with AppMeasurement
Alloy.js (Adobe Experience Platform Web SDK)
- What Is Alloy.js?
- Alloy.js is the JavaScript library that powers the Adobe Experience Platform Web SDK (often abbreviated as AEP Web SDK). It represents Adobe’s modern, unified approach to client-side data collection, designed to replace multiple siloed libraries (such as AppMeasurement.js, at.js for Adobe Target, and DIL.js for Audience Manager) with a single, lightweight SDK.
- Rather than sending data directly to individual Adobe product endpoints, Alloy.js routes all data through the Adobe Experience Platform Edge Network – a globally distributed, low-latency data collection infrastructure. From the Edge Network, data is forwarded to the appropriate Adobe solutions (Analytics, Target, RTCDP, Journey Optimizer, etc.) based on the configured DataStream.
- Implementing Tracking Using XDM
- The recommended way to send data with Alloy.js is by using an XDM (Experience Data Model) object. XDM is a standardized, open-source schema specification maintained by Adobe that defines a common language for customer experience data.
- There are two ways to create & populate the XDM Object and send the data to Adobe Edge. The major difference between the two approaches is the way and the place where the XDM is populated. In the first approach, where we create a XDM Object Data element, we populate it there and directly send it in rule, but when we go ahead with second approach of creating a XDM Variable, we populate it before sending the event in a rule. Additionally, in the Variable approach, it provides a custom code editor, so we can write custom logics and manipulate the XDM there, similar to the “On Before Send Event” in the extension.
- Implementing Tracking Using the Data Object (Without XDM)
- For teams migrating from AppMeasurement.js who want to leverage Alloy.js without immediately building out a full XDM schema, Adobe provides an alternative approach using the data object. This allows you to pass Adobe Analytics variables in a familiar format, bypassing the XDM schema requirement.
- Key points when using the data object approach:
- No XDM schema setup is required in Adobe Experience Platform.
- The Analytics variables are passed in a structure very similar to AppMeasurement.js, lowering the barrier to migration.
- This approach is officially supported by Adobe and is well-suited for phased migrations.
- However, data sent purely through the data object does not benefit from XDM’s standardization, portability, or reuse across non-Analytics AEP services.
- Teams are generally encouraged to move toward XDM over time for the full benefits of the Adobe Experience Platform.
For Detailed Implementation Steps for Alloy.js, refer the article: Moving Beyond AppMeasurement: Implementing Analytics using AEP Web SDK and Adobe Tags
Conclusion
Both AppMeasurement.js and Alloy.js are valid mechanisms for implementing Adobe Analytics tracking, but they differ fundamentally in architecture, philosophy, and capability. The table below summarizes the key differences:
| Feature | AppMeasurement.js | Alloy.js (Web SDK) |
|---|---|---|
| Data Format | Adobe Analytics variables (s.eVar, s.prop, s.events) | XDM schema or data object |
| Integration | Direct Adobe Analytics integration | Routes through Adobe Experience Platform Edge Network |
| Tracking Calls | s.t() for page views, s.tl() for link tracking | sendEvent() for all interactions |
| Schema | Predefined Adobe Analytics variable model | XDM (Experience Data Model) or flexible data object |
| Future Support | Legacy – still supported but not the recommended path | Modern – Adobe’s recommended approach going forward |
| Setup Complexity | Lower – straightforward variable assignments Adobe Analytics only |
Higher – requires XDM schema or data object mapping |
| Platform Support | Adobe Analytics only | Multiple Adobe solutions (Analytics, Target, RTCDP, etc.) |
From a practical standpoint, the choice between the two often comes down to your organization’s current state and roadmap:
- If you have an existing, stable AppMeasurement.js implementation and no immediate plans to adopt other Adobe Experience Platform capabilities, maintaining AppMeasurement.js is a perfectly reasonable approach.
- If you are starting a new implementation, rebuilding your analytics foundation, or planning to leverage Adobe Experience Platform products (Real-Time CDP, Journey Optimizer, Customer Journey Analytics), Alloy.js is the clear strategic choice.
- If you need to migrate gradually, the data object approach in Alloy.js provides a low-friction migration path that preserves your existing variable naming conventions while moving to the new infrastructure.
It is also worth noting that Adobe has signaled that the Web SDK is the future of client-side Adobe data collection. New features and capabilities are being built for Alloy.js first, and the long-term direction for any Adobe-centric digital analytics practice points firmly toward the Experience Platform Web SDK.