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.
| What it counts | COUNT(distinct order_no) ÷ COUNT(distinct session_id) per site, then aggregated. SFCC stamps each visit with a session_id via cookie; a returning customer who visits three times and buys once contributes 3 to the denominator and 1 to the numerator. |
| Numerator (orders) | Confirmed orders by default. Cancelled / failed / replacement rows can be filtered out for a strict realised-cash CR. |
| Denominator (sessions) | SFCC server-side session count where available, with a fallback to ingested SCAPI / OCAPI session-event data. Using server-side counts (not GA4) means ad-blocker / consent rejection does not deflate the CR. |
| VAT / tax treatment | n/a, this is a ratio. |
| Shipping | n/a, ratio metric. |
| Discounts | n/a, ratio metric. |
| Refunds | NOT subtracted from the numerator. A refunded order still counts in CR; the conversion event happened. Refund leakage is a separate dial. |
| Cancelled / voided orders | Excluded by default for CR. The confirmation_status = CONFIRMED filter is the right denominator-aware view. |
| Currency | n/a, ratio metric. |
| Channels / sources | Multi-site by design. Each siteId has its own CR. Realm-wide CR is a traffic-weighted average of every site, dominated by the highest-traffic site. Per-site is the right operational read. |
| B2B portals | Counted with the same definition. B2B CR runs 5 to 25% because trade portals are mostly logged-in account holders with purchase intent; this skews the realm-wide CR upward when B2B traffic is meaningful. |
| Time window | 30D vsP (default 30 days vs prior 30 days) |
| Alert trigger | <1.5% (DTC default), driven by sentiment_key: conversion_rate_trend. Raise to <3% for B2B-dominated sites and lower to <1% for content-heavy / awareness-stage sites. |
| Roles | owner, 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 running on Salesforce Commerce Cloud, multi-site realm. Window covers 14 Mar 26 to 12 Apr 26.siteId | Site | Sessions | Orders | CR | vs prior 30D |
|---|---|---|---|---|---|
RefArch-US | US DTC | 8,420,000 | 184,200 | 2.19% | 2.34% (down 0.15pp) |
RefArch-UK | UK DTC | 2,840,000 | 62,400 | 2.20% | 2.18% (flat) |
RefArch-DE | DE DTC | 2,210,000 | 41,800 | 1.89% | 1.94% (down 0.05pp) |
RefArch-JP | JP DTC | 1,980,000 | 28,600 | 1.44% | 1.48% (down 0.04pp) |
RefArch-B2B | B2B trade portal | 18,400 | 1,420 | 7.72% | 7.41% (up 0.31pp) |
Headless-Subbrand | Sub-brand on SCAPI | 1,420,000 | 12,800 | 0.90% | 0.84% (up 0.06pp) |
| Realm-wide (traffic-weighted) | 16,888,400 | 331,220 | 1.96% | 2.06% |
- 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
| Card | Why pair it with Conversion Rate |
|---|---|
| Total Orders | The numerator. CR moves are only meaningful in the context of total order volume. CR down + orders up = traffic-led growth, healthy. CR down + orders down = funnel problem. |
| Total Revenue | The other half. Revenue can hold or rise even with CR drops if AOV moved. |
| Average Order Value | Trades off with CR. Free-shipping thresholds raise AOV but slightly lower CR; the right balance is whichever moves total revenue. |
| Top Products | A CR drop concentrated on a specific category often points to a single broken PDP, removed price, or stale recommendation panel. |
| Out-of-Stock Products | OOS spikes drop CR cleanly. A 5% CR drop with a 12% OOS share is usually the same story. |
| Refund Rate | The downstream view. A CR rise driven by aggressive promotion often shows up as a refund-rate rise 14 to 30 days later. |
adobe_commerce.conversion_rate | Closest enterprise-tier peer, documentation cross-link only. |
google_analytics.ga_conversion_rate | The browser-side view, useful for understanding traffic-source quality even when SFCC server-side CR is the truth. |
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.
| Reason | Direction | Why |
|---|---|---|
Session counting. BM uses SFCC’s server-side session_id. Vortex IQ uses the same source where available. | Should match closely | Largest gaps come from custom session-handling cartridges that override the default cookie behaviour. |
| Time-zone. BM uses the site’s configured time zone; Vortex IQ runs on UTC. | Boundary days off | Averages out for 30-day windows. |
Order-status filter. BM may filter to COMPLETED only; Vortex IQ uses confirmation_status = CONFIRMED by default which includes OPEN orders awaiting fulfilment. | Vortex IQ slightly higher | Set BM to “All confirmed” to match. |
| Bot / scraper sessions. BM has bot filters; Vortex IQ relies on SFCC’s upstream bot exclusion. | Either, drift is small | Spikes during scraper attacks can deflate CR until SFCC’s WAF blocks the source. |
B2B logged-in sessions. Some BM views exclude B2B trade-portal sessions from the headline; Vortex IQ includes every siteId. | Vortex IQ higher when B2B is present | Filter to DTC sites only. |
| Page-impression filtering. Some BM reports count only sessions that hit a “purchasable” page (PDP, cart, checkout); Vortex IQ counts every session. | Vortex IQ slightly lower | This narrows the denominator and raises BM’s CR; not always desirable. |
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:
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
google_analytics.ga_conversion_rate | GA4 CR ≈ SFCC CR × (1 − tracking gap), GA4 typically 10 to 25% lower | GA4 misses 10 to 25% of orders due to ad-blockers and consent rejection, AND misses some sessions. The ratio of the two losses determines whether GA4 CR runs higher or lower than SFCC. Treat SFCC as the source of truth for CR. |
google_analytics.ga_total_transactions ÷ google_analytics.ga_total_sessions | Should approximate sfcc_total_orders ÷ sfcc_total_sessions | Both sides have measurement gaps, but SFCC’s are smaller. Use GA4 for traffic-source decomposition, SFCC for the headline. |
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.