Identity Resolution and the Limits of Stitching

The premise of most customer data platforms is that scattered activity — this device, that session, this email address — can be joined into one person. Transparency matters alongside technical matching; this page explains how employees may recognise that monitoring is taking place.

Some of it can. The parts that can are narrower than the pitch, the error rate is rarely stated, and the errors run in a direction that flatters the vendor.

The three methods, and what each establishes

Deterministic matching

Joining on a shared identifier the person supplied: an email address, an account, a customer number.

When it matches, it is right. This is the only method with that property.

It only covers people who identified themselves. Anonymous browsing is out of scope by construction, and that is usually the majority of sessions.

The failure mode is coverage, not accuracy. You miss people; you do not usually merge the wrong ones — although a shared family email address will merge two people, and a customer with three email addresses will appear as three customers.

Probabilistic matching

Inferring that two devices belong to one person from signals: IP address, timing, behaviour, device characteristics.

It never establishes identity. It estimates a likelihood, and the threshold for calling it a match is a business decision made by whoever built the system.

The failure modes go both ways. Two people in one household on one IP address get merged. One person on office wifi and home wifi does not.

Vendors rarely publish accuracy, and where a figure is given it is usually measured on a population where deterministic matches were available for validation — which is the population where the method is least needed and works best. The accuracy on the anonymous majority is unmeasured by construction.

Regulatory context matters here. In several jurisdictions probabilistic linking of a person across sites is processing personal data, with the obligations that implies.

Data clean rooms

Two parties compare datasets to find overlap without either exposing individuals.

Genuinely useful for a specific question: how much do our audiences overlap, and how did people we both know behave.

Deterministic underneath — it matches on hashed identifiers — so it inherits the coverage limitation.

Expensive, slow, and narrower than the marketing implies.

What the errors do to your numbers

The part that matters, and it is rarely quantified.

Over-merging inflates per-customer metrics. Two people counted as one produces a customer with twice the activity, which pushes up average order frequency and lifetime value. See customer lifetime value.

Under-merging inflates customer counts and deflates retention. One person appearing as three looks like three customers who each bought once, rather than one who bought three times. Retention curves look worse than reality.

Both distort attribution. A journey stitched wrongly attributes a conversion to a touchpoint a different person saw.

And the errors are not random. They correlate with household size, device count, browser choice and technical sophistication — which correlate with income and with purchasing behaviour.

Questions worth asking a vendor

What proportion of my traffic can you resolve deterministically? This is the number that matters and it is usually much lower than the headline coverage figure.

What is the accuracy of the probabilistic matching, measured how, on what population? If the validation set is people who logged in, say so.

What threshold is used to declare a match, and can I change it? A lower threshold increases coverage and increases false merges. Someone chose that trade; it should be you.

How do you handle a household on one IP?

What happens when someone uses a new device?

Can I see the match rate over time? A falling rate is a signal that something changed in your collection.

Working within the limits

Build the deterministic base first. Anything that encourages identification — accounts, saved baskets, loyalty, order lookup — increases the share of activity you can join accurately. This is a product and incentive question rather than a data question, and it is where the return is.

Keep the confidence level with the join. A merged profile should record whether the merge was deterministic or inferred, so downstream analysis can choose. Most platforms flatten this and the distinction is lost.

Report metrics both ways where it matters. Retention on deterministic identity only, and on the full stitched set. The difference is the size of your uncertainty, and it is more informative than either number alone.

Do not use stitched identity for anything with consequences for the individual. Personalisation based on a wrong merge shows one person another person's history. This is a poor experience and, depending on what is shown, a data protection incident.

Reconcile against transactional identity. Your order table has real customer identity for anyone who bought. Comparing the platform's customer count against it is the available ground truth. See when two systems disagree.

The methods that do not need identity

Worth stating, because identity resolution is frequently bought to answer questions that do not require it.

Incrementality testing works on groups, not individuals. A geo experiment or a holdout does not need to know who anyone is.

Marketing mix modelling operates on aggregates.

Cohort analysis needs a customer identifier for purchasers, which you have deterministically from orders.

If the goal is to know what a channel contributed, identity resolution is not the tool — and it is frequently sold as though it were. See incrementality.

The summary

Deterministic matching is accurate and covers only people who identified themselves.

Probabilistic matching estimates a likelihood and has an error rate in both directions, correlated with things that correlate with buying behaviour.

Over-merging inflates per-customer metrics; under-merging inflates customer counts and deflates retention.

Invest in the deterministic base, keep the confidence level attached to the join, and reconcile against your order table.

And check whether the question you have actually needs identity at all — the causal ones do not. For an authoritative treatment of identity evidence and assurance, see NIST identity-proofing guidance.