Troubleshoot Identity Resolution Ruleset Processing Errors

During the match and merge process, identity resolution expects every contact point record to have a unique combination of record ID, data source ID, data source object ID, and key qualifier. When the process runs into records with the same combination of these four fields, it only considers the first contact point record it finds during matching. Other contact point records with matching attributes are skipped. The record used for matching is selected arbitrarily, which can impact matching.

To resolve this error, groom your data at the data source or using data transforms to eliminate or repair poor quality data.

The external data lake object wasn't accessible when the ruleset tried to run.

If the external data lake object isn't accessible because of an authentication error or other problem, try fixing it. Otherwise, edit the ruleset's match rules and reconciliation rules to remove references to the external data lake object.

During matching, the combined character limit of all values in all fields included in a match rule can't be greater than 500 characters. During the matching process, if the combined vales of fields being matched exceeds 500 characters, some values or parts of values are truncated. Mismatches can result because matching is based on truncated values.

For example, supposed a match rule uses the Exact Phone, Exact First Name, and Normalized Email Address fields, the combination length of the record's phone number, first name, and email address can't be greater than 500 characters.

Long values are commonly caused by formatting errors in source data. If you imported data from a CSV file, long streams can be created when incorrect formatting makes several records run together.

Identity resolution can't combine more than 50,000 records into a single unified profile. Any clusters with more than 50,000 records are split into multiple unified profile records. To determine why large profiles are being created, consider these things:

• Are any match rule criteria allowing matches on blank fields? If so, consider changing your match rule criteria to disallow matching on blank values. Or, groom your data at the data source or using data transforms to eliminate or repair poor quality data.
• Are default values being entered into fields in your data source? For example, if a phone number is missing, are users or processes entering a placeholder value such as 000-0000?
• Are your match rules too broad? Match rules can be narrowed by adding more criteria or using more strict match methods.

If the string "null" is present in any of the following contact point record fields, the contact point is skipped during matching.

• The ssot__EmailAddress__c field on the ssot__ContactPointEmail__dlm object
• The ssot__FormattedE164PhoneNumber__c on the ssot__ContactPointPhone__dlm object
• The ssot__AddressLine1__c, ssot__CityId__c and ssot__CountryId__c fields on the ssot__ContactPointAddress__dlm object
• The ssot__AdvertiserId__c field on the ssot__Device__dlm object
• The ssot__IdentificationNumber__c field on the ssot__PartyIdentification__dlm object
• The ssot__Id__c field on the ssot__ContactPointApp__dlm object
• The ssot__SocialHandleId__c field on the ssot__ContactPointSocial__dlm object

If the string "null" is entered into a custom field that's used by match or reconciliation rules, or if "null" is entered into any field in the ruleset's primary data model object, it's converted to an empty string.

To avoid triggering this error, groom your data at the data source or using data transforms to eliminate or repair poor quality data.