Identity resolution

How identity resolution works

Identity resolution decides whether two rows refer to the same entity. When they share a stable id, the answer is deterministic. When they only share noisy fields, the answer is probabilistic and needs thresholds or review.

A public encyclopedia defines record linkage as finding records that refer to the same entity across different data sources, and notes aliases such as data matching and entity resolution 1. The same article describes deterministic record linkage and probabilistic record linkage as core methods, plus blocking to limit comparisons 1.

Customer data platforms describe customer profile unification and list identity resolution among capabilities that help build a single view of each individual 2. That product language is the GTM face of the same matching problem.

After identities link, data enrichment can fill gaps on the surviving profile. RichAPI Profile enrichment still needs a LinkedIn profile URL, and Company enrichment needs a LinkedIn company page URL 3. Resolution without a provider key cannot invent fields by itself.

Deduplication is the cleanup twin. Resolution links. Deduplication merges or suppresses. Many pipelines do both: resolve across systems, then collapse duplicates inside the CRM.

Credits follow the surviving enrichment calls. Profile and Company enrichment cost 1 credit per call and bill on any 2xx 3. Resolving first keeps those credits pointed at one human.

Privacy follows too. Linking personal data across sources widens what you know about a person. Keep lawful basis and notice in the same design review as the match keys 3.

Stitching across devices and channels is the hard mode of the same problem. A CDP may claim cross-channel connectivity, but the underlying match still rests on shared identifiers or probabilistic edges 2. If those edges are weak, activation will look personal while being wrong.

Offline keys deserve explicit design. Badge QR codes, invoice emails, and event check-ins often create the only bridge between a conference lead and a later product user. Capture them on purpose.

When two high-confidence clusters disagree, stop and review. Silent auto-merge of enterprise buyers with common names is how wrong opportunities get created 1.

Vendor identity graphs are not a substitute for your own keys. A provider may resolve well inside their network and still miss your product user id. Keep first-party identifiers as first-class citizens in the graph 2.

Test resolution with known twins, such as the same employee on two subsidiaries, or two employees who share a name at one company. Those cases teach your thresholds faster than a random million-row dump 1.

Measure resolution quality the way you measure enrichment. Track precision on a labeled twin set and recall on known multi-system people. If precision falls, tighten thresholds before you expand automatic merges 1.

Share the identity dictionary with enrichment and support. When a ticket arrives, agents should see which keys produced the unified person instead of guessing across five tabs.

Why identity resolution matters before waterfall spend

Without resolution, each system invents its own person. Marketing sees an email. Product sees a user id. Sales sees a CRM contact. Enrichment sees a LinkedIn URL. Four bills. One buyer.

Resolution creates the map between those keys. Then a waterfall enrichment step can fill email or phone once for the unified profile instead of once per silo.

Deterministic links on email or national id are cheap and explainable 1. Probabilistic links on name and company catch more cases and create more false merges 1. Pick confidence thresholds with a human review queue for the middle band.

CDP-style unification is one place this lives, but you can also resolve inside a warehouse before activation 2. The architecture matters less than having an owner for match rules.

Score match rate on enrichment only after identities are stable. Otherwise you enrich ghosts and call it coverage.

Document every link edge with the keys that matched, the time, and the confidence. Support will need that trail the first time two companies share an office manager named Jordan.

Security teams should see the identity graph. Linking systems expands blast radius for a credential leak. Limit who can export the resolved profile and log every enrichment call against the unified id 3.

Re-resolve on a schedule. People change emails and jobs. A link that was true last year can be false after a domain migration. Identity resolution is maintenance, not a migration project you finish once.

Example of resolving one buyer across CRM, product, and enrichment keys

A buyer appears as a CRM contact with work email, as a product user with the same email, and as a LinkedIn profile URL captured from a webinar 1. Identity resolution links all three on the email and stores the LinkedIn URL on the unified person 1.

Ops then calls RichAPI Profile enrichment once with that URL for 1 credit 3. Title and company land on the surviving profile. Sales and success both see the same record.

A second webinar registration with a personal inbox address and the same LinkedIn URL links through the profile key instead of email 1. Without that second key, the personal address would have created a duplicate path and a second enrichment charge.

The runbook shows the link graph and the enrichment receipt together. That is identity resolution paying for itself in avoided duplicate credits and clearer routing 23.

When the buyer changes jobs, the work email breaks but the LinkedIn URL still resolves 1. The graph keeps the person, sales updates the account, and enrichment refreshes title once instead of creating a net-new lead that steals attribution.

The scorecard from that run becomes the template for the next cohort, so arguments about coverage start from the same denominator every time.

Identity resolution vs deduplication

Identity resolution links records across sources into one entity graph. Deduplication merges or suppresses duplicate rows inside a working list or CRM.