Data Cloud Identity Resolution Services
Get unified profiles you can trust. We design and test match and reconciliation rules against your real data, so profiles are neither over-merged nor fragmented.
Identity resolution is where Data Cloud either earns trust or loses it. If two different people are merged into one unified profile, a customer can receive someone else's offer. If one person stays split across five profiles, segments overcount, insights undercount and personalisation looks random. Both failures are usually caused by rules written before anyone looked closely at the data.
GeekMidst designs, tests and tunes identity resolution rulesets so that unified profiles reflect how your customers actually appear across systems. We work on new implementations and on existing rulesets that are producing results nobody quite believes.
Signs your identity rules need attention
- Unified profile counts are far lower than expected, or barely lower than source record counts.
- Shared mailboxes, family phone numbers or placeholder emails are joining unrelated people.
- The same customer appears with different names or addresses depending on which screen you look at.
- Marketing and service teams disagree on whether a profile is "the same person".
How we approach it
Identity resolution in Data Cloud has two parts. Match rules decide which source records belong to the same individual, using criteria such as exact or normalised email, phone, party identifiers like a loyalty or customer number, and name and address combinations. Reconciliation rules decide which value wins when matched records disagree, for example the most recently updated value, the most frequent value or a value from a preferred source.
We treat both as design decisions with business owners, not as setup screens. A rule that merges on email alone may be right for a retailer with verified accounts and wrong for a business where several staff share one inbox. The options and behaviour available can change between releases, so we confirm current rule types and limits for your org in Salesforce Help during design. For more background, read how identity resolution match rules work.
Common matching choices and their trade-offs
| Approach | Works well when | Watch out for |
|---|---|---|
| Exact email | Emails are verified and personal | Shared, role-based or placeholder addresses |
| Normalised phone | Phone is captured consistently with country codes | Household and switchboard numbers |
| Party identifier | A stable customer or loyalty ID exists across sources | IDs reused or reassigned in source systems |
| Name plus address | Strong address data, few identifiers | Typos, moves and common names |
| Layered rules | Different sources carry different identifiers | Rules that unintentionally chain unrelated records |
How a typical engagement runs
- 01
Profile the identifiers
Measure fill rates, formats, duplicates and suspicious values (test@, 0000000000, shared domains) for every identifier in every source.
- 02
Agree merge policy
Decide with business owners which identifiers are trusted for which sources, and which values should win when records conflict.
- 03
Build a test set
Assemble known cases: true duplicates, look-alikes that must stay separate, and households. These become the acceptance tests.
- 04
Configure and run
Set up the ruleset, run it and compare unified profile counts and consolidation rates with the expected range.
- 05
Inspect and tune
Review sample profiles, especially the largest clusters, adjust rules or upstream cleansing, and re-run.
- 06
Document and monitor
Record the final rules and reasons, and set up checks that flag sudden changes in consolidation after new data arrives.
What you receive
- An identifier assessment for each source, with recommended cleansing or exclusions.
- A documented ruleset: match rules, reconciliation rules and the reasoning behind each.
- The test set and results, so future changes can be checked against the same cases.
- Monitoring guidance, including which counts to watch and what a worrying change looks like.
What we need from you
Access to the Data Cloud org and source owners, a business owner who can sign off the merge policy, and examples of known duplicates or problem records. If your consent rules depend on profile-level decisions, involve your privacy team early, because merging profiles can change which consent applies. See reconciliation rules for unified profiles for how these choices play out.
Questions we hear
What is a good consolidation rate?
Can we change rules after go-live?
Should we cleanse data before or after ingestion?
Does identity resolution merge source records?
How long does tuning take?
Not sure your unified profiles are right?
Share what you are seeing, and we will suggest how to assess your current identifiers and rules.
