Cross-Device Identity Resolution: Matching, Uncertainty and Risk

Identity resolution is the process of deciding whether records, accounts, devices or interactions refer to the same entity. It is not a way to increase the number of recognised customers, although that is how it is usually sold. Every link is a decision made under uncertainty, and a wrong link assigns one person’s activity, preferences or information to somebody else.

That makes this a measurement and governance discipline rather than a reach technique. A useful implementation defines what it is resolving, quantifies its error, preserves uncertainty rather than hiding it, and restricts use when confidence is insufficient.

This article covers that decision. For the separate problem of reconciling orders, payments, returns and product records, see cross-platform transaction integration.

Start by Defining the Entity

Customer identity is too imprecise to be a data model. Organisations routinely resolve several different entity types and then treat the results as interchangeable.

Entity	Meaning	Common mistake
Person	An individual human being	Treating a shared login, address or device as one person
Account	A registration or contractual account	Assuming one account always belongs to one person
Household	People associated through an address or other evidence	Assigning household behaviour to a named individual
Organisation	A legal entity, business or institutional customer	Treating employees, branches and the organisation as interchangeable
Device	A browser, phone, computer, television or other endpoint	Treating possession of a device as proof of personal identity
Session	A bounded interaction with a site, application or service	Treating repeated sessions as a persistent person

An identity graph should therefore use typed nodes and typed relationships. A device may be associated with an account. An account may be used by a person. Several people may belong to a household. Those three statements are not equivalent and collapsing them is where most damage begins.

A household is not a person. An IP address is not proof that two interactions belong to one person. A login establishes control of an account at a moment in time; it does not authorise every downstream use of the resulting data.

A device should remain a typed entity even when it is linked to an authenticated account. Device context may affect presentation, capability and timing, but it is not proof of personal identity and should not be collapsed into a person record. Where that context drives presentation and continuity decisions rather than identity ones, see content personalisation for cross-device journeys.

Define the Use Case Before the Matching Rule

The same evidence can be adequate for one use and unacceptable for another.

An approximate household grouping may be fine for protected aggregate analysis. It is not fine for revealing a named customer’s purchases, changing a service decision, or suppressing an individual from an important communication.

Before resolving anything, document the entity type, the decision or experience the result will support, the expected benefit, the harm caused by a false merge, the harm caused by a false split, the minimum acceptable confidence, the legal and contractual restrictions, and how an affected person can challenge or correct the result.

Risk should set the evidence threshold. The vendor’s available match volume should not.

The Current Technical Environment

Cross-device resolution operates inside browser, operating-system and regulatory controls that have moved considerably, and several widely repeated assumptions about them are now simply wrong.

Browser and Platform Controls

Safari has blocked third-party cookies by default since March 2020 (1). Firefox partitions cookies by top-level site through Total Cookie Protection, rolled out by default in June 2022 (2), which limits cross-site linkability even where a cookie technically exists.

On mobile, App Tracking Transparency requires an app to request permission before tracking activity across other companies’ apps or websites, or accessing the advertising identifier for tracking, and has done since April 2021 (3). Android tells developers to respect tracking choices, not to bridge advertising identifier resets, and to obtain explicit consent before connecting that identifier to personally identifiable information (4).

No universal opt-in rate should be quoted for any of this. Permission is app-specific and user-specific, and a resettable identifier is not a permanent person key.

What Happened to the Cookie Replacement Programme

Chrome did not complete its original third-party-cookie phase-out, and any article still describing that programme as unfolding is out of date.

On 22 April 2025, Google said it would retain Chrome’s existing user-choice approach rather than deploy a new standalone prompt (5). On 17 October 2025, it announced the retirement of most Privacy Sandbox advertising technologies, including Topics, Protected Audience, Attribution Reporting, Private Aggregation, Related Website Sets, IP Protection and several Android equivalents, citing ecosystem feedback and low adoption, while retaining CHIPS, FedCM and Private State Tokens (6). In the same week, the Competition and Markets Authority released Google from the associated commitments (7).

