Redefining a metric silently breaks every downstream report that reused the dashboard without warning

What it is

A dashboard typically serves many consumers: team members, downstream reports, embedded pages. When a metric's statistical definition changes (say, "active user" shifts from "opened the app" to "completed a core action"), the numbers on the dashboard jump from the change date onward—but every reader accustomed to the old meaning will misread that jump as a business change unless they know a change occurred. A notification mechanism for definition changes is the precondition for "the number changed and readers know why." Without notification, the change's outcome is not an upgrade but each reader independently reinventing an explanation.

Why it happens

The structural cause of misreading without notification: readers' understanding of a metric comes from the pattern established by historical data, not from the current definition document. Three months of "active user = opened the app" builds a stable expectation; the new number on the change date (computed under the new definition) deviates from that expectation and is automatically interpreted as business volatility—because "numbers moving" is the most common signal on a dashboard, while "the definition changed" is invisible. Notification injects the correct causal information into the reader's interpretation process, interrupting the false business attribution. Technically, notification presupposes that the system knows "who uses this dashboard": subscribers, embed references, scheduled downstream exports—that consumer registry is the notification's address book. A dashboard system with no consumer registry is technically incapable of sending notifications, which is the root cause in many organizations.

Where it stops holding

Timing matters: notifying before the change takes effect gives readers mental preparation; annotating the chart at the moment of change lets whoever is viewing then perceive it immediately; sending a summary notification after the change reaches those who haven't looked—three timings serve different reader states and are not mutually exclusive. Another boundary is "who needs notifying": frequent viewers need immediate notification, monthly viewers need a change summary displayed at their next visit (rather than a pile of ignored notifications). Notification fatigue is real too: if every minor tweak triggers a notification, readers learn to ignore them, and truly important changes drown.

Applying it

• Maintain a consumer registry (subscribers, embedding references) for every metric dictionary definition; use it as the minimum notification list when a definition changes.
• On the effective date, annotate dashboard charts (a vertical line with a "definition changed" marker), visible for at least 30 days.
• Verification: pick a historical definition change and check whether every downstream consumer of the affected dashboard was notified; any missed consumer is a notification-mechanism gap.

Related

• Same group: U7.10.1 Customization increases personal fit but weakens the team's shared reference · U7.10.2 Personal configurations must be distinguished from the official version and resettable · U7.10.3 Long-frozen dashboards keep using metrics that are no longer valid · U7.10.5 Dashboards no one views should be retired rather than kept
• Nearby: U7.05.5 The comparison period's statistical scope must match the current period's · U7.09.3 Data must carry a visible timestamp
• Search terms: metric change notification · schema change · consumer registry