Adobe Analytics for eCommerce: An Implementation Playbook for Online Retailers

Why does the purchase event in your Adobe Analytics report suite show 87 orders for yesterday while the Magento (Adobe Commerce) order grid shows 102? That gap is the implementation problem nine out of ten merchants actually have with Adobe Analytics for eCommerce – the platform is correctly capturing what the data layer hands it, and the data layer is not handing it everything. Most setup work since the AEP Web SDK rollout is about closing that gap.

This is the implementation playbook the scandiweb Analytics team runs when a retailer asks why their Adobe Analytics numbers do not reconcile with their order management system, why merchandising eVars are blank, or why migrating from AppMeasurement is harder than the docs make it look. For the definitional version – what Adobe Analytics is, what licensing tiers exist, how it differs from Customer Journey Analytics – the sibling article on what Adobe Analytics is used for is the right starting point. This one assumes you are past that decision and are configuring or fixing the implementation.

Overview

• A working Adobe Analytics eCommerce setup is mostly about the data layer and the seven standard commerce events – not the Analytics UI.
• Merchandising eVars and product strings are where most revenue-attribution gaps sit, because they are easy to declare and easy to break.
• New 2026 implementations should use the AEP Web SDK and XDM for commerce, with a deliberate parallel-run plan against AppMeasurement before cutover.

What an Adobe Analytics eCommerce implementation needs

A retailer-grade Adobe Analytics eCommerce setup has six moving parts: a clean data layer, a tagging library (AEP Web SDK or AppMeasurement), a report suite with the right commerce variables, the seven standard commerce events, merchandising eVars for product-level attribution, and a QA harness that catches breakage on deploy. Get those six right, and the reports take care of themselves.

The pattern we see across Adobe Commerce, Shopify Plus, and headless storefronts is that teams over-invest in the report layer and under-invest in the data layer. Reports cannot fabricate data. If scAdd does not fire on add-to-cart, no Workspace project will show you cart abandonment by product. If the data layer passes a string instead of a number into revenue, Adobe Analytics shows the order but contributes zero to revenue totals. The work is in the layer that the marketing team rarely opens.

For a deeper walkthrough of the install path itself – tag manager choices, data element naming, deployment cadence – see our companion guide on Adobe Analytics implementation steps.

The six things to declare before the first tag fires

1. Report suite ID per environment (production, staging, dev), with timezone matched to the merchant of record.
2. eVar and prop assignments documented in a Solution Design Reference (SDR) – the single artifact that prevents two teams overwriting the same eVar slot.
3. The seven Adobe Analytics standard commerce events: scOpen, scAdd, scRemove, scView, scCheckout, purchase, prodView.
4. Merchandising eVars (typically eVar1–eVar5) flagged for the right binding type – Product Syntax for category, Conversion Variable Syntax for campaigns – and the right allocation model.
5. The products string format: category;productID;quantity;price;events;eVars for every commerce hit.
6. A QA layer (Adobe Experience Platform Debugger plus a CI script that diffs network calls against expected events on the top five user journeys).

Tagging strategy: AEP Web SDK or AppMeasurement?

For new 2026 implementations, the AEP Web SDK is the default. AppMeasurement still works, and Adobe still supports it, but every new feature – including the integration paths that connect Adobe Analytics to Adobe Commerce KPIs and Adobe Journey Optimizer – lands on the Web SDK first. Adobe Experience Platform documentation now treats Web SDK as the recommended path for collecting commerce data (Adobe, May 2026).

The trade-off is real. Web SDK requires XDM schema work upfront – mapping each commerce event into the Adobe Experience XDM ExperienceEvent schema, which adds two to four weeks of analyst time at the start. AppMeasurement gets a basic implementation live faster, but technical debt compounds: every time Adobe rolls out a new Adobe Experience Cloud product, you build a new integration instead of inheriting it from the platform.

When to keep AppMeasurement (for now)

• A stable estate with no Adobe Experience Cloud expansion on the 12-month roadmap.
• A small team without analyst bandwidth to design XDM schemas and run a parallel-tagging window.
• An immediate platform replatform on the horizon – do the AEP migration on the new platform, not the dying one.

When to migrate now

• Activating Adobe Real-Time CDP, Customer Journey Analytics, or Journey Optimizer this year.
• Running multi-brand or multi-region report suites where XDM’s stricter schema enforcement prevents the eVar drift we see in older AppMeasurement implementations.
• Replacing legacy tag manager configurations as part of a broader Adobe Experience Cloud ecosystem rollout.

