Additional Information Regarding the Comparison Process

You will have a better understanding on how match candidates are compared by getting a deeper insight about the comparison process.

Multiple Values in an Attribute

It’s important to remember that with the Reltio architecture, an attribute will typically hold multiple values, each sourced from a contributing crosswalk, resulting from one or more merges. Suppose for First Name, Profile A has values of Bill, and William, while Profile B has values of Willy, William, and Will. The comparison process intrinsically is designed to test each value from Profile A against each value of Profile B. In this case that will produce 2x3, 6 possibilities for a positive evaluation of that attribute.

Here is a screenshot taken from the Sources view of a profile, illustrating how the Name field for this organization contains a variety of values, accumulated during many merges.

Comparing only the OV of the Attribute

It is quite possible and likely that within an attribute, only one of the values it contains is deemed to be the operational value (OV). This means when any normal call to retrieve the attribute’s value occurs, just the OV will be returned, rather than the multiple values the attribute is holding. IQVIA is the OV in the example above.

The combinatorial approach (2x3 = 6 in our example above) has its benefits but for most customers’ needs, it is desirable to restrict comparison to just the operational value (OV) of the attribute. If this makes sense from a business perspective, it will often reduce the number of combinations and improve performance. You can achieve this by including the setting of useOvOnly = true in your match group which is recommended. Continuing with our example, if the OV of Profile A is William, and the OV of Profile B is Billy, then instead of a 6-way test, there will only be a single test of William against Billy. That said, whether this test produces a positive or negative match will depend on the match strategy designed for this match group. For example, use of the NamesDictionaryCleanser will cause William and Billy to be considered nicknames of one another and will result in a positive match outcome.

Note: The setting of useOvOnly is recommended and is set at the match group level, thus it applies to the whole rule, meaning it affects all attributes in the rule.

Case Insensitivity During Comparison

The Reltio match engine performs all match evaluations in a case-insensitive manner.

How Comparison Operators rollup to rule level

How does the test for similarity at the attribute level rollup to one directive of the three possible directives at the rule level? That depends on the type of matching you have chosen to use for the match group.

  • automatic or suspect rules

    In either of these types of rules, each Comparison Operator within the rule will evaluate to TRUE or FALSE. The outcome of the rule is the boolean algebraic sum of the Comparison Operators. For example, if you have a simple rule that indicates a logical automatic‘AND’ of (Fuzzy(First Name, Last Name), Exact(AddrLine1), then there are three comparisons taking place. In order for the rule to evaluate to TRUE, all three comparisons must evaluate to TRUE.

  • relevance_based rule

    With this type of rule, the directive coming from the rule is based on a score calculated from an algorithm specified by you using weights and actionThresholds within the rule. For more information, see Relevance-Based Matching - Detailed Explanation.