Entity Resolution Is a Decision, Not a Score

Introduction

A multi-branch operator that has grown by acquisition holds the same customer many times over: once in each system it bought, under a slightly different name, a reformatted address, and a phone number typed three ways. Collapsing those records into one customer is entity resolution, and the software that does it does not hand back a yes or a no. It hands back a score for each candidate pair, and someone has to decide where on that score to draw the line between “same customer, merge them” and “different customers, keep them apart.” That line is not a technical detail the model settles for you. It is a business decision, because the two ways of being wrong do not cost the same, and because the arithmetic of a large customer book makes the line matter more than the accuracy number ever lets on.

• Matching returns a score, not an answer. The hard part is not computing how similar two records look; it is deciding at which score to merge them. Move the threshold and you trade one kind of error for the other.
• A false merge is not a false split. Merging two real customers into one is effectively irreversible: it fuses service addresses, billing, and history into a record you cannot cleanly pull apart. Splitting one customer into two is a recoverable duplicate. When the errors are asymmetric, the threshold is a cost decision.
• Imbalance makes precision collapse. Almost every candidate pair is a non-match, so a tiny false-positive rate over that huge population can swamp the true matches. A matcher with a strong accuracy score can still produce a merged book that is mostly wrong.
• The cost ratio sets the operating point. The F-measure cannot pick the line for you; the ratio of a false-merge cost to a false-split cost can. That is a governed policy an operator owns, not a number a vendor reports.

A score, not an answer

How you actually compare two records - the string similarity, the phonetic keys, the blocking that keeps the work from exploding, and the survivorship that folds matched records into one - is the subject of the companion essay on the negative effects of dirty data, and it is referenced here rather than repeated. Take those mechanics as given. What they produce, for every pair of records that might be the same customer, is a number: a similarity or a probability that says how alike the two look. The resolution is not finished when that number exists. It is finished when you decide which numbers are high enough to act on, and that decision is where the money and the risk live.

Framing entity resolution as a scored decision rather than a lookup is the standard modern view; a widely cited survey of the field treats it as the problem of clustering records into entities from noisy, uncertain evidence, and it flags the open challenges that remain. The cut is usually described with two familiar quantities. Precision is the share of the pairs you merged that really were the same customer; recall is the share of the truly-same pairs that you managed to merge. Push the threshold up and precision rises while recall falls, because you only merge when very sure; pull it down and recall rises while precision falls, because you merge on thinner evidence. Every candidate operating point is a point on that trade-off, and the model does not tell you which one to stand on.

A false merge is not a false split

The reason the choice cannot be delegated to an accuracy score is that the two errors are not interchangeable. A false split - leaving one customer as two records - is a duplicate: annoying, a little wasteful, and fully recoverable, because the next match run or a human can join them later with nothing lost. A false merge - fusing two different customers into one record - is a different animal. It overwrites one account’s service address with another’s, commingles their billing and their service history, and does it in a way that is hard to undo, because once the rows are merged the information needed to separate them again may be gone. In a field-service book the blast radius is physical: a crew routed to the wrong property, an invoice sent to the wrong payer, a cancellation history attached to the wrong customer.

Because the errors differ, so should their weights, and the entity-resolution literature has the machinery to say so. The standard way to score a resolution against a truth set, the generalized merge distance, measures how far a proposed grouping is from the correct one using splits and merges as its elementary operations, and its central feature is that the cost of a split and the cost of a merge are separately configurable. Set them equal and you recover the ordinary symmetric measures; set the merge cost higher and you have written down, formally, the fact that a wrong merge hurts more than a wrong split. The moment those two costs differ, the “best” resolution is no longer the most accurate one. It is the one that spends the fewest expected dollars of error, and that depends on a ratio only the operator can supply.

Why imbalance makes it bite

If the two error costs were close, the threshold would barely matter. What makes it bite is the shape of the problem: candidate pairs are overwhelmingly non-matches. The public entity-resolution benchmarks make the scale concrete. In the widely used Leipzig DBLP-Scholar benchmark, matching 2,616 records against 64,263 gives 168,112,008 candidate pairs, of which just 5,347 are true matches - about one in every 31,440, or 0.0032 percent. The true matches are a rounding error against the non-matches. Those counts are verified against the published benchmark evaluation, and while DBLP-Scholar is among the most imbalanced of the public benchmarks, the others are lopsided too: across the set the true matches are under a tenth of a percent of the candidate pairs, so an imbalance of at least a thousand to one is the rule rather than a cherry-picked extreme.

Under that imbalance, an innocent-looking false-positive rate is ruinous for precision. If a matcher wrongly flags even one percent of non-matching pairs, one percent of 168 million is over a million false merges, against a few thousand real ones, so the merged output is almost entirely wrong even though the matcher was “99 percent right” on non-matches. This is exactly the trap that Davis and Goadrich show when they compare precision-recall curves with the more familiar ROC curve: the ROC curve ignores how many non-matches there are, so a model can post a strong ROC while its precision has quietly collapsed. In the computed example on this page the matcher has a genuinely strong ROC-AUC of about 0.96, and a naive threshold chosen to catch 95 percent of true matches still lands at a precision of about 9 percent. The accuracy score looks fine; the book it produces does not.

The cost ratio sets the point

The way out is not a better score but an explicit decision rule, and cost- sensitive learning gives the exact one. Elkan shows that when correct decisions are free, the optimal policy is to take the positive action - here, merge - only when the estimated probability of a match clears a threshold p* equal to the cost of a false positive divided by the sum of the false-positive and false-negative costs. A false merge is the false positive. So if a wrong merge is judged four times as costly as a wrong split, p* is four divided by five, or 0.80: merge only when the model is at least 80 percent sure. Change the ratio and the threshold moves with it; the number is not a tuning knob to be swept for the best F-measure, it is read directly off the business’s own cost of being wrong.

