Total Registered Customers for the selected period.
At a glance
The count of registered customer profiles held in your Salesforce Commerce Cloud (SFCC, formerly Demandware) customer list(s), the durable customer records that exist independently of any single order. This is the size of your known, addressable audience: people who created an account, not the much larger pool of guest checkouts who bought once and left no profile behind. On a multi-site realm, customer lists are often shared across sites, so this number is typically realm-wide rather than per-site.
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 fashion retailer runs a single SFCC B2C realm with four DTC sites (US, UK, DE, JP) and a B2B portal, all sharing one customer list. On 12 Jun 26 the card reads the realm-wide registered base. Decomposing where those profiles came from over the trailing period:
Things to notice:
- A third of the base registered at checkout, not before. The checkout-time registration prompt is doing heavy lifting (980,000 profiles). If that step gains friction or is removed in a checkout redesign, registered-customer growth stalls even though revenue holds. Watch this card after any checkout change.
- Guest checkout is invisible here, and that is the point. Over the same window the realm took far more orders than it gained profiles. The shoppers who checked out as guests are real revenue but leave no durable record. Pair this card with New Customers and Total Orders to size the guest gap.
- The B2B base is tiny in count but disproportionate in value. 28,400 trade profiles is 1% of the base, yet B2B AOV runs many times DTC, so those accounts can drive an outsized share of revenue. A flat raw count hides that. Read it alongside Repeat Purchase Rate to see how much of the base actually transacts more than once.
- The go-live import (142,000) is a one-time step in the trend. If you re-platformed onto SFCC, the migration day shows up as a single jump, not organic growth. Strip it out mentally when reading the slope, otherwise you overstate ongoing acquisition.
Sibling cards merchants should reference together
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. Registered customers live in customer lists, not in the Sales reports.
The closest view is Merchant Tools, Customers, Customer Lists, then open the customer list attached to your site(s) and read the total customer count for that list. On a shared-list realm a single list backs every site; on a per-site model you may need to read each list and sum. Administration, Global Preferences, Customer Lists shows which list each site is bound to, which is the first thing to confirm when the numbers look off.
Other Business Manager views that touch customers but are not this card:
- Customers, Customer Groups: dynamic and static segments within a list, narrower than the full list count.
- Reports & Dashboards, Customers: new vs returning customer reporting over a window, a flow view, not the cumulative stock this card shows.
- Customers, Customer Search: lets you filter and export profiles, useful to verify which test patterns inflate the raw count.
Known limitations / merchant FAQs
Does this include guest checkouts? No. Only registered customer profiles are counted. Guest checkouts complete a purchase without creating aCustomer profile, so they generate revenue but never appear here. The gap between your order volume and registered-customer growth is your guest ratio, and it directly caps how much of your audience you can email or remarket to. If that gap is wide, the lever is your account-creation flow, not this card.
Is this per site or realm-wide?
It depends on how your realm binds customer lists to sites. SFCC commonly shares one customer list across several sites, in which case this card is effectively realm-wide. If your realm uses per-site lists, the card counts the connected list(s). Confirm the binding in Administration, Global Preferences, Customer Lists before comparing against any per-site read.
Why is the count higher than the number of people who bought this month?
Because this is a cumulative stock, every profile ever created and not deleted, while a monthly buyer count is a flow. Most of the registered base is dormant at any moment. To see the active slice, pair this card with Repeat Purchase Rate and the order cards.
We re-platformed onto SFCC and imported our old customers. Does that inflate the trend?
The migration appears as a single step change on go-live day, not organic growth. Read the slope after the import to judge ongoing acquisition. The imported profiles are genuine registered customers, they just did not register on SFCC, so they should be counted, but do not mistake the one-time jump for a marketing win.
Do test and internal accounts count?
They can, if they live in the production customer list. Sandbox and QA profiles inflate the raw figure. Where a recognisable test pattern exists (for example a known email domain), profile-level filters can exclude it. If your count looks suspiciously round or high, check the customer list for internal accounts first.
Why is there no alert on this card?
Registered-customer count is a slow-moving stock that should drift upward, so a single threshold rarely carries operational meaning the way a stock-out or failed-order alert does. The signal lives in the trend and in the actionable siblings (for example High-Value Customers Unengaged on Email), not in a level alarm. Alert rules can still be tuned per profile if your business wants one.
How does this relate to Einstein and personalisation?
Einstein and SFCC personalisation operate on registered profiles and their behaviour, so this base is the raw material those features draw on. A larger, cleaner registered base gives Einstein more signal. That is another reason guest-heavy stores under-perform on personalisation: the system simply knows fewer of the people walking through the door.