Matching, Merge, Survivorship and Match Rules

Take a look at our updated Matching resources page

Reltio Matching

Matching, Merge, Survivorship and Match Rules

👆Search the Reltio Community ABOVE or scroll below for any Reltio Matching, Merge, Survivorship and Match Rules Questions👆

This page provides comprehensive information on Reltio Matching, Survivorship, Match Rules, and Merging through a collection of questions, blogs, and how-to guides sourced directly from the Reltio Community. Our aim is to simplify the search process and make it easier to find relevant content on Reltio Matching, Merging, and Survivorship.

Reltio Community blogs on Matching, Match Rules & Merging (Take a look at our updated Matching resources page Reltio Matching

Anatomy of a Match Rule
The match rules for your Reltio tenant will control how profiles get identified as matches, and if they match, whether to merge them automatically or send them for review by a data steward. Before creating your match rules, think about what is needed to identify two profiles as a match.

How A Data Steward Uses Reltio to View and Manage Matches
If you have read the previous blog on matching, you will know that there are two types of match rules in Reltio: Automatic and Suspect. When an automatic match rule is triggered, the records are merged automatically. Automatic match rules are used when confidence about the match is high, so no human intervention is needed.

Reltio Master Data Management Match Rules - FAQ's Part 1
As a Senior Technical Consultant, I get asked a lot of the same questions over and over. In this blog, of two, I will focus on FAQ’s around Matching Rules. Survivorship and Match Rules are tightly coupled in terms of their actual use, but for this blog post, I will focus on Match Rules and return to survivorship later. Let us start with some easy questions about how they are implemented.

Reltio Master Data Management Match Rules - FAQ's Part 2
In the first part of our blog on Match Rules, we covered an overview of Match Rules and how they work. Now let us dive into the options available to you in implementing a match rule.

Match Tuning Best Practices: Data Profiling and Analysis  
Reltio Master Data Management’s purpose is to consolidate thousands of profiles and data sources to a cloud-native, user-friendly system that ultimately helps businesses run smoothly. Match Tuning’s purpose is to ensure that consolidation happens in an effective and efficient manner.

Effective Match Tuning: Design and Implementation
Match tuning is the iterative process of developing match rules while minimizing bad matches, maximizing automation, and preserving system performance. Match tuning is performed using a three-step process, that I call the match tuning life cycle.

Rule-Based Matching: Matching Anatomy
Before diving into the anatomy of a good match, it’s worth summarizing a previous webinar on match tuning best practices. In this webinar, we discussed the match rule life cycle and its three stages; data analysis and profiling, design and implementation, and testing and tuning. 

The Rule-Based Matching Process
To view these APIs in real time, be sure to tune into the webinar and watch our presenter, Suchen Chodankar, perform many of the aforementioned processes. For example, he starts in his Reltio tenant with zero records available. He uses the data modeler to review the list of rules available. In this example, he has five rules. 

The Rule-Based Matching Process Continued PLUS Configuration Examples
Another way to look at data tokenization is to consider each record an entity, and picture the tokenization rules forming multiple buckets. For our purposes, we will refer to entities as E1, etc. When E1 is loaded, it goes through the tokenization process.

Q&A - Click the link to get entire answer

  • Match/Merge rule best practices - Hi everyone - Can you share Match/Merge best practices? What features have you enabled to improve the quality of the suggested matches?
  • Keyword based Survivorship - Does Reltio has any survivorship method which allows a value having specific keyword/character to become master value?
  • How are others dealing with Match and Merge ID's and OV values of attributes? - We have a broad mix of systems getting customer master data. How those systems will deal with match & merge ID's and the OV values of the attributes is a challenge. Reltio OV logic is also limited but we don't want to customize logic for this. What are others doing in this area? I would like to know best practices and how other big organizations are tackling this challenge.
  • Survivorship based on condition - I want to implement a solution where i want value for an attribute to win based on a condition. Can the team help here? 
  • Way to exclude entities from matching if not a match is set to ANY_MATCHING_ATTRIBUTE? - If we update the physical configuration so that the not a match is reset for 'ANY_MATCHING_ATTRIBUTE' is there a way to prevent two entities from being matched even if one is updated? Basically we would want the default behavior to be that records would be re-evaluated if matching fields are updated (in case there isn't enough information for a definitive decision) , unless a steward already determined the two records were distinct and don't need to look at the records again.
  • DTSS Match Configuration - Does anyone know if you can specify for the pre-defined DTSS match rules, which rules are auto and which rules are suspect? I find the documentation to be very confusing because in one place it says that all matches are potential matches between the DT and CT, which would not seem very efficient and introduce a huge workload of adjudicating millions of potential matches.
  • Ability to get 'Not A Match' export from Reltio - In the UI you can see when 2 profiles have been stewarded and selected as 'Not A Match'. Is there a way to get this information out of Reltio, to see Reltio_uri_1 not a match Reltio_uri_2?
  • Match Rules are not triggered after they are changed - The OOTB match rules for the Reltio Accelerators (Account 360, Identity 360 etc) are provided as a starting point for developing your own match rules. Use or modify those that support your business requirements, delete those you don't need . They are designed to handle some common scenarios for matching e.g. Contact First Name, Last Name and email address are the same. In order to prevent accidental merges, the OOTB match rules are mostly set by default to "Suspect".
  • Can someone help me understand token generation better? - Let me talk about what a match token is first. A match token is basically a shortcut to prevent comparing one entire data set to another and go ahead and reduces it to likely matches so that there's a smaller set to compare. And it does that by taking the most identifying attributes and stringing them together into what we call a token, and when those tokens match, it then considers the other attributes not in a token.,,,,
  • Is there a limit on number of matching rules that can be used in parallel? - There is not a hard limit, but best practice is generally you want to keep it under 10 per entity type. Every match rule should have a strong identifying attribute at the center of it. And maybe you could have two versions or three versions for some of these, but it's rare to have 10 plus identifying attributes that could drive different matches. And if you have 10 plus rules, go ahead and configure them.....
  • What is the difference between relevance based match and Match IQ and what are the best practices - Relevance-based matching, let's talk about how it is different from the automatic and the suspect rule matches that we have, or match rule types that we have. Automatic and suspect match rule types are more of a binary output rules. When you put some instruction in one of these rules type, the result will always be either true or false, whether it matched or it did not match. If it did match, then it basically goes and perform the action that is tied to that rule type...
  • Which is a better comparator class, Cleanser for "Country" Attribute? - Is Match token necessary for Country Attribute?  Answer: Country attribute is one good candidate for match attribute. If your requirement is that I will never, ever match my records from US with records from, say, France, then country attribute is a good match attribute because what you're doing is you are making sure that the France record and the US record will never be in the same bucket.


Still can't find what you are looking for? Login to the Reltio Community