MDM Matching Algorithm Tuning: Precision vs Recall

MDM matching algorithm tuning is the process of adjusting how a master data management (MDM) system decides that two records describe the same real-world entity. You configure the rules, field weights, and score thresholds so the system merges true duplicates and keeps distinct entities apart. Tuning trades precision (how many proposed matches are correct) against recall (how many true matches are found).

Why Matching Configuration Decides Your Golden Record Quality

Matching is the first step in building a golden record, and every later step depends on it. If the matcher merges two different customers, survivorship rules will blend their attributes into one corrupted record. If it misses a true duplicate, downstream reports double-count the entity and stewards spend hours on manual reconciliation. Most teams treat the matching engine as a black box that ships with defaults, then wonder why their customer or product counts never reconcile.

I’ve come to think of matching as a measurement instrument. A thermometer that reads five degrees high is not useful just because it reads precisely. Tuning is how you calibrate the instrument against what the business actually considers “the same thing.” That calibration is rarely obvious from the start, and it changes as source systems change.

At Nestle Purina, where we managed product and supplier master data across multiple source systems, the first matching configuration we ran looked clean on paper. Once we started reviewing samples, we found that package sizes, pack counts, and regional naming variants were being treated as differences in identity in some cases and as duplicates in others. The fix was not a better algorithm. It was a disciplined approach to rules, weights, and thresholds, supported by a validation process that the business trusted. That is the approach this article lays out.

This article walks through how matching algorithms work, how to configure rules and weights, how precision and recall trade off, and how to set thresholds that minimize false matches without leaving real duplicates unresolved. It also covers edge cases such as name variations, missing data, and multi-source records, and it closes with the validation and monitoring practices that keep match quality from drifting. The emphasis is on configuration you can carry out and defend, not on theory. Governance context matters too. If you are still establishing ownership and policy, What is Data Governance? The Complete Guide for 2026 covers the foundations that tuning decisions should sit within.

How MDM Matching Algorithms Work: Deterministic vs Probabilistic

Every MDM matching engine answers the same question: given two records, how likely is it that they refer to the same entity? The two dominant approaches answer it differently, and most production systems use some mix of both. Understanding the difference is the starting point for any tuning exercise, because the knobs you can turn depend on which approach is doing the work.

Deterministic matching applies explicit rules. If two records share the same tax identifier, or the same normalized email address and the same postal code, the system declares a match. The logic is transparent, which is its greatest strength. A steward can read the rule and explain exactly why two records were merged. The weakness is brittleness: a single typo in an identifier, or a missing field, causes the rule to fail silently.

Probabilistic matching instead compares many fields, scores how well each one agrees, and combines those scores into an overall likelihood. The classic formulation is the Fellegi-Sunter model, published by Ivan Fellegi and Alan Sunter in 1969, which estimates match and non-match probabilities for each field comparison. Modern engines use variations of this idea with different string comparators and learned weights. Probabilistic methods tolerate noise far better, but they are harder to explain, and their behavior depends on parameters that must be set and checked.

In my experience, the right answer for most enterprises is a layered approach. Deterministic rules catch the high-confidence cases cheaply: an exact match on a verified national identifier, for example, should rarely need scoring at all. Probabilistic scoring then handles the remaining population, where records share a name and address but no reliable key. Layering also makes tuning easier, because you can measure how each layer contributes to total matches and total errors.

The mechanics of field comparison matter as much as the decision model. String comparators such as Levenshtein edit distance, Jaro-Winkler similarity, and phonetic encodings like Soundex or Double Metaphone each capture a different kind of difference. Levenshtein counts single-character edits, which suits typos. Jaro-Winkler weights agreement at the start of a string, which suits personal names with shared prefixes. Phonetic encodings suit names that sound alike but are spelled differently. Choosing a comparator is a configuration decision with real consequences, and I’ll return to it when we discuss name variations.

Setting Match Rules and Assigning Weights

