Trend and Seasonality

Look at a plot of monthly airline passengers, or retail sales, or the atmospheric CO₂ record at Mauna Loa, and your eye does something automatic and clever: it splits the wiggly line into parts. A long climb. A yearly ripple riding on top. A bit of leftover jitter. That instinct — that a messy series is really several simpler things added together — is the single most useful organising idea in applied time-series analysis, and this page makes it precise.

The decomposition view says any observed series y_t can be thought of as the sum (or product) of a small number of components, each with its own character and its own cause:

y_t = T_t + S_t + C_t + R_t.

Read left to right: a trend T_t, a seasonal term S_t, a cyclical term C_t, and an irregular remainder R_t. Separate them and each becomes something you can describe, model, and forecast on its own terms. Leave them tangled and every question you ask gets a muddy answer.

The four components, one at a time

This is a page about telling four things apart, so let us define them sharply — the differences are exactly where beginners go wrong.

Many textbooks fold the cycle into a broadened "trend-cycle" term and work with just y_t = T_t + S_t + R_t — because in practice the trend and the cycle are both smooth, both aperiodic, and fiendishly hard to separate from a finite record. Keep all four in mind conceptually, but do not be surprised when classical decomposition only hands you three.

The sharpest distinction: seasonal is not cyclical

These two are constantly confused, so pin the difference down once and for all. A seasonal effect has a period fixed by the calendar — you can write it on a wall chart in advance. Ice-cream sales peak every July; electricity demand dips every weekend; A&E admissions spike every New Year. The period never changes: it is exactly s steps, forever.

A cyclical effect rises and falls too, but on a timescale that is not fixed and not known ahead of time. A recession is not scheduled for every fourth year. The distinction is not cosmetic — it changes what you can do. Because seasonality has a known period you can estimate it and subtract it cleanly (that is seasonal adjustment). A cycle has no such handle, so it usually stays bundled with the trend and is modelled, not removed.

Seasonal S_tCyclical C_t
PeriodFixed & known (12, 4, 7, 24…)Variable & unknown
DriverCalendar / clock (weather, holidays)Economy, feedback, natural resonance
Typical length≤ 1 year, exactSeveral years, ragged
Can you remove it cleanly?Yes — the period is knownNo — no fixed handle to grab

Seeing it built up

Below, a purely deterministic illustration: a rising straight trend T_t = 2 + 0.15\,t, a seasonal wave S_t = 1.6\sin(2\pi t/12) of period 12, and their sum T_t + S_t — the kind of shape you meet in monthly sales. The observed series (top) is the wave you would actually record; the two faint lines are the components hiding inside it. Decomposition is the art of running this picture backwards: given only the top curve, recover the pieces.

Notice how the seasonal wave has a constant amplitude here: every yearly ripple is the same height, and it sits on top of the trend as a fixed add-on. That is the additive picture. When instead the ripples grow as the level grows — December's spike getting taller every year — the model wants to be multiplicative, the theme of the next page.

Why bother separating them?

Because almost every real question is about one component, not the mess:

This is exactly why government statistics agencies publish seasonally adjusted unemployment and GDP: the raw figure jerks up and down with the calendar in a way that hides the signal everyone actually cares about — the trend. Decomposition is what turns a single confusing line into several honest ones.

The classic error: you see a series rise and fall a few times, declare it "seasonal", and start subtracting a 12-month pattern. But seasonality requires a fixed, calendar-locked period. The sunspot record oscillates beautifully — yet its "cycle" wanders between about 9 and 14 years and drifts in phase, so it is cyclical, not seasonal, and no fixed-period seasonal model will ever fit it. The test is simple: can you name the period in advance from the calendar or clock? Yes (a year, a week, a day) → seasonal. No (roughly-every-few-years, length varies) → cyclical. Force a seasonal model onto a cycle and you will "remove" a pattern that was never periodic, mangling the very turning points you wanted to study.

Three broad sources, and it helps to know which you are dealing with. Natural: the tilt of the Earth gives temperature, rainfall and crop yields a hard 12-month rhythm. Institutional / calendar: tax years, school terms, quarterly reporting, paydays — human schedules that repeat exactly. Social / religious: Christmas retail, Ramadan food consumption, the weekend. A subtle wrinkle: some of these are not on the solar calendar at all — Easter and Ramadan drift year to year, so a naive "same month every year" seasonal model misfires around them, which is why serious seasonal-adjustment software carries explicit "moving holiday" corrections.

A lighter, applied treatment of these same four components lives on the data-science side of the Primer at time-series components; this page is the rigorous version you build the rest of the module on. Next we make the split operational: how to actually estimate T_t and S_t from data with classical decomposition.