Metric Restatement

A metric restatement is a correction to a number you have already published. The definition changed, a bug was found in the pipeline, a double-counted source was removed, or a segment was reclassified — and the history now reads differently from the version people have in their decks. Restatements are unavoidable in any company that keeps improving its instrumentation, and the damage they do has almost nothing to do with the size of the correction and almost everything to do with how it is handled. Handled badly, a restatement looks like a company that either did not know its own numbers or is adjusting them to suit the story. The mechanics that keep it clean are boring and worth committing to in advance. Restate the whole history on the new definition rather than splicing a new method onto an old series, because a chart that changes method partway through shows a step that no event in the business produced. Publish both series side by side for at least one reporting period so the audience can see the size and direction of the change themselves. Say plainly which definition changed and when the change takes effect, and keep the old definition documented rather than deleting it, since somebody will find an old export and need to reconcile it. Name the reason without dressing it up: a bug is a bug. The harder rule is about scope. A number that has left the company — sent to investors, quoted in a contract, used in a public claim — is in a different category from an internal dashboard, and the decision to restate it is not an analytics decision. Deciding that in the moment, under pressure, is how a small correction becomes a credibility problem, so it is worth agreeing beforehand who is told, in what order, and how quickly. It also helps to notice that most restatements are the delayed cost of a decision nobody recorded — a definition changed in a query six months ago and never written down anywhere the next person would look.