Reltio Connect

 View Only

Relevance-Based Matching vs. Traditional Matching: What is the Difference?

By Joel Snipes posted 03-13-2022 10:48

  
Relevance based matching is a recent Reltio feature that can help simplify your rulesets by allowing you to craft more flexible rules.

Everyone has experienced the problems caused by duplicate data. Two restaurant reward or frequent flier accounts leading to frustrating support tickets, forgotten logins, expired points and frustrated customers. A MDM practice with a thoroughly crafted set of match rules can solve this issue but as your practice improves, so does your match rule count.

Relevance based matching is a recent Reltio feature that can help simplify your rulesets by allowing you to craft more flexible rules. What previously took two or three rules to solve for can often be done in just one. 

Relevance-Based Matching vs. Traditional Matching: What is the Difference?

 

Our original matching paradigm, which I will refer to as binary matching, is completely logic-based. Every operand is evaluated to be true or false. Only by having each condition evaluate to true will a match be created.

In relevance-based matching, each operand evaluates to a numerically weighted score. If the final sum of the scores surpasses a user defined threshold, a match will be created.

In binary matching there are only two outcomes, there is either a match or not. Whereas in relevance based matching, there can be one or many outcomes. If the match score of two entities is between .5 and .7 you could set the result to a “weak potential match”, if it is between .71 and .85 you could set it to a “strong potential match”, and between .86 and 1 you could set it to an “auto match”. While only two outcomes are available (Automatic and Potential Match) the labels you use to describe them can be segmented as specifically as you like. 

Relevance-based matching, each operand evaluates to a numerically weighted score. If the final sum of the scores surpasses a user defined threshold, a match will be created.


The obvious question after learning of relevance based matching thresholds is “How are the scores calculated?”. By default every attribute is weighted equally with the highest possible weighting of 1. For example, say we are looking at customer data with the following attributes: 

  •       First name
  •       Last name
  •       Suffix
  •       Address Line one
  •       City
  •       State

Though each of these is weighted equality by default ,you can change the weighting of an attribute to make it less influential. For example, Last Name is generally a stronger indicator two individuals are the same than First Name, so you might set the weight of first name to .8 or the weight of Suffix to .5. Weights are not currently supported directly in the UI and must be defined via JSON in the advanced editor. Example below.

Though each of these is weighted equality by default ,you can change the weighting of an attribute to make it less influential.


While you are developing a new relevance based match rule it is best to set the type of all actionThresholds to “potential_match”. By doing so you can tune your thresholds without dealing with the difficulties of unmerging auto matches that should not have happened. Or in the inverse, if a user feels as though they’re under-matching with a threshold set to 80%, they can drop down to 75% or 70% to get more results. Once you're comfortable with the performance of your rules then you can return your actionThreshold to the “auto_merge” with confidence. 

You probably noticed there are many commonalities between the two systems of matching, such as the tokenizing of attributes, comparator classes, and dictionaries. Relevance based matching allows you to manage a smaller set of rules with more dynamic outcomes. In my next blog I’ll dive into the actual configuration and testing of relevance based match rules.

Watch the Reltio Community Show: Relevance-Based Matching: 

 

 


#Matching
#Relevancebasedmatching
#Featured
0 comments
6256 views

Permalink