Designing the report suite for eCommerce

A report suite for a single-storefront retailer is straightforward: one production suite, one staging suite, one rollup if the brand also runs a B2B channel. It gets harder with multi-region, multi-brand, and franchise estates – where the same product catalog runs through different storefronts at different prices, and finance still wants one number for global revenue.

The Adobe Experience League commerce report suite template covers the canonical baseline: timezone, currency, default page settings, and the seven standard commerce events (Adobe Experience League, May 2026). Use it as the starting point, then layer brand-specific decisions on top.

eVar assignments that age well

The merchandising eVars (the ones that capture product-level attribution) are where most implementations break in year two. Reserve at minimum:

• eVar1 – Product category (Product Syntax binding, Last Touch allocation).
• eVar2 – Internal search term (Conversion Variable Syntax, Most Recent allocation).
• eVar3 – Campaign / channel (Conversion Variable Syntax, Linear allocation if you run a multi-touch attribution model).
• eVar4 – Customer segment / cohort (Visit expiration).
• eVar5 – Promotion or coupon code (Conversion Variable Syntax, Most Recent allocation).

Document the binding type and allocation model in the SDR. The most common bug we audit is two analysts independently re-purposing eVar3 for two different campaigns six months apart – at which point the data behind every paid-channel ROI report is silently corrupted.

The purchase event and the data layer

The purchase event is the single most important commerce event and the one that gets implementation wrong the most often. A correct purchase hit contains:

• events=purchase plus events=event1 if you track first-time buyer separately.
• The products string with category, product ID, quantity, price, the same purchase event repeated per line, and merchandising eVar values.
• The order ID, currency, tax, and delivery cost in their own data elements (often binding into eVar6 and eVar7, plus the appropriate currencyCode in XDM).

The three failure modes scandiweb sees across audits:

1. Duplicate purchase hits – the data layer fires on the order confirmation page AND on a return-to-page refresh. Fix: dedupe on purchaseID in the tagging library, not in the report suite.
2. Missing tax and delivery-cost breakouts – revenue arrives, but finance cannot reconcile to the ERP because tax is bundled into the currencyCode total. Fix: declare tax and delivery cost as discrete numeric data elements before launch, not after the first finance complaint.
3. String-typed revenue – the data layer hands over "129.95" instead of 129.95, and Adobe Analytics silently coerces or drops it depending on the SDK version. Fix: cast numbers explicitly in the data layer. Never assume the back end will send the right type.

How do you set up Adobe Analytics for an eCommerce site?

Setting up Adobe Analytics for an eCommerce site is a five-step sequence: build a clean data layer, install the AEP Web SDK or AppMeasurement, create a report suite from the commerce template, configure the seven standard commerce events plus merchandising eVars, and validate every event with the Adobe Experience Platform Debugger before declaring the implementation live.

The work that is invisible in that summary is the data layer. A clean data layer is a JSON object available on every page that names the event (page, productView, cartAdd, purchase, etc.), describes the page or product or cart contents in stable property names, and is populated by the back end before the tag manager reads it. Without that contract between the back end and the tag manager, the frontend tag fires on stale or partial data, and every downstream report inherits the mistake.

A practical five-day implementation cadence

• Day 1 – SDR review and data-layer specification. Sign-off between engineering, analytics, and marketing on event names and properties.
• Day 2 – Backend implementation of the data layer on cart, checkout, and order confirmation pages.
• Day 3 – Tag manager configuration in staging (Adobe Experience Platform Data Collection or Adobe Launch). For more on tag library options, see Adobe Launch tag management.
• Day 4 – Test plan execution: 20+ scripted journeys covering catalog browse, add-to-cart, abandonment, guest checkout, logged-in checkout, and refund.
• Day 5 – Production cutover with a parallel-tagging window if the old AppMeasurement install stays live for reconciliation.

Analysis Workspace for eCommerce: the four reports that earn their keep

A retailer team that opens Analysis Workspace daily uses four projects, not forty. Build these first and ignore the temptation to roll out a dashboard of vanity metrics.

1. Purchase funnel with fallout

Steps: prodView → scAdd → scCheckout → purchase. Visualize as a fallout report segmented by device, by traffic source, and by new vs returning. The fallout step that loses the most users is the page that earns the next CRO test – not the page with the most traffic.

2. Product contribution analysis

