Revenue / orders. AOV slipping while orders climb usually = overly aggressive coupon stack.
At a glance
Average value of an order placed on the Salesforce Commerce Cloud realm in the period. Computed as SUM(order_total) ÷ COUNT(orders). The most volatile of the executive trio (revenue, orders, AOV) on multi-site realms because it is sensitive to mix shifts that revenue and order count absorb.
Calculation
Calculated automatically from your Salesforce Commerce Cloud data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A Fortune-500 fashion retailer running on Salesforce Commerce Cloud. Window covers 14 Mar 26 to 12 Apr 26. Per-site AOV (the operational read):
Realm-wide arithmetic mean (the meaningless view):
- The DE site is down 6.3% in AOV but only 2.5% in orders. The basket is shrinking faster than the volume. This is a discount-led move (a regional VAT-included Spring promo ran for the second half of the window), not an audience-led move. Pair with Top Products and the site’s promotion settings. Below the
drop >10% WoWalert threshold, but worth a manual look. - **B2B AOV at 40 on its own. Always read AOV per-site on SFCC realms.
- The headless sub-brand on SCAPI runs a 5.6% AOV lift over its prior period. Modern PWA checkouts expose recommendation widgets and bundle prompts more aggressively than ISML, lifting basket size. The headless storefront and the legacy ISML site should be treated as separate operational reads even when they ship from the same warehouse.
- The realm-wide arithmetic mean swings 4 to 6% week-on-week purely from currency mix. A stronger JPY week pulls the headline up; a stronger GBP week pulls it down. The number reflects FX volatility, not merchant performance. Pin per-site panels and ignore the realm-level AOV tile for any operational decision.
Sibling cards merchants should reference together
AOV is rarely useful on its own, especially on multi-site SFCC realms. Pair it with these:Reconciling against the vendor’s own dashboard
Where to look in Business Manager: SFCC’s admin tool is Business Manager athttps://<realm>.business.demandware.net. The closest report is Merchant Tools, Site, Reports & Dashboards, Sales for any single site. Set the same date range and look at the Average Order Value column. That figure should match this card’s per-site read to within timezone and status-filter differences.
For multi-site comparisons, use the cross-site Reports & Dashboards rollup (in BM) which reports in the realm’s configured base currency.
Other Business Manager views that look like the same number but aren’t:
- Reports & Dashboards, Sales (per-site): matches this card for that site only.
- Order Search, sum of
order_total÷ count: closest manual computation, useful for spot checks. - Pricing & Promotion reports: AOV attributed to specific promotions, narrower than this card.
Internal identity (within SFCC):
sfcc.aov = sfcc.total_revenue ÷ sfcc.total_orders
These three cards are mathematical siblings; if they don’t match it’s a sampling or rounding artefact, not a real disagreement.
Cross-connector reconciliation (when the merchant has connected analytics):
Known limitations / merchant FAQs
Why is my realm-wide AOV figure jumping around when nothing changed in the business? On multi-site realms, AOV is the most volatile of the executive trio (revenue, orders, AOV) because it is sensitive to mix shifts that revenue and order count absorb. A single big B2B order at 80 pulls the realm AOV up by 50% on its own. Read AOV per-site as the operational view, and treat the realm AOV as a navigation anchor only. My DTC AOV slipped 8% but revenue is flat. Where did it go? Three usual culprits in order of likelihood. (1) Discount lift. A site-wide promotion or aggressive coupon stack mechanically lowers AOV by the discount percentage. Checkmerchandise_total - shipping_discount - product_promotional_adjustment against order_total. (2) Mix shift toward smaller baskets. Top-sellers moved from premium SKUs to entry-level SKUs (a viral 120 hero piece). Check Top Products. (3) New-customer surge. A successful acquisition campaign brought in first-time buyers who typically spend less than returners.
B2B drives my realm AOV. Is that the wrong way to read this card?
Yes, on multi-site realms the right read is per-site. B2B AOV at 8,000 dominates the arithmetic mean once you have any B2B volume; DTC sees its real signal masked. Use the per-site filter for DTC AOV (typically 200), keep B2B as its own panel, and pin both side-by-side.
Why does Business Manager show a slightly different AOV?
Three reasons. (1) Refund netting. Some BM reports show “net AOV” subtracting refunds; this card shows gross. (2) Site filter. BM defaults to a single site; this card aggregates all sites. (3) Status filter. BM defaults to confirmed orders only; this card includes all unless filtered.
Does AOV include B2B contract pricing or only catalogue prices?
B2B order_total reflects whatever was negotiated and stamped on the order line, including account-priced contracts, volume tiers, and customer-group discounts. SFCC stores the final order_total after every adjustment; the card sums it as-is. If you want to see contract-vs-catalogue uplift, that is a separate analysis using pricebook and customer_group_promotions.
How do I lift AOV on an SFCC site?
Five practical levers, in typical-lift order. (1) Free-shipping threshold set 15 to 25% above current AOV. ISML pages and SCAPI both honour shipping_promotion rules. (2) Cross-sell zones in PDP and cart, populated by recommendation calls or Einstein Recommendations. (3) Bundle pricing via Variation Master groups or Einstein Bundles. (4) B2B tiered pricing if you run a trade portal, lift the second-tier ladder. (5) Subscription-and-save cartridges like Subscribe Pro or Ordergroove which raise effective AOV by locking customers into recurring orders. Test for 4 to 6 weeks; measure AOV and conversion rate together.
What about subscription orders, do they each count for AOV?
Yes. Each recurring SFCC order created by a subscription cartridge is a separate row with its own order_total. A customer paying 40 in AOV, not one $480 order. If you want a customer-lifetime view, use a CLV / LTV card (on the roadmap).
My headless storefront on SCAPI shows higher AOV than my legacy ISML site. Why?
Two usual reasons. (1) Audience differs. Headless storefronts are typically rolled out for a sub-brand or a flagship segment; the visitor mix skews to higher intent or higher LTV customers. (2) Checkout flow differs. Modern PWA checkouts often expose recommendation widgets and bundle prompts more aggressively than ISML, lifting basket size. Treat the two sites as separate operational reads.