Skip to main content

How Seasonality Forecasting Works

A plain-language look at how Pricen learns when your products sell more or less across the year, and how that forward-looking view feeds into your pricing decisions.

Most products have natural demand rhythms. Winter coats sell more in autumn, sunscreen peaks in summer, and gift items spike around the holidays. Seasonality forecasting is the part of Pricen that detects these patterns automatically from your own sales history and projects them forward, so your pricing can anticipate demand changes rather than react to them after the fact.

You don't configure or run this yourself. It happens automatically as your data is processed, and its results feed other parts of the platform, primarily the pricing engine. This article explains what it does behind the scenes so you can understand where a forward-looking demand estimate comes from and how much to trust it. For how the pricing engine uses this alongside your demand curve, see How Price Simulation Works.

What the forecast produces

The output is a seasonal multiplier for each product, one for every day, a number that says how much above or below average demand is expected on a given date.

Multiplier

Meaning

1.0

Normal demand, no seasonal adjustment.

1.3

30% more demand than usual.

0.7

30% less demand than usual.

To keep thin or unusual data from producing extreme predictions, multipliers are capped between 0.01 and 3.0, so the system will never predict demand higher than three times the average.

Why it matters

Without a seasonal view, a pricing system can only look at what happened recently and assume it continues. That causes three problems you may recognise.

Mispricing during seasonal transitions. If a product sold well last week because it was entering peak season, a system without seasonality might treat that demand as permanent and be slow to adjust when the season ends. In a natural low season, it might cut prices unnecessarily and erode margin on sales that would have happened anyway.

Confusing price effects with demand. If you ran a 30% discount last July, your raw sales data shows a big July spike. A naive model would "learn" that July is a peak month. Pricen removes the influence of past price changes first, so the seasonal pattern reflects genuine customer demand, not the echo of an old promotion.

Stockout distortion. If a product was out of stock for two weeks in March, the data shows zero sales for those weeks. A simple system would conclude March is a low-demand month. Pricen recognises out-of-stock periods and estimates what demand would have been, so a stockout doesn't corrupt the forecast.

How the forecast is built

The process has three phases.

1. Clean the data. Before looking for patterns, the system corrects for things that would distort the picture. It fills in estimated demand for days a product was out of stock, and it removes the effect of past price changes: a product that was cheaper six months ago naturally sold more, but that's a price effect, not a seasonal one. What remains is the genuine calendar-driven demand pattern.

2. Find the seasonal pattern. The system builds the pattern up in layers, from broad to fine.

Layer

What it captures

Data it needs

Monthly

The big annual shape: is December stronger than June? Is there a summer lull?

At least 6 months of history

Weekly

The within-week rhythm: are Saturdays consistently stronger than Tuesdays?

At least 8 weeks of history

Holiday

Sharp, predictable spikes such as Black Friday or Christmas.

At least 2 years of history

Each layer is fitted on what remains after the previous one, so they don't interfere with each other, and at prediction time they're multiplied together. If December is 30% above average and Saturdays are 10% above average, a Saturday in December ends up roughly 43% above average (1.3 × 1.1 = 1.43).

Products are analysed in groups (for example, all products in the same category) rather than one at a time. Most individual products don't sell enough per day to reveal a clear pattern; the day-to-day randomness drowns it out. Pooling related products together reveals the shared seasonal rhythm, which is then applied back to each product at its own scale.

3. Generate the forecast. The group's seasonal pattern is applied back to each individual product, scaled to that product's own average sales level. The result covers both the historical period, so the fit against past data is visible, and a 90-day forward horizon.

How often it updates, and how far it looks

The forecast horizon is 90 days, roughly one quarter, which suits most pricing and inventory planning. Seasonality is recalculated every two weeks, so the 90-day window rolls forward continuously as new data arrives.

Products with very little history receive a flat forecast (all multipliers 1.0). This is a deliberate, safe default: the system is acknowledging it doesn't have enough information to detect a pattern, rather than guessing.

Why data quality matters

Every number the system produces is an estimate, and an estimate is only ever accurate enough, never exact. The forecast is learned from your historical sales, so its quality depends on the quality of that history: ideally there should be few or no missing days or missing values. Sparse sales, large gaps, or data unrelated to a product's real demand all make the estimates weaker. In short, garbage in, garbage out.

For the questions we hear most often about seasonal forecasts, see Seasonality Forecasting: Common Customer Questions.

Did this answer your question?