The practical conclusion is not that identity has become impossible. It is that no organisation should design its identity model around a presumed universal browser identifier or a single replacement for third-party cookies, because the replacement programme the industry spent six years preparing for was withdrawn.

Alternative identifier frameworks are not that replacement either. They are ecosystem-specific deterministic advertising frameworks with bounded participation, coverage and permitted purposes, published by organisations with a direct commercial interest in their adoption (8). Describe their scope, participants and permissions. Do not call them cookie replacements.

Server-Side Collection Is Not an Exemption

Server-side collection is regularly described as a way to bypass blockers and browser restrictions. That framing is wrong and it is dangerous, because it encourages teams to treat a legal question as a technical one.

Server-side tagging moves processing to a server the organisation controls, which can genuinely improve routing, redaction, data quality and governance (9). What it does not do is create data. The server still receives what was collected from a device or another authorised source. It does not override browser controls, app permissions, consent choices, or collection that never happened in the first place.

Authentication Is Not Entity Resolution

Federated login technologies can help establish an authenticated account relationship, and formal identity guidance treats identity proofing, authentication and federation as distinct processes with their own assurance levels (9)(10). None of that is marketing entity resolution.

Authentication answers whether the person presenting credentials controls this account right now. Resolution answers whether two records describe the same entity, which is a different question with different evidence and different failure modes. Conflating them produces systems that feel rigorous because a login was involved and are still merging households into people.

Inventory Identifiers and Assess Their Reliability

Build an identifier register before writing a single matching rule.

Identifier or signal	Typical value	Principal limitations
Internal customer or account ID	Strong within the issuing system	May be duplicated, recycled, migrated or shared
Authenticated login	Strong evidence of account control at that moment	Does not prove exclusive use or authorise unrelated processing
Verified email address	Useful deterministic account signal	Can be shared, reassigned, mistyped or aliased
Verified phone number	Useful account or contact signal	Can be shared, recycled or reassigned
Loyalty identifier	Useful within a defined programme	Cards and accounts are often shared within households
Order reference	Strong transaction reference	Identifies an order, not necessarily a person
First-party browser identifier	Useful for continuity within its scope	Browser-specific, clearable and subject to consent
Advertising identifier	Resettable device-level signal	Permission, opt-out and platform restrictions apply
App installation identifier	Useful within an app or developer scope	Not normally a universal person identifier
Postal address	Household or delivery-location signal	Occupants change and addresses are shared
IP address	Network observation	Shared, dynamic, proxied and unsuitable as proof of identity
Device characteristics	Weak supporting evidence	Fingerprinting and privacy restrictions apply
Behavioural similarity	Weak probabilistic evidence	Similar behaviour does not prove common identity
Hashed email or phone	Pseudonymous representation	Hashing does not make the data anonymous

For each identifier, record where it originates, whether it has been verified, its permitted purposes, its expected lifetime, its reset behaviour, known sharing patterns and which system is authoritative for it.

Matching Methods

Deterministic Matching

Deterministic matching applies declared rules to identifiers regarded as sufficiently reliable for a defined purpose: the same authenticated account ID appearing in two approved systems, an app and web session explicitly linked after authentication, two records containing the same verified loyalty identifier, or an order submitted from an authenticated account.

Deterministic does not mean infallible. Two records can share a value because of account sharing, data-entry error, reassignment, migration defects or fraud.

Each rule should specify the exact fields used, the entity type inferred, the source hierarchy, expiry or reassessment conditions, conflict handling, permitted uses, and whether the rule may merge existing clusters automatically. Do not collapse a household account into a person record simply because the rule matched exactly.

Probabilistic Matching

Probabilistic matching estimates how strongly multiple observations support a match when no adequate unique key exists.

