Trending
The holiday season is a strange forecasting problem. For most of the year, sales drift along a predictable path and a simple model handles it. Then a few weeks arrive where a large share of annual revenue lands, promotions overlap, and a snowstorm in one region shifts an entire weekend's numbers. Building a forecast for that window is one of the most useful mid-level machine learning projects you can take on, because the feedback is immediate and the constraints are real: you need numbers a buying or staffing team can act on, not a leaderboard score.
Forecasts only matter if they change an action. A weekly revenue prediction is mildly interesting; a prediction that tells a store manager how many shifts to schedule is useful. So before opening a notebook, write one sentence describing what someone will do differently because of your output.
Holiday decisions usually fall into a few buckets:
Each needs a different forecast. Inventory planning wants item-level demand with uncertainty ranges. Staffing wants an aggregate daily curve per store. Markdown timing is closer to a causal question — what happens if we change the price — and that is a different problem from pure prediction. Pick one, and resist the urge to build a model that answers all four at once.
Two tables carry most of the signal: a sales history and a calendar. Your sales history should have one row per date (or per date and store), with units and revenue kept separate. Units are what demand models generally want. Revenue folds price changes into the target and quietly turns a demand problem into a pricing problem.
The calendar table is where most of the gains live. Include day of week, week of year, holiday flags, distance in days to the nearest major holiday, payday indicators if they matter in your market, and promotional flags. Then add the feature people forget: a flag for weeks that shift. Thanksgiving moves between years and drags Black Friday, Cyber Monday, and the whole December run-up with it. If your model only sees "week 47," it will misread those weeks every other year.
Before modeling, check for stockouts. If an item was unavailable, recorded sales understate demand, and a model trained on those rows learns the wrong lesson. A zero-sales day caused by an empty shelf is not the same as a zero-sales day caused by no interest.
A baseline saves weeks of wasted effort. Try three cheap ones:
Measure error on the holiday window specifically, not on the full year. If a boosted tree model beats "last year, same week" by two percent, the extra machinery may not be worth the maintenance. Baselines also work as a production guardrail: if the model predicts three times the baseline, you want an alert, not a silent oversized order.
Create lag features for sales 7, 14, 28, and 364 days back — 364 rather than 365 keeps the day of week aligned. Add rolling means and medians over 7, 28, and 90 days, plus a year-over-year ratio so the model sees relative growth rather than raw volume.
Distance to Christmas in days usually beats the raw calendar date. "Days until Christmas" or "days relative to Black Friday" is a much easier relationship to learn than month and week number, and it stays stable when the calendar shifts.
Include a promo flag and a discount depth column. Without them, a model attributes a promotional spike to seasonality and confidently expects the same lift next year when nothing is on offer.
On retail data with a few years of history and solid calendar features, gradient boosting on lag and calendar inputs is a strong default. Classical options — exponential smoothing or SARIMA — are simpler, easier to explain to stakeholders, and produce intervals more naturally. Additive frameworks that handle multiple seasonalities and holidays with little tuning are a reasonable first pass when you want something working this week.
If you want to go further, try a global model with store ID as a categorical feature instead of training one model per store. Global models usually win when individual stores have thin history.
Backtesting is where projects succeed or quietly fail. Do it like this:
A model that is five percent off overall but forty percent off in the peak week is not ready. That peak week is the entire reason you built it.
A few failure modes show up again and again. Two seasons of history is a thin sample, so regularization and human judgment matter more than architecture. Structural shocks — a new competitor nearby, a store closure, a shipping cutoff that moved — cannot be learned from history, so leave room for a manual override. Promotion calendars written after the fact will teach the model about a past it cannot know in advance; be careful about which promo signals are available at prediction time. And watch for aggregation mismatches: forecasting per store and summing often gives a different answer than forecasting the region directly.
A forecast that lives in a notebook decays within a month. Wrap the pipeline so it runs on a schedule, writes predictions to a table, and logs the features it used. Track actual-versus-forecast error weekly and set a threshold that forces a review instead of letting silent drift accumulate.
Start small: one category, one region, one decision. Keep the naive baseline running alongside the model so you always know whether the complexity is earning its place. Store prediction intervals rather than point forecasts, because the buyer ordering inventory needs to know how much cushion to add. Then walk through the errors with the people who make the decisions — they know about the local road closure or the competitor's opening that your features never saw.
Run it through one full holiday season before expanding. The second year is where the project gets interesting: you have a real error history, a model that has seen a complete cycle, and a much clearer sense of which features were worth the trouble.
Photo: gonghuimin468 / Pixabay
