Matching use cases

This topic provides some insight into how matching occurs when party profile feeds are ingested into Redpoint CDP.

For the purposes of this topic, assume that…

• name = first name + middle name + last name

• address = address 1 + address 2 + city + state + zip

• email = email address

• phone = phone number

Furthermore…

• When 2 or more records have the same name and source_party_profile_ID without matching PII, then the CDP generates the same individual and household IDs. They match due to the same source_party_profile_ID on both records.

• When 2 or more records are passed with email address only, then the CDP generates the same individual and household IDs if the email_only match flag is set to Y.

• When 2 or more records are fully duplicated based on PII, only one record will pass through matching. This includes custom match and social login fields, too.

• If all “Match Fields” are same for 2 or more records, then one record is reported as a duplicate, and the other gets processed through matching to load into Redpoint CDP.

• Anonymous records (records that don’t have the minimum PII) are removed from the matching process. This includes custom match and social login fields, too.

• If social_login fields are populated and they are same across the platform, then they will match to the same individual and household (assuming no other PII fields are populated). In general, social_login fields are used for the matching criteria, and not the combination of social_login + social_platform fields together.

• If custom_match_attribute field(s) are populated with PII, then custom_match_attribute (across 1 to 5) will be used for matching. custom_match_attribute_name fields are not part of the matching criteria.