Designing Unified Individual Profiles

Most teams start identity resolution by connecting every source they have and hoping the profiles look right. They rarely do. A unified individual profile is the output of a dozen design decisions: what counts as a person, which identifiers are trustworthy, which source wins for each field, and what the business will do when two people share an email. Make those decisions on paper first and the build becomes much simpler.

Start with the questions the profile must answer

Before choosing sources, list the decisions the profile will drive. A profile built for email personalisation needs a reliable email, name, preferences and recent purchases. A profile built for service agents needs case history, product holdings and a phone number they can trust. A profile used for paid media activation needs consent status above everything else.

Write five to ten of these use cases down, with the fields each needs. That list becomes your scope, and it stops the profile turning into a dumping ground for every column in every system.

Decide what a person is

This sounds philosophical, but it is practical. Is a customer who buys as a consumer and also as a sole trader one person or two? Is a parent who manages a child's account the same individual as the child? Is a CRM Contact at a business customer the same person as their personal ecommerce login?

Data Cloud models people with the Individual DMO and its contact points, and B2B organisations with Account. Unified Individual profiles answer the question who is this person, while account relationships answer who do they work for. Keep those concerns separate, and do not use company-level identifiers to match individuals.

Rank your identifiers

Not all identifiers are equal. A useful exercise is to score each candidate on three things: how unique it is to one person, how consistently it is captured, and how long it stays valid.

• Internal customer IDs and loyalty numbers are usually the strongest, as long as every source uses the same format. Map them to Party Identification with a clear identification type.
• Email is strong for individuals but weak where inboxes are shared. Pair it with a name check.
• Phone varies wildly. Mobile numbers captured for one-time passwords are good; landlines and numbers typed by staff are not.
• Postal address identifies a household, not a person. Treat it as a supporting signal only.
• Device and cookie IDs link anonymous engagement to a known person once they log in, but should not be used to merge two known people.

Your ruleset should lean on the strongest identifiers and require pairs for the weaker ones.

Choose a merge policy, and write it down

There is no neutral setting. Aggressive matching finds more of each customer's history but risks merging different people. Conservative matching keeps people apart but leaves duplicates that inflate audience counts and split engagement history.

Which risk matters more depends on use. If a merged profile could show one person's order history to another in a service channel, be conservative. If the profile mainly drives broad marketing segments, a little more aggressive matching may be acceptable. Record the policy, the reasoning and the owner, so that future rule changes are judged against it.

Plan attribute survivorship

After records are grouped, each field on the unified profile needs a value. Decide per field which source is authoritative. Billing systems often own legal name and address; the ecommerce platform may own the most recent email; the preference centre owns communication preferences. Reconciliation rules let you express this, but the decision is a business one.

Treat consent as a first-class part of the design

Unification makes it easier to reach a person through more channels, which raises the stakes on consent. Decide:

• Whether consent is held per contact point (this email, this phone) or per person and purpose.
• Which source is the system of record for each consent type.
• How the most restrictive applicable choice is applied when sources disagree.
• How consent is checked at segment and activation time, not just at ingestion.

Regimes such as GDPR and India's DPDP Act shape these choices. Agree the approach with your privacy team; this guide is not legal advice.

Common mistakes

• Unifying before cleaning. Placeholder emails and shared phones produce giant merged profiles. Profile sources for placeholder and shared values first.
• Treating the unified profile as a golden record for every system. It is a read model for engagement and insight. Writing it back to operational systems needs its own design and governance.
• No owner for the ruleset. Rule changes rebuild profiles and move segment counts. Someone must approve them.
• Skipping the walkthrough. Ten real-looking examples worked through by hand will expose most policy gaps.

Design checklist

1. Use cases and required fields listed.
2. Definition of a person agreed, including households and B2B contacts.
3. Identifiers ranked and paired where weak.
4. Merge policy written, with an owner.
5. Field-level survivorship agreed per source.
6. Consent model defined and enforced at activation.
7. Sample cases walked through and signed off.

For hands-on help with the build, see our Salesforce Data Cloud consulting service.