Once you know which decision model your engine uses, the next task is defining the fields, rules, and weights that drive it. This is where most configuration effort goes, and where most avoidable errors are introduced. The guiding principle is that each field should contribute evidence proportional to how reliably it identifies an entity, and no more.

Start by ranking candidate match fields by discriminating power. A field has high discriminating power when agreement on it is rare among non-matching records and common among true matches. Government-issued identifiers, verified tax numbers, and globally unique product codes typically rank high, provided they are populated and accurate. Names rank lower because common names collide frequently. Postal addresses fall somewhere in between and change over time. Phone numbers and email addresses are useful but get reassigned or shared, so they need caveats.

Writing Deterministic Rules Precisely

Deterministic rules should be written against normalized values, never raw source values. Normalization covers case folding, whitespace removal, punctuation stripping, standardized abbreviations, and removal of placeholder values such as “N/A”, “UNKNOWN”, or all-zero identifiers. If your rule compares raw values, every upstream formatting difference becomes a missed match.

Keep the number of deterministic rules small and each one defensible. A useful test is whether a data steward could explain the rule to an auditor in two sentences. If the explanation requires caveats about which source systems are trusted or which fields are often blank, the rule probably needs to be scoped more narrowly or moved into the probabilistic layer.

Assigning Field Weights

In probabilistic configurations, weights express how much agreement or disagreement on each field should move the overall score. A common mistake is to assign weights by intuition alone, such as giving the name field the largest weight because it feels most important. Weights should instead reflect the evidence each field provides, which is why they are usually derived from the match and non-match agreement rates observed in your own data.

A workable approach is to start with a labeled sample. Pull a few thousand record pairs, label them as matches or non-matches through steward review, and calculate how often each field agrees within each group. A field that agrees in 95 percent of true matches but only 2 percent of non-matches carries strong evidence and deserves a substantial weight. A field that agrees in 90 percent of matches but also in 40 percent of non-matches carries weak evidence and should contribute little. The exact arithmetic depends on your engine, but the principle is the same across implementations.

Weights also need to account for missing data. A missing field should usually contribute nothing, neither supporting nor opposing a match. Penalizing matches for missing values is a frequent source of false negatives, because records from sources with sparse data never reach the threshold. Configure your engine so that null comparisons return a neutral score, and verify that the behavior matches your intent.

Here is an illustrative configuration structure for a probabilistic matcher. The field names, weights, and comparators are examples for discussion, not defaults from any particular product:

# Illustrative probabilistic match configuration (example values only)
match_model: probabilistic
fields:
  - name: tax_id
    comparator: exact
    agree_weight: 6.0
    disagree_weight: -4.0
    missing_weight: 0.0
  - name: legal_name
    comparator: jaro_winkler
    agree_threshold: 0.92
    agree_weight: 3.0
    disagree_weight: -2.0
    missing_weight: 0.0
  - name: postal_code
    comparator: exact
    agree_weight: 1.5
    disagree_weight: -1.0
    missing_weight: 0.0
  - name: phone
    comparator: normalized_exact
    agree_weight: 1.0
    disagree_weight: -0.5
    missing_weight: 0.0

Notice that missing values are neutral by design and that the highest-weight field is the one with the strongest identifying power. The specific numbers should come from your own agreement analysis, not from this example.

Documenting the Rule Set

Every rule and weight should carry a rationale and an owner. When a steward asks why two records with the same postal code and a 0.88 name similarity were not merged, the answer should be findable without a debugging session. I recommend keeping a match rule register that records each rule, its purpose, the sample used to justify its weight, and the date it was last reviewed. Treat changes to this register like changes to any governed reference data, with approval and version history. The workflow for that approval belongs in your broader stewardship process, which is covered in master data management workflows and approvals.

Understanding Precision and Recall in Duplicate Detection