For any spike or dip in conversion, run Workspace’s Contribution Analysis on the purchase event grouped by product, category, and campaign. It surfaces which dimension value moved the metric the most. Pair this with Adobe Target and GA4 integration when the spike traces back to a personalization test.

3. Cart abandonment cohort

A weekly cohort of users who hit scAdd but not purchase within 7 days, segmented by category and price band. Feed the cohort into Adobe Journey Optimizer or your ESP for triggered emails.

4. Revenue attribution by channel

A flow visualization from the first-touch channel to the converting channel, weighted by your allocation model. This is where the Linear vs Last Touch vs Algorithmic decision shows up – which is why the eVar3 allocation choice in the SDR matters so much.

Common Adobe Analytics eCommerce pitfalls (and how the scandiweb Analytics team handles them)

The patterns repeat across the merchants we audit. None of them is mysterious, and all of them are preventable.

• Two report suites with the same name. Multi-region rollouts create staging suites that copy production names with a -staging suffix and then drift apart. Fix: a documented suite naming convention enforced in the SDR.
• Data-layer values that exist on staging but not production. The product team tests in staging, where the data layer is enriched. Production goes out without the same enrichment. Fix: data-layer regression tests run on every release.
• Merchandising eVars filled by the front end instead of the back end. Frontend-populated eVars break the moment a third-party script changes load order. Fix: backend-rendered data layer, always.
• Tag manager rules duplicating events. Two analysts add two rules that both fire scAdd. Cart additions double. Fix: a single ownership matrix for tag manager rules and a code review step before publishing.
• No DataWarehouse exports. Finance asks for raw transaction data and the team has no way to pull it. Fix: schedule DataWarehouse exports to S3 weekly from Day 1.

scandiweb has delivered Adobe Commerce and Magento (Adobe Commerce) projects with full Adobe Analytics implementations for retailers across apparel, electronics, and grocery since opening in 2003 – more than 2,100 eCommerce projects in total. The pitfalls above are the ones that recur on the technical-audit calls we run before quoting an analytics fix.

How is Adobe Analytics different from Google Analytics 4 for eCommerce?

For eCommerce specifically, Adobe Analytics gives you deeper product-level attribution through merchandising eVars and richer Workspace analysis (fallout, contribution, cohort). Google Analytics 4 gives you a free entry point, native BigQuery export, and tight Google Ads integration. The choice is rarely about features – it is about whether your team has the analyst depth to use Adobe’s flexibility without breaking it.

That is the lighter take. For a fuller comparative breakdown, including pricing, look at the sibling guide on Adobe Analytics pricing tiers and the definitional companion on what Adobe Analytics is used for. For most enterprise retailers running Adobe Commerce already, Adobe Analytics removes a procurement conversation – the licensing slot is open, and the integration with Adobe Real-Time CDP and Adobe Target removes the data-stitching overhead that GA4-plus-third-party-CDP stacks add.

Migrating from AppMeasurement to the AEP Web SDK

The migration is a four-stage program, not a tag swap. Stage 1 is XDM schema design – mapping every existing eVar, prop, and event into the XDM ExperienceEvent schema with commerce extensions. Stage 2 is parallel implementation – both libraries running side by side, writing to two separate report suites or two separate datasets. Stage 3 is reconciliation – running daily diffs on the top metrics until the variance is within 1%. Stage 4 is cutover and AppMeasurement removal.

The reconciliation step is where most projects stall. Variances above 5% almost always trace to one of three causes: timing differences in how the two libraries flush hits, schema-mapping errors where a data element was renamed but not re-bound, or sampling differences in cases where one library lazy-loaded and the other did not. Plan for two to four weeks of reconciliation, not one. The Adobe Experience League integration documentation between Adobe Commerce and Adobe Analytics has the canonical mapping for product, cart, and order data (Adobe Experience League, April 2026).

For retailers also running content-driven storefronts, the same migration logic applies to the Adobe Experience Manager for the eCommerce layer, where the data layer often spans multiple delivery channels.

Why is my Adobe Analytics revenue number different from my order management system?

Almost always a data-layer issue, not an Adobe Analytics issue. The four most common causes are duplicate purchase hits (refresh on confirmation page), missing or mis-typed revenue values (string instead of number), refund handling not subtracting from the original order, and a timezone mismatch between the report suite and the order management system. Audit those four before assuming the report suite is wrong.

The harder cases involve guest-checkout users hitting Adobe Analytics from a different domain than the order placement endpoint, or PCI-compliant checkout flows that block the SDK on the final confirmation page. Both are solvable, but both require a server-side hit to recover the conversion – Adobe’s Server-Side Forwarding or a direct Adobe Experience Platform Edge Network call from the order management system on order create.