The chart at the top of this page makes that concrete with a fully reproducible computation on public, illustrative parameters, and no client data anywhere. It models one fixed matcher scoring candidate pairs in which two percent are true matches, under a false-merge-to-false-split cost ratio of four to one. The left panel is the precision-recall frontier, and three operating points sit on the same curve. The naive point that maximizes recall lands at about 9 percent precision. The point that maximizes the F-measure balances the two errors at roughly 59 percent precision and 53 percent recall. The cost-optimal point, Elkan’s p* of 0.80, sits at about 91 percent precision and 19 percent recall: it deliberately accepts more false splits, which are recoverable, to avoid the false merges that are not. The right panel is the expected cost per pair against the threshold, and its minimum is not where the F-measure peaks; the peak-F1 threshold costs roughly 2.2 times as much as the cost-optimal one. A seeded simulation reproduces the closed-form curves as an independent check, and every one of these coordinates is locked in the committed build script.

This is why the F-measure cannot be the target. As Hand and Christen argue in the record-linkage setting, the F-measure quietly fixes a relative weight between precision and recall that depends on the matcher rather than on the problem, so choosing a threshold to maximize it imports a weighting nobody chose. The honest alternative is to state the weighting out loud as a cost ratio and let it set the point. The ambiguous middle - the pairs that score near the line - does not disappear under this framing; it becomes a clerical-review queue, and even the size of that queue is a cost decision, traded against the analyst time it consumes. A computed operating point is a model output with disclosed assumptions, not a measurement, and its whole value is that the assumption is visible and can be argued with.

The single customer view

Executives rarely ask for entity resolution by name. They ask for a single customer view, a customer 360, one trustworthy answer to “how many customers do we actually have, and which of these records are the same household” once several acquired books are pooled. That request is where this decision surfaces to the boardroom, because a single customer view is exactly a pile of merge-or-not decisions, and its quality is set by where the threshold was drawn. Ask for one number and you have implicitly asked someone to choose a cost ratio, whether or not anyone wrote it down. Consolidating records into one authoritative version is a solved discipline; what the tooling does not settle is the knob it leaves exposed - the operating point - which is a governed policy, not a default.

Treating it as policy has practical consequences. The right cost ratio is not universal: the threshold for merging two records before dispatching a crew to a physical address, where a false merge sends a truck to the wrong house, should be stricter than the threshold for a marketing rollup, where a false merge only blends two mailing lists. So a single customer view worth trusting is not one threshold but a small set of them, chosen per use and recorded, with the ambiguous pairs routed to review rather than force-merged. The output an operator should demand is not a merged table but a merged table plus the operating point that produced it and the error budget it implies, so the decision can be audited and revisited as the book, and the cost of a wrong merge, change.

Assumptions and limits

The figure is an illustrative model, and its honesty is in the disclosures. The scores are drawn from two clean bell curves, one for matches and one for non-matches; real matchers are messier, their score distributions overlap in stranger ways, and their probabilities are often poorly calibrated, so the exact coordinates would move on real data even though the shape of the argument holds. The cost ratio is illustrative too: four to one is a stand-in for a judgment an operator has to make, and the point is that some ratio is always being assumed, not that this one is right. The class-imbalance figure is a modeling choice stated in the caption; after blocking, real books are less extreme than the raw benchmark, though the direction never reverses. The synthetic model uses no client or first-party data, and the real benchmark numbers are external, cited results, not a measurement of any operator’s book.

The claim this essay defends lives inside those limits: that entity resolution returns a graded score, that the two errors it can make are asymmetric and one is effectively irreversible, that class imbalance makes precision collapse where an accuracy score would not warn you, and that the sensible response is to set the operating point from a stated cost ratio rather than from the F-measure. That a chosen threshold will hit its intended error budget on live data is not guaranteed, because real score distributions and real match rates differ from any model; the operating point is a disciplined starting decision to be monitored, not a mechanical certainty, and every figure here is an analytical implication under stated assumptions, not a measured result.

What this means for the operator

For a multi-branch operator pooling acquired books, the program is concrete: state the cost of a wrong merge relative to a wrong split for each use of the data, set the match threshold from that ratio rather than from an accuracy score, route the ambiguous middle to review, and keep the operating point on record so a single customer view can be audited instead of trusted blindly. Doing that turns deduplication from a black-box score into a governed decision with a visible error budget. It also connects to the neighboring questions in this research: the matching mechanics and the cost of dirty records themselves are the subject of the negative effects of dirty data; the reason a clean customer count matters to a deal is the argument of why valuation follows revenue quality, not revenue; and once records resolve correctly, measuring retention properly is the theme of why churn is a distribution, not a number.

The boundary a vendor has to state is plain. Software does not choose the cost ratio, and it does not decide which records to merge or which to hold for review; those are the operator’s calls, and the value of a resolved book is only as good as the operating point disclosed with it. What a data and intelligence layer can support is that decision: scoring candidate pairs, exposing the precision-recall trade-off, applying the threshold the operator sets, and keeping the ambiguous pairs and the chosen error budget on the record. Ardenus is built for that layer and sits on top of the systems an operator already runs, but no result, saving, or forecast is attributed to Ardenus here; the methods are the public record of cost-sensitive decision-making and record linkage, and no client or first-party data appears anywhere in this essay. You can read more of our research on the Ardenus articles hub, or see the platform itself on the technology page.