What Is Identity Resolution? Matching People, Accounts, Devices, and Events: Explains deterministic and probabilistic matching, confidence, and privacy limits.

Identity resolution is the governed process of deciding whether identifiers and records from different systems refer to the same person, account, device, or other entity, then linking events to the appropriate entity without erasing meaningful boundaries. Deterministic rules use observed identifier relationships; probabilistic rules infer links with uncertainty and require explicit confidence, review, and correction controls.

The output is not one magical “customer ID.” It is a set of claims: this browser identifier was linked to this authenticated user at this time; these two contact records represent the same person under this rule; this person is associated with this business account; these events can be analyzed together for this permitted purpose.

Twilio Segment’s identity-resolution guide describes joining interactions across touchpoints to a unified profile and lists identifiers such as user IDs, anonymous IDs, device IDs, group IDs, and custom external IDs. That model is useful, but “unified” must not be confused with complete or certain. Each link comes from data with an origin, time, rule, and error mode.

There is no universal matching formula or confidence threshold. A score of 0.9 has no portable meaning without the model, features, calibration set, population, and decision threshold behind it. Even exact matches can be wrong when an email address is shared, a phone number is recycled, an account is reassigned, or a source system stamps the wrong identifier.

Start with entities, not columns that happen to match#

Identity resolution fails early when a data model treats every identifier as if it names a person. Keep at least four concepts separate:

A person can use several devices and belong to more than one account. A device can be shared by several people. An email alias can route to a team. An event belongs to the identifier observed at collection time; a later resolution rule may relate it to a person, but should preserve the original evidence.

Adobe’s Identity Graph Linking Rules make this distinction concrete through identifier namespaces, unique namespaces, and namespace priority. The product uses rules to prevent two different person identifiers from collapsing into one graph when a shared browser or other identifier connects them.

Deterministic matching is an evidence rule#

Deterministic matching links records when an explicit rule is satisfied. Examples include the same stable internal user ID appearing in two systems, or an authenticated event that carries both an anonymous browser ID and a known account ID. Segment describes its approach as exact matching on identifier values and stresses consistent stamping and identifier priority.

Deterministic does not mean infallible. The rule can be exact while the identifier is weak. Matching two records on normalized email is different from observing the application bind an authenticated login ID to a browser session. The contract should classify identifiers by evidence strength and context:

• Authoritative identifiers are issued and controlled by the organization’s source system for the entity.
• Verified contact identifiers have passed a defined verification event, with its time preserved.
• Observed device links arise from authenticated use or another documented association.
• Declared identifiers were supplied but not independently verified.
• Shared or recycled identifiers cannot safely enforce person uniqueness.

The matching rule should name which combinations can create a link, which can only propose one, and which must never merge profiles. It should also specify whether the link is permanent, time-bounded, or superseded by later evidence.

Probabilistic matching creates an inference#

Probabilistic resolution estimates whether records refer to the same entity from several imperfect signals. Names, locations, device characteristics, time patterns, and behavior can contribute, but no individual feature should silently become identity proof.

Confidence needs a decision contract. Evaluate the model on labeled examples that resemble the population and missing-data patterns where it will operate. Measure at least two error types separately:

• False merge: two different entities are linked. This can expose or misapply data, suppress the wrong person, corrupt attribution, and make correction difficult.
• Missed link: two records for the same entity remain separate. This can fragment history, duplicate contact, or undercount behavior.

The acceptable balance depends on use. A tentative analytical grouping with no individual action may tolerate a different threshold from a link used to disclose records, target a person, determine eligibility, or honor a deletion request. The UK ICO advises that statistical inferences about people be recorded as informed guesses rather than facts and evaluated for the purpose and impact of error.

Do not report only “match rate.” Increasing the fraction of resolved records can improve recognition or increase false merges. A useful evaluation reports precision-like false-merge performance, recall-like missed-link performance, coverage, abstention, and results by material segment. It also tests identifier reuse, shared devices, transliteration, missing fields, household contact points, and source-system errors.

Events can be replayed, but history must stay bounded#

When a previously anonymous visitor later authenticates, an identity system may associate earlier events with the known person. Adobe’s graph-based stitching documentation describes live stitching plus replay over a configured lookback window. It also documents limits involving timestamps, shared devices, graph size, and backfill.

That means an “identity-resolved” report is versioned. A report produced before the login may show the anonymous device; a later replay may show the person ID. The pipeline needs to record which graph version and lookback rules produced the result, or the same query can change without an explainable data event.

A safe event record keeps:

1. the original event and collection timestamp;
2. the identifier and namespace observed at collection;
3. the resolution rule and graph version applied;
4. the resolved entity, confidence class, and effective time;
5. the permitted downstream uses; and
6. any later split, correction, expiry, or deletion.

Privacy is a design boundary, not a cleanup step#

Identity resolution makes personal data more connected and often more consequential. Before collecting or linking an identifier, define the purpose and ask whether that identifier is necessary for it. Separate permitted analytical use from activation, personalization, disclosure, and automated decision use.

The ICO’s direct-marketing guidance treats data matching and appending as regulated processing; telling people that data might be obtained from third parties does not by itself make every match permissible. Applicable requirements vary, so privacy and legal owners need to assess the real sources, recipients, jurisdictions, purposes, and rights.

Operationally, the graph must support more than merging:

• Explain: show the evidence and rule behind a link.
• Correct: replace an inaccurate identifier or relationship without losing the history of the correction.
• Split: undo an over-merged graph and replay affected downstream data.
• Delete: locate related records for an applicable request and avoid recreating the link from stale sources.
• Expire: stop using a link whose evidence or permitted purpose has ended.
• Restrict: prevent a tentative inference from reaching a high-impact activation.

Adobe notes that some privacy requests require undoing stitching across unauthenticated events. Its graph simulation tool also lets operators test shared-device and graph-collapse behavior before applying rules. The broader lesson is portable: every merge rule needs an observable failure test and a working reversal path.

A minimum acceptance test#

Before a resolution rule reaches production, run it against a controlled set that includes known matches, known non-matches, ambiguous pairs, shared identifiers, changed accounts, recycled contact points, and missing values. Review the result with the owners of the downstream decision, not only with the data team.

Reject the rule if any of these remain unanswered:

• Which entity and purpose does the link serve?
• What direct evidence or inference created it?
• What are the measured false-merge and missed-link risks for that use?
• Can a person, account, device, and event remain distinct where required?
• Can the link be explained, corrected, split, expired, and deleted?
• Which systems are prohibited from receiving tentative links?