Per-site / per-locale revenue mix. Enterprise SCC realms run 5-20 country sites typically - shapes localisation + market investment.
At a glance
How revenue splits across the storefronts in your Salesforce Commerce Cloud (SFCC, formerly Demandware) realm, one slice per siteId / locale. This is the card that turns SFCC’s defining feature, one realm hosting many country and brand storefronts, into a market-investment view. Enterprise realms commonly run 5 to 20 sites (US, UK, DE, FR, JP, a B2B portal, a headless sub-brand, and so on), and the shape of this donut tells you where your money actually comes from and where localisation and marketing spend should follow.
| What it counts | SUM(order_total) grouped by siteId (and locale) over the window. Each slice is one storefront’s gross revenue. order_total is the customer-paid figure including merchandise, shipping, and tax. |
| Why it matters | Realm-wide revenue is a single number that hides everything interesting. This card is where you see that, say, the US is 70% of revenue while five EU sites split the rest, or that a B2B portal carrying 4% of orders carries 22% of revenue. It directly informs market investment: which sites deserve more localisation, which underperform their traffic, and which are not worth the cartridge maintenance. |
| Reading the value | Read it as a mix, not absolute levels. A slice growing or shrinking relative to the others is the signal. Watch for a site whose revenue share is far below its traffic or catalogue investment, that is an underperforming market. Watch for over-concentration in one site, that is a single point of failure. |
| VAT / tax treatment | Each slice is tax-inclusive, like order_total everywhere in SFCC. UK / EU sites typically use tax-inclusive line pricing; US sites typically add tax on top; both land in order_total. |
| Currency | Multi-currency, no FX by default. Each site reports in its own currency. A naive donut that mixes USD, GBP, EUR, and JPY slices is visually misleading because the units differ. Read share within a single currency, or use a base-currency view where available, before drawing conclusions about relative size. |
| Refunds | NOT deducted. Each slice is gross order_total; refunds are tracked separately via Return / Credit objects. Use Refund Rate for the leakage layer per site. |
| Locale vs site | One siteId can serve multiple locales (a DE site serving de_DE and de_AT). Whether slices are per-site or per-locale depends on configuration; the card label and tooltip indicate the grouping in use. |
| Unit | currency |
| Time window | 30D (default 30-day window) |
| Alert trigger | none configured by default. Mix-shift alerts are commonly added per profile, for example flagging when any site’s share moves sharply versus the prior period. |
| Sentiment key | scc_revenue_by_site |
| Roles | owner, finance, marketing |
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 runs one SFCC B2C realm with four DTC sites, a B2B portal, and a headless sub-brand. The 30-day window covers 14 May 26 to 12 Jun 26. To make the mix readable, the team views it converted to a single base currency (USD) using month-end rates.siteId | Site / locale | Native currency | Revenue (USD base) | Share of realm |
|---|---|---|---|---|
RefArch-US | US DTC, en_US | USD | $23,580,000 | 56.2% |
RefArch-UK | UK DTC, en_GB | GBP | $8,420,000 | 20.1% |
RefArch-DE | Germany DTC, de_DE | EUR | $5,310,000 | 12.7% |
RefArch-JP | Japan DTC, ja_JP | JPY | $3,240,000 | 7.7% |
RefArch-B2B | B2B trade portal, en_US | USD | $1,180,000 | 2.8% |
Headless-Subbrand | Sub-brand, en_US (PWA Kit / SCAPI) | USD | $190,000 | 0.5% |
| Total | $41,920,000 | 100% |
- One site is over half the realm. US DTC at 56.2% is the engine and the single point of failure. If
RefArch-UShas a bad day, the realm-wide revenue card moves hard while four other sites sit untouched. This is why a per-site view matters: the headline can hide a healthy estate with one sick site, or a sick estate masked by one strong one. - The slices are only comparable because they were converted to a base currency first. In native currency the raw donut would mix USD, GBP, EUR, and JPY, slices whose sizes mean nothing relative to each other. Always read this card in a single currency. SFCC sites each carry their own currency by design, so the base-currency view (or a single-site filter) is the only honest comparison.
- The headless sub-brand is tiny but strategically separate. At 0.5% (
Headless-Subbrand) it barely registers, but it is a distinct brand on PWA Kit / SCAPI and should be judged on its own growth curve, not buried in the realm total. A new headless site often starts as a sliver here and is exactly where you watch for early traction. - Germany at 12.7% may be under-indexing its traffic. If
RefArch-DEcarries, say, 18% of sessions but 12.7% of revenue, that gap is a localisation, payment-method, or conversion problem specific to that market. Pair this card with Conversion by Locale to confirm whether a low revenue share is a traffic problem or a conversion problem.
Sibling cards merchants should reference together
| Card | Why pair it with Revenue by Site / Locale |
|---|---|
| Conversion by Locale | The natural follow-up: a low revenue share is either a traffic problem or a conversion problem. Per-locale CR tells you which. |
| Total Revenue (30d) | This card decomposes the realm-wide total into its site-level slices. Read them together. |
| Orders by Currency | Revenue mix and currency mix are two views of the same multi-site structure. A currency shift usually shows up as a revenue-share shift. |
| Active Sites / Storefronts | The slice count here should match the active-site count there. A missing slice is a missing or dark site. |
| Average Order Value | Per-site AOV explains why a small-volume site (like a B2B portal) can hold a large revenue slice. |
| Top Products by Revenue | The same SKU can sell very differently across locales; pair to see which products drive which markets. |
Reconciling against Salesforce Commerce Cloud
Where to look in Business Manager: SFCC’s admin tool is Business Manager, accessed at a per-realm URL likehttps://<realm>.business.demandware.net. The per-site revenue figures live in Merchant Tools, Site, Reports & Dashboards, Sales, scoped to whichever single site you select in the Business Manager site picker. To reproduce this card you read each site’s Sales report in turn and place them side by side; SFCC does not always present a single cross-site donut in the standard reports.
For a cross-site rollup, Reports & Dashboards, Sales at the realm level (if your role has multi-site read) reports in the realm’s configured base currency. That base-currency rollup is the right thing to compare this card against when you are viewing it in base currency.
Other Business Manager views to be careful with:
- Reports & Dashboards, Sales (per-site): matches one slice of this card for that site, in that site’s currency.
- Reports & Dashboards, Sales (realm rollup): matches the whole card only when both are in base currency.
- Order Search filtered by site and date: lets you sum
order_totalper site via export for a manual cross-check.
| Reason | Direction of divergence |
|---|---|
| Currency / FX. Per-site BM reports are in site currency; the realm rollup is in base currency; this card is in display currency unless you convert. Mixing these produces apparent gaps. | Material for international realms |
| Time-zone. BM site reports run in each site’s configured time zone; Vortex IQ runs on UTC by default. Boundary days shift. | ±1 day at boundary |
Status filter. BM Sales reports apply a default status filter; this card sums all order_total unless filtered. The “All” filter in BM matches Vortex IQ behaviour. | Vortex IQ higher than filtered BM |
| Data warehouse lag. SFCC Reports & Dashboards lags real-time order placement by minutes; SCAPI / OCAPI is near-real-time. | Vortex IQ slightly higher for current-day data |
| Locale vs site grouping. If this card groups by locale while BM reports by site, a multi-locale site splits across slices. | Slice-level differences, realm total unchanged |
Known limitations / merchant FAQs
Why do the slices look wrong when I view the realm in native currencies? Because each SFCC site reports in its own currency and the donut is comparing different units. A USD slice and a JPY slice are not on the same scale, so the visual proportions mislead. Always read this card in a single currency: use the base-currency view or filter to one site at a time. SFCC’s multi-currency design makes a mixed-currency donut technically possible but operationally meaningless. Is this per-site or per-locale? It depends on configuration. OnesiteId can serve several locales, so the card can group by site (one slice per storefront) or by locale (one slice per language/region within a site). The card label and tooltip indicate which grouping is active. If a multi-locale site appears as several slices, the card is in locale mode.
Why is our tiny-volume B2B portal such a large revenue slice?
Because B2B AOV is typically 30 to 50 times DTC AOV on enterprise SFCC realms. A B2B portal can carry a small percentage of orders and still hold a large revenue share. This is expected, not a data error. Pair with Average Order Value to see the per-site AOV that explains the gap.
A site shows zero or near-zero revenue. Is it broken?
Possibly, or it may be a newly launched, low-traffic, or pre-launch site. Check first against Active Sites / Storefronts to confirm it is enabled, then against Conversion by Locale to see whether it has traffic that is not converting. A live, trafficked site with zero revenue is an incident; a new or disabled site reading zero is expected.
Does this include refunds?
No. Each slice is gross order_total. SFCC tracks refunds via separate Return / Credit objects that do not change the original order. For net revenue per site, read this card alongside Refund Rate and apply the refund layer per site.
How does a headless PWA Kit site appear here?
As its own slice, with its own siteId. A headless storefront on PWA Kit / SCAPI is a distinct site, so its revenue is tracked separately from the legacy ISML sites. This is intentional, a headless sub-brand should be measured on its own, and this card is where you watch its share grow.
Can I alert on a site’s share dropping?
There is no threshold by default, but mix-shift alerts are commonly configured per profile, for example flagging when a site’s revenue share moves sharply versus the prior period. Set this in the Sensitivity tab. Because the card spans many sites, most merchants alert on the one or two sites that matter most rather than on every slice.