Merge rate is the share of duplicate candidate groups that actually get folded into one golden record — not the share you flag as possible duplicates. It is the single most visible health number of an identity-resolution lane: too low and duplicates accumulate across channels; too high and you start folding two different people into one record. On Devotel Orbit the number is measurable end to end — the deterministic publisher emits identity.auto_merge_candidate, the deterministic endpoint reports accepted/failed/needs manual review counts, and every merge writes an auditable row — and it is governed by two controls a tenant owns: the auto-merge confidence threshold and the field-level survivorship policy that decides what the merged record keeps.
This guide is for the operator who owns that posture. It defines the metric, walks through how the pipeline counts it, and gives the working set of survivorship rules that keep a golden record complete and accurate after each merge.
What "merge rate" actually means
In identity-resolution work, a duplicate candidate group is a set of contact records the matching layer believes may be the same person. A merge rate has a numerator and a denominator:
- Denominator: the number of candidate groups the matching layer produced for a window (per duplicate scan, day, or tag).
- Numerator: the number of those groups that ended with a real fold — one golden record surviving, the rest marked merged.
The denominator is under your control only insofar as you tune matching strictness. Too-loose blocking keys (phone-type respellings, single shared-channel matches) inflate the candidate pool; careful deterministic keys (lowercased email, E.164 phone, external id) produce fewer but cleaner candidates. The numerator is where the confidence threshold and the survivorship rules act.
Three regimes show up repeatedly in production:
- Deterministic auto-merge band. Equal normalized identifiers on a declared key group transitively, and the group folds without human review when its confidence clears the auto-merge threshold. This is the healthy part of the numerator.
- Probabilistic review band. Pairs that are only similar — fuzzy names, a phone-format respelling, a shared channel id — rank into a review queue with a confidence score. A steward accepts each fold explicitly, or returns it. This band grows the numerator safely, not silently.
- Post-merge survivorship. Once a fold is decided, field-level survivorship decides which side of each field wins on the golden record. Survivorship is where accuracy becomes a policy rather than a pick-by-side guess.
Computing the rate in Orbit
There are two concrete surfaces for reading it. The deterministic endpoint reports its result alongside the groups it examined: accepted (folded), failed (rejected), and needs_manual_review (still in the steward queue). The deterministic publisher also emits the identity.auto_merge_candidate event for each group it folds automatically, so the numerator for the auto-band is queryable rather than inferred. Together these give you the three counters above: auto-merged, steward-merged, and still-in-review.
In the Identity Resolution surface (/audience/identity-resolution), the first two counters are exposed on the merge console; the review queue is the third. A healthy week gives: a steady deterministic auto-accept count, a review queue that drains rather than accumulates, and relatively few needs_manual_review leftovers.
Because the deterministic endpoint flags over-merges in the simulation before any rule saves (/audience/identity-resolution simulation), the strongest lever for producing a healthy rate is strictness-first tuning: raise the confidence threshold until the deterministic band stops folding provably-different people, then invest the remainder into the review queue rather than loosening auto-merge.
Survivorship: what the golden record keeps
Once a merge decides to fold, the survivorship policy resolves which side of each governed field wins. On Orbit the catalog is the scalar contact columns — phone, email, WhatsApp/Viber id, names, company, country, timezone, language, external id — the fields that make a golden record readable and routable. Custom attribute keys (attributes.*) stay with the per-merge merge console and never enter policy.
Each rule chooses a strategy — keep the survivor (target), keep the merged-in (source), most recently updated, most recently created, prefer one source system (with the source_system value named), or prefer non-null — and then a null-fallback applies: a winning side whose value is empty yields to the loser's non-empty value, so a golden record never nulls a known value. Every rule is per-field, and one default strategy optionally covers the rest of the catalog.
Three rules-of-thumb that hold up across tenants:
- Prefer the most recently updated value for contact fields that drift — names, company, display name. The newest write reflects the customer's latest correction.
- Prefer a named source system for fields a trusted upstream owns — the CRM-managed email, the imported phone. When Orbit's inbound channels create records, the deliberately-managed source wins and the messy inbound side yields.
- Prefer non-null on the remaining catalog — when nothing owns the field, the most-complete value is the right one, and the null-fallback still stops a blank winner from erasing a known value.
The policy is tenant-authored and scoped to your organization. It lives at organizations.settings.cdp.survivorship_policy and surfaces on the API at GET /api/v1/cdp/survivorship-policy, with PUT replacing it and DELETE reverting to no-policy behavior. Every merge — automated from the identity resolver (/alias), deterministic from a duplicate scan, or manual from the merge console — resolves the policy into per-field preferences and the explicit per-merge preference you hand the console still wins; the policy is the default, not an override of deliberate intent.
Tuning checklist
- Read the counters weekly. Auto-merged, steward-merged, in-review. A draining review queue is the healthy signal.
- Tighten deterministic blocking keys before touching confidence thresholds. Fewer, cleaner candidates out-perform a bigger pool every time.
- Dry-run rules in the simulator. A proposed rule set runs against live data and flags over-merges before save; a too-loose rule fails in preview, not production.
- Author survivorship per field. Name the trusted source system for managed fields, lean recency for drifting fields, non-null for the rest.
- Watch merge rate alongside completeness. A falling golden-record completeness (more nulls after merges) usually means a survivorship rule picked a side the data didn't support — check the null-fallback and the rule's strategy first.
Frequently asked questions
What is a healthy merge rate range?
There is no single platform-wide number because it depends on how dirty the source channels are. A healthy directional signal is a steady rise in the steward-drained fraction (the review queue shrinks over time) together with a stable auto-accept band, rather than a sudden jump in auto-merges from a loosened threshold.
Does a survivorship policy override the merge console's explicit preference?
No. An explicit field_preferences you supply on the merge console or on POST /contacts/merge still wins. The policy supplies the org-wide default only when the merge request does not specify one.
Which contact fields can a survivorship rule govern?
The scalar columns on the contact record: phone, email, WhatsApp id, Viber id, first and last name, display name, company, country code, timezone, language, and external id. Custom attributes.* keys stay governed by per-merge choices.
Where does the survivorship policy live?
At organizations.settings.cdp.survivorship_policy (JSON), readable/writable through GET, PUT, and DELETE on /api/v1/cdp/survivorship-policy, and rendered in the Identity Resolution dashboard.
Will an empty policy change how my merges behave?
No. A tenant with no survivorship policy resolves to an empty preference map on every merge, so the merge flow behaves exactly as before the policy surface shipped.
The takeaway
Merge rate is measurable when identity resolution is, and survivorship rules turn a fold into a predictable golden record rather than whichever side the join happened to land on. On Devotel Orbit both are tenant-owned: the deterministic auto-merge threshold, the steward review queue, and the per-field survivorship policy are controls you set per organization, with every change auditable and every merge reversible within its window. The (Identity Resolution concept) page and the (CDP feature surface) cover the surfaces; the (changelog) is where the lane's hardening lands week by week.