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.
| What it counts | AVG(order_total) across every order returned by SCAPI / OCAPI in the window. Each order contributes equally weighted by order_total, regardless of basket size. |
| VAT / tax treatment | Tax-inclusive by definition. SFCC order_total already includes tax_total. UK / EU sites typically run tax-inclusive line item pricing; US sites typically run tax-on-top, both end up reflected in order_total. The card sums blindly, it does not normalise across the two modes. |
| Shipping | Included. adjusted_shipping_total (post-shipping-discount) is part of order_total. |
| Discounts | Already deducted. order_total is the post-promotion, customer-paid figure. |
| Refunds | NOT deducted. SFCC tracks refunds via separate Return / Credit objects on the Orders API. The original order_total does not change after a refund. A fully refunded 200 to AOV. For a net view, divide Net Revenue by Total Orders. |
| Cancelled / voided orders | Included by default. CANCELLED, FAILED, REPLACED, and REPLACEMENT rows count. Filter to confirmation_status = CONFIRMED and status IN [OPEN, COMPLETED] for a realised-cash AOV. |
| Currency | Multi-currency arithmetic mean WITHOUT FX conversion. A realm running USD, GBP, EUR, and JPY sites gets a meaningless single AOV at the realm level. Use the per-site filter for the operational view. |
| Channels / sources | Multi-site by design. Every siteId contributes (DTC US, DTC UK, B2B portal, headless SCAPI sub-brand). B2B AOV at 8,000 dominates any realm-wide arithmetic mean once any B2B volume is present, per-site is the right read. |
| Time window | 30D vsP (default 30 days vs prior 30 days) |
| Alert trigger | drop >10% WoW, driven by sentiment_key: aov_trend |
| Roles | owner, marketing, finance |
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):siteId | Site | Orders | Revenue | AOV | vs prior 30D |
|---|---|---|---|---|---|
RefArch-US | US DTC, USD | 184,200 | $23,577,600 | $128 | $131 (down 2.3%) |
RefArch-UK | UK DTC, GBP | 62,400 | £6,739,200 | £108 | £105 (up 2.9%) |
RefArch-DE | DE DTC, EUR | 41,800 | EUR4,932,400 | EUR118 | EUR126 (down 6.3%) |
RefArch-JP | JP DTC, JPY | 28,600 | JPY480,480,000 | JPY16,800 | JPY16,400 (up 2.4%) |
RefArch-B2B | B2B trade portal, USD | 1,420 | $6,887,000 | $4,850 | $4,720 (up 2.8%) |
Headless-Subbrand | Sub-brand on SCAPI, USD | 12,800 | $1,203,200 | $94 | $89 (up 5.6%) |
- 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:| Card | Why pair it with AOV |
|---|---|
| Total Revenue | AOV × Orders = Revenue. AOV without revenue context misreads basket-shift moves. |
| Total Orders | The denominator. Rising AOV with falling orders means you’re selling more to fewer people, often the signal of a successful targeted campaign that pulled higher-LTV buyers. |
| Conversion Rate | Trades off with AOV. Free-shipping thresholds raise AOV but slightly hurt conversion; the right balance is whichever moves total revenue. |
| Top Products | Tells you which SKUs moved AOV up or down. Mix-shift drives most AOV changes. |
| Repeat Customer Rate | Repeat buyers spend more per order than first-timers. Rising AOV often correlates with rising repeat rate. |
| Refund Rate | This card is gross of refunds. A refund-heavy returns season can mean gross AOV holds while net AOV slips. |
adobe_commerce.aov | Closest enterprise-tier peer. Documentation cross-link only. |
shopify.aov | Same metric on Shopify. Useful for SFCC merchants running a Shopify Plus pop-up alongside the realm. |
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.
| Reason | Direction | Why |
|---|---|---|
Multi-currency rollup. BM cross-site rollup uses the realm’s base currency (FX-converted at the day’s rate). Vortex IQ sums order_total in display currency without FX. | Materially different on international realms | Realm-wide AOV is meaningless without FX; pin per-site panels for the operational view. |
Site filter scope. BM defaults to the currently-selected site; Vortex IQ aggregates every siteId unless filtered. | Vortex IQ’s realm AOV is a mixed-currency artefact | Use per-site filter to compare apples-to-apples. |
| Refund netting. Some BM reports show “net AOV” subtracting refunds; this card is gross. | BM lower (some views) | Use Net Revenue ÷ Total Orders for the netted view. |
| Status filter. BM defaults to confirmed orders only; Vortex IQ includes every status unless filtered. | Vortex IQ slightly lower (the unconfirmed orders’ lower average pulls the mean down) | Filter to confirmation_status = CONFIRMED. |
| Time-zone. BM uses the site’s configured time zone; Vortex IQ runs on UTC by default. | Boundary days off | Averages out for 30D windows; visible on “today”. |
Replacement double-count. By default both REPLACED and REPLACEMENT rows count, with the replacement typically smaller; this pulls AOV down slightly. | Vortex IQ slightly lower when replacements are heavy | Filter status != REPLACED to deduplicate. |
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):
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
google_analytics.ga_aov | GA4 AOV ≈ SFCC AOV, within ±5% on a single-site comparison | GA4 misses 10 to 25% of orders due to ad blockers and consent rejection; the missing population is not random (mobile-heavy, EU-heavy, lower-AOV typically), so GA4 AOV may run slightly higher than SFCC AOV by skewing toward higher-AOV desktop conversions. Treat SFCC as the source of truth for AOV. |
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.