Benchmark identity repair by evidence preservation, not duplicate rate

Duplicate rate is an attractive data-quality metric because it is easy to explain: count suspected duplicate profiles and divide by the relevant population. It is not enough to judge identity repair. A low rate can mean that matching rules miss difficult duplicates, while a high rate can reflect a deliberately broad candidate detector that sends uncertainty to review. RevOps needs a measurement design that follows evidence from candidate creation through merge, downstream reconciliation and any later correction.

Intercom's September 28 changelog provides a useful operating boundary. The product can preview what will move, restrict merging with a teammate permission and expose a REST API in Preview. These controls create observable stages: candidate, review, approval and execution. The organization can measure those stages without pretending that Intercom publishes a universal quality benchmark. The purpose is to build an internal baseline tied to the team's own identity rules and customer consequences.

Start with candidate precision. Select a sample of pairs produced by each rule and have an accountable reviewer classify them as same person, different person or unresolved. Report each matching rule separately. Exact email, shared phone, external customer ID, normalized domain plus name and fuzzy attribute combinations have different risk. One overall percentage hides the rule that creates most of the false matches.

Next measure evidence completeness before approval. A merge candidate should include the source and destination identifiers, account associations, verified contact points, relevant external IDs, activity ranges, consent or preference context and the reasons the detector proposed a match. Score the packet by required evidence present, not by the number of populated fields. A field has value only when its meaning and authority are known.

Measure conflict rate as its own signal. Count candidates where stable identifiers disagree, account associations conflict, two current owners claim the profiles or high-impact attributes have incompatible authoritative values. A conflict is not a failed review. It is a correct reason to stop automation. The useful trend is whether upstream systems and matching logic reduce recurring conflicts over time.

After execution, measure survivorship correctness with a sampled post-read. Confirm that the intended destination exists, expected conversations or tickets are visible, required attributes match the approved choice and the source profile no longer participates in normal workflows according to the product's observed behavior. Keep platform success separate from business verification. The API or interface can report completion while a connected destination remains stale.

Add downstream reconciliation coverage. List the systems and jobs that can observe a customer identity change: CRM, support, product, lifecycle, warehouse, billing, customer-success and analytics. For each high-impact merge, record which destinations were checked, which re-evaluated derived state and which held customer-facing action. The coverage rate is the share of required checks completed, not the share of integrations that returned no error.

Amplitude's survey export shows why this layer matters. Selected user properties now appear beside responses and in CSV exports, subject to Data Access Controls. A merge can affect which context an analyst sees even when the response itself is unchanged. A reconciliation test should verify the person-to-account grain, property source and export timestamp for a small sample after identity repair. The goal is not to audit every file forever; it is to prove that the new identity model reaches a representative downstream use safely.

Hightouch's audience-membership trait adds derived-state reconciliation. Membership should usually be recomputed from the surviving identity and current source data rather than copied as if it were an intrinsic attribute. Measure the number of memberships that changed after repair, the age of the source evaluation and any destination sync exceptions. A change is not automatically an error. It is a result that deserves explanation when it can trigger communication or eligibility.

Correction cost is another essential layer. Count reversed merges, manual destination fixes, customer-facing actions recalled, analyst files regenerated and operator hours spent reconstructing a decision. Do not use the metric to punish reviewers. Use it to price the risk of aggressive automation and to decide which matching rules should stay manual. A small number of expensive corrections can outweigh a large amount of fast duplicate removal.

Build cohorts by rule, source system and consequence. A duplicate generated by repeated web-form submission has a different risk profile from two records that represent a contact who changed employers. A support-only profile merge has different consequences from a merge that controls billing, entitlement or renewal outreach. Cohorts let the team expand automation where evidence is strong without forcing one policy across every identity pattern.

Avoid inventing a target from external percentages. The official sources used here describe product capabilities, not comparable cross-company merge performance. Establish the baseline from recent internal cases, publish the exact definitions and improve one failure mode at a time. A useful scorecard can show candidate precision, unresolved share, conflict rate, evidence completeness, verified survivorship, downstream coverage, correction rate and median exception age.

Close the loop by connecting failures to design changes. False positives should change a matching rule or required evidence. Missing destination checks should change the release checklist. Repeated audience surprises should change recomputation or hold logic. Slow exceptions should change ownership. The metric is valuable when it produces a more reliable identity operation, not when it creates a polished dashboard around an unchanged repair process.

The benchmark that matters is not how few duplicates remain at a point in time. It is whether a reviewer can reconstruct why two profiles were combined, which identity survived, which evidence moved, how derived state changed and whether every consequential destination reached the intended state. That standard is slower to describe but far closer to the customer and revenue risk RevOps actually owns.

Related reading: Research & Benchmarks · Data Quality · Intercom · Hightouch