Classical record-linkage theory compares field agreement and disagreement, weighting evidence by how discriminating each value is (11). Later Bayesian approaches represent uncertainty explicitly and can leave ambiguous records unresolved rather than forcing every pair into a decision (12). That second property matters more than it sounds: a method that is allowed to say it does not know is safer than one that always answers.

Inputs may include name and address similarity, verified contact attributes, temporal overlap, account and device relationships, source-specific error patterns and declared household relationships. Behavioural resemblance, IP addresses and device characteristics should not become strong identity evidence merely because they are abundant. Fingerprinting can identify or correlate users without transparent state such as cookies, which is exactly why it carries significant privacy risk rather than being a neutral substitute for a cookie (13).

A probabilistic model should produce a calibrated score whose meaning has been tested. A score of 0.9 should not be described as ninety per cent accurate unless validation shows that roughly ninety per cent of comparable decisions are correct in the relevant population.

Graph-Based Resolution

Graph-based resolution represents records and identifiers as nodes joined by typed relationships: authenticated by, uses device, shares address, owns account, submitted order, member of household, supersedes identifier.

Graphs preserve distinctions that a single golden customer row erases. They also introduce a specific risk: one weak edge can create a path that collapses several unrelated records into a single cluster.

Controls should include typed nodes and edges, edge-level evidence and timestamps, maximum path lengths for automated inference, rules preventing household edges from becoming person equivalence, cycle and conflict detection, cluster-size anomaly detection, and the ability to remove an edge and recompute the affected clusters.

Validate Before You Believe

Build Truth Sets

A match model cannot be assessed from the records it resolves. You need validation data containing known matches and known non-matches, drawn from controlled account-linking events, verified customer corrections, carefully reviewed samples or independently authenticated relationships.

The set has to represent difficult cases rather than obvious ones. Include shared addresses, recycled phone numbers, family email accounts, duplicate registrations, name changes, account migrations, common names, fraud and account takeover, devices used by several people, and identifiers whose ownership changes over time.

Keep training and final validation data separate where a model is trained, and do not show reviewers the model’s preferred answer before they make an independent assessment.

Measure More Than Match Rate

A high match rate does not establish accuracy. It may only show that the rules are permissive.

Precision is the proportion of declared matches that are correct: true matches divided by all declared matches. It answers the question of whether the system is right when it says two records belong together.

Recall is the proportion of real matches the system finds: true matches divided by all matches that actually exist.

Coverage is the proportion of eligible records for which the system produces a usable resolution at the stated threshold. Coverage is not accuracy, and a system can raise it simply by accepting more false matches.

False-merge rate is how often records belonging to different entities land in the same cluster. State the denominator explicitly: declared matches, candidate pairs, clusters or affected entities are four different numbers.

False-split rate is how often records belonging to the same entity stay separated.

Cluster purity is the degree to which each cluster contains records from one true entity. Report the distribution as well as the average, because the damage lives in the tail.

Calibration is whether predicted confidence matches observed correctness, checked by confidence band, source, population, channel and time period.

Review rate is the proportion of candidate links routed to manual review, with outcomes and turnaround.

Consent-propagation accuracy is the proportion of identity changes where permissions, objections and restrictions reach every affected record, and reach no unrelated person.

The reason to insist on this list is that recognised populations are never random samples, and the resulting metrics flatter themselves. I have argued for years that mobile apps are overhyped in direct-to-consumer retail for exactly this reason. People buy from more than thirty brands a year and cannot hold all those apps, so the ones who install yours were already loyal. Brands were delighted with their app numbers, and the app results beat the website results, but that gap was selection rather than performance. Identity resolution has the same shape: the population you successfully resolve is disproportionately the population that logs in, buys often and stays put. Metrics computed on the resolved population and then reported as if they described all customers are making the identical error.

Set Thresholds by Use Case

