Changing the main time window without shifting the comparison baseline breaks the year-over-year math

What it is

Year-over-year and period-over-period figures on a dashboard depend on an implicit baseline window: when the user changes the main chart from "last 7 days" to "last 30 days," the baseline for those comparisons must shift to the corresponding previous period. If the baseline stays put, the user sees new data from the main window paired with a baseline from an old window—two different time periods rendered side by side, the meaning of the percentage change already gone, yet the numbers remain on screen and no reader knows.

Why it happens

The root cause is that the main window and baseline window are two independent pieces of state while the user's mental model perceives only one: "the time range." When the implementation stores them separately, any interaction that updates only the main window creates a silent misalignment. The user did nothing wrong—the control was operated correctly—but the percentage on screen no longer answers "how does this period compare to the last." This distortion is structurally identical to scope mismatch (see the same-group knowledge in Related): two operands measuring different things, the calculation proceeding normally, the output looking fine. The remedy is to make the time range a single source of truth: the main window, baseline window, and every window-dependent property (aggregation granularity, comparison annotations) all derive from that one state, and the interaction layer modifies only that state.

Where it stops holding

Not every baseline should follow: if the user explicitly pinned a comparison period ("always compare to last month"), the baseline should stay put when the main window changes—"not updating" is the correct behavior; the key is making sure the user knows whether the baseline follows or not. In compound scenarios where the main window widens but baseline data is insufficient (e.g., the range becomes 90 days but the system stores only 60 days of history), the sync logic must handle partial comparability and annotate the gap explicitly. Cross-metric baseline sync also has a granularity-matching issue: daily and monthly metrics define "previous period" differently, and linkage must compute each at its own granularity.

Applying it

• When the time range control changes, cascade the update to every window-dependent metric: YoY, PoP, comparison lines, aggregation granularity—one interaction, everything refreshed.
• Provide an explicit control for pinning the comparison period (e.g., a "lock comparison period" toggle); when active, annotate the chart with the fixed baseline's date range.
• When baseline data is incomplete, show an "incomplete baseline" notice beside the comparison value instead of silently truncating.
• Verification: change the time range once and check each percentage on screen against whether its baseline window's start and end dates moved in sync; any number that did not move is a sync failure instance.

Related

• Same group: U7.06.1 The default time range determines the conclusion most users will see · U7.06.2 Preset ranges should cover common cycles and allow custom input · U7.06.3 Relative and absolute ranges suit different usage scenarios · U7.06.5 The active time range must be visible alongside the chart
• Nearby: U7.05.5 The comparison period's statistical scope must match the current period's · U7.05.2 Period-over-period suffers cyclic interference; year-over-year removes cycles but reacts late
• Search terms: comparison baseline sync · linked time range · crossfilter