Seasonality Analysis

A statistical study that averages historical returns by calendar slot — day of week, month of year, or hour of day — to describe recurring patterns in past data.

What it is

Seasonality analysis groups historical price changes by a calendar dimension — day of the week, month of the year, hour of the day, or day of the month — and averages the returns within each group. The output is a profile such as 'the average Tuesday close-to-close change over the last 500 trading days' for each weekday. Unlike a plotted line indicator, seasonality is a summary statistic: it condenses many past observations into one number per calendar slot. Analysts use it to describe tendencies like month-end flows, session-open volatility, or the much-discussed monthly effects in equities. It is important to be precise about what this is: a backward-looking average of noisy data, not a forecast. An average is not a guarantee — a positive 'average Friday' can coexist with many sharply negative Fridays, and a pattern measured in one sample can vanish in the next. Seasonality output is educational, descriptive context only, not financial advice, and trading involves risk of loss regardless of what any historical average shows.

How it works

The mechanics are deterministic averaging. First choose a return definition — typically the percentage close-to-close change of each bar, which keeps observations comparable across price levels. Second, choose a calendar bucket: on a daily chart, the weekday of each bar; on a monthly view, the calendar month; on intraday charts, the hour or session. Each bar's return is added to its bucket's running sum, and a count is kept per bucket. The seasonal value for a bucket is its sum divided by its count — a plain arithmetic mean. Done correctly, this must respect the chart's timezone (a 'Monday' in exchange time may differ from UTC), handle holidays and missing sessions by simply skipping them rather than filling zeros, and use only confirmed bars so the current forming bar does not distort the average. The critical statistical caveat is the multiple-comparisons problem: if you scan seven weekdays, twelve months, thirty-one days-of-month, and twenty-four hours, you are running dozens of implicit tests, and some buckets will look impressive purely by chance. With roughly 100 observations per weekday bucket, the standard error of the mean is often as large as the mean itself — which is why honest seasonality work reports sample sizes and dispersion, not just the averages.

How traders read it

• Read each bucket's value as 'the historical average return for this calendar slot in this sample' — a description of the past, not a prediction of the next occurrence.
• Always check the sample size behind a bucket: an 'average January' built from ten Januaries is ten data points, far too few to distinguish signal from noise.
• Compare the average to the spread: if the average Tuesday is +0.05% but individual Tuesdays range from -3% to +3%, the average tells you almost nothing about any single Tuesday.
• Be suspicious of the strongest-looking bucket — scanning many calendar slots guarantees some will look significant by chance alone (the multiple-comparisons trap).
• Check stability by splitting the history in half: a pattern present in the first half but absent in the second is more likely noise or a regime that ended.
• Watch timezone and session alignment on intraday seasonality — an 'hour 8' bucket means different things in UTC, exchange time, and your local chart timezone.

Common settings

There are no standard indicator settings, only study choices: the return definition (close-to-close percentage change is common), the calendar bucket (weekday on daily charts, month on monthly views, hour or session intraday), and the lookback window (for example 2-5 years of daily bars, giving very roughly 100-250 observations per weekday). Longer lookbacks give larger samples but mix in older market regimes; shorter ones are more current but statistically weaker. The chart timezone setting materially changes intraday and weekday bucketing and should always be stated with any result.

Strengths

• Fully deterministic and reproducible — given the same data, bucket definition, and timezone, everyone gets the same averages.
• Makes vague folklore ('mondays are weak') into a checkable, quantified statement with a sample size attached.
• Useful descriptive context for when volatility and participation tend to cluster (session opens, month-end, major-session overlaps).
• Simple arithmetic with no smoothing parameters to curve-fit — the honesty risks lie in interpretation, not calculation.
• Naturally pairs with dispersion and sample-size reporting, encouraging statistically honest analysis.

Pitfalls to watch

• Multiple comparisons: scanning many calendar buckets (7 weekdays x 12 months x 24 hours...) means some patterns will look significant purely by chance; the more slots you test, the more false positives you harvest.
• Small samples: even five years of data yields only about 60 monthly observations split across 12 months — five per bucket — far too few for reliable conclusions.
• Regime change: seasonal effects measured over old data can weaken or invert; a historical average carries no mechanism that forces it to persist.
• Timezone and DST errors: intraday and weekday buckets shift silently if the chart timezone or daylight-saving handling differs from the session you think you are measuring.
• Averages hide dispersion: a bucket's mean can be dominated by one or two outlier bars, making a 'strong' seasonal slot an artifact of a single event.
• No predictive power: a seasonal average is a description of past data, not a forecast, and trading on it still carries full risk of loss.

Pine v6 example

//@version=6
indicator("Day-of-Week Average Return", overlay = false)

// Accumulates the average close-to-close % change per weekday.
// Descriptive statistics only - averages of past data, not forecasts.
var float[] sums   = array.new_float(7, 0.0)
var int[]   counts = array.new_int(7, 0)

pctChange = 100.0 * ta.change(close) / close[1]

if barstate.isconfirmed and not na(pctChange)
    idx = dayofweek - 1 // 1 = Sunday ... 7 = Saturday
    array.set(sums, idx, array.get(sums, idx) + pctChange)
    array.set(counts, idx, array.get(counts, idx) + 1)

todayIdx = dayofweek - 1
n = array.get(counts, todayIdx)
avgToday = n > 0 ? array.get(sums, todayIdx) / n : na

plot(avgToday, "Avg % change, this weekday", color = color.blue, style = plot.style_histogram)
hline(0, "Zero", color = color.gray)

Pro tip: Before trusting any seasonal pattern, count how many calendar slots you scanned to find it and divide your enthusiasm accordingly — testing dozens of buckets guarantees a few will look good by luck. Then split your history in half and check the pattern exists in both halves, and always read the average next to its sample size and spread. This is educational statistical context only, not advice: a historical average predicts nothing, and trading involves risk of loss.

Educational only — not financial advice, not a recommendation to trade. No indicator is predictive; trading involves substantial risk of loss.