Use case	Required confidence	Cost of a false match
Aggregate analysis	Moderate, with aggregation safeguards	Biased estimates
Basket or content continuity after login	High, authenticated	The wrong customer state is shown
Marketing suppression	High precision	An eligible customer is wrongly excluded, or a suppressed one is contacted
Financial, eligibility or service decision	Very high and independently verified	Material customer harm
Household-level analysis	Explicitly household-scoped	Person and household are conflated

Make thresholds asymmetric where the harms are asymmetric. A suppression system should prioritise precision, because merging the wrong person can silence someone who remains eligible or contact someone who objected. A low-risk aggregate analysis can accept more unresolved records instead of maximising person-level coverage.

No probabilistic marketing link should silently become evidence for a financial, eligibility, fraud or service decision. If it can cross that boundary, the boundary is not implemented. For the operational side of who may enter a workflow, see the CRM operating model.

Define Survivorship and Source Authority

Once records are linked, the system still needs rules for conflicting values. Survivorship decides which value is presented, and it should not default to the most recent value without context.

For each attribute, define the authoritative source, verification status, effective date, observation date, ingestion date, permitted purpose, whether historical values must remain available, and how corrections are handled.

An authenticated account system may be authoritative for a current email address. An order system remains authoritative for the delivery address used on that historical order. Updating a customer’s current address must not rewrite the transaction.

Model Identity Over Time

Identity relationships are temporal, and treating them as static is a slow-acting fault. Phone numbers are reassigned. People move. Household membership changes. Employees leave. Devices are sold. Accounts are merged, split, compromised or shared.

Store when an identifier was observed, when a relationship became effective, when it ended or was invalidated, why the system formed or removed it, and which rule or model version produced it.

Reprocessing historical data with a newer graph will change reported results. Any analytical product built on resolved identity should disclose the identity version used and whether history has been restated.

Propagate Permissions and Restrictions Safely

Identity resolution does not create permission.

First-party data is not unrestricted data. A login does not authorise every downstream use. Storage and access rules apply according to what the technology does rather than what it is called: the regulator’s finalised guidance expressly covers cookies, pixels, link decoration, device fingerprinting, scripts and tags, and treats storage or access for advertising, tracking and profiling as requiring consent (14). The equivalent European guidance reaches the technical scope question in similar terms, though it is EU guidance rather than UK law (15). And a hashed identifier normally remains personal data, because hashing pseudonymises rather than anonymises when people can still be identified using separately held information (16).

Provide Review and Correction

Incorrect merging can expose another person’s information or drive decisions from somebody else’s behaviour. That is a customer harm, not a data-quality metric.

Maintain processes for customer rectification, internal review of ambiguous clusters, complaint investigation, separating incorrectly merged records, rebuilding affected analytical outputs, notifying downstream systems, and documenting the correction without preserving misleading current data.

Regulatory guidance on accuracy expects organisations to take reasonable steps to ensure personal data is not incorrect or misleading, to correct it where it is, and to consider challenges to accuracy carefully rather than dismissing them (17).

Monitor Drift and Source Change

Identity performance decays quietly. It deteriorates when a source changes validation rules, when an identifier is deprecated or reset more often, when a new customer segment behaves differently, when account-sharing patterns shift, when a platform changes its privacy controls, when a vendor alters its graph or suppliers, or when the proportion of missing values moves.

Monitor precision, recall, coverage, calibration, cluster purity, review outcomes and consent-propagation accuracy by source and by use case. Alert on sudden match-rate increases, unusually large clusters, sharp changes in identifier overlap, increased contradiction between authoritative sources, consent conflicts, growing reliance on one weak signal, and unexplained historical restatements.

A sudden improvement in coverage is more often a newly permissive rule than better identity. Treat it as a defect until proven otherwise.

Evaluate Vendors With Evidence

Ask any vendor to disclose the entity types they resolve, the identifiers and data suppliers used, whether the graph includes household or inferred relationships, how truth data is obtained, precision and recall and calibration by threshold, whether results have been independently tested, how UK and EU permissions are represented, how identifier resets and browser restrictions are handled, how customers can be corrected or removed, whether historical outputs can be reproduced, whether model or supplier changes trigger notice, and which claims are vendor-reported rather than independently evidenced.

