What Is Identity Resolution? How Matching Works
Identity resolution links customer records and interactions across systems, devices, and channels to a common profile, making it possible to connect anonymous visits with known accounts. Twilio’s identity resolution guide
What identity resolution is used for
Customer identity resolution brings together activity recorded under different identifiers, supporting analysis of anonymous visitors, customer experience, and personalized marketing, including connecting browsing activity with a profile after registration (Twilio’s guide).
The broader term entity resolution also covers matching records for things other than customers: AWS documents matching customer information, product codes, and business data codes across applications and data stores (AWS Entity Resolution overview).
Which identifiers are matched?
Customer identity systems can work with cookie IDs, device IDs, email addresses, and identifiers supplied by other systems; Segment documents all of these as inputs to its identity graph (Segment’s identity resolution documentation).
Different identifiers represent different objects:
| Identifier | What it represents |
|---|---|
| User or account ID | A user record in an application’s database. Segment recommends a stable database ID rather than an email address or username as its userId. Identify specification |
| Anonymous ID | A substitute identifier used to associate traits, events, or page views when the user is not yet known in the database. Identify specification |
| Cookie or device ID | An identifier used in linking activity across web and mobile touchpoints; Segment includes these alongside customer identifiers in its graph. Identity resolution documentation |
| Group ID | A group record, distinct from an individual user record. Segment’s Group call associates a user with an account, organization, or other group using separate userId and groupId fields. Group specification |
An account with multiple users is therefore a membership relationship in Segment’s model: the Group call records which account a user belongs to, rather than replacing the user’s identifier with the group’s identifier (Group specification).
Deterministic and probabilistic identity resolution
The two approaches differ in how they decide that records belong together:
| Approach | Basis for a match |
|---|---|
| Deterministic matching | Exact agreement on attributes under a defined rule. Attributes must match according to that rule for the record pair to qualify. ONS explanation of linkage methods |
| Probabilistic matching | Statistical evidence about whether a record pair refers to the same entity, accounting for both matching errors and agreement that can occur by chance. ONS explanation of linkage methods |
In classical probabilistic record linkage, agreements and disagreements on attributes receive weights that are combined into a matching score, with thresholds separating matches, non-matches, and ambiguous pairs that can receive manual review (ONS methodology).
Matching systems can also use machine learning: AWS’s documented model evaluates fields associated with names, email addresses, phone numbers, addresses, and dates of birth, then produces match groups with confidence scores indicating their quality relative to other groups (AWS matching techniques).
The methods can be combined: ONS describes a strategy that starts with exact matching, continues with probabilistic matching, and finishes with clerical resolution (ONS data linkage policy).
How records become a unified profile
The process includes preparing the inputs, deciding which records match, maintaining their identity links, and making the linked data available for use:
- Prepare the input fields. AWS uses schema mappings to identify matching fields and can normalize inputs by removing extra spaces and special characters and converting text to lowercase (AWS data preparation documentation).
- Apply the matching method. In AWS’s rule-based workflow, related records are organized into match groups with the rule number that produced each group (AWS rule-based matching documentation).
- Maintain the identity graph. Segment maps multiple external identifiers to a persistent profile ID and supports rules controlling which identifiers and sources can create associations (Segment’s identity graph documentation).
- Send the linked profile to other tools. Customer profiles and their associated data can be passed to CRM, advertising, and marketing automation systems (Twilio’s identity resolution guide).
An identity graph is the representation of the identifiers linked within a profile; Segment uses this graph to connect activity from web, mobile, server, and other touchpoints (Segment’s identity graph documentation).
How anonymous visits are joined to accounts
An identification event can carry both an anonymous ID and a database user ID, supplying the connection between the two; Segment’s Identify specification documents this payload and recommends identification after registration or login (Identify specification).
Historical activity can also be linked after new identity information becomes available: Adobe Customer Journey Analytics distinguishes live stitching, which resolves incoming events using the graph available at that time, from replay stitching, which recalculates earlier events using updated graph information (Adobe graph-based stitching documentation).
Replay follows a schedule and a lookback window, so later identity information can change attribution for eligible earlier events; Adobe explicitly excludes data outside that window from replay (Adobe stitching documentation).
When Adobe cannot retrieve a person ID for an event, it retains the persistent ID for that unstitched event (Adobe stitching documentation).
Shared identifiers and incorrect profile merges
Exact agreement does not eliminate incorrect merges: Adobe documents graph collapse caused by multiple logins on a shared device, invalid contact details, and non-unique placeholder identifiers (Adobe Identity Graph Linking Rules).
Adobe’s linking rules include two controls:
- Unique namespaces: a graph can contain only one identifier from a namespace configured as unique, preventing distinct person identifiers in that namespace from merging (Adobe linking rules).
- Namespace priorities: identifier types are ranked, and those priorities help determine which links are removed in graphs with multiple layers (Adobe linking rules).
Adobe also provides graph simulation to test whether configured identifiers merge or stay separate before applying rules to production data, including testing the effects of shared or reused identifiers (Adobe Graph Simulation guide).
Identifier correction and data deletion have different effects
Segment’s documented Delete Profile Identifier API, currently in public beta, removes identifiers while preserving profile traits, events, and merge history (Delete Profile Identifier API documentation).
That operation removes identifiers from Unify systems only; Segment directs complete user-data deletion requests to its separate deletion and suppression process (Deletion scope documentation).
Privacy requests also affect historical stitching in Adobe: the documented process removes the requested identity from the graph and undoes its association with unauthenticated events to prevent future stitching to that identity (Adobe stitching privacy documentation).
How to measure identity resolution accuracy
A false positive links records that belong to different entities; a false negative leaves records for the same entity unlinked (ONS data linkage quality standards).
Two measures describe these errors:
| Measure | What it measures |
|---|---|
| Precision | The proportion of accepted links that are true matches. ONS quality standards |
| Recall | The proportion of all true matches that the process finds. ONS quality standards |
The match rate measures the amount of data linked, not whether those links are correct; ONS explicitly says it should not be used as a linkage quality metric (ONS quality standards).
ONS describes evaluating score thresholds using records whose match status is already known. ONS linkage methodology It also specifies that required quality standards depend on the linkage project, rather than prescribing one threshold for every use (ONS quality standards).
Privacy, correction, and retention
Replacing identifying information with a profile key does not necessarily make the data anonymous: the UK Information Commissioner’s Office says pseudonymised data remains personal data in the hands of someone who holds the additional information needed to identify the person (ICO pseudonymisation guidance).
Pseudonymisation also does not automatically permit reuse for a different purpose; the ICO describes conditions such as compatibility with the original purpose or an appropriate basis for the new processing (ICO guidance on further processing).
Where the EU GDPR applies, Article 5 requires defined purposes, data minimisation, accuracy, appropriate security, and limits on keeping identifiable data; Article 6 requires a lawful basis for processing (GDPR Articles 5 and 6).
Article 5 also requires reasonable steps to erase or rectify inaccurate personal data without delay, taking account of the processing purpose (GDPR Article 5).
Is identity resolution the same as identity verification?
In identity proofing, the term has a specific meaning: NIST defines identity resolution as distinguishing a unique individual within the population served by a credential service provider (NIST identity proofing guidelines).
NIST treats evidence validation and identity verification as separate steps: validation checks evidence and attributes, while verification establishes that the applicant is the rightful owner of that evidence (NIST guidelines).
Under that distinction, linking visits to a customer account does not, by itself, verify the real-world identity of the account holder (NIST guidelines).