Match and merge rules MDM platforms rely on decide two things: first, which records represent the same real-world entity (matching), and second, when conflicting values exist across those records, which value survives in the golden record (merging). Get the matching wrong and you either miss real duplicates or incorrectly combine two different entities; get the merge rules wrong and the resulting golden record is technically deduplicated but factually unreliable.
Matching: deterministic vs probabilistic
Deterministic matching relies on exact matches against strong, reliable identifiers — a national ID number, a VAT number, an internal account ID — and is highly accurate but only works when that identifier is present and consistent across sources. Probabilistic matching scores similarity across multiple weaker fields — name, address, phone, date of birth — using weighted algorithms, which catches matches deterministic rules miss (typos, formatting differences, nicknames) but requires careful tuning to avoid false positives.
Merge: survivorship rules
Once records are matched, survivorship rules decide, field by field, which source’s value wins. Common approaches include most-recently-updated wins, most-trusted-source wins (a regulatory system might always beat a self-service web form), and most-complete-record wins. Sophisticated MDM programs mix these — recency for contact details, source-trust for identity fields, completeness for optional attributes — rather than applying one blanket rule across every field.
Why this needs ongoing tuning
Match and merge rules aren’t a one-time configuration. As new source systems get added, data volumes grow, and edge cases surface — two legitimately different customers who share a name and address, for instance — the rules need review and adjustment. Programs that treat match/merge as “set once” typically see match quality degrade over 12 to 18 months as the data landscape shifts underneath the original configuration.
Where Agilus fits in
Agilus configures and tunes match and merge logic as a core part of every MDM implementation, including a validation phase where proposed matches are reviewed by business stewards before merge rules go live in production — this catches mismatched logic before it corrupts the golden record rather than after.
Testing match and merge rules before go-live
Before match and merge rules MDM configurations go into production, it’s worth running them against a representative sample of real, messy source data rather than clean test data — test records built to validate the happy path rarely surface the edge cases that cause problems later, like two customers who share a name and a street address, or a product code that was reused years apart for two different items. A structured validation phase, where a sample of proposed matches is reviewed by business stewards who know the data, catches both false positives (wrongly merged records) and false negatives (missed duplicates) before they reach production and become far more expensive to unwind.
It also helps to build a feedback loop from the start: a simple way for stewards to flag a match they believe is wrong, that routes back to adjusting the underlying rules rather than just manually correcting that one record. Programs without this loop tend to accumulate a growing list of one-off manual corrections that mask an underlying rule problem, instead of fixing the rule itself — which means the same wrong match keeps recurring every time similar data comes through.
FAQ
What’s a false positive match, and why does it matter?
A false positive is when the system incorrectly merges two different real-world entities into one record — for example, combining two different customers who share a name. It’s more damaging than a missed match because unmerging records after other systems have consumed the bad golden record is far harder than catching a missed duplicate later.
Can match and merge rules be different for different data domains?
Yes, and they generally should be — customer, product, and supplier data each have different identifier reliability and risk profiles, so most MDM programs configure separate rule sets per domain rather than one universal rule set.