Precision and recall are the two measures that tell you whether your matching configuration is doing what you intend. Precision is the share of proposed matches that are correct. Recall is the share of true matches that the system actually found. The two pull against each other: making the matcher more willing to merge raises recall and usually lowers precision, while making it more cautious does the reverse.

Put more formally, for a given run, precision equals true positives divided by the sum of true positives and false positives, and recall equals true positives divided by the sum of true positives and false negatives. A false positive in MDM means two distinct entities were merged. A false negative means a true duplicate was left unmerged. These error types have different business costs, which is why you cannot tune for one measure in isolation.

Why the Trade-Off Is Asymmetric

In most enterprises the two error types are not equally expensive. A false positive corrupts a golden record, which can misdirect invoices, shipments, or regulatory reports, and it can be hard to undo once downstream systems have consumed the merged record. A false negative leaves duplicates in place, which is inconvenient and inflates counts but is usually recoverable through later matching passes or steward review. For this reason, many programs set a precision floor and then maximize recall beneath it.

That is not a universal rule. In a customer context where duplicate outreach causes regulatory or reputational problems, recall may be the more urgent measure. In a product context where two near-identical SKUs have different regulatory labeling, precision matters more. The right balance depends on what a wrong merge or a missed merge costs your specific business, and that cost should be agreed with data owners before you tune anything.

Measuring Both on a Labeled Sample

You cannot measure precision and recall without ground truth, and ground truth requires labeled data. Build a labeled evaluation set by sampling candidate pairs across the score range, not just the obvious matches. Include pairs near your current threshold, because those are where the decisions change. Have two stewards label each pair independently and resolve disagreements, then record the rationale for ambiguous cases. That disagreement rate is itself a useful signal: if experienced stewards cannot agree on a pair, the automated system will not agree with you consistently either.

Once you have labels, compute precision and recall at several thresholds and plot them against each other. The resulting precision-recall curve shows what each operating point costs in the other measure. Choosing a point on the curve is a business decision informed by the data, not a technical default.

Practical Targets and Their Limits

Teams often ask what precision and recall targets to aim for. I’m reluctant to offer a universal number, because the achievable values depend on data quality, source overlap, and the difficulty of the entity type. Customer records with rich identifiers can reach very high precision. Supplier records scraped from heterogeneous procurement systems often cannot. Set targets per entity type and per source combination, based on what your labeled sample shows is achievable, and revisit them as data quality improves. Connecting these measures to your broader quality program is useful; the data quality dimensions framework provides vocabulary for explaining why a match failure is an accuracy or completeness problem rather than a vague “bad data” complaint.

Tuning Thresholds to Minimize False Matches

The threshold is the score at which the engine decides two records match. Scores above the upper threshold are merged automatically. Scores in an intermediate band are sent to a steward for review. Scores below the lower threshold are treated as distinct. Tuning thresholds is the most direct lever you have over the precision-recall balance, and it is also the lever most often set once and forgotten.

A two-threshold design deserves more attention than many implementations give it. The automatic-merge threshold should be set high enough that errors there are rare, because automatic merges carry the highest risk. The review band should be wide enough to capture ambiguous cases that a steward can resolve, but not so wide that stewards drown in queue volume. The non-match threshold determines how much of the candidate population is discarded without review, and setting it too aggressively is a common cause of silent recall loss.

Finding the Operating Point

Use your labeled sample and the precision-recall curve to select thresholds. Start by identifying the lowest threshold that keeps precision above your agreed floor in the automatic-merge band. That point defines how aggressively you can auto-merge. Next, set the review band to span the scores where precision drops below the floor but recall remains valuable. Finally, set the non-match threshold where the proportion of true matches falling below it becomes unacceptable to the business.

Expect the curve to have a knee. Below the knee, lowering the threshold adds many true matches at little precision cost. Above it, each additional merge carries disproportionate risk. The knee is often the most defensible automatic-merge point, but confirm it against your sample, because the position varies with data quality and field coverage.

