Sign in

Blog · Data quality and reconciliation

Identifier drift: when a system re-keys an account and the history breaks

What happens to every measure when a CRM migration, a merge or a re-numbering changes an account's identifier: the account appears new, its history appears lost, dormancy fires, concentration drops, and share of wallet resets. The dated identifier map that prevents it, the three ways drift is detected on upload, the rule that old identifiers are never reused, and the worked recovery after a migration that re-keyed a third of the base.

By CoviragePublished 16 September 20263 min read
The short answerWhen an account's identifier changes, every measure that uses history treats it as a new account: it has no cadence, so it cannot be dormant; no prior revenue, so its trend is infinite; no prior share, so its gap resets; and the old identifier goes silent, so it appears churned. The fix is a dated identifier map, old to new, applied on every upload, with old identifiers never reused. Drift is detected three ways on upload: identifiers seen last time and absent now, identifiers new now with a revenue history that matches a vanished one, and a count of new identifiers above a threshold. A migration that re-keyed a third of the base is recovered with one map, not by hand.

A CRM migration goes well: every account is in the new system with a new identifier. The next month's report shows nine hundred new accounts, nine hundred churned ones, dormancy on half the book and concentration halved. Nothing happened to a single customer. This guide sets out what identifier drift does to each measure, the dated map that prevents it, how drift is detected, and a worked recovery.

What drift does to each measure

Measure Effect of a re-key
Dormancy Old identifier goes silent: appears dormant, then lost. New one has no cadence: cannot be assessed
Churn Old identifier counted churned; new counted new. Both wrong
Run rate and trend New identifier's trend is from zero
Share of wallet and gap History gone; the norm applies to a customer with no past
Concentration Top customers split between old and new identifiers; share understated
Cohorts New identifier joins this year's cohort; the old cohort loses a member
Coverage Activities on the old identifier no longer count for the new

The dated identifier map

Old identifier New identifier Effective date Reason
C-2207 4471 2026-04-01 CRM migration
C-9034 4471 2026-06-15 Merge: same customer, two records
C-1187 retired 2026-06-15 Duplicate of C-9034; retired

Applied on every upload, before anything is computed: every row with an old identifier is read under the new one from the effective date, and history is joined.

Three detections on upload

Detection Rule Output
Vanished Identifier with revenue last period, absent now List
Appeared Identifier new now, with revenue in its first period above a floor List
Paired A vanished and an appeared whose pattern matches Proposed map row, with confidence, for confirmation

And a threshold: new identifiers above a stated share of the base in one upload stops the run, because that is a migration, not new business.

A worked recovery

Migration re-keyed 880 of 2,640 accounts.

Step Result
Upload stopped: 880 new identifiers, 33% of base Threshold breached
Pairing on revenue pattern, product mix, region 812 proposed pairs at high confidence; 51 at medium; 17 unmatched
Confirmation 812 accepted; 48 of 51 accepted; 3 rejected as genuinely new; 17 investigated: 14 new customers, 3 typos
Map applied; upload re-run 0 phantom churn; dormancy unchanged from last month; concentration unchanged

One map of 860 rows. Without it, every measure would have been wrong for a year.

Where it goes wrong

No map. Nine hundred phantom churns.

Map applied by overwriting history. Last year restated; cohorts move.

Identifiers reused. A new customer with an old one's past.

Pairs applied without confirmation. Two real customers merged by a pattern match.

Every upload, the map first

Mapped once and dated, the identifier map is applied before any measure, the three detections run, and the threshold stops a migration from becoming a report. Covirage builds this from the exports as they are. The metrics governance solution describes the setup, and the CRM to ledger reconciliation guide covers identifier drift as the fifth mismatch type.

Questions people ask

Why never reuse an old identifier?

Because a reused identifier joins a new customer's rows to an old customer's history. Every measure on the new customer inherits the old one's cadence, trend and share. An identifier, once retired, is retired.

How is a re-key detected automatically?

By pairing: an identifier absent this upload and one new this upload whose revenue pattern, product mix and location match. The report proposes the pair with a confidence; a person confirms it into the map. Without confirmation it is listed, not applied.

What about merges of two real customers?

Two old identifiers map to one new, with the date. Before the date, two customers; after, one. Concentration and share are computed on the customers in force in the period, and last year is not restated.

Related reading

Data quality and reconciliation

A CRM data quality scorecard: five fields, five checks, one number per rep

How to score CRM data quality from the export rather than from complaints: five fields that every coverage and pipeline measure depends on, owner, close date, stage, activity date and account identifier, the check for each, the completeness and validity rate per rep, why the score is reported beside the measures that depend on it, and the rule that a measure computed on data under a stated score is shown greyed.

16 Sept 20263 min readData quality and reconciliation

Account hierarchy: parents, subsidiaries and the level you actually sell to

How to build and use an account hierarchy for sales analytics: the levels that exist in most customers, group, legal entity, site, department, the one level where the buying decision is made and every measure is computed, the levels beneath kept as dimensions, the dated parent mapping that survives acquisitions, the identity that revenue sums identically at every level, and the two mistakes that produce forty customers where there is one and one where there are forty.

16 Sept 20263 min readData quality and reconciliation

B2B customer segmentation from the ledger, not from personas

How to segment a B2B customer base from data the company holds: the two or three fields that make a segment useful for norms, size, sector and channel, why behavioural fields like order frequency and product mix belong in the measures rather than the segment definition, the minimum segment size that makes a norm mean something, the test that a segmentation is good, and why personas do not survive contact with a ledger.

16 Sept 20263 min readData quality and reconciliation

Baseline and norm: what this account usually does, and what accounts like it do

The difference between a baseline, an account's own typical level from its own history, and a norm, what similar accounts do when the relationship is full, why the two answer different questions, has this account changed and how far is it from where it could be, which measures use which, surge and dormancy against baseline, gap and share against norm, the case where an account is at its baseline and far from the norm, and the rule that both are stated on the line that uses them.

16 Sept 20263 min read