Adobe Analytics Implementations: Web SDK vs AppMeasurement

| Last Updated October 13, 2023 - by jean paul behrens under digital analytics

Implementing Adobe Analytics in today’s world means you first have to make a decision that will have a lasting impact on your solution. Should you implement it with the Adobe Experience Platform Web SDK extension (alloy.js) or with the Adobe Analytics extension (appMeasurement.js)? What are the differences?

Implementing Adobe Analytics through Platform Web SDK may sound complex, and there are more unknowns around how to best do it. That comes with the “new tech” territory. Using the traditional appMeasurement.js may sound more familiar and less risky. In this blog post, I will assume you are implementing Adobe Analytics using the Experience Platform Data Collection tags feature (Adobe Launch) and will review the high-level architecture of either approach, as well as compare the Pros and Cons (as of this writing) of either approach. My goal is to ensure you make the proper decision and you have a successful Adobe Analytics implementation.

High-level architecture

Below is a diagram illustrating the general steps admins of Adobe Analytics would have to take to stand up the solution with either Web SDK vs Adobe Analytics extensions.

After contracts are signed, you will get invites for Admin Console and be provisioned for each solution you have licensed. This step is the same regardless of approach. Differences start as soon as the next step.

Using the Adobe Analytics extension in Data Collection tags (Adobe Launch), it leverages the purpose-built library called appmeasurement.js for Adobe Analytics. This extension allows you to map data points from your website to eVar, Props, events, etc in Analytics. You will also be required to deploy the Experience Cloud ID Service extension. You will need to configure ECID service to manage identities such as authenticated customer/user IDs, but also unauthenticated ECID which is how Adobe identifies visitors by default. Once this is live on the website you will have 2 different network beacons; demdex.net for ECID and omtrdc.net for Analytics. From here you are good to go!

When implementing Adobe Analytics via Web SDK, it is going to appear more streamlined and straightforward. Instead of two extensions, you will use only one. This happens because Web SDK uses a new library, aptly called alloy.js, that combines all Adobe tech into a single JavaScript. However, there are two extra steps. First, you must define the XDM schema that will standardize data collection for your digital data sent to the Adobe Edge server. Second, you must configure the Datastream that instructs the Adobe Edge server to send data to Adobe Analytics. When that is live on the website you will see only one network request; adobedc.net.

But JP, what the heck is Adobe Edge Server?

Adobe Edge server is part of the Adobe Edge Network. The new and improved way Adobe distributes data to its own and third-party tools. Below is a great illustration from Adobe laying it all out. You can read more about Adobe’s Edge Network, but in practical terms, what this means to you is you must configure a Datastream.

But enough with that foundational context. Let’s look at the Pros and Cons list of using either extension to deploy Adobe Analytics; which is what you are here for!

Pros & Cons of Web SDK vs Adobe Analytics extension:

Please note that this comparison will evolve over time as there are continuous development efforts with the Web SDK. Since I originally put this comparison together a year ago, many of the Pros and Cons have changed. Reach out to us if you are reading this in the future and want clarity on the current state.

This current pros & cons list is based on our experience after having done many appMeasurement and Web SDK implementations, as well as writing the official Experience League tutorial of implementing Adobe Experience Cloud with Experience Platform Web SDK extension.

When you are deciding which implementation route works for your team, it is important to know that due to the active developments in Web SDK, there will be some things supported in appMeasurment that are not yet supported in Web SDK and vice versa, but eventually will be. However, these should be addressed on a case-by-case basis. To check the status of your current state and help identify which process is a better choice you can use this link.

Pros	Cons
Web SDK
Future-proofing for Adobe solutions, all new feature development happening only on Web SDK Support for First Party Device IDs (mitigates browser cookie restrictions) Recommended method for unlocking Customer Journey Analytics (CJA) Unified XDM schema ensures that all tools within the Adobe stack have the same data, the same data structure, and are sequenced properly by default Faster page load speed, with a single JS library, a single beacon Real-time streaming to Experience Platform Unlocks event-forwarding (server-side to non-Adobe tags) Eliminates the step to configure a data feed for AEP	Debugging requires both browser client-side and Adobe Edge server-side inspection of network requests Activity Map supported at extra cost with additional billable hits per click Strict validation rules to ensure data hygiene (if one data point in a call is incorrect, the whole call fails) Recommended practice is to maintain two XDM schemas (one for Platform and another for Analytics) Manual bot mitigation required for Experience Platform
TraditionalappMeasurement.js
Implementation familiarity Debugging happens all client-side Activity Map compatibility with no extra charge Analytics bot filtering rules apply to the Experience Platform	A separate Visitor ID Service (ECID) configuration is necessary Complex integration with Adobe Solutions dependent on successful sequencing of tags Four JS libraries on the page, slower page load speed Server-side event-forwarding is limited to AAM Batch connection to Experience Platform (latency between 2 – 90 minutes) Target Edge segmentation with Analytics signals not supported in the Platform An additional step required to send AA data to AEP

Personally, if you only have Adobe Analytics and rely extensively on Activity Map and the browser extension this may be the only technical reason for you to stick with Adobe Analytics extension. That said, you can always recreate it with custom dimensions although you won’t be able to use the Activity Map browser extension to overlay clicks on the actual page. The Adobe Target and Analytics integration A4T used to be another technical reason but with recent changes to the extension, those are mostly gone.

The path to mature your digital organization is clearer with Web SDK. Customer Journey Analytics by itself is a power tool and, although CJA is not dependent on receiving streaming data from Web SDK, it certainly makes the data process a lot quicker. You also have the ability to unlock the potential other other tools in the Experience Cloud a lot quicker.

On the other hand, a straightforward Adobe Analytics with essential tagging will be quicker to deploy with the appMeasurement.js library.

As is often the case, each organization is unique and your use cases as well as analytics staff will better drive which approach to take rather than a list of Pros and Cons by itself. Reach out to me on LinkedIn or contact us to learn about how we can best help your situation.

Read more from our Digital Analytics practice here.