Orders / sessions. Below 1.5% usually = checkout / page-speed issue, not traffic.
At a glance
Share of Salesforce Commerce Cloud sessions that resulted in a confirmed order in the period. Computed as COUNT(orders) ÷ COUNT(sessions). The single best canary for checkout-funnel health and the first metric to check after a site release, an indexer rebuild, or a payment integration change.
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, multi-site realm. Window covers 14 Mar 26 to 12 Apr 26.
What’s interesting:
- The realm-wide CR is 1.96%, above the
<1.5%alert threshold. The card stays quiet. But the real story is in the per-site spread: US is down 0.15pp, JP sits at 1.44% (below threshold for any DTC view), and the headless sub-brand sits at 0.90% (well below). Read CR per-site on SFCC realms. - The headless sub-brand on SCAPI runs structurally lower CR (0.90%). Three usual reasons: (a) it is a newer site with marketing programs still maturing, (b) the React PWA checkout has fewer cross-sell / trust signals than ISML, (c) some session events from the headless front-end are lost to ad-blockers (server-side counts close most of this gap, but not all). Pair with Total Orders, the sub-brand’s order count is up 5.6% on the prior period; CR rose 0.06pp despite the structural drag. The trend is healthy.
- B2B portal CR is 7.72%, 4× DTC. This is normal, trade portals filter top-of-funnel browsing because nearly all visitors are logged-in account holders. The
<1.5%alert default would never fire on a B2B site; raise the threshold to<3%or<5%for the B2B panel. - JP CR sits at 1.44%, below the
<1.5%alert threshold. Common pattern on multi-locale realms: non-home markets have less localised pricing, less local payment-method coverage (no Konbini / no Bank Transfer), and slower CDN performance from the home region. Use Conversion Rate by Market (when added) to confirm this is a localisation issue rather than a checkout outage. JP customers in apparel typically convert lower than US customers across all platforms; this is structural, not a bug. - The 0.10pp realm-wide CR drop is the kind of move worth investigating proactively. No site triggered the alert individually; the realm-wide drop is below threshold; but the trend is consistently down across US, DE, and JP. Pair with checkout-error rates (BM Reports & Dashboards → Errors) and the PSP’s authorisation rates to rule out a payment integration regression.
Sibling cards merchants should reference together
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 like-for-like view is Merchant Tools, Site, Reports & Dashboards, Conversions for any single site. Set the same date range, ensure the site filter matches Vortex IQ’s per-site selection, and read the Conversion Rate column.
The cross-site rollup view is Reports & Dashboards, Site Performance which weights each site by sessions; the realm-wide CR there should match this card’s realm-wide read within timezone rounding.
Other Business Manager views that look like the same number but aren’t:
- Reports & Dashboards, Sales (per-site): shows order count, not CR.
- Einstein Recommendations dashboard: CR attributed to recommendation impressions only, narrower than this card.
- Marketing Cloud Personalisation (formerly Evergage / Interaction Studio): CR within a personalisation segment, not site-wide.
Internal identity (within SFCC):
sfcc.conversion_rate = sfcc.total_orders ÷ sfcc.total_sessions (per-site)
If realm-wide CR doesn’t equal sum(orders) ÷ sum(sessions) across sites, you’re looking at a per-site averaged CR, not a traffic-weighted realm CR. Vortex IQ uses the traffic-weighted version.
Cross-connector reconciliation:
A persistent gap > 30% between SFCC CR and GA4 CR usually means GA4’s UTM hygiene is poor or the tag-manager configuration is outdated. The fix is on the analytics side, not the SFCC side.
Known limitations / merchant FAQs
Why is my realm-wide CR misleading? Should I read it per-site? Yes, almost always. SFCC realms typically host sites with very different traffic mixes (paid social-heavy DTC US, SEO-driven UK, trade-only B2B portal, headless sub-brand). Each has structurally different conversion behaviour. The realm CR is a weighted average of those, dominated by the highest-traffic site, and often hides material problems on smaller sites. Pin per-site CR panels for any operational read. My CR dropped to 1.2% but traffic is up 30%. Should I be worried? Almost always no. The relationship between CR and traffic volume is inverse on most acquisition campaigns: a wave of top-of-funnel paid traffic (broad social audiences, generic Google searches) brings lower-intent visitors who convert at half the rate of organic and direct visitors. The right question is whether total orders moved, not whether CR moved. Pair this card with Total Orders. If orders rose more than CR fell in proportion, the campaign worked. My headless storefront shows CR of 0.8%, my ISML site shows 2.4%. Is the headless build broken? Probably not, but worth investigating. Three usual reasons. (1) Tracking gap. Headless React storefronts often lose 10 to 20% of GA4 / Adobe Analytics events to ad-blockers and consent failures; the order count reaching SFCC is correct but the session denominator is undercounted on the analytics side. The card uses SFCC server-side session counts where available, which closes most of this gap. (2) Audience. Headless sub-brand sites often run with smaller, more fragmented marketing programs producing less qualified traffic. (3) Checkout maturity. New headless checkouts ship with fewer cross-sell, recovery, and trust signals; SFCC ISML sites have been tuned for years. Does the card count B2B portal sessions and orders? Yes if the B2B portal is configured as asiteId on the realm. B2B CR is typically higher than DTC (5 to 25%) because trade portals filter out top-of-funnel browsing; visitors are nearly all logged-in account holders with purchase intent. This pulls realm-wide CR up if B2B traffic is meaningful, another reason to read per-site.
My CR dropped overnight from 2.1% to 1.4% with no campaign change. What broke?
Three usual canaries to check, in order. (1) Checkout error rate. Open BM Reports & Dashboards → Errors and look for a spike on Checkout-Submit failures. A failed payment integration, expired API certificate, or PSP outage will surface there. (2) Add-to-cart rate. If ATC dropped, the issue is upstream (broken PDP page, removed price, a hero image failing to render). (3) Site-search results. If site-search return rate dropped, an indexer ran badly and customers cannot find products. SFCC’s ConfigZero / Einstein search indexes update overnight; a bad index sinks CR cleanly.
Are sessions or visitors used as the denominator?
Sessions. SFCC stamps each visit with a session_id; this card divides confirmed orders by distinct sessions in the window. A returning customer who visits three times and buys once contributes 3 to the denominator and 1 to the numerator. If you want a per-visitor view (single denominator increment per unique customer), that is a different card.
The Salesforce account team’s CR number is different. Why?
Salesforce’s account-team reports often pull from Marketing Cloud Personalisation (formerly Evergage / Interaction Studio) or Einstein Recommendations, which can use different denominators (page views, recommendation impressions, personalisation segments). They are also commonly looking at one site only. Compare like-for-like: same site, same date range, sessions denominator.
What is a “good” CR on SFCC?
Highly variable by industry, traffic mix, and AOV. Useful benchmarks. (1) DTC apparel typically 1.5 to 2.5%. (2) B2B trade portals typically 5 to 25% (logged-in account holders convert at much higher rates). (3) Multi-locale international DTC typically 1.0 to 2.0% (the card pools locales by default; non-localised pricing depresses CR in non-home markets). The <1.5% alert threshold is a reasonable DTC default; raise it for B2B sites and lower it for content-heavy or top-of-funnel sites.