Match Criteria

The match criteria are responsible for matching records against each other to find those that match. When users are only interested in exact matches, the match criteria are reasonably straightforward.

If the SSN (Social Security Number) for two customer objects or the EAN (European Article Number) for two product objects are identical, the records are likely duplicates and the matching criteria should return 100 percent. If the SSN or EAN does not match, the match criteria should probably return 0 percent.

In many cases you cannot work with exact matches; instead, you will deal with approximate matches or a combination of exact and approximate matches. For example, for a customer you do not have a SSN available so you will identify duplicates based on names, mailing addresses, phone numbers, and street addresses. For a product, you will identify duplicates based on the manufacturer and manufacturer part number.

This data can have variations, even in objects that represent the same real-world entity. Names and addresses can be spelled differently, middle names could be omitted, abbreviations can be used in names and addresses, the customers could be registered with different phone numbers or mailing addresses, and other options that introduce ambiguity to the records.

This complexity can be handled via a decision table in the match criteria logic, which further divides the functionality into normalizers, matchers, and rules.

Match Criteria Tab

The Match Criteria tab defines how to compare two objects and evaluate to what degree they are similar. It is separated into the following flippers:

Other Match Criteria

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

Important: Create new match algorithms with embedded match codes as defined in the Configuring Matching Algorithms topic here.

Match code generators are only available when match codes are not embedded into the matching algorithm. For more information, see the Match Codes topic here.