Watching for Threshold Sensitivity

Small threshold changes can have large effects when the score distribution has dense clusters near the boundary. Before finalizing a threshold, plot the histogram of scores for labeled matches and non-matches. If the two distributions overlap heavily around your chosen point, the threshold is sitting in a region where the engine cannot separate the populations well, and the real fix is better fields or better comparators rather than threshold adjustment.

In my experience, the most common threshold error is treating the threshold as a substitute for data quality work. Teams raise the threshold to stop false merges, which then increases missed matches, and they keep adjusting the number without addressing the underlying cause, such as a source system that stores addresses in a different format. A threshold can only separate evidence that is already present in the data.

Keeping Thresholds Under Change Control

Thresholds should be treated as governed parameters. Record each change with the date, the reason, the evaluation results before and after, and the approver. Avoid tuning thresholds directly in production without first measuring the effect on a held-out sample. Several teams I’ve worked with kept a staging copy of the matching configuration and ran every proposed change against the labeled set before promoting it, which caught several changes that looked beneficial on average but damaged a specific region or product line.

Handling Edge Cases: Name Variations, Missing Data, and Multi-Source Records

The clean cases in a matching configuration are rarely where tuning gets hard. The difficult work sits in the edge cases: names that vary by culture or transliteration, records with sparse or inconsistent attributes, and entities that arrive from many source systems with different conventions. Each of these needs deliberate configuration, because default settings tend to handle the typical case and fail the unusual one.

Name Variations and Transliteration

Personal and organizational names vary in several ways. Nicknames replace formal names, as with “Bill” for “William.” Word order changes across cultures, so family names may appear first in some source systems. Diacritics are dropped or retained inconsistently, and transliteration from non-Latin scripts produces multiple valid spellings. Organizational names add their own problems: legal suffixes such as “Ltd” or “GmbH” are sometimes included and sometimes omitted, and trading names differ from legal names.

For these cases, normalization is the first line of defense. Strip legal suffixes into a separate field and compare cores. Standardize diacritics and case before comparison. Maintain a controlled nickname table if your population warrants it, and treat it as reference data with an owner. Phonetic comparators help with spelling variants that sound alike, but they can over-match short or common names, so pair them with a second field rather than relying on them alone.

Be cautious with comparator thresholds for names. A Jaro-Winkler similarity of 0.92 may be appropriate for long surnames and too permissive for short ones. Some teams scale name thresholds by string length, which reduces false matches among short names without sacrificing recall on longer ones. Test any such scaling against your labeled data, because the appropriate behavior varies by population.

Missing and Sparse Data

Missing data creates two opposite risks. If missing fields are penalized, true matches fall below threshold and recall drops. If missing fields are ignored entirely, the engine may merge records that merely share a common name and nothing else, and precision drops. The neutral-weight approach described earlier handles the first risk, but it can aggravate the second if the remaining fields are weak.

One practical response is to require a minimum amount of evidence before auto-merging. For example, a rule might prohibit automatic merges when fewer than two independent identifying fields are populated, sending those cases to review instead. This keeps recall intact while protecting precision in the sparse tail. Track the proportion of records that fall into this category, because a growing share usually signals an upstream capture problem rather than a matching problem.

Multi-Source Records and Survivorship Interactions

Multi-source matching adds complexity because the same entity appears in several systems with different update histories, identifiers, and trust levels. A record from a source with strong validation may be more reliable than one from a legacy system, and the matcher should reflect that in how it scores evidence, not only in how survivorship later chooses attribute values. Source-specific comparators or weights can address systematic differences, such as one source that always uppercases names or one that stores addresses in a different order.

Matching and survivorship are linked in ways that are easy to overlook. A match decision determines which records enter the same survivorship calculation, so a loose match configuration can contaminate survivorship outcomes that look correct in isolation. The relationship between the two steps is explored in matching and survivorship in MDM, and it is worth reviewing that interaction before finalizing thresholds for multi-source entities.

