The first result is often wrong: what we measured across 196 records

By: Jeremy Nash
Study completed:: 2026-07-19
Published:: 2026-10-01

The first result is often wrong

When the correct record is somewhere in the results, the data provider's first-listed record is not that person 44.9% of the time (95% CI 36.0%–53.8%, 88 of 196). Position in the list correlates with nothing but recency and name specificity, not with the quality of the match.

The question

A name-and-location search commonly returns a list, not a single answer. If you take the first record on that list, how often is it the wrong person?

This study measures one thing only: where, in the returned list, the record we had already independently identified as connected to a property actually sat. It does not measure or claim anything about why the data provider ordered the list the way it did.

How we tested it

We pulled 200 records from a tenant's production history (June 20 to July 17, 2026): people already determined, through this platform's own relationship matching, to be strongly connected to a search target at a given property. For each, we ran the same name-plus-location search the production system runs, with production's own query parameters, and recorded whether and where that person's record appeared in the response.

The query narrows in three steps, each run only if the previous one returned too many matches: name plus state, then name plus city and state, then name plus zip only. We used whichever address actually surfaced the person in the original job, not an address picked after the fact.

Four of the 200 records hit "too many matches" even at the narrowest available query level; those are excluded from the main count and reported separately. None came back with the person entirely absent from the results. That leaves 196 records where the person appeared somewhere in the response, which is the basis for the headline.

"Wrong" here means specifically: not the record this platform's own matching had already identified as the person connected to that search target. It is not a claim that the data provider's choice is objectively incorrect, and it is not a claim about how the provider ranks results, because the provider publishes no usable confidence score on these records. We describe position only.

Results

Outcome	Count	Share of 196
Correct record was first	108	55.1%
Correct record was present, but not first	88	44.9%

95% CI on "not first": 36.0%–53.8% (cluster bootstrap over the 44–45 searched properties in the sample, since records sharing a property aren't independent).

Read another way: reading only the first result finds the right person 55.1% of the time. Reading the first two finds them 68.9% of the time. The first three: 78.6%. The first five: 84.2%. The first ten: 92.3%. Among the 88 buried records, the median position was #3, the mean was #6.6, and the worst was #62. The median response length in this sample was 11 records.

The effect is strongest for common surnames: 32.8% not-first for a unique surname in the sample, rising to 66.0% for surnames appearing 5 or more times. It also strengthens with a narrower query: 36.5% not-first at the broadest level, 60.9% at the narrowest.

What this does and does not show

This measures position only, not why the provider ordered the list that way. The field meant to carry a match-confidence score is 0 on 702 of 703 records in our own data, and our own API documentation already describes it as inert. A claim that the provider ranks by confidence would be checkable against our own records and false, so we don't make it.

This is a conditional claim: when the person is in the results. Every record in this sample was a record the provider had already returned to us once, so this study says nothing about how often the provider fails to return a person at all. The zero "absent" count is not a coverage or recall finding; it reflects how the sample was built, not how complete the provider's data is.

The population is address-anchored, well-connected records, the richest-file case, from one tenant's book that's predominantly Texas (194 of 200 records). There's also a known, unmeasured direction of bias: the provider's secondary sort key favors records recently seen at the queried location, and this sample selects people likely to fit that profile, which would push the true match toward position one. So 44.9% is plausibly conservative, but that direction is reasoned, not measured, and isn't asserted as fact.

An earlier, smaller pass at this same question, run before the measurement was pre-registered, produced a 71% figure on just 14 observations. That number is superseded by this study and should not be quoted.

Why it matters if you skip trace

If your workflow is "run the search, take the top hit, dial it," this is the error rate baked into that habit: nearly half the time the top hit is wrong, even restricted to cases where the right person was findable at all. It gets worse for common names, which is exactly the population investors hit most in distressed-property work.

A system that checks a candidate's relationships against the other people on a deal, instead of reading position in a single-name list, catches a wrong guess that position alone cannot. If dialing the first hit has been burning you on wrong numbers, run a group search instead of trusting the top of the list.

Data and reproducibility

196 scored records (200 selected, 4 excluded as unresolvable at any query level) across 44–45 searched properties, 37 source jobs.
Measured July 19, 2026, under a pre-registered blueprint, revised once (before any measurement call) after an internal audit found a geography-assignment defect in the draft version.
309 data-provider calls against a 500-call ceiling, zero errors.
Sensitivity checks: excluding records where more than one sampled person shared the same query, 42.5%; excluding deceased records, 40.9%. The defensible range across these cuts is roughly 41–45%.
The full blueprint and results file, including the audit log, are available on request.

Cite this: GroupSkip Research (2026). The first result is often wrong: what we measured across 196 records. groupskip.com/research/first-result-wrong.