Match Criteria

The match criteria are responsible for matching records against each other to find those who match. In some cases, users may only be interested in exact matches. In these scenarios, the match criteria would be reasonably straightforward.

Suppose the social security number for two customer objects, or the EAN number for two products, are identical. In that case, these are likely duplicates, and the matching criteria should return 100%. If the social security number does not match, the match criteria should probably return 0%.

In many cases, however, you cannot work with exact matches; but instead, you will have to deal with approximate matches or a combination of exact and approximate matches. For example, you do not have a social security number available. You will have to identify duplicates based on names, mail addresses, phone numbers, and street addresses. You will need to identify the product based on the same manufacturer and manufacturer part number information for products.

These pieces of data can have variations, even in objects that represent the same real-world entity. Names and addresses could be spelled differently, middle names could be left out, abbreviations could be used in names and addresses, the customers could be registered with different phone numbers or mail addresses, and myriad other options that introduce ambiguity to these records.

Because of this complexity, the match criteria's logic is most often represented in a decision table, which not only depends on match codes but further divides the functionality into normalizers, matchers, and rules.

Overview

The Match Criteria tab contains how to compare two objects and evaluate to what degree they are similar. It is separated into sections:

• Data Elements: This section contains the data elements that the matchers and match code generators evaluate. The data elements present data in a form that is easy to compare, which often includes normalization in some form.
• Matchers: This section contains the field-level comparison logic and is where to specify exactly how to match two company names.
• Rules: Rules determine how field-level matchers resolve if two objects are a match or not.
• Match Code Generators: When dealing with datasets of thousands or millions of objects, comparing every object with every other object is not a viable solution. To identify the records that should be compared, match codes must be generated for the applicable objects. Only records with at least one equal match code are then evaluated via rules.
• Match Code Filter: This component allows users to filter values that meet criteria set on a Transformation Lookup Table
• Evaluator: This section is used to test the comparison of two objects.

Other Match Criteria

For match algorithms without embedded match codes, several legacy options exist for match criteria.

It is recommended that all new match algorithms are created with embedded match codes.

When match codes are not embedded into the matching algorithm, match code generators are not available. For more information, see the Match Codes topic in this documentation here.