Use cases that move the needle for eCommerce teams

A properly implemented Adobe Analytics for eCommerce setup is the data substrate for personalization, retention, and merchandising decisions. The four use cases retailers come back to:

• Cart abandonment recovery – cohort exports feeding a triggered email or Adobe Journey Optimizer flow.
• Product affinity for merchandising – Workspace’s Item dimension on prodView segmented by category to surface cross-sell pairs.
• CRO test triage – fallout reports identifying the highest-loss step before any test brief gets written. Pair with our Conversion Rate Optimization work for an end-to-end CRO program.
• Adobe-derived industry benchmarks – Adobe’s Digital Economy Index publishes monthly US online consumer transaction trends derived from Adobe Analytics data (Adobe Business, 2026), useful for sizing a brand’s performance against the wider market without licensing third-party panel data.

When Adobe Product Analytics fits alongside Adobe Analytics

Adobe Product Analytics is the newer product-led-growth sibling to Adobe Analytics. For eCommerce specifically, Adobe positions it as the surface for “real shopper behavior into growth – timing, intent, and triggers made actionable” (Adobe for Business, September 2025). The practical division: Adobe Analytics is still the system of record for revenue, channel attribution, and funnel reports. Adobe Product Analytics is the exploration layer for behavioral cohort discovery without writing SQL.

Most retailers do not need both yet. Implement Adobe Analytics correctly first, then layer Product Analytics on the same XDM dataset when the analyst team has the bandwidth to use exploration tools that are not pre-built dashboards.

FAQ

What are the seven standard commerce events in Adobe Analytics?

The seven standard Adobe Analytics commerce events are scOpen (cart opened), scAdd (item added to cart), scRemove (item removed), scView (cart viewed), scCheckout (checkout started), purchase (order placed), and prodView (product detail viewed). They anchor every commerce report and every Workspace funnel. Declare all seven before launch, even if you only need three on Day 1.

Do I need to use eVars for product attribution in Adobe Analytics for eCommerce?

Yes. Merchandising eVars are how Adobe Analytics ties a conversion event back to the specific product or category that earned it. Without merchandising eVars configured correctly (binding type plus allocation model), revenue still arrives in reports, but you cannot break it down by product, category, or campaign, which makes most eCommerce decisions impossible.

Can Adobe Analytics replace my order management system for revenue reporting?

No. Adobe Analytics is the source of behavioral revenue – revenue attributable to traffic, channels, and campaigns. The order management system is the source of accounting revenue – revenue net of refunds, returns, and chargebacks. The two should reconcile within 1–2%, and they should never replace each other.

How long does an Adobe Analytics eCommerce implementation take?

A clean implementation on a single-storefront site with an existing data layer takes two to three weeks of analyst plus engineering time. A multi-brand, multi-region implementation or an AppMeasurement-to-AEP Web SDK migration takes six to twelve weeks, with most of the time spent on schema design and reconciliation, not on tagging itself.

Should I migrate to the AEP Web SDK now or wait?

Migrate now if you are activating any other Adobe Experience Cloud product this year (Real-Time CDP, Journey Optimizer, Customer Journey Analytics). Wait if the estate is stable, the analyst team is small, or a platform replatform is on the 12-month roadmap – in which case, do the AEP work on the new platform.

What is the most common Adobe Analytics eCommerce implementation bug?

The most common bug is a purchase event that does not reconcile to the order management system, caused by a data-layer issue – usually a duplicate hit on confirmation-page refresh or a string-typed revenue value the SDK does not parse correctly. Audit the four data-layer causes (duplicate, type, refunds, timezone) before changing any Adobe Analytics configuration.

Is Adobe Analytics worth it for a mid-market eCommerce retailer?

For retailers already on Adobe Commerce or planning a move into Adobe Experience Cloud (Real-Time CDP, Target, Journey Optimizer), Adobe Analytics removes a procurement and integration conversation. For standalone Shopify or BigCommerce retailers without other Adobe products, Google Analytics 4 plus a third-party CDP is usually a more proportionate spend.

Decide whether your Adobe Analytics setup is closing the gap between behavioral revenue and your order management system, or quietly widening it. Book an Adobe Analytics audit and the scandiweb Analytics team will work through the data layer, the eVar map, and the AEP migration plan with your engineering and marketing leads.

Share on: