Unified Customer Profile with Data Cloud

When the same customer exists as a CRM contact, a web shop account, a loyalty member and a Marketing Cloud subscriber, every team sees a different person. Segments double count, service agents miss context and personalisation relies on whichever system happens to be closest. This blueprint describes how to build a unified customer profile in Data Cloud (now branded Data 360) that the rest of the business can rely on.

This is a reference blueprint, not a write-up of a specific client project. Source systems, field names and rules are examples to adapt.

The business problem

The typical starting point looks like this:

• Customer identifiers differ by system: CRM IDs, shop account numbers, loyalty numbers and email addresses.
• Email addresses and phone numbers are stored in inconsistent formats.
• There is no agreed answer to "which address is current?" when sources disagree.
• Consent is captured in several places and never compared.

The target is one Unified Individual per real person, built from rules everyone understands, with consent and key attributes attached and available for segmentation, activation and CRM users.

Designing the rules

Start strict and loosen only with evidence. Every additional rule increases the chance of merging two different people, and an over-merged profile is harder to explain and fix than a missed match. Be careful with shared identifiers: a family email address, a company switchboard number or a placeholder like a dummy phone number will glue unrelated people together. Exclude known placeholder values in a transform before resolution runs.

Reconciliation rules decide which value wins when sources disagree. Options include last updated, most frequent and source priority. A common pattern is source priority for names (the CRM is usually curated), last updated for contact points, and keeping all addresses as separate contact points rather than picking one. For more depth see how identity resolution match rules work and reconciliation rules for unified profiles.

Data model and consent

Map each source at its true grain. Order headers and order lines belong in different objects; mapping lines to an order-level object will inflate spend insights later. Keep a data dictionary that records, for every mapped field, its source, transformation and owner.

Consent needs the same care as identity. Bring consent records into Data Cloud's consent objects with the channel, purpose, status and capture date, and decide how conflicts between sources are resolved before anyone builds a segment. Under the GDPR and India's Digital Personal Data Protection Act, purpose and evidence of consent matter, so keep the capture source and timestamp. Segments for marketing should filter on consent explicitly rather than relying on downstream systems to suppress.

Testing and launch

1. Profile the data. Before resolution, count nulls, placeholder values and duplicate identifiers per source. Our data quality checks before identity resolution list what to look for.
2. Build a known-answer set. Pick a sample of customers whose records you can verify by hand, including tricky cases such as shared emails and name changes, and check how each one resolves.
3. Reconcile counts at each layer. Source rows, DLO rows, DMO rows and unified profiles should be explainable at every step.
4. Review with the business. Show service and marketing users a set of unified profiles and ask whether they look right.
5. Launch in stages. Start with one or two sources, then add the rest once the rules are stable.

How to measure it

Measure profile quality and adoption, not vanity counts:

• The consolidation rate (source records per unified profile), tracked over time, with investigation of sudden jumps.
• The share of the known-answer set resolved correctly, re-checked after every rule change.
• The number of over-merge reports from users, and how quickly they are diagnosed.
• Downstream use: how many segments, activations and CRM pages rely on the unified profile instead of a single source.

Risks and variations

• Over-merging from shared or placeholder identifiers is the most damaging failure. Guard against it in transforms.
• Cost and consumption. Ingestion, resolution and queries consume credits; check current pricing and limits for your org in Salesforce Help before sizing refresh schedules.
• B2B variation. Account-level unification uses Account objects and different rules; plan it as a separate ruleset.
• Federated sources. Zero-copy data reduces copying but brings its own latency and query behaviour to test.

Our Data Cloud consulting and identity resolution services cover this design work end to end.