The Unified Customer Profile: Architecture for Knowing Who Your Customer Actually Is

Ask a marketing team "who are our customers?" and watch the investigation unfold: names and emails scattered across the CRM, consent records trapped in the email service provider, preferences owned by the recommendation engine, order history in commerce, login and location data in yet another system. The CX Works material framed this as a mystery with a crime scene, and the metaphor is apt because the outcome is genuinely a loss: generic experiences, unusable analytics, and regulatory exposure, all because no system holds the whole person. The fix is not a report; it is a data architecture with a governed profile at its center. This guide covers that architecture and, specifically, where SAP Commerce fits in it without overreaching.

The Silo Problem, Precisely#

A typical B2B stack runs a dozen customer-touching technologies (lead management, campaign tools, CRM, personalization, commerce, service); a multi-brand enterprise multiplies that. Each system captured customer data for its own purpose, in its own model, and the union was never anyone's job. The measurable symptoms:

• Blank insight fields: the attributes that would drive personalization (channel preference, frequency preference, interests, consent) are the ones most often missing or scattered, because no single system was accountable for them.
• Consent you cannot locate, let alone honor: the one data class where "we are not sure where it lives" is a compliance finding waiting to happen.
• Analytics on fragments: models and segments built on any single silo describe a sliver of the customer and mislead confidently. Garbage in, confident garbage out.
• Change that does not propagate: a customer updates their email in one place; the other eleven systems keep mailing the old address.

The strategic cost is market share, and the source's survey figure captures the scale of the pain: a majority of B2B organizations report that the inability to merge siloed data in time actively hobbles their initiatives.

The Architecture: A Governed Profile at the Center#

The customer-centric pattern places a single, governed profile store at the center of the stack, acting as the source of truth for customer identity, registration, consent, and the custom and system data that accrues over a relationship. In SAP terms this role is played by a CIAM/customer-data platform (SAP Customer Data Cloud is the portfolio answer); architecturally the role matters more than the product. Three responsibilities define it:

1. Transform data from every stack system into unified per-customer profiles keyed on one durable identity (the same immutable-key discipline the SSO and B2B identity guides insist on).
2. Orchestrate the profile, or specific attributes, bidirectionally across the ecosystem, including back-office ERP and MDM. Bidirectional is the load-bearing word: the profile both absorbs and distributes, which is what enforces first-party accuracy everywhere.
3. Govern the profile through its whole lifecycle, consent and preferences included, so there is exactly one place to change a consent record and have it stick everywhere.

The profile builds over time through interactions: a name and email captured at a conference, enriched through delegated onboarding, order history attached, preferences accumulated, all under one common ID. The data taxonomy from the source is a useful modeling checklist: identity (first-party plus federated/social), registration (consents, ToS/privacy/cookie acceptance, channel and frequency preferences), system (source, timestamps, location), and custom (brand preferences, content and product interactions, reviews, wishlists, sizes, loyalty).

Where SAP Commerce Fits: Participant, Not Master#

The critical architectural discipline, and the one commerce teams get wrong: the profile store is not the master of everything, and commerce is not the master of the customer. Draw the mastership map explicitly:

• Identity, consent, preferences, cross-channel profile: mastered by the CIAM/profile layer. Commerce federates against it for login (the OIDC and SSO guides) and reads the profile it needs.
• Organization/account master data (B2B): mastered by ERP/MDM, copied into both the profile layer and commerce's B2BUnit model (the B2B identity guide's onboarding flow).
• Transactional and commerce-native data: order history, carts, commerce entitlements live in commerce, and flow out to enrich the profile and analytics.
• The customer record in commerce (Customer/B2BCustomer): a working projection synced with the profile store, not an independent truth. When they disagree, the profile layer wins on identity and consent; commerce wins on orders.

Get this map wrong in the common direction (commerce quietly becoming a second identity master with its own consent flags) and you rebuild the silo problem inside your own estate. The integration seams that keep it honest are the ones the integration guides already cover: Integration Objects for profile sync, events for change propagation, a per-consumer OAuth client so the profile layer and commerce each read what they are entitled to.

Change Once, Update Everywhere, Honor Everywhere#

Two payoffs deserve their own treatment because they are why the architecture is worth its cost:

Data quality for personalization and ML. Recommendations and machine-learning segmentation are only as good as their input; a complete, deduplicated, consent-carrying profile is the difference between personalization that lands and the uncanny-valley targeting that erodes trust. Commerce contributes the behavioral gold (what they browsed, bought, returned) into the profile, and consumes the enriched segments back for on-site personalization (the personalization guide picks up the mechanics). The virtuous loop only closes when the profile is unified.

Consent as a governed, central function. This is where unification stops being nice-to-have and becomes risk management. With consent and preference data centralized:

• You can honor a preference change in real time across every channel, which the source's corporate-travel example makes concrete (verify consent and channel preference before an alert fires, instantly).
• You can answer data-subject access, rectification, and erasure requests from one place instead of orchestrating a scavenger hunt across a dozen systems. The data protection guide's GDPR obligations become tractable exactly when the profile is unified; they are near-impossible when it is scattered.
• You reduce regulatory exposure structurally: consent that lives in one governed store is consent you can actually enforce, and honoring preferences at every engagement is what keeps the complaint volume (and thus the regulator's attention) low.

"Change once, update everywhere" is the profile layer's whole promise, and consent is the attribute where breaking that promise is most expensive.

Bridging Online and Offline#

The unified profile is also what makes omnichannel identity (the omnichannel guide's hardest problem) actually work, and the source's progressive-identity examples are the pattern library:

• Recognize the online customer in-store: a registered customer with your app identifies via a QR code scanned at a kiosk or associate tablet, and their online preferences and sizes surface to drive an in-store recommendation. Identity-driven interactions convert far better than anonymous ones.
• Start in-store, continue online: offer the e-receipt, capture consent, create a "lite" account with the in-store purchase already attached, then incentivize conversion to a full account with offers tuned to what they just bought. The progressive-identity ladder (capture incrementally, never demand everything at once) is the same one the B2B onboarding guide applies to organizations.
• Location as a signal: an authenticated app user near a store becomes an opportunity for relevant, consented outreach, with the profile providing the behavioral context that makes the outreach welcome rather than creepy.

Every one of these depends on one identity resolving across web, app, and physical POS, which is precisely what the central profile provides and no single silo can.

The Roadmap#

Unifying profiles is a program, not a project, and it sequences like one:

1. Map mastership and silos. One diagram: every customer-data system, what it masters, what it should master, and the target profile store. This is the deliverable that turns "we need a 360 view" into an engineering plan.
2. Stand up the governed profile store and make it the identity and consent master (login federation first, per the OIDC guide, because authentication is the natural first integration).
3. Wire commerce as a participant: sync Customer/B2BUnit projections, push transactional and behavioral data out, consume enriched profiles and consent back, all through governed integration seams.
4. Centralize consent and retire every scattered consent flag, so DSAR and erasure run from one place (data protection guide).
5. Close the personalization and omnichannel loops on top of the now-trustworthy profile.

The competitive edge the source promises is real but unglamorous: nearly every competitor already has the data. The differentiation is architectural discipline: unify it, govern it, honor it, and use it, while everyone else keeps theirs in a dozen boxes that never learned each other's names.