Sales do not always vary at random. Demand can rise or fall with recurring cycles—days of the week, months, quarters, or years. In a forecasting system, these patterns affect how much history to collect, how to test predictions, and what counts as a useful baseline. section 7.2.4 section 8.6.1
Account for the cycle throughout the forecasting workflow:
- Collect enough history to observe it. More than three years of retail transactions can help a model learn seasonal sales patterns; timestamps also allow holiday information to be added. section 6.7.1
- Match validation windows to the cycle and the production forecast horizon. Yearly patterns call for at least two years of training history; for weekly patterns, use whole weeks in each test fold so folds contain the same weekdays. section 7.2.4
- Test a simple seasonal baseline before adopting a more elaborate model. If grocery sales have strong weekly seasonality, last week’s sales for the same product and store may be more useful than yesterday’s. section 8.6.1
- Monitor recurring changes without treating every expected peak as an incident. If periodic changes hurt performance, consider incorporating them into the model or using an ensemble. section 14.4.4
Same weekday, not previous day
To forecast sales for an item at a particular grocery on September 8, use its actual sales on September 1 as a baseline. This one-week lag reflects weekly shopping patterns and allows for data that arrives late. It is a benchmark to compare against alternatives such as lag-based linear models or seasonal forecasting methods. section 8.6.1
A predictable weekend increase in loungewear demand should be anticipated rather than automatically trigger a drift alert. The operational question is whether the model captures the recurring pattern well enough to maintain forecasting performance. section 14.4.4
