Data 360 identity resolution: measure the downstream impact of errors

A successful identity-resolution job can still put the wrong customer’s history in front of an agent. Completion tells you that processing finished. It doesn’t tell you that every merge was correct, or that the resulting profile was safe to use.

To measure the downstream impact of an identity-resolution error, trace affected source records through their unified profiles into the segments, activations, and agent actions that consumed them. Count verified outcomes separately from potential exposure. A suspicious profile that never left a test segment is different from one used in a customer message.

The match-rule guide covers how profiles get combined. This article starts after a suspected mistake, when you need to decide what to pause, what to repair, and how to prove the repair worked.

Separate processing failure from an incorrect match

Salesforce’s ruleset processing reference distinguishes failed jobs from successful jobs with warnings. Warnings can mean some records were skipped or filtered. During processing, profiles from the last successful publish remain available.

Record the last successful job, the warning or error state, source record counts, unified profile counts, and the ruleset configuration in use. Preserve the observation time. If you only save today’s totals, you may lose the evidence needed to explain what a downstream system read yesterday.

For a completed job, inspect both directions of matching error. Over-merging combines different people. Under-merging leaves one person’s records split across profiles. A third problem is attribute selection: the people may be matched correctly while a stale address or account attribute wins reconciliation.

Salesforce defines consolidation rate as 1 - unified profiles / source profiles. That measures how much records were combined. Treating it as an accuracy score rewards aggressive merging, including the wrong merges.

Build a trace from source record to business action

Create a restricted investigation dataset. For each suspected case, preserve the source system and source record ID, the unified profile ID at the time, the ruleset, and the downstream operation’s identifier and timestamp. Retain only the fields the investigation requires.

Salesforce’s unification walkthrough describes unified profiles and the link objects connecting source records to them. Use those relationships to identify contributing records. Don’t join on a person’s name or email as a shortcut; those fields may be what caused the error.

Then follow the consumers your implementation uses. A marketing segment may produce an activation that creates a send. An Agentforce action may retrieve a profile, populate a response, and update a case. Save the IDs connecting those operations when you have them, and mark gaps in the chain explicitly.

Track four measures, with a defined time window and denominator:

• Confirmed incorrect merges divided by reviewed merges in the investigation sample.
• Confirmed missed matches divided by known same-person pairs reviewed.
• Distinct affected records used in downstream operations during the incident window.
• Verified incorrect sends, disclosures, or updates attributable to those records.

The first two describe your reviewed sample. They estimate wider accuracy only if the sampling method supports that inference. Reviewing the largest clusters is useful for finding severe failures, but it doesn’t produce an unbiased error rate for the whole customer base.

Compare the decisions before counting the money

Recompute the affected segment or decision against corrected identity data in a controlled environment. Keep its business filters unchanged. Compare membership using stable source identifiers, because unified profile IDs can change when groups split or recombine.

For example, suppose a test finds that 18 source contacts would leave a renewal segment after a match-rule correction. Those 18 are changed memberships. If delivery logs show that four received the wrong offer, record four verified incorrect sends. These are illustrative numbers, not a customer result or a platform benchmark.

Compare the selected contact point and consent decision as well as membership. A segment can contain the right person while an activation chooses the wrong destination. Your segmentation and activation checks should follow the record through that last step.

Keep cost categories separate. Verified duplicate message charges, documented support effort, and refunds can be measured from records. Potential lost revenue needs an explicit model and assumptions. Multiplying every affected profile by average customer value overstates what the evidence proves.

Repair the consumer as well as the profile

Pause the affected activation or action when the error can keep spreading. Preserve the relevant configuration before editing it. Correct the source data, match rule, or reconciliation rule responsible, then validate known positive and negative identity pairs before resuming the consumer.

Re-running unification doesn’t recall an email or undo a completed CRM update. Review the downstream operation log for work that needs correction. Use the action’s idempotency controls when replaying work so recovery doesn’t create a second side effect.

For Agentforce, test an action with the corrected identity, an ambiguous identity, and a caller who lacks access to the record. The action should require the verified customer relationship and applicable access checks before disclosing history. A unified profile ID alone isn’t authorization.

Close the incident when the affected consumer passes those checks and the responsible owner accepts the remaining exceptions. A green ruleset job is one piece of evidence. The corrected customer-facing outcome is the result you need to demonstrate.