In brief — Neither Salesforce Data 360 nor Adobe Real-Time CDP performs customer data modelling on its own. Each supplies the same primitives — a canonical schema, identity resolution, survivorship, derived attributes, activation and governance — and a durable customer 360 comes from modelling seven layers deliberately in whichever platform is in use. Accepting the platform defaults is what produces a single customer view that fragments the moment store, web, app and loyalty data disagree. This is the seven-layer method, mapped to both platforms, with a multi-channel grocer as the running example.
The problem: a CDP does not model the data for you
Customer data platforms are frequently bought in the belief that unification is a feature to be switched on. In practice, both leading platforms ship modelling primitives, not a finished model. Salesforce Data 360 (formerly Data Cloud) exposes a canonical model through Data Model Objects; Adobe Real-Time CDP exposes one through the Experience Data Model (XDM). Left at their defaults, each yields a partial, drifting profile — the same failure a hand-built model has when a step is skipped.
The running example makes the stake concrete. A multi-channel grocer sees one household as several customers: a loyalty number scanned at the till, an account email on the e-commerce site, a device identifier in the mobile app, and a tokenised payment-card hash across card transactions. Whether the model is built in Data 360, in Adobe Real-Time CDP, or by hand in the warehouse, the modelling work is the same, and it is what decides whether those four records resolve to one person or stay fragmented.
That work organises into seven layers. Each depends on the one before it, and each has a direct realisation in both platforms — the platform choice changes the construct names, not the modelling decisions. The mapping below is the map for the rest of the article.
The method: seven layers, one model, either platform
The layers run in order: ingest and stage, standardise and quality-check, model the schema, resolve identity, model history and features, segment and activate, then govern and validate. The first two prepare the data, the middle three build the model, and the last two make it usable and trustworthy. Retail is the illustration throughout; the method is not retail-specific.
Layer 1 — Ingest and stage the sources
The model begins with landing raw source data unchanged, so that every later transformation is reproducible from an untouched copy. Nothing should be reshaped in flight. In Data 360 this is Data Streams landing into Data Lake Objects; in Adobe Real-Time CDP it is Sources landing into Datasets. Both support batch and streaming ingestion and change-data-capture patterns, so late-arriving and out-of-order records are an expected input rather than an exception. For the grocer, the till export, the e-commerce order feed, the app event stream and the card-transaction file each land as their own raw object before any joining is attempted.
Layer 2 — Standardise and quality-check
Match rate is set here, before any identity logic runs. Raw records must be normalised — addresses, names, email and phone formats — and obvious duplicates and malformed rows resolved, because identity resolution can only match on fields that are clean and consistent. Data 360 handles this with transforms and formula fields over the Data Lake Objects; Adobe Real-Time CDP uses Data Prep mapping functions and schema validation, with dataset-level data-hygiene controls. Skipping this layer is the most common cause of a low match rate later, and neither platform standardises by default.
Layer 3 — Model the schema: grain, entities, and profile versus events
This is the layer where most of the durable modelling happens, and it is best understood as a picture. The model declares the grain of each object, the entities it represents, and the split between relatively stable profile records and immutable, time-stamped events. It also declares the entities above the individual — household and, for business customers, account — because a model that recognises only the individual grain cannot answer household-level questions.
Both platforms enforce the profile-versus-event split as a schema decision rather than leaving it to convention. In Adobe Real-Time CDP, XDM classes make it explicit: the XDM Individual Profile class holds record data, the XDM ExperienceEvent class holds time-series data, and a schema is built from field groups on one of those classes. In Data 360, the equivalent is mapping Data Lake Objects to Data Model Objects, with profile DMOs distinct from engagement DMOs and relationships declared between them. The modelling discipline is to place stable attributes on the profile record and behaviour on the event, rather than folding counters such as last-order-date into the profile — the choice that later keeps the model rebuildable rather than drifting.
Layer 4 — Resolve identity: keys, coverage, and the golden record
With clean data in a declared schema, identity resolution unifies records into one customer. The modelling decisions are three: which keys exist, which key has the widest coverage and so becomes the primary match, and how conflicts between sources are resolved into a single golden value. For the grocer, the card number typically spans till, website and card records, so it carries more coverage than the till-only loyalty number or the app-only device identifier, and becomes the primary matching key; records it misses fall to fuzzy or model-based matching, accepting lower certainty.
Data 360 expresses this as Identity Resolution rulesets — match rules, deterministic and fuzzy, plus reconciliation rules that set source precedence — producing the Unified Individual. Adobe Real-Time CDP expresses it as identity namespaces feeding the Identity Service and Identity Graph, with Merge Policies deciding survivorship by dataset precedence and recency to produce the Real-Time Customer Profile. The concession is real in both: aggressive fuzzy matching raises coverage but risks over-merging two adults on one household card, while deterministic-only under-merges and leaves activity unattached; that line is a modelling choice, not a platform default.
Layer 5 — Model history, metrics, and features
A profile that only holds current state cannot answer “what was true then,” which retail analysis needs whenever results are read against the customer state at the time of a campaign. The model must therefore retain attribute history and define derived metrics and features once, rather than letting each team re-derive them. Data 360 provides Calculated Insights for metrics and computed attributes over the unified profile, with effective-dating patterns for history. Adobe Real-Time CDP carries history naturally in the ExperienceEvent time-series and supports computed attributes, with the Query Service used for point-in-time and feature work. An honest limitation applies to both: the real-time profile is optimised for current state, so full bi-temporal history and heavier feature engineering typically live in the data lake or query layer, not in the live profile.
Layer 6 — Segment, activate, and serve
The model earns its value only when it is consumed, which imposes its own modelling requirement: destination identifiers and the mapping to them must exist, or a well-built profile cannot be activated. Data 360 builds Segments and pushes them through Activation Targets and Data Actions, including streaming activation and API access for real-time use such as Agentforce. Adobe Real-Time CDP uses the Segmentation Service — batch, streaming and edge — feeding Destinations, with identity mapping and hashing applied on the way out, and the Real-Time Customer Profile API for low-latency retrieval. The modelling point is that the primary key resolved in Layer 4 must carry through to the destination identity, or activation silently drops the customers the model worked to unify.
Layer 7 — Govern and validate
The final layer keeps the model trustworthy and lawful, and it belongs in the design rather than bolted on afterwards. Governance means a consistent taxonomy so fields mean the same thing across sources, consent carried with the record and enforced by data party and purpose, and privacy handled by design — including the tension between an append-only event history and a right-to-erasure request. Data 360 provides Data Spaces, consent Data Model Objects, data-usage policies and a Privacy Center with deletion; Adobe Real-Time CDP provides Data Governance labelling and enforcement (DULE), XDM consent field groups, dataset expiration and a Privacy Service for regulated deletion. Validation sits here too: match rate, over- and under-merge rates, and profile and identity monitoring are how the model is shown to be correct and kept so. Retrofitting governance across a model already in production is materially harder than establishing it at the start.
Conclusion: the platform supplies primitives, the model is the work
Read together, the seven layers describe the same customer data model expressed in two platforms: ingest and stage, standardise, declare the schema and the profile-versus-event split, resolve identity to a golden record, model history and features, activate through a mapped identity, and govern and validate. Data 360 and Adobe Real-Time CDP name these constructs differently — Data Model Objects against XDM, Identity Resolution rulesets against the Identity Service, reconciliation rules against Merge Policies — but the modelling decisions at each layer are the same, and they are what determine whether the customer 360 holds.
The practical starting point is narrow and available in either platform immediately: inventory the identity keys each source carries and measure their coverage, then check whether the current schema places behaviour on events or has folded it into profile attributes. Those two diagnostics reveal most of the fragility in an existing single customer view, and neither requires leaving the platform already in use. The durable value is the model, not the tool that stores it — and a platform left at its defaults tends to encode the wrong shape at the point where it is most expensive to change.
Next step
A useful next move for a team on either platform is to pressure-test where identity resolution and the profile-versus-event split sit in the current implementation, using identity resolution as the reference for what that layer should contain. That diagnostic — rather than a platform migration — is the honest first step, because it establishes whether the gap is the tool or the model built inside it.
Frequently Asked Questions
Is customer data modelling different in Data 360 versus Adobe Real-Time CDP?
The modelling decisions are the same; the constructs differ. Data 360 models the canonical schema as Data Model Objects and resolves identity with rulesets and reconciliation rules, while Adobe Real-Time CDP models it as XDM schemas and resolves identity with the Identity Service and Merge Policies. Both enforce a profile-versus-event split at the schema level, so the seven-layer method applies to either with only the construct names changing.
Does a packaged CDP remove the need for data modelling?
No. Both Data 360 and Adobe Real-Time CDP supply modelling primitives rather than a finished model, and left at their defaults they produce a partial, drifting profile. The unification, schema, survivorship and governance decisions still have to be made deliberately; the platform executes them but does not make them.
How is a golden record different from a customer 360 profile?
The golden record is the resolved, de-duplicated identity — one persistent key per customer with survivorship rules for conflicting fields, produced by Identity Resolution in Data 360 or Merge Policies in Adobe Real-Time CDP. The customer 360 profile is broader: the golden record plus the derived attributes and the linked event history. The golden record answers “who is this person”; the profile answers “who they are and what they have done”.
How does the profile-versus-event split map to XDM and Data Model Objects?
In Adobe Real-Time CDP the split is explicit in the XDM class: record data uses the XDM Individual Profile class and behavioural data uses the XDM ExperienceEvent class. In Data 360 the equivalent is separating profile Data Model Objects from engagement Data Model Objects and relating them by key. In both, stable attributes belong on the record and behaviour belongs on the event, so corrections append rather than overwrite.
How is a right-to-erasure request handled against an immutable event history?
Erasure is handled by the platform’s privacy layer rather than by mutating the model: Data 360 through its Privacy Center and deletion, Adobe Real-Time CDP through the Privacy Service, both of which remove or de-identify a customer’s records across profile and event stores on request. Because the event log is append-only by design, the model must be built to allow this deletion path from the start rather than treating erasure as an afterthought.
How many identity keys are needed before the model is worth building?
The test is coverage, not count: the model becomes worthwhile once at least one strong, stable key links a large share of activity across more than one source. A single high-coverage key such as a widely scanned loyalty identifier can support a useful model, whereas several keys each present on a small fraction of records cannot. Measuring coverage per key, in Layer 4, is what answers this for a given retailer.
