Identity resolution: how record matching actually works

Identity resolution is the process of deciding that two or more records refer to the same real person. It's the machinery underneath every people-search product, skip trace, identity check, and customer-data deduplication project: given "Jon Smith, 42 Oak St" in one system and "Jonathan Smith Jr., 42 Oak Street" in another, are they the same human? The answer is rarely a string comparison — it's a scored decision built from many partial signals.

Identity resolution vs entity resolution vs record linkage

Three terms, one family of problems:

• Record linkage is the oldest and most general term, from statistics: matching records across datasets that lack a shared key. Everything else specializes it.
• Entity resolution is the computer-science generalization — the entities can be people, companies, products, or addresses. Deduplicating a CRM is entity resolution.
• Identity resolution is entity resolution where the entity is specifically a person, and the payoff is a unified view of that person — their name variants, address history, phones, and emails connected under one identity.

If you're evaluating tools: vendors selling "entity resolution" usually sell software you run on your own data; vendors selling "identity resolution" usually sell reference data — a compiled graph of people to resolve your fragments against.

Deterministic vs probabilistic matching

• Deterministic matching joins records on exact, agreed keys: the same email, the same phone number, the same normalized name-plus-date-of-birth. It's fast, explainable, and precise — and brittle. One typo, nickname, or moved house and the join silently fails.
• Probabilistic matching scores every candidate pair across many attributes, weighting each by how discriminating it is (a shared rare surname means more than a shared common one; a shared phone number means more than a shared city) and tolerating disagreement on some fields. It finds matches determinism misses, at the cost of returning *confidence* rather than certainty.

Production systems are almost always hybrid: deterministic passes first on strong identifiers, probabilistic widening after — with every result labeled by which pass produced it. An unlabeled blend is the mark of a system that doesn't want you to know how sure it is.

Why names are the hard part

Contact identifiers are nearly unique per person; names are anything but. A name-matching layer has to handle:

• Nicknames and diminutives — William/Bill/Will/Billy are one person; a lookup table of common equivalences is table stakes.
• Maiden and former names — a surname change severs naive joins; resolved identities must carry prior surnames as first-class name variants.
• Name order and compound surnames — "Garcia Lopez, Maria" vs "Maria Lopez"; Hispanic and East Asian naming conventions break first-last assumptions.
• Spelling drift and transliteration — Sean/Shawn/Shaun; Mohammed's dozens of romanizations. Phonetic algorithms (Soundex-family, and better successors) catch what exact matching can't.
• Precision differences — one source has a full date of birth, another only a birth year; a good matcher compares at the precision both sides share instead of failing the comparison.

What a production pipeline looks like

Real pipelines pool candidates, then score them:

• Pool. Cheap, high-recall passes gather candidates on strong identifiers first (exact phone, email, name + address), then progressively relaxed passes — nickname expansion, former surnames, transposed name order, phonetic variants, nearby geography — each pass labeled by which relaxation it used.
• Score. Every pooled candidate is scored on how many *independent* attributes agree — independence is what matters; three fields derived from the same source record are one signal, not three.
• Label and rank. Results are returned ranked, carrying both the match tier (which pass found it) and the confidence score, so a downstream human or system can set its own threshold.

This pool-and-score architecture is how CoverFi's own search works: the match tiers in the glossary are the pool passes, and the 0–100 confidence signal is the score. Every response tells you exactly how it matched — the property this page has been arguing every resolution system owes you.

Persistent identifiers

Resolution is only durable if the resolved identity keeps its identifier across data refreshes. CoverFi assigns each person a permanent GD- record ID that survives dataset updates, so a record fetched this quarter reconciles with the same person next quarter — the difference between an identity graph and a search result that evaporates.

Identity resolution with CoverFi

CoverFi is the reference-data flavor of identity resolution: 250M+ people, each carrying name variants, a decade-plus of address history, phones, and emails, searchable by whatever fragment you hold — name, address, phone, or email — through the search page or the REST API. Per-lookup credit pricing means resolving a record costs a known amount, and zero-result searches refund automatically. The data dictionary documents every field in the resolved records.