{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-09-23T13:44:02.417Z"},"content":[{"type":"documentation","id":"8437212d-c719-4f86-9b0d-a9cf00144690","slug":"moving-average-hides-events-research","title":"The Moving Average on Your Dashboard Is Hiding the Week That Mattered (2026)","url":"https://www.koji.so/docs/moving-average-hides-events-research","summary":"A moving average divides event height by the window length and multiplies duration by it, conserving area while destroying the peak - and alert thresholds respond to height, not area. Covers attenuation arithmetic, the (k-1)/2 lag rule, the unavoidable choice between a centred average with no current value and a trailing average that describes the past, and 28 defensible smoothings of one series.","content":"**Short answer:** a moving average divides the height of an event by the window length and multiplies its duration by the same number. The area under the event is preserved exactly; the peak is destroyed. Since every alert threshold, every \"is this bad enough to act on\" rule, and every eyeball scanning a chart responds to **height**, smoothing removes precisely the property you were using to detect things. A one-day outage worth 70 points becomes a seven-day bump worth 10.\n\nThis is the second half of a pair. If your problem is that the gap between measurements has manufactured a trend, the standard next move is to smooth the noisy series so the \"real\" trend shows through. That move is not neutral. It has a known, computable cost, and the cost falls hardest on exactly the events you most need to see.\n\n## What smoothing is for, and what it costs\n\n### What the handbooks actually say\n\nThe purpose is not in dispute. The NIST/SEMATECH Engineering Statistics Handbook puts it directly: \"Smoothing data removes random variation and shows trends and cyclic components\". Hyndman and Athanasopoulos, in *Forecasting: Principles and Practice*, describe the same thing: \"the average eliminates some of the randomness in the data, leaving a smooth trend-cycle component\".\n\nRead both sentences again with an adversarial eye. Neither says smoothing removes *noise*. They say it removes **random variation** and **randomness**. A moving average has no concept of what is noise and what is signal. It cannot. It applies one arithmetic operation to every point in the window. As the NIST handbook puts it, the average \"weighs\" all past observations equally.\n\nSo the operation does not distinguish a measurement wobble from a genuine one-off event. Both are short-lived departures from the local level, and both are treated identically: flattened in proportion to the window. The larger the window, the better it works, in both directions. Hyndman and Athanasopoulos again: \"In general, a larger order means a smoother curve.\"\n\n## The arithmetic of a deleted event\n\nTake a metric sitting at a baseline of 0 with a trailing moving average of window k = 7. On one day, something happens and the value jumps to 70 - a serious incident, a botched release, a pricing page that broke.\n\nThat single day now falls inside seven consecutive seven-day windows. In each of them it contributes 70/7 = 10. So the smoothed series shows:\n\n| | Raw series | 7-day trailing average |\n| --- | --- | --- |\n| Peak height | 70 | 10 |\n| Duration above baseline | 1 day | 7 days |\n| Area under the event | 70 | 70 |\n\n### A spike is divided by the window and stretched by the window\n\nThat is the whole rule, and it generalises. For a trailing average of length k, a one-period event of height h becomes an event of height h/k lasting k periods. Height is divided by k. Duration is multiplied by k. **Area is conserved exactly.**\n\nNothing was lost in an information-theoretic sense - the integral is intact. What was lost is the concentration. A 30-day average of the same incident shows a 2.3-point bump for a month. A 90-day average shows 0.8 points for a quarter, which is indistinguishable from drift.\n\n### Why every threshold you own is a height\n\nHere is why the conservation of area is no comfort. Consider the rules you actually operate:\n\n- An alert that fires when the metric moves more than 15 points.\n- A rule that a wave-over-wave change above 10 percent gets escalated.\n- A human glancing at a chart and noticing a spike.\n\nEvery one of those tests a **height**, an amplitude, a peak. Not one of them integrates. So a 70-point incident that trips a 15-point threshold in the raw series produces a 10-point bump in the smoothed series and trips nothing. The incident is still in the data, fully accounted for, and permanently below the line at which anyone looks at it.\n\nThis is the inversion worth carrying away: **smoothing was adopted to stop the alerting from firing on noise, and it works by suppressing amplitude, which is the only thing the alerting can see.** The fix and the failure are the same operation. You do not get a cleaner detector; you get a detector with a higher effective threshold that nobody wrote down.\n\n## The lag: how late is a smoothed number?\n\nThe second cost is timing. A trailing average is an average of the past, so it reports change late by a predictable amount.\n\n### Worked example: a 7-day average meets a real step change\n\nSuppose the metric genuinely steps from 0 to 10 on day 0 and stays there - a real, permanent improvement.\n\n| Day | Raw | 7-day trailing average | Share of the change visible |\n| --- | --- | --- | --- |\n| 0 | 10 | 1.4 | 14% |\n| 1 | 10 | 2.9 | 29% |\n| 3 | 10 | 5.7 | 57% |\n| 5 | 10 | 8.6 | 86% |\n| 6 | 10 | 10.0 | 100% |\n\nThe change completes on day 0. The chart finishes agreeing on day 6. The midpoint - the day the dashboard shows half the change - is day 3, which is (k-1)/2. That is the general rule: **a trailing average of length k reports a step change with a lag of roughly (k-1)/2 periods and does not fully reflect it for k periods.**\n\n### Scaled to the windows teams actually use\n\nA 12-week trailing average lags by five and a half weeks. A quarterly rolling average lags by six weeks. If a team ships a fix and then watches a 12-week rolling metric to decide whether it worked, they are reading a number whose midpoint describes the state of the world in the middle of the previous quarter.\n\n## The hole at the end of the series\n\nThere is a way to remove the lag: centre the average, so each point averages equally before and after. This is standard practice, and it fixes the timing problem completely. It also introduces a different problem, which Hyndman and Athanasopoulos state plainly: \"There are no values for either the first two years or the last two years, because we do not have two observations on either side.\"\n\nA centred moving average cannot produce a value for the most recent periods, because half of the data it needs has not happened yet.\n\n### Two options, and there is no third\n\nSo the choice is exact and unavoidable:\n\n- **A centred average** is correctly timed and has **no value for now**.\n- **A trailing average** has a value for now, and that value **describes the past**.\n\nThere is no third option, and no window length escapes it. Every dashboard showing a smoothed current number has silently taken the second branch. The number labelled \"this week\" is an estimate of a week that is, on average, (k-1)/2 periods ago. The label is the error, not the arithmetic.\n\n## 28 defensible versions of one chart\n\nOne more thing worth counting. To smooth a series you choose:\n\n- a window: 3, 5, 7, 14, 28, 30, or 90 - seven common choices\n- a placement: trailing or centred - two\n- a statistic: mean or median - two\n\nThat is 7 x 2 x 2 = **28 smoothings of the same data**, every one of which a competent analyst could defend, and all of which produce different peak heights, different turning points, and in some cases different directions over a short horizon. You present one. Nothing on the chart records which one, and the choice is usually made by whichever default the charting library shipped with.\n\nThe discipline is simply to write the choice down next to the chart, the way you would write down a sample size.\n\n## When smoothing is the right call\n\nSmoothing is not a mistake; using it without pricing it is. It is the right tool when:\n\n- You are trying to see a **slow trend** and you have already established, separately, that short-lived events are handled by a different mechanism.\n- The **cycle length is known** and you are using a window that matches it deliberately, to remove it.\n- The series is genuinely dominated by measurement error rather than by real short events.\n\n### And when it is the wrong tool\n\nIt is the wrong tool when the events are the point - incidents, launches, outages, a competitor announcement, a pricing change - or when the series is short. On a four-wave tracker, a rolling average is mostly an elaborate way of throwing away three of your four data points.\n\n## How to smooth without losing the event\n\n### Six practical rules\n\n1. **Plot the raw series behind the smoothed one.** One extra line, usually one argument. This alone removes most of the harm, because the peak stays visible while the trend stays readable.\n2. **Set thresholds on the raw series, trends on the smoothed one.** Detection and interpretation want different inputs. Never let a smoothed series feed an alert.\n3. **State the window and placement on the chart.** \"28-day trailing mean\" belongs in the axis label.\n4. **Keep an event log alongside the metric.** If you know a release landed on the 14th, you do not need the chart to reveal it, and you can check the smoothed series against a known event to calibrate how much it hides.\n5. **Prefer a shorter window plus an explicit event marker** over a long window that looks tidy. Tidiness is the symptom.\n6. **Compute the attenuation once.** Divide the smallest event you would want to catch by your window length, and compare the result with your alert threshold. If the quotient is below the threshold, your detector is off for that class of event. This takes ten seconds and almost nobody does it. Because Koji retains every timestamped response, you can recompute the same metric at several windows and read the attenuation off directly rather than deriving it.\n\n## How Koji handles this\n\nSmoothing is usually a downstream reaction to a sparse, noisy series, and a sparse, noisy series is usually a symptom of expensive collection. Fix the collection and the pressure to smooth mostly disappears.\n\n- **Denser series, less need to smooth.** Because AI-moderated interviews run continuously rather than in scheduled waves, Koji produces series dense enough that real movement is visible without a long window. The reason teams reach for a 90-day average is that they have too few points, not that they love averages.\n- **Qualitative events survive that quantitative smoothing destroys.** A single participant describing a broken flow is exactly the kind of one-off amplitude that a rolling average erases. Automatic thematic analysis surfaces it as a named theme with the verbatim attached, so the event has a second, non-numeric route to your attention.\n- **Structured questions give you the raw distribution, not just a mean.** All six structured question types - open_ended, scale, single_choice, multiple_choice, ranking, and yes_no - retain the underlying response distribution. A mean can be smoothed into blandness; a distribution shows a bimodal split that no single line ever will.\n- **Real-time reporting removes the lag you were compensating for.** Part of the appeal of a long window is that it papers over waiting for the next wave. When results aggregate as interviews complete, the current number is genuinely current.\n- **Timestamps make the attenuation checkable.** Because every response is timestamped, you can recompute any window on the same underlying data and see directly how much a given choice of window hides.\n\nLegacy survey tooling pushes in the opposite direction: because each wave is expensive, teams get few points, and few noisy points make a long rolling average look like the only readable option. That is the trap. Koji is built so that you do not need a PhD in time-series analysis to avoid it - the default is a dense series you can read raw.\n\n## Common mistakes\n\n- **Feeding a smoothed series into an alert.** The most common and most costly version of this error. The threshold and the smoothing were chosen by different people at different times and nobody multiplied them together.\n- **Comparing a smoothed number to an unsmoothed target.** A 28-day trailing average will not reach a target on the day the underlying metric does. It will get there roughly two weeks later, and someone will draw a conclusion in between.\n- **Reading the last point of a trailing average as \"now\".** It is not. It is the recent past, offset by about half the window.\n- **Increasing the window because the chart still looks noisy.** Each increment raises your effective detection threshold. If the chart is noisy, the honest answers are more data or a raw overlay.\n- **Assuming a median filter is a free upgrade.** A rolling median is more robust to single outliers, which means it deletes one-off events even more completely than the mean. That is sometimes what you want and it is never neutral.\n- **Forgetting that the smoothing choice is a choice.** Twenty-eight defensible versions, one presented, zero recorded.\n- **Smoothing to compensate for too few data points.** This is the most common root cause, and it is a collection problem wearing an analysis costume. Denser continuous collection in Koji removes the pressure to smooth rather than managing its consequences.\n\n## The bottom line\n\nA moving average is a filter with a published price list: height divided by the window, duration multiplied by it, timing late by half of it, and no value at all for the present if you want the timing honest. None of that is a flaw to be fixed - it is what the operation does. The discipline is to pay the price knowingly: keep the raw series visible, keep thresholds on raw data, label the window, and check once whether the smallest event you care about survives the division. When smoothing is priced, it is a good tool. When it is a default, it is a detector you have quietly switched off.\n\n## Frequently asked questions\n\n### How much does a moving average delay a real change?\n\nA trailing average of length k reports a step change with a lag of about (k-1)/2 periods and takes k periods to reflect it fully. A 7-day average is about 3 days late, a 28-day average about 13 days, and a 12-week average about five and a half weeks. If you ship a change and watch a long rolling metric, budget for that delay before concluding the change did not work.\n\n### Why not just use a centred moving average instead?\n\nYou can, and it fixes the timing entirely - but a centred average cannot produce a value for the most recent periods, because it needs data from both sides of each point and the future half does not exist yet. That is the unavoidable trade: correct timing with no current value, or a current value that describes the past. Most dashboards choose the second without saying so.\n\n### What window size should I use?\n\nWork backwards from the smallest event you want to detect rather than from what looks tidy. Divide that event size by your candidate window and compare the result with your alert threshold or with what is visible by eye. If a 70-point event becomes a 10-point bump and your threshold is 15, the window is too long for that purpose regardless of how clean the chart looks.\n\n### Does smoothing lose information?\n\nNot in total - the area under an event is conserved exactly. But it redistributes that area from a tall narrow shape into a short wide one, and every practical detector you use, from alert thresholds to human attention, responds to height rather than area. So the information survives while the detectability does not, which is the distinction that matters operationally.\n\n### Is a rolling median safer than a rolling mean?\n\nIt is more robust to outliers, and that is the problem as often as it is the benefit. A median filter can remove a one-day event essentially completely rather than attenuating it, because a single extreme value does not move a median much at all. Use a median when you are certain the extremes are measurement error, and a mean with a raw overlay when they might be real events.\n\n### How does Koji reduce the need for smoothing?\n\nKoji collects continuously through AI-moderated interviews rather than in expensive periodic waves, so the series is dense enough to read without a long window - the usual reason for reaching for a 90-day average is too few data points, not a preference for averages. Automatic thematic analysis also gives one-off events a second route to your attention as named themes with verbatim quotes, so an event that a rolling average would flatten still surfaces.\n\n## Related Resources\n\n- [Why Your Quarterly Metric Shows a Trend That Is Not There](/docs/measurement-interval-false-trend) - the companion problem: how the gap between measurements manufactures a trend in the first place.\n- [Research Decision Lag](/docs/research-decision-lag-oscillation) - what the lag documented here does once it sits inside a decision loop.\n- [Common Cause vs Special Cause](/docs/common-cause-special-cause-research-metrics) - deciding whether a move is real, which needs the raw series rather than a smoothed one.\n- [Alarm Flooding and Alert Design](/docs/alarm-flooding-research-alert-design) - why raising thresholds to quiet the noise is the failure mode, not the fix.\n- [Singleton Themes](/docs/singleton-themes-unseen-coverage) - the qualitative equivalent of a one-off event, and why the things that happen once carry the most information.\n- [Structured Questions Guide](/docs/structured-questions-guide) - the six question types that preserve the full response distribution instead of collapsing it to a mean.","category":"Analysis & Synthesis","lastModified":"2026-09-23T03:32:19.259986+00:00","metaTitle":"The Moving Average Is Hiding the Week That Mattered","metaDescription":"A rolling average divides an event height by the window and stretches it by the window. Every threshold you own is a height. The arithmetic.","keywords":["moving average research metrics","rolling average hides events","smoothing time series research","window size moving average","trailing vs centred moving average","moving average lag","dashboard smoothing"],"aiSummary":"A moving average divides event height by the window length and multiplies duration by it, conserving area while destroying the peak - and alert thresholds respond to height, not area. Covers attenuation arithmetic, the (k-1)/2 lag rule, the unavoidable choice between a centred average with no current value and a trailing average that describes the past, and 28 defensible smoothings of one series.","aiPrerequisites":["Comfort reading a time series chart","Basic understanding of averages"],"aiLearningOutcomes":["Compute how much a given window attenuates a one-period event","Explain why smoothing conserves area but destroys detectability","Calculate the reporting lag of a trailing moving average","Choose between centred and trailing smoothing knowing what each costs","Keep detection on raw data and interpretation on smoothed data"],"aiDifficulty":"intermediate","aiEstimatedTime":"11 min"}],"pagination":{"total":1,"returned":1,"offset":0}}