Source-level identifiers also need care. An identifier that is unique within one system may be reused across systems or may refer to different entities in different contexts. Before using a source identifier as a deterministic key, verify its uniqueness across all contributing sources, and document any known exceptions.

Testing and Validation: Building a Match Quality Framework

A matching configuration is only as credible as the evidence behind it. A match quality framework turns tuning from an occasional project into a repeatable discipline. It defines what is measured, how often, against which sample, and who decides when results are acceptable. Without that structure, teams tend to change configurations based on the most recent complaint rather than the overall error profile.

Building the Evaluation Set

The evaluation set is the foundation of the framework. It should be stratified across entity types, source systems, and score ranges, and it should be refreshed periodically so it reflects current data rather than the population from the first tuning cycle. Keep a held-out portion that is never used for weight or threshold fitting. Without a held-out set, you will overfit the configuration to the sample and overstate its quality.

Labeling standards matter as much as sample size. Write a short labeling guide that defines what counts as a match for each entity type, including how to treat parent-child relationships, branch locations, and discontinued products. Stewards who label to different standards produce labels that look like model error when they are actually inconsistency. Measure inter-steward agreement on a common subset, and resolve the guide until agreement is consistently high.

Defining Acceptance Criteria

Before running an evaluation, agree on acceptance criteria. These should specify minimum precision and recall for each entity type, maximum review queue volume, and any hard limits, such as zero automatic merges across distinct tax identifiers. Writing criteria down before results arrive prevents the common pattern of moving goalposts to fit the outcome. The criteria should be approved by the data owners who bear the consequences of errors, not only by the team running the matcher.

Your framework should also define regression tests. Any configuration change should be evaluated against the held-out set and against a fixed set of known difficult cases, such as pairs that previously caused incidents. A change that improves average precision but reintroduces a known bad merge should fail the regression suite, even if the aggregate numbers look better.

Structuring the Validation Cycle

A practical cycle runs in four stages: propose a configuration change with a stated hypothesis, evaluate it on the held-out set, review the error breakdown with stewards, and decide whether to promote, revise, or reject. The error breakdown matters more than the headline metrics. Two configurations with identical precision can have very different error profiles, with one making a few catastrophic merges and the other making many small ones. Stewards can often spot the difference immediately, and their judgment should inform the decision.

Document each cycle. The record should show the hypothesis, the evaluation results, the decision, and the rationale for any rejected alternatives. Over time, this log becomes the institutional memory of why the configuration looks the way it does, which is invaluable when staff change or when an auditor asks why a particular rule exists.

Common Pitfalls in Algorithm Configuration

Most matching problems I’ve encountered were not caused by exotic failures. They came from a small set of recurring mistakes, and recognizing them early saves considerable rework. The following pitfalls appear across organizations, sectors, and engine types.

Tuning on Unrepresentative Samples

A sample drawn only from recent records, or only from one source system, will produce a configuration that works for that slice and fails elsewhere. Historical records often have different quality characteristics from new ones, and some sources are overrepresented in any convenient extract. Stratify the sample deliberately, and check whether the configuration performs consistently across strata before promoting it.

Ignoring Transitive Matches

Matching is usually pairwise, but merges create clusters. If record A matches B and B matches C, the system may merge all three even when A and C would not match directly. Chains like this can grow into large clusters that contain several distinct entities, and the error appears only after the cluster is formed. Monitor cluster size distributions and set limits or review triggers for unusually large clusters. Clustering behavior should be part of your evaluation, not an afterthought.

Confusing Data Problems with Algorithm Problems

When a match fails, the cause may lie in the data rather than the matcher. A source system that truncates addresses, a feed that drops trailing characters from identifiers, or a standardization step that fails silently will all produce matching errors that no threshold change can fix. Before retuning, check the input values for the failing pairs. If the inputs are wrong, fix the upstream process, and treat the matcher as correct until proven otherwise.

