About Match Cascades

The Match endpoint first uses data normalization to structure data variations (for example, in street types (“Boulevard” vs. “Blvd” vs. “Boulv”) and then converts each component into a hash. Fuzzy matching is then used to compare the hash to the obfuscated data in the identity graph following a match cascade.

The match cascade determines not only the order or priority of the types of matches that are attempted, but also which steps are performed. For example, the default match cascade does a name+zip matching, but the strict match cascade does not. The cascade is determined by the matchLevel parameter.

For example, the obfuscated name, street address, and zip code are compared. If there isn't a match, the obfuscated name and email address is compared, before moving on to the next steps in the match cascade.

For each API call, you can choose either the default match cascade, which uses all possible match steps, or the strict match cascade, which skips some of the match steps in the default match cascade.

If the number of maintained AbiliTec IDs requested in the API call is “1”, the comparison is stopped as soon as a step in the match cascade results in a maintained AbiliTec ID. That AbiliTec ID is then returned along with data about the match.

If the number of maintained AbiliTec IDs requested in the API call is greater than “1”, the comparison in the match cascade continues until either the requested number of AbiliTec IDs are found or all the steps in the match cascade are completed, whichever comes first.

If a maintained record doesn’t exist in the identity graph for any of the PII touchpoints in the match cascade, a derived AbiliTec ID is generated and returned for the input data.