Entity matching groups records that refer to the same real-world person, household, account, or other entity. Pairwise similarity is only the beginning. A production system must decide how much evidence a use case requires, whether a network of pairwise links forms a coherent cluster, and how downstream systems keep referring to an entity as records change.
These challenges were described in Amperity's peer-reviewed SIGMOD research on industrial entity matching. They remain useful evaluation criteria because match output supports customer analysis, segmentation, service, experiments, models, governance, and operational workflows.
Key Takeaways
Different use cases require different balances of precision and recall, so one universal match threshold can create the wrong risk tradeoff.
Pairwise matches must form coherent clusters; transitive links can otherwise connect records that contain meaningful conflicts.
Missing data is not the same as contradictory data, and a clustering system should treat those conditions differently.
Persistent entity identifiers help downstream systems track customers even when new records cause clusters to merge, split, or change.
Evaluate entity matching with false merges, missed matches, cluster coherence, identifier stability, explainability, and downstream impact.
What is entity matching?
Entity matching, also called record linkage or entity resolution, determines which source records describe the same underlying entity. In customer data, the evidence can include names, emails, phones, addresses, account IDs, loyalty IDs, and source-specific patterns.
Deterministic rules connect records through exact identifiers or explicit logic. Probabilistic models evaluate multiple signals and estimate match confidence. A hybrid system can use both, but the final output still needs clustering, conflict handling, persistent identifiers, and operational controls.
Challenge 1: Match confidence depends on the use case
A direct message about a recent purchase may require high precision because a false merge creates an obvious and potentially sensitive error. An aggregate analysis or media suppression use case may tolerate a different balance between false merges and missed matches.
Precision measures how many accepted matches are correct. Recall measures how many true relationships the system found. Raising a threshold often improves precision while reducing recall; lowering it often finds more relationships while increasing false-merge risk.
The entity-matching system should expose enough evidence to choose and govern that tradeoff. Instead of labeling one clustering universally true, teams can use purpose-built identity views from a shared data foundation when the product and operating model support them.
Questions to ask
Can the system produce or support identity policies at different confidence levels?
Who selects the policy for each downstream use case?
How are false merges and missed matches measured with representative data?
Can a reviewer understand why two records connected or remained separate?
Challenge 2: Pairwise matches must form coherent clusters
Many systems create a graph in which records are nodes and accepted pairwise matches are edges. Connected components can then group records transitively: if A matches B and B matches C, all three may enter one cluster even when A and C were never directly compared or appear inconsistent.
The chain can become dangerous when one ambiguous record bridges two people or accounts. Cluster-level logic must detect meaningful conflicts and decide whether to split the graph, reject an edge, or preserve the connection.
Missing data versus conflicting data
Two records may look dissimilar because a source never collects a field. That is different from both records containing incompatible values for an identifier treated as exclusive. Pruning every weak or absent comparison can split legitimate customer history, while ignoring hard conflicts can merge different people.
The matching policy should encode source semantics. A null loyalty ID, a shared household phone, two different verified account IDs, and a changed address do not carry the same evidence. Test the system on the missingness and conflicts that occur in your actual sources.
Questions to ask
Does the clustering step inspect conflicts across the full cluster, not only accepted pairs?
Can the system distinguish missing information from contradictory information?
How does one weak or erroneous edge affect a large connected component?
Can teams inspect and correct a false merge without losing source lineage?
Challenge 3: Entity identifiers must remain useful over time
Customer data changes. New transactions arrive, contact information changes, duplicates are corrected, accounts are merged, and privacy workflows remove records. A cluster can gain or lose members even when the real-world customer remains the same.
Downstream tables, experiments, models, audiences, and service systems still need a durable way to refer to the customer. Reassigning every identifier after each clustering run creates unnecessary churn and makes longitudinal analysis difficult.
A persistent-ID process should balance continuity with correctness. It must define what happens when clusters merge, split, appear, or disappear, and preserve enough history to explain the change. Stability should not freeze an incorrect match forever.
Questions to ask
What causes an existing entity ID to persist, split, merge, or retire?
Can downstream teams see which profiles changed and why?
How do deletion and correction workflows affect entity history and exports?
How much identifier churn occurs between representative runs?
How to evaluate entity matching in production
Create a reviewed test set from the sources and edge cases that matter. Include shared households, common names, guest purchases, corporate and personal emails, changed addresses, reused phones, sparse records, source-specific missing fields, duplicate accounts, and conflicting identifiers.
Measure false merges and missed matches at both pair and cluster levels. Review customer-count changes, value distribution, audience size, suppression, model inputs, consent behavior, and identifier stability. A single vendor-reported match rate cannot describe all of those outcomes.
Monitor the system after launch. Data sources, collection patterns, customer behavior, and product rules change. Track cluster movement, unusual component growth, match confidence, jitter, corrections, and downstream incidents.
From entity matching to trusted customer context
Amperity's current Identity Resolution offering uses explicit rules for certain relationships and AI scoring where connections are less obvious. It supports purpose-built identity graphs and preserves transparency into how records connect.
The original research paper describes the technical motivation for multi-confidence clustering, conflict-aware clustering, and persistent entity IDs. The paper is historical evidence, while current product claims should follow current product pages and documentation.
See how Amperity resolves fragmented first-party customer records for different decisions. Request a demo using your sources, difficult match cases, and precision and recall requirements.