A vendor case study can support a statement about that vendor’s reported implementation. It cannot establish a universal match rate or a business uplift.

A headline match rate is commercially attractive but analytically incomplete. Require precision, recall, coverage, calibration and the consequences of error for the intended use, rather than accepting a single volume metric that is easy to show and pleasant to circulate. For the platform-selection question, see CDP implementation and operating discipline.

Know When to Leave Records Unresolved

A responsible identity system has an explicit unresolved state and uses it.

Stop or restrict a use when validation data is inadequate, precision falls below the use-case threshold, confidence is materially miscalibrated, permissions cannot be propagated reliably, a source change invalidates earlier assumptions, false merges could expose information or cause material harm, customer corrections cannot be implemented, or the organisation cannot explain why the link exists.

Unresolved does not mean failed. It means the available evidence does not justify the proposed use, which is a legitimate and frequently correct answer.

When passing results downstream for linking customers to purchase records, send an entity reference, a confidence band, the entity type, the identity version number and the applicable restrictions. Do not ask the transaction pipeline to recreate the matching logic, and do not let privacy-enhancing technology stand in for any of this: those techniques address specific threat models and do not create lawful authority or prove identity accuracy, as the guide to privacy-safe personalisation sets out.

Frequently Asked Questions

References

1. John Wilander, WebKit, Full Third-Party Cookie Blocking and More. Browser engineering announcement. Published 24 March 2020. WebKit is developed principally by Apple, which controls Safari. Describes WebKit and Safari behaviour, not all browsers. https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

2. Mozilla, Firefox rolls out Total Cookie Protection by default to more users worldwide. Browser announcement. Published 14 June 2022; updated 28 August 2024. Mozilla develops Firefox. Describes Firefox behaviour, not market-wide availability. https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/

3. Apple, iOS 14.5 offers Unlock iPhone with Apple Watch, diverse Siri voices, and more. Official release announcement, iOS 14.5. Published 26 April 2021. Apple controls the platform and the App Store. Establishes the App Tracking Transparency permission requirement; it does not establish any universal opt-in rate. https://www.apple.com/newsroom/2021/04/ios-14-5-offers-unlock-iphone-with-apple-watch-diverse-siri-voices-and-more/

4. Android Developers, Best practices for unique identifiers. Platform developer guidance. No publication date shown; live documentation. Google controls Android and associated advertising services. Developer guidance rather than UK law; implementations may differ by device and service. https://developer.android.com/identity/user-data-ids

5. Anthony Chavez, Google, Next steps for Privacy Sandbox and tracking protections in Chrome. Official platform announcement. Published 22 April 2025. Google controls Chrome and holds commercial advertising interests. States the retained user-choice approach; it does not guarantee that the approach will not change again. https://privacysandbox.google.com/blog/privacy-sandbox-next-steps

6. Anthony Chavez, Google, Update on Plans for Privacy Sandbox Technologies. Official platform announcement. Published 17 October 2025. Google developed the technologies and operates advertising businesses. Announces retirement across Chrome and Android and states that phase-out will follow Chrome and Android processes; it does not provide every final removal date. https://privacysandbox.google.com/blog/update-on-plans-for-privacy-sandbox-technologies

7. Competition and Markets Authority, Investigation into Google’s Privacy Sandbox browser changes. Competition regulator case page, case reference 50972-1. Case opened 2021; commitments released 17 October 2025. Independent UK regulator. A competition decision; it is not a determination that any Google privacy practice complies with data protection law. https://www.gov.uk/cma-cases/investigation-into-googles-privacy-sandbox-browser-changes

