Matching rules

Overview

Before creating a Golden Record from multiple data sets, Helix must first determine which records from the various data sets refer to the same person. The matching rules define the criteria used to decide when two records belong to the same person. Power users can customize the rules; other users may only view them. The matching process runs nightly.

How rules work

Select the Matching Rules tab to open the interface. On the left side, you'll see the fields and groupings you can use to create rules. On the right side, you'll see any existing rules. Each rule consists of one or more criteria. Those criteria specify which fields to compare and how to compare them.

When Helix runs the matching process, it takes two records and compares them using the first rule. It uses the field mappings to determine which fields from the source data to compare. If all of the rule's criteria are satisfied, then the rule is met and the two records will be used to combined into that individual's Golden Record. Otherwise, Helix proceeds to the next rule, and so forth. If none of the rules are met, Helix concludes that the records are for different individuals.

When using a group in the match criteria, only one field from each record needs to match.

Create or edit a rule

Click + New Rule to add an additional rule to the list. Enter a name for the rule. Next, choose at least one field or grouping to use in your criteria. Find it in the left column, then click and drag it into the new rule.

To change an existing rule, you can drag new criteria into the rule and remove existing criteria with the x button. To remove a rule entirely, use the trash can icon.

When finished, click the Save button.

Criteria match types

For each field or grouping you add, open the drop-down list next to it within your rule and choose the type of match you wish to use. Most criteria use "exact" or "fuzzy" matches:

• Exact: The two fields must contain the exact same value, except for capitalization and leading or trailing spaces. For example:
  • "MacArthur" will match "Macarthur" or "MacArthur     ", but not "McArthur" or "Mac Arthur".
  • “Muhammad” will match "MUHAMMAD", but not “Mohammad”.
  • "404-555-0199" will not match "(404) 555-0199".
• Fuzzy: Helix will apply KORE's logic to determine when two different values are likely to represent the same thing. For example:
  • "Mac Arthur" and "Mac-Arthur" will match "MacArthur" since all whitespace and formatting are removed before comparing.
  • “Muhammad” will match “Mohammad” since it's a very common variation of the spelling.
  • "Bob" will match "Robert" since it's a very common shortening of the name.
  • "404-555-0199" will match "(404) 555-0199" since all formatting is removed before comparing.
  • "404-555-0199 x101" will match "404-555-0199 ext 101" since alpha characters are considered part of the formatting and are dropped before comparing.
  • "404-555-0199" will not match "404-555-0199 x101" since the extra digits for the extension are not dropped before comparing.

The Email field can use "exact" matches or two other types:

• Domain: Helix ignores the username portion of the email address. For example:
  • "sportsfan@example.net" will match "hockeyfan@example.net".
• Without Domain: Helix only compares the username portion of the email address. For example:
  • "sportsfan@home.example.net" will match "sportsfan@company.example.net".

Best practices

KORE's best practices for configuring the matching rules will depend on your use cases for helix and the specific business practices of your organization

Use case 1

Using Helix as a master data management solution to create golden records from the PII data across all of the platforms that interact with customers (this scenario should cover nearly all Helix users).

Questions you should consider when setting up your matching rules:

1. Do we want to have strict matching rules that may not always group all of the records together and result in potentially having more than one golden record grouping for the same fan? Or do we want to have looser rules may result in larger golden record groups that consist of multiple individual fans being flagged as the same person?

   1. If you want to error on matching more records together than should be then you should use simple criteria in your matching rules. An example would be matching on just group email without domain.

   2. If you want to error on matching less records together then you should add more criteria to your matching rules. An example of this would be to add criteria for name or phone number along side group email exact match.

2. Do we want to consider families / relatives who share contact information (i.e., email, phone number, address) as one marketable golden record or many individual potential customers?

   1. If you consider families / relatives as one golden record than using single criteria matching rules with group email or group phone number is ok.

   2. If you consider families / relatives as separate customers and therefore separate golden records then you should add first name to the matching rule criteria.

3. Does you business practices that require specific fields to be filled out (i.e., email, phone number, etc.)? Or do you have many customers who submit generic work email address and phone numbers (without extensions)?

   1. If this describes your data then you will likely form inaccurate and extremely large golden record clusters by using the group email as your only matching criteria for a given matching rule unless you have already cleaned up your data to remove those values.

Use case 2

You already have a master data management solution that creates golden records and you only want to leverage Helix as a marketing tool to build tags, attributes and audiences.

Without Helix to CRM sync

If you are not using Helix to perform MDM and create golden records than you should only have one Helix data source which is pointed to your golden record table within your database. In this case you should create a single matching rule with exact matching on the primary key / ID field.

With Helix to CRM sync + KORE PSS Ticketing module

If you are using the KORE PSS Ticketing product along side Helix and the Helix to CRM Sync then you will need to add a second Helix database connection and Helix data source that is connected directly to the KORE PSS Ticketing database. You will also need to add the CRM ID to your original Helix data set (with the golden records) and create a second matching rule on CRM ID. It is important that this is a second matching rule and not an additional criteria of the original rule. In the example below this is represented by the field KORE ContactID which is the CRM ID.

 

With Helix to CRM sync and without KORE PSS Ticketing module

If plan on using the Helix to CRM sync feature and you do not have the KORE PSS Ticketing product then KORE recommends that you create a second Helix data set that uses the CRM ID as the primary key and add an additional rule to your matching rules to match on CRM ID. This assumes that the original Helix data set uses a primary key that is a golden record ID and not the CRM ID.

The Helix to CRM Sync feature will use the field you have selected as the primary key of your CRM data set when determining when it should update an existing CRM record or when to create a new CRM record. Therefore if you do not want the Helix to CRM sync to create new records in your CRM and instead you only want Helix to update existing CRM records then you should update your original Helix data set to use the CRM ID as the primary key and not the golden record ID.

General recommendations

Using “grouped” fields whenever possible will increase your match rate. Examples of common fields to group are all email fields into the group email and all phone numbers into the group phone number.

Be intentional when using a signal criteria in a matching rule. Some fields are worse off by themselves, such as email domain, zip code, state, etc.

Anti-pattern rules to avoid

Generic Rules built around fields that tend to have generic values can potentially create false positive massive grouping. This happens when you have a lot of fans using a generic company name, email and/or work phone. If this is common in your data then KORE recommends cleaning these values by replacing them with a NULL value as outlined in the section above.