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.
| What it counts | The number of registered customer profiles in the SFCC customer list(s) attached to the realm. A registered customer is a Customer / profile object created when a shopper signs up or opts to create an account at checkout. It persists across sessions and orders. |
| Why it matters | This is your owned audience, the addressable base you can email, segment, personalise to via Einstein, and remarket to. Guest checkouts convert revenue but leave no durable relationship; registered customers are the asset that compounds. The trend tells you whether your acquisition and account-creation flows are growing the base or stalling. |
| Reading the value | Read it as a slowly-moving stock figure, not a flow. It should climb steadily as new registrations exceed any list pruning. A flat or falling line on a growing-traffic store usually means the account-creation step has friction, or guest checkout is absorbing shoppers who would otherwise register. |
| Registered vs guest | Registered only. Guest-checkout shoppers do not create a profile and are not counted here. The gap between order volume and registered-customer growth is itself a useful diagnostic: a high guest ratio caps your remarketing reach. |
| Customer lists / scope | SFCC customer lists can be shared across multiple sites in a realm or scoped per site. This card counts profiles in the connected list(s); on a shared-list realm that is effectively the whole audience. |
| Test / internal profiles | Sandbox, QA, and internal test accounts can inflate the raw count if they live in the production customer list. Profile-level filters can exclude known test patterns where configured. |
| Unit | number |
| Time window | RT (live count, recomputed on each refresh) |
| Alert trigger | none configured |
| Sentiment key | scc_total_customers |
| 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 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:| Source of profile | Profiles | Share of base |
|---|---|---|
| Created at account sign-up (pre-checkout) | 1,840,000 | 61% |
| Created at checkout (opted to register) | 980,000 | 33% |
| Imported from prior platform at go-live | 142,000 | 5% |
| B2B trade-account profiles | 28,400 | 1% |
| Total Registered Customers (this card) | 2,990,400 |
- 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
| Card | Why pair it with Total Registered Customers |
|---|---|
| New Customers | The flow that feeds this stock. New Customers is the rate of additions; this card is the cumulative base. A flat base with healthy New Customers means churn or pruning is offsetting growth. |
| Repeat Purchase Rate | Tells you what share of the registered base actually transacts again. A big base with low repeat rate is a re-engagement opportunity, not a healthy audience. |
| Total Orders | The gap between order volume and registered-customer growth sizes your guest-checkout ratio, which caps remarketing reach. |
| Average Order Value | Combine with the base to estimate value per known customer and spot mix shifts between DTC and B2B accounts. |
| High-Value Customers Unengaged on Email | The actionable slice of this base: which of your registered top spenders have gone quiet on email. |
| Total Revenue | Revenue divided by the registered base is a rough value-per-customer read; useful as a long-run trend. |
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.
| Reason | Direction of divergence |
|---|---|
| Customer-list scope. Business Manager shows one list at a time; Vortex IQ counts the connected list(s). If your realm has several lists and only one is connected, Vortex IQ reads lower. | Vortex IQ lower if lists are unconnected |
| Shared vs per-site lists. On a shared-list realm the count is realm-wide; a per-site BM read will look smaller than the realm total. | BM per-site lower than Vortex IQ realm-wide |
| Test / internal profiles. BM raw count includes sandbox and QA accounts unless filtered; Vortex IQ can exclude known test patterns where configured. | Vortex IQ lower when test filter is on |
| Refresh lag. New registrations appear in the API near-real-time; BM list counts and the data warehouse can lag a few minutes. | Vortex IQ slightly higher for current activity |
| Pruning / GDPR deletions. Right-to-erasure deletions remove profiles; depending on timing, BM and Vortex IQ can be briefly out of step. | ±small at deletion boundaries |
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. Sensitivity 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.