8. Unified ID 2.0, Unified ID 2.0 overview. Technical framework documentation. No publication date shown; live documentation. The Trade Desk and participating advertising organisations have a direct commercial interest in adoption. Establishes the framework’s intended design and scope; it does not establish universal adoption, independent privacy compliance or general accuracy. https://unifiedid.com/docs/intro

9. Google, An introduction to server-side tagging. Product developer documentation. No publication date shown; current documentation. Google markets the product described and related advertising services. Describes the server-side tagging architecture; it does not establish legal authority or unrestricted collection. https://developers.google.com/tag-platform/tag-manager/server-side/intro

10. David Temoshok, Diana Proud-Madruga, Yee-Yin Choong, Ryan Galluzzo, Sarbari Gupta, Connie LaSalle, Naomi Lefkovitz and Andrew Regenscheid, National Institute of Standards and Technology, Digital Identity Guidelines. NIST Special Publication 800-63-4, DOI 10.6028/NIST.SP.800-63-4. Finalised 31 July 2025; supersedes SP 800-63-3. Not UK law: United States government guidance covering identity proofing, authentication and federation, not general marketing record linkage. https://csrc.nist.gov/pubs/sp/800/63/4/final

11. Ivan P. Fellegi and Alan B. Sunter, “A Theory for Record Linkage”. Peer reviewed journal article, Journal of the American Statistical Association, December 1969, DOI 10.1080/01621459.1969.10501049. Foundational statistical theory; it does not prescribe modern marketing identity systems or address privacy compliance. Not UK law. https://doi.org/10.1080/01621459.1969.10501049

12. Mauricio Sadinle, “Bayesian Estimation of Bipartite Matchings for Record Linkage”. Peer reviewed journal article, Journal of the American Statistical Association, 2017, DOI 10.1080/01621459.2016.1148612. Focuses on bipartite file linkage; it does not establish marketing match-rate benchmarks. Not UK law. https://doi.org/10.1080/01621459.2016.1148612

13. Nick Doty and Tom Ritter, W3C Privacy Working Group, Mitigating Browser Fingerprinting in Web Specifications. W3C Group Note, published 25 September 2025. A Group Note rather than a W3C Recommendation. Directed at specification authors; it is not a legal compliance code and does not claim that fingerprinting can be eliminated. https://www.w3.org/TR/fingerprinting-guidance/

14. Information Commissioner’s Office, Guidance on the use of storage and access technologies. Regulatory guidance. Draft published 20 December 2024; finalised 29 April 2026, superseding the draft. Expressly covers cookies, pixels, link decoration, device fingerprinting, scripts and tags. UK regulator guidance, not legislation or a case-specific legal judgment. https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/

15. European Data Protection Board, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, Version 2.0. Final version adopted 16 October 2024. Not UK law: EU supervisory guidance whose application depends on jurisdiction and facts. https://www.edpb.europa.eu/documents/guideline/guidelines-22023-on-technical-scope-of-art-53-of-eprivacy-directive_en

16. Information Commissioner’s Office, Introduction to anonymisation. Regulatory guidance. No publication date shown; current live guidance. Supports the position that pseudonymised information remains personal data where identification remains possible using separately held information; it does not make every hashed identifier personal data in every factual context, and identifiability must be assessed. UK regulator guidance, not legislation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-sharing/anonymisation/introduction-to-anonymisation/

17. Information Commissioner’s Office, Principle (d): Accuracy. Regulatory guidance on UK GDPR Article 5(1)(d). No publication date shown; current live guidance. Applies to personal data; not every record held by a marketing system is necessarily personal data. UK regulator guidance, not legislation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/accuracy/

Position dated 29 July 2026. Browser policy, platform policy and regulatory guidance in this area change frequently, and the last three years contain two reversals large enough to invalidate published advice. References 1 to 6, 8 and 9 come from organisations that control the platforms or products they describe. UK data protection guidance continues to be revised following the Data (Use and Access) Act 2025. Verify every platform and regulatory statement against the live source before relying on it.