Overreliance on a Single Comparator

Using one string comparator for all fields is a common shortcut. Edit distance suits identifiers and short codes, while phonetic or token-based comparators suit names and descriptions. Applying one comparator everywhere either over-matches or under-matches depending on the field. Choose comparators by field type and test each choice on the labeled data.

Treating Tuning as a One-Time Project

Source systems change, business rules change, and the population of records shifts. A configuration that was well calibrated at launch can drift into poor performance within a year without any change to the matcher itself. Schedule periodic re-evaluation, and treat unexpected changes in match rates as signals to investigate rather than as acceptable noise.

Hiding the Review Queue

Stewards who receive an unmanageable review queue will clear it by accepting whatever the system proposes, which quietly converts a review band into automatic merges with worse controls. Watch queue volume and steward decision patterns. If stewards approve almost everything in a band, that band is probably too wide, or the threshold is too conservative, and the configuration should be reviewed rather than trusted as a stamp.

Monitoring Match Quality in Production

Evaluation on a labeled sample tells you how the configuration performed at the time of testing. Production monitoring tells you whether it is still performing well now. The two work together: evaluation sets the baseline, and monitoring detects departures from it between evaluation cycles. Without monitoring, drift goes unnoticed until a downstream report or customer complaint exposes it.

Operational Metrics to Track

Track match rates by source system, entity type, and score band. A sudden shift in the proportion of records auto-merged, sent to review, or left unmatched is one of the most informative early signals. Track review queue volume and the proportion of queue items resolved as matches, since a changing approval rate may indicate that the population has changed or that stewards’ standards have drifted. Monitor cluster size distribution, flagging clusters above a set size for inspection.

Some signals require sampling rather than automated counting. Periodically draw a sample of auto-merged records and have stewards verify them. This is the only reliable way to estimate production precision, because the system cannot judge its own false merges. Similarly, sample records that remained unmatched and check for missed duplicates. Sampling is labor-intensive, so keep the sample size proportionate to risk, and increase it after configuration changes or source system migrations.

Setting Alert Thresholds

Alerts should fire on meaningful deviations from baseline rather than on normal variation. Establish the normal range for each metric from several evaluation periods, and set alerts at a level that would indicate a real change, such as a sustained shift in the auto-merge rate beyond the typical range. Alerts that fire constantly are ignored, so tune the monitoring itself, just as you tune the matcher.

Closing the Loop with Stewards

Monitoring findings should flow back into the configuration process. When sampling reveals a systematic false merge pattern, log it as a regression case, investigate the cause, and feed the case into the next evaluation cycle. When stewards repeatedly resolve a particular type of pair the same way, consider whether that pattern should become a rule. This feedback loop is what turns a static configuration into one that improves over time.

Reporting should match the audience. Data owners need precision and recall estimates with clear business consequences. Engineers need the detailed error breakdowns and configuration history. Governance committees need evidence that the matching process is controlled, documented, and reviewed. A single dashboard rarely serves all three, and trying to make it do so usually produces a report nobody reads.

Governing Match Rule Changes Over Time

Matching configurations accumulate decisions, and those decisions need an owner once the original team moves on. Assign a named data owner for the match rule set, separate from the engineers who maintain the matcher, and require that owner’s approval for changes to thresholds, weights, and deterministic rules. This separation keeps the people who bear the consequences of errors in the decision loop.

Connect the matching configuration to your wider reference data and policy artifacts. Ownership and approval definitions for reference data often live in a governance charter, and the data governance charter template can help you clarify who approves changes to shared matching logic. Where a data owner’s responsibilities are not yet written down, the data governance RACI matrix is a practical way to assign responsibility for each decision.

Retention and audit requirements also apply to match decisions. For regulated data, you may need to show why two records were merged at a given point in time, which means retaining the configuration version and the score breakdown for merged pairs. Plan that retention before you need it, because reconstructing historical match logic after the fact is very difficult.

