Two FMCG demand planners can run the exact same forecasting algorithm on the exact same raw sales history and get meaningfully different accuracy — not because one model is smarter, but because one planner fed it far better inputs. Feature engineering is the unglamorous work of turning raw transaction data into the signals a model can actually learn from, and in FMCG categories it is often the single biggest lever on forecast accuracy, ahead of the algorithm choice itself. Teams looking to close this gap can Book a Demo to see how iFactory's feature libraries are built for FMCG demand patterns specifically.
Why Raw Sales History Is Not Enough on Its Own
A time series of weekly unit sales tells a model what happened, but it doesn't tell the model why, and forecasting models that only see the raw number tend to repeat past patterns blindly rather than adapting to what's actually driving demand. A spike three weeks ago might have been a promotion, a competitor stockout, or a cold snap that drove soup sales — and without features that separate these causes, the model has no way to know which pattern is likely to repeat and which was a one-off. Feature engineering is what gives the model the context a human planner would use instinctively.
Lag and Rolling Window Features: Capturing Momentum Without Overfitting
Lag features are the most intuitive starting point — feeding a model last week's sales, sales from four weeks ago, and sales from the same week a year ago gives it a sense of both recent momentum and seasonal repetition. The risk is including too many lag periods, which can cause a model to overfit to noise in the historical data rather than learning genuine patterns. Rolling window features address part of this problem by smoothing short-term volatility into a trailing average or sum, giving the model a cleaner trend signal that's less sensitive to any single unusual week.
The right combination of lag depth and window length varies by category maturity and volatility. A stable, high-volume staple category can often rely on shorter lag windows since its demand pattern is consistent, while a newer or highly promotional category benefits from longer rolling windows that average out the noise from frequent promotional spikes.
Calendar and Event Features: Encoding the FMCG Demand Rhythm
FMCG demand follows recurring calendar rhythms that a generic time series model won't infer on its own — payday-driven spikes at the start and middle of the month, holiday lead-up surges that vary by category, and day-of-week patterns that differ between weekday convenience purchases and weekend stock-up trips. Calendar features encode these rhythms explicitly, so the model doesn't have to rediscover them from a limited history of past holidays that may not repeat identically each year.
Event features capture the sharper, less-recurring shifts that calendar features can't explain — a promotion running this week, a price change last month, or a new distribution point that came online. These features are what separate a genuine demand shift from noise, and without them a model risks treating a one-time promotional spike as a pattern likely to repeat on its own next month.
| Feature Type | What It Captures | Risk If Omitted |
|---|---|---|
| Calendar features | Recurring rhythms tied to day, month, and holiday timing | Model misses predictable seasonal shifts entirely |
| Event features | Non-recurring shifts from promotions, pricing, and distribution changes | Promotional spikes get misread as a recurring trend |
| External features | Outside factors like weather influencing category-specific demand | Weather-sensitive categories show unexplained volatility the model can't learn from |
External Features: When Weather and Local Context Actually Matter
Not every FMCG category benefits equally from external features — a shelf-stable pantry staple with steady year-round demand gains little from weather data, while beverages, soups, ice cream, and seasonal personal care items can show demand swings tightly correlated with temperature and local conditions. Adding external features indiscriminately across an entire portfolio wastes modeling effort on categories where the signal doesn't apply, while skipping them on genuinely weather-sensitive categories leaves real accuracy on the table.
The practical approach is testing external feature relevance category by category rather than assuming a blanket rule, since the same weather variable that meaningfully improves a beverage forecast may add nothing but noise to a laundry detergent forecast running through the same model pipeline.
Frequently Asked Questions: AI Forecast Feature Engineering for FMCG
How many features are too many for a single forecasting model?
There isn't a fixed universal number, but adding features without evaluating whether each one genuinely improves accuracy on validation data tends to introduce noise faster than it adds signal, particularly for lower-volume SKUs with limited historical data to support a large feature set. A disciplined approach tests feature contribution systematically and prunes features that don't measurably improve out-of-sample accuracy, rather than including every available feature by default. Teams building this discipline can Book a Demo to see how feature selection is validated in practice.
Do new product launches need a different feature approach than established SKUs?
Yes — lag and rolling window features depend on historical data that a new launch simply doesn't have yet, so early-life forecasting typically leans more heavily on calendar, event, and analog-product features borrowed from comparable historical launches until enough of the new SKU's own history accumulates to support standard lag-based features reliably.
How often should feature libraries be refreshed as category behavior changes?
Feature relevance can shift as consumer behavior, competitive activity, or distribution patterns change, so periodic revalidation — commonly on a quarterly or seasonal cycle — catches features that have stopped adding value and identifies new signals worth testing, rather than leaving a feature set static indefinitely after initial setup.
Can feature engineering compensate for genuinely poor-quality raw sales data?
Feature engineering can smooth out some noise and fill certain gaps, but it cannot fully compensate for systematically inaccurate underlying data, such as point-of-sale records that don't reconcile with actual shipments or inventory counts. Cleaning the underlying data pipeline generally delivers more accuracy improvement than any amount of feature engineering layered on top of unreliable inputs.
Should every category in a portfolio use the same feature set?
No — a uniform feature set applied across a diverse FMCG portfolio tends to underperform a category-specific approach, since a weather-sensitive beverage category and a stable pantry staple respond to very different signals. Grouping categories by demand behavior and tailoring feature sets to each group strikes a practical balance between full customization and manageable maintenance overhead. Contact iFactory Support for guidance on grouping categories for feature strategy.
