Time series and forecasting · insight-1236
Convert monthly totals to per-day or per-trading-day rates before modelling seasonality
- Evidence type
- documented fact
- Difficulty
- easy
- Roles
- Data analyst, Data scientist
- Industries
- retail, finance, e-commerce
Summary: situation, action, reason, boundary
Situation
Monthly revenue for a retailer swings partly because months contain different numbers of trading days, and the seasonal model learns a short-February dip and a long-month bump as seasonality.
Action
Divide each month's total by its trading days, model the per-day rate, and multiply the forecast by the future calendar's trading days. When the weekday mix matters, use counts of each weekday as regressors instead.
Reason
Calendar adjustment removes variation that comes from the number of days rather than from demand, so the model does not have to learn it as a seasonal pattern.
Boundary
Monthly and quarterly sales, bookings, claims and cash-flow series with trading-day sensitivity.
Symptom or risk
Seasonal indices absorb calendar length and month-to-month noise stays higher than it needs to be.
Exceptions
Quantities not proportional to days, such as month-end stock, should not be divided by days.
Trade-offs
The forecast of totals now depends on a correct future trading-day calendar, including local holidays.
Pitfalls
Forgetting to multiply back, so a daily rate is published as a monthly total.
Example
Hypothetical: two months with the same daily rate of 100 units total 2,800 units over 28 days and 3,100 units over 31 days, a 10.7% apparent jump (31/28 = 1.107) with no change in demand.
Lessons and concepts
Claims and their sources
FPP3 gives the example of monthly retail sales being divided by the number of trading days so that the analysis uses average sales per trading day instead of monthly totals.