Time Series Decomposition Demo

Revenue was up 12% in December, and the VP asks whether the business is actually growing or just riding the holiday bump. A raw chart cannot answer that — both the upward trend and the December spike live in the same line. Time series decomposition pulls the line apart into three layers: the trend (is the baseline rising, falling, or flat over months?), the seasonal component (how much does December reliably add every year?), and the residual (the noise left after removing both). Once those layers are separated, you can answer the VP’s question with a number instead of a shrug.

The mistake that derails most first attempts: eyeballing a peak and calling it “growth.” If December always adds 15% and this December added 12%, the trend actually slowed — the seasonal component just masked it. Decomposition strips the mask away so you see the underlying trajectory.

The period tells the algorithm how many data points make up one full seasonal cycle. Monthly data with yearly seasonality uses period = 12. Daily data with weekly patterns uses period = 7. Hourly server logs with daily cycles use period = 24. Get the number wrong and the seasonal component absorbs part of the trend or vice versa — every downstream conclusion is then off.

If you are unsure of the period, plot the raw data and count the distance (in data points) between repeating peaks. An autocorrelation plot makes this mechanical: the first strong positive spike after the origin marks the period. For monthly sales data, the spike should appear at lag 12. If it appears at lag 6 instead, you may have a semi-annual pattern, or your data might have two overlapping cycles (quarterly promotions inside a yearly trend).

One trap: choosing a period longer than half your data length. Classical decomposition needs at least two full cycles to estimate seasonal indices reliably. Twelve months of monthly data (period = 12) gives exactly one cycle — not enough. You need at least 24 months, and 36 or more is much better. If your series is too short, the seasonal estimates will be noisy and the residuals will look patterned.

The residual is everything the model could not explain with trend and seasonality. If the decomposition did its job, the residual should look like random noise — no visible pattern, no autocorrelation, roughly centred at zero (additive) or at one (multiplicative). That is the sign that you extracted all the structure the data has to offer at this level of complexity.

Patterned residuals are the most useful diagnostic. If you see a clear wave in the residuals, you probably picked the wrong period or missed a second seasonal cycle (daily inside weekly, for example). If the residuals trend upward, the moving-average window was too short to capture a slowly bending trend. If specific months consistently show large residual spikes, there may be a holiday or event effect that the fixed seasonal index cannot represent.

Residuals also flag outliers. A single point with a residual three times the standard deviation of the rest is worth investigating — it could be a data error, a one-time promotion, or a system outage. Classical decomposition does not handle outliers; it simply dumps them into the residual. More advanced methods like STL apply robustness weights to downplay these spikes.

The seasonal swings in my data are getting bigger over time. Which model?
Multiplicative. In an additive model, the seasonal component adds a fixed amount each December — say, +$50k. In a multiplicative model, December multiplies the trend by a factor — say, 1.20. As the trend rises, 1.20× produces larger absolute swings. If your December spike was $10k in year one and $30k in year three (while the trend tripled), the pattern is multiplicative. A quick check: plot the data. If the seasonal envelope fans out like a trumpet, use multiplicative.

I used additive but the residuals show a pattern that follows the trend. What went wrong?
The additive model subtracted a constant seasonal value from a series whose seasonal swings grew with the level. The leftover growth shows up as patterned residuals — positive residuals in peak months, negative in troughs, scaling with the trend. Switch to multiplicative and the residuals should flatten.

Can I take the log and use additive instead of multiplicative?
Yes. log(Trend × Seasonal × Residual) = log(Trend) + log(Seasonal) + log(Residual), so a multiplicative model on the original scale becomes additive on the log scale. This is a common trick when your tooling supports only additive decomposition. Just remember to exponentiate the components when you present results.

The trend line looks flat but the series is clearly rising. Why?
The moving-average window may be too wide, over-smoothing the trend and pushing the real movement into the residual. Try a narrower window. Alternatively, if the rise is entirely seasonal (every Q4 spikes, then drops back), the trend correctly shows no lasting change — the series bounces but never ratchets higher.

Trend strength is 85% and seasonality strength is 90%. Do they add up?
No. Strength measures are not additive shares of variance. Trend strength compares the variance of the detrended series to the original; seasonality strength compares the residual variance to the original. Both can be high simultaneously if the series is dominated by trend and a strong repeating cycle on top of it.

Can I use the decomposition output for forecasting?
Not directly. Classical decomposition describes the past — it does not extrapolate. The trend stops at the last data point, and the seasonal indices assume the pattern repeats unchanged. For forecasting you need a method that projects the trend forward (ARIMA, exponential smoothing, Prophet). But decomposition is a useful first step: it tells you what components to model.

The first and last few trend values are missing. Is that a bug?
No. The centred moving average needs data on both sides of each point. With period = 12, the first 6 and last 6 trend values cannot be computed because there are not enough neighbours. This is an inherent limitation of classical decomposition, not a software error.

Two model forms and one trend estimator cover classical decomposition:

Units note: in the additive model, T, S, and R share the same units as Y. In the multiplicative model, T is in original units, S and R are dimensionless ratios (1.20 means 20% above trend).

Scenario: You have 36 months of MRR (monthly recurring revenue) for a B2B SaaS product. Revenue grows from $120k to $340k with visible Q4 spikes each year. The seasonal swings appear to grow with the level, so you choose multiplicative decomposition with period = 12.

Step 1 — Estimate trend.
A 13-point centred moving average (period = 12, made odd) smooths away the monthly noise. The trend line rises from about $135k in month 7 to $310k in month 30. The first 6 and last 6 trend values are null.

Step 2 — Detrend and compute seasonal indices.
Divide each observation by its trend value. Group the ratios by month position (January values together, February values together, and so on). Average each group and normalise so the 12 indices average to 1.0. Result: January index = 0.93 (7% below trend), November index = 1.08 (8% above), December index = 1.14 (14% above).

Step 3 — Compute residuals.
Residual = Original / (Trend × Seasonal). Most residual values cluster between 0.95 and 1.05 with no visible pattern — the decomposition captured the main structure. One month shows a residual of 1.18 — a pricing change that boosted revenue beyond the seasonal norm.

Step 4 — Narrate the result.
“Underlying MRR grew roughly 2.5× over three years. Q4 reliably adds 8–14% on top of trend, with December as the strongest month. After removing trend and seasonality, residuals are random except for one anomaly in month 22 — the mid-contract price increase. The business is genuinely growing, not just cycling.”