A 95% accurate matcher gives 27.9% confidence on a pool of 50 accounts. Why pool size decides accuracy, and which signals actually shrink it.
- Identity resolution accuracy depends on pool size: a 95% accurate matcher gives 27.9% confidence against 50 accounts and 1.9% against 1,000.
- Shrinking the pool beats improving the model: cutting 1,000 candidates to 10 lifts confidence from 1.9% to 67.9% with the same matcher.
- Name alone barely narrows anything; a declared handle collapses the pool to 1, an advantage visa screening has over hiring.
- A missed account is a gap; a wrong match is an adverse decision about somebody else, so send ambiguous matches to a human.
- Attribution accuracy is measurable, unlike most of screening, against accounts the subject confirms.
Identity resolution is the stage every other part of a screening product depends on. A perfect classifier reading the wrong person's posts produces a confident, well formatted, completely invalid report.
It is also where vendor accuracy claims mislead most, because what decides whether a match is trustworthy is not the model. It is how many people could plausibly be the match.
Here is the arithmetic, the signals that actually help, and how to handle the matches your system cannot settle on its own.
Why does pool size decide accuracy?
Because matching is a classification problem with a very low base rate. Only 1 account in the candidate pool is the right person, so the more candidates there are, the more chances the matcher has to be confidently wrong.
Take a matcher that is 95% sensitive and 95% specific, which is a respectable model, and run it against different pool sizes.
| Candidate accounts | Prior | Confidence a flagged match is correct |
|---|---|---|
| 2 | 50% | 95.0% |
| 5 | 20% | 82.6% |
| 10 | 10% | 67.9% |
| 50 | 2% | 27.9% |
| 200 | 0.5% | 8.7% |
| 1,000 | 0.1% | 1.9% |
The same matcher is right 95% of the time against 2 candidates and wrong 72% of the time against 50. The model did not change. The question got harder.
So a vendor quoting a single accuracy figure has not told you much. Ask what pool size it was measured against.
Is a better model the answer?
It helps, and it is the expensive route. Here is the same pool of 50 with progressively better specificity.
| Specificity | Confidence | What that takes |
|---|---|---|
| 95% | 27.9% | A reasonable model |
| 99% | 66.0% | A good model and more signals |
| 99.9% | 95.1% | Very hard on public data alone |
| 99.99% | 99.5% | Not realistic from the outside |
Now compare that with just shrinking the pool, holding the model at 95%.
| What you know | Pool size | Confidence |
|---|---|---|
| Name only, common name | 1,000 | 1.9% |
| Name and country | 50 | 27.9% |
| Name, country and employer | 10 | 67.9% |
| Name and email domain | 2 | 95.0% |
| A handle the subject declared | 1 | Certain |
Adding a country and an employer takes you from 1.9% to 67.9% with no change to the matcher at all. Getting the same result through modelling alone would mean pushing specificity close to 99.9%, which is not achievable from public signals.
So identity resolution is a data problem before it is a model problem. Spend your effort on collecting narrowing information, not on tuning a scorer handed an impossible question.
Which signals are even available per platform decides how far you can narrow. The field list is public. See the coverage list
Which signals actually narrow the pool?
The ones that few people could share. Ranked roughly by how much they collapse the candidate set.
| Signal | Power | Notes |
|---|---|---|
| Declared handle | Total | Collapses to 1. The strongest signal available and the rarest |
| Verified connection | Total | If the subject connected the account, identity is established by the platform |
| Email or email domain | Very high | A work domain plus a name is close to unique |
| Cross-link in bio | High | A profile naming another handle is direct evidence |
| Employer and role | High | Especially combined with location |
| Phone number | High | Where lawfully available |
| Profile photo match | Medium | Useful, and sensitive. Consider the fairness implications |
| Location | Medium | Narrows a lot for a rare city, little for a capital |
| Name | Low | On a common name it narrows almost nothing |
The top 2 rows are a different category from the rest. A declared handle or a verified connection does not narrow the pool, it removes the problem, because the subject told you. Everything below is inference, which is why we treat it as a different kind of evidence in the risk taxonomy.
The profile photo row needs a decision before you build it. Face matching narrows well and brings the fairness problems of facial analysis with it.
Why does screening make false positives worse?
Because the 2 error types have very different consequences, and the asymmetry should shape your thresholds.
- A missed account is a coverage gap. Your report says less than it could, and the completeness score should show it, as we set out in the screening coverage post.
- A wrong match attributes somebody else's content to your subject. In a screening context that becomes an adverse decision about the wrong person, and it is the failure that ends up in a legal letter.
So the usual instinct of tuning for balanced accuracy is wrong here. Tune for precision, accept lower recall, and route the difference to human review rather than guessing. The pipeline position is in how to build a social screening product.
The practical rule that follows: never auto-clear a match below your confidence threshold to protect throughput. That is trading the error you can survive for the one you cannot.
What about declared handles?
Where they exist, they change the problem entirely, and they are more common in regulated screening than people realise.
US visa applications require applicants to disclose the handles they used over a 5 year lookback, including deleted accounts. That gives screening something hiring does not have: a checkable denominator. You can report how many declared accounts you found, which turns an unknown into a measurable gap. That is why visa and immigration screening can report completeness properly.
In hiring you usually have no declared handles, so ask for what you can lawfully collect. Even an email domain and a current employer moves you from a pool of hundreds to a pool of a handful, which the arithmetic above shows is worth far more than a better model.
How should the system behave?
# Confidence decides routing. It is not a yes or no.
AUTO_ACCEPT = 0.95
AUTO_REJECT = 0.40
def route(candidate):
c = candidate.confidence
if c >= AUTO_ACCEPT:
return "include" # carry c into the report anyway
if c < AUTO_REJECT:
return "discard"
return "human_review" # the band that protects you
# 2 rules that matter more than the thresholds:
# 1. the confidence travels WITH every finding. A reviewer
# reading an item should see how sure you are it is them.
# 2. widen the review band when the name is common. Pool size
# is an input to routing, not just to the score.The second rule is the one people miss. A fixed threshold treats a common name and a rare one identically, which they are not.
What can you actually measure?
More than in most of screening, because attribution has a ground truth that risk prediction does not.
- Match accuracy against confirmed accounts. Where a subject confirms which accounts are theirs, you can measure precision and recall directly. It is the 1 hard accuracy number in screening, since risk prediction has no ground truth.
- Declared versus found. On populations with declared handles, the gap is a direct coverage measure.
- Human review rate and overturn rate. How often a reviewer disagrees with the automated call tells you where your thresholds sit.
- Confidence distribution by name commonality. If confidence does not drop on common names, your scorer is not accounting for pool size.
That last check is a quick way to audit any vendor. Ask them to run 2 subjects, 1 with a very common name and 1 with a rare one, and show you the confidence scores. If the scores look similar, the pool size is not in the model.
Summary
Identity resolution accuracy is set by how many people could plausibly be the match, not by how good the matcher is. A 95% model is excellent against 2 candidates and close to useless against 1,000, and the fix that works is collecting information that narrows the field rather than tuning the scorer.
In screening, tune for precision rather than balance, because a missed account is a gap and a wrong match is a decision about the wrong person. Route anything ambiguous to a human, widen that band when the name is common, and carry the confidence score all the way into the report so the person reading it knows how sure you are.
Want the attribution layer that the rest of a screening report depends on? Get a demo
How accurate is cross-platform identity matching?
It depends on how many accounts could plausibly be the subject's. A matcher 95% sensitive and specific gives about 95% confidence against 2 candidates, 67.9% against 10 and 1.9% against 1,000.
What is the best way to improve match accuracy?
Collect signals that narrow the candidate pool. Adding a country and an employer can lift confidence from 1.9% to 67.9% with the same matcher; modelling alone would need close to 99.9% specificity.
Which signals are strongest for identity resolution?
A declared handle or a connected account, since both remove the inference. Then email or email domain, a cross-link in a bio, employer and role, and phone number. Name alone narrows little.
Should a screening system auto-accept uncertain matches?
No. A missed account is a coverage gap; a wrong match attributes someone else's content to your subject and can become an adverse decision about the wrong person. Route ambiguous matches to a human.
Can identity match accuracy be measured?
Yes. Where subjects confirm which accounts are theirs, you can measure precision and recall directly, and with declared handles the gap between declared and found is a direct coverage measure.