If you are unsure how mature your matching governance is, the data governance maturity assessment gives a structured way to identify gaps in ownership, documentation, and monitoring before you commit to a tuning program.

The Bottom Line on MDM Matching Algorithm Tuning

Tuning an MDM matching algorithm is a calibration exercise, not a search for a perfect setting. Your configuration should reflect the evidence in your data, the costs your business attaches to each kind of error, and the controls your governance program requires. Deterministic rules handle the high-confidence cases with transparency, probabilistic scoring handles the ambiguous population, and thresholds set the boundary between automatic action and human review.

What I’ve seen matter most across programs is not the choice of algorithm but the discipline around it. Teams that build a labeled evaluation set, agree on acceptance criteria before testing, document every rule and threshold, and monitor production samples tend to keep their golden records trustworthy. Teams that tune reactively, rely on default settings, or treat thresholds as a fix for data quality problems tend to find their counts diverging from reality without knowing why.

If there is a single practice to start with, make it the labeled sample. It converts arguments about whether a match configuration is “good enough” into measurable questions about precision and recall, and it gives stewards and engineers a shared basis for decisions. Everything else in this article, from weighting to threshold selection to monitoring, depends on that foundation.

Frequently Asked Questions About MDM Matching Algorithm Tuning

What is the difference between precision and recall in MDM matching?

Precision measures the share of proposed matches that are actually correct, so low precision means distinct entities are being merged. Recall measures the share of true duplicates the system finds, so low recall means duplicates remain unmerged. Improving one usually reduces the other, so tuning means choosing a balance based on which error your business can least afford.

How do I know if my MDM match threshold is set correctly?

Measure precision and recall at several thresholds using a labeled sample of record pairs that stewards have reviewed. Plot the results as a precision-recall curve and choose the point where precision stays above your agreed floor for automatic merges. Validate the choice on a held-out sample before promoting it to production.

What is the difference between deterministic and probabilistic matching in MDM?

Deterministic matching declares two records a match when they satisfy explicit rules, such as sharing a verified identifier. Probabilistic matching compares several fields, scores each agreement or disagreement, and combines the scores into a likelihood. Most enterprise programs use deterministic rules for high-confidence cases and probabilistic scoring for the ambiguous remainder.

How should I assign weights to fields in a probabilistic matching configuration?

Derive weights from observed agreement rates in a labeled sample rather than from intuition. Fields that agree frequently among true matches but rarely among non-matches deserve higher weights. Configure missing values to contribute a neutral score, so sparse records are not penalized unfairly.

What causes false duplicates in MDM and how can I prevent them?

False duplicates usually come from loose thresholds, common names colliding, transitive chains that merge distinct entities, or weak fields carrying too much weight. Prevent them by setting a conservative automatic-merge threshold, requiring minimum evidence before auto-merging, monitoring cluster sizes, and sampling auto-merged records for steward review on a regular schedule.

How often should MDM matching rules and thresholds be reviewed?

Review them on a fixed schedule, and also after significant source system changes, migrations, or shifts in monitored metrics. The right interval depends on how quickly your data changes, but many teams re-evaluate at least once a year and whenever production sampling shows drift. Record each review and its outcome.

Can I improve MDM match quality without changing the algorithm?

Often yes. Many match failures originate in normalization, source data quality, or inconsistent identifiers rather than in the matcher itself. Standardizing values, fixing upstream capture problems, and verifying identifier uniqueness across sources can improve both precision and recall without altering the algorithm or its thresholds.

What is a good review band width for MDM match decisions?

There is no universal width. The band should capture ambiguous pairs that stewards can resolve, while keeping review queue volume manageable. Check steward approval patterns: if stewards approve nearly everything in the band, it is likely too wide, and if queues grow faster than they can be cleared, the band or threshold needs adjustment.