How should monthly product demand be forecast when each product has very little history?

Why per-product complexity is fragile with short histories

A monthly series with 18 observations contains only one complete annual cycle plus six more months. Even a series with 45 to 55 observations contains relatively few independent examples of a rare promotion, a price change, a discontinuation, a stockout, or a seasonal event. A separate model for every product must estimate level, trend, lag effects, perhaps seasonality, and possibly feature effects from that thin record. A flexible learner can fit the past closely without having learned anything that repeats.

This is why a lower training error is not enough. Forecast accuracy must be measured on future observations that were not used to fit the model. Forecasting: Principles and Practice warns that a sufficiently parameterized model can fit the training data perfectly yet forecast poorly. Forecast accuracy

The practical implication is not “never use machine learning.” It is to move complexity to a level where the data support it. One pooled model trained on thousands of product-month observations can share a price effect, calendar effect, or promotion response across related items. It can still make a distinct forecast for each product by using item and context features. The model should be regularized and compared honestly with simple local methods.

Monthly aggregation is usually appropriate if the operational decision is monthly production or purchasing. Returning to invoice-level transactions does not create more monthly demand outcomes. It can still improve the monthly dataset by revealing stockout dates, order cancellations, customer concentration, invoice timing, price, promotion exposure, backlog, and returns. Preserve those facts before aggregation, then use only the information that was actually known when a monthly forecast would have been issued.

Make the target honest before modeling

Decide what demand means. Invoiced quantity, shipment quantity, orders received, consumption, and required production are related but not interchangeable. A factory may need a production forecast that considers backlog, planned orders, inventory, lead time, and capacity, not merely next month’s invoices.

The most damaging data issue is a stockout. If a product was available for only part of a month, observed sales may be lower than customer demand. In a lost-sales setting, observed sales are capped by available inventory. In simplified form:

observed sales = minimum(true demand, available inventory)

The resulting sales data are censored. Treating a stockout month as ordinary low demand teaches the model to forecast too little, which can reinforce the next stockout. Research on censored-demand forecasting makes this distinction explicit: when stock is sufficient, sales can represent demand, but under stockouts sales underestimate unobserved demand. Demand forecasting under lost-sales policies Censored observations and inventory records

Build a monthly record with at least:

For future inputs, distinguish known plans from realized outcomes. A planned promotion and agreed price can be valid forecast-time features if they were committed before the forecast was made. Next month’s realized price, invoice, availability, or promotion result is future information and must not be used in a backtest for this month.

Establish baselines before trying a pooled model

Baselines are not a ceremonial first step. They reveal whether the data contain enough stable signal to beat a simple rule. A complex model that cannot beat them out of sample is not ready for production.

Keep the baselines small and transparent. Use the same availability rules, horizon, and origin dates for every candidate. For a three-month production decision, do not declare a model better because it wins at one month ahead while losing at two and three months ahead.

Annual seasonal-naive forecasts deserve special care. With 18 observations, a forecast for month 19 can compare only one prior same calendar month. It is sensible to include that comparison, because a month-of-year effect might matter. It is not sensible to give a separate product model many seasonal parameters or to assume that one previous December predicts every future December. Seasonal evidence becomes stronger when it repeats across multiple years and remains helpful in rolling backtests.

Match the method to the demand pattern

Classify each product using history, but keep the classes practical. The purpose is to choose sensible challengers and safety rules, not to create a perfect taxonomy.

Intermittent demand needs different baselines

Intermittent demand means frequent zero-demand periods, not merely small demand. Croston’s method estimates nonzero demand size and the interval between nonzero demands separately, then uses their ratio as an average demand-per-period forecast. That separation was designed for stock-control problems where ordinary exponential smoothing can behave poorly with intermittent requests. Croston 1972

Use at least these comparators for an intermittent item:

• Croston: a classic size-and-interval method. It is useful as a reference but has known bias in many settings.
• SBA: the Syntetos-Boylan approximation applies a correction to Croston’s forecast and is a common benchmark.
• TSB: the Teunter-Syntetos-Babai method smooths demand occurrence probability rather than waiting only for an interval update. It can reduce the forecast when demand stops arriving, which is valuable when obsolescence is plausible. Teunter, Syntetos, and Babai 2011

No method is automatically best for all intermittent products. The pattern may reflect true sporadic demand, stockouts, a new launch, erratic invoicing, a minimum order quantity, or an end-of-life product. Check the business process before interpreting zeros. Evaluate a method on its own pattern slice and on inventory outcomes, not only an all-product average.

Borrow strength with pooled and hierarchical forecasts

A pooled or global model learns one relationship across many related series rather than fitting a new relationship for each product. For example, it can learn how the last three months, product family, release age, known price change, and planned promotion relate to next month’s demand. Products with sparse history borrow information from the rest of the portfolio, while category and product attributes let their forecasts differ.

Start with a deliberately modest pooled model:

Regularized linear models, gradient-boosted trees, and other global learners can all be reasonable candidates. The choice matters less at first than the comparison design. If a pooled model uses hundreds of product-month rows but the baseline uses only the local series, the pooled model has a legitimate statistical advantage. It must nevertheless beat the baselines in rolling-origin tests and preserve expected behavior for important items.

Partial pooling is often a useful middle ground. Build separate pooled models for groups that have meaningfully different demand processes, such as spare parts, fast-moving consumables, and made-to-order capital components. Do not split so finely that each group repeats the original small-sample problem.

Reconcile products with their totals

Many operations need forecasts at several levels: individual product, family, category, plant, customer segment, region, and total factory demand. Independent product forecasts often do not sum to the independently forecast category total. Forecast reconciliation adjusts forecasts so the levels are coherent, meaning child forecasts add up to their parent forecast.

Aggregation can reveal signal that is invisible in a single product. A category may show a stable seasonal or promotional pattern even when its individual products are noisy. Hierarchical forecasting treats those aggregation relationships explicitly, and reconciliation can use information from more than one level. Forecasting hierarchical series Forecast reconciliation and MinT

Use hierarchy thoughtfully. Reconcile only valid summing relationships, such as units measured in the same unit and product families that are truly exhaustive. A category total cannot repair censored sales or a missing product mapping. With a very large number of bottom-level products and very short history, sophisticated reconciliation covariance estimates can themselves be unstable. Begin with a simple coherent approach, then validate a shrinkage or MinT reconciliation against it.

Include price, promotions, and cold starts without leakage

Price and promotion effects are especially easy to overstate. A discount may coincide with a holiday, a stockout, a clearance event, or a decision to promote an already high-demand item. A pooled forecast model can learn association, but it does not automatically establish a causal price elasticity.

For operational forecasting, use price and promotion variables when the future plan is known at forecast creation. If management wants to compare possible future prices, make scenarios. Hold all other inputs fixed where reasonable, produce a forecast for each scenario, and label the difference as model-based planning support rather than proof of causal impact. If pricing decisions require causal estimates, involve analysts with an appropriate experimental or causal design.

For a cold-start product, do not create fake history by copying a predecessor’s sales into its time series. Use a documented prior:

• An analog-product forecast based on attributes and comparable launches.
• A category or product-family rate adjusted for price, channel, and planned launch period.
• Confirmed orders, customer commitments, and planner judgment.
• A range of low, central, and high scenarios until actual sales accumulate.

Record the chosen analog and override rationale. Then shrink the prior toward observed item data as the product develops history. Treat a product relaunch, pack-size change, or customer-contract change as a possible new regime, not automatically as a continuation of the old series.

Backtest as the operation will forecast

Random train-test splits are invalid for time series because they let future observations influence training. Feature fitting can also leak. For example, scaling a demand feature using the full dataset, computing a category average including future months, or using final promotion status all feed future information into the past.

Rolling-origin backtesting avoids that error. At each origin, train only on the months available at that point, forecast the required horizon, then compare against the next observed months. The origin moves forward and the errors are averaged. This is the standard time-series cross-validation design. Forecasting: Principles and Practice on rolling origins

For each backtest fold, rebuild every time-dependent object from the training slice:

1. Product lags, moving averages, zero rates, and seasonal features.
2. Product or category encodings and normalization statistics.
3. The censored-demand or availability treatment.
4. Any model-selection and hyperparameter rule.
5. Future price, promotion, calendar, and commitment features as they were known at that origin.

Freeze the forecast issue date and retain a small “as-of” dataset for each fold. This can feel laborious, but it is the difference between a forecast test and a retrospective data analysis.

Which accuracy measure to use

Avoid MAPE as a primary portfolio measure when products can have zero or near-zero demand. Percentage errors are undefined at zero and unstable near zero. MASE scales absolute error by an in-sample naive benchmark, making errors more comparable across differently scaled products. RMSSE uses squared scaled error and is useful when larger misses deserve greater penalty. Forecast accuracy measures

For a nonseasonal series, MASE divides the average absolute forecast error by the average absolute one-step change in that product’s training history. A MASE below one means the method beat that naive scale on average. RMSSE uses the corresponding squared-error scale. Both need a fallback policy when a product’s naive denominator is zero, such as a constant historical series.

The M5 forecasting competition used a weighted RMSSE across a large hierarchy. That is a useful reminder to weight products by the business objective rather than allowing thousands of tiny, low-value items to decide the model. Its particular weights are not a universal inventory objective. M5 accuracy competition results

Report at least:

Forecast accuracy is not the same as inventory performance. An under-forecast may be much more costly than an over-forecast for a critical spare part, while excess inventory may dominate for a perishable product. Evaluate the forecast distribution with the actual replenishment lead time, review cycle, order constraint, cost of shortage, holding cost, and target service level.

Worked example with 18 monthly observations

Hypothetical setup: A factory has 250 products with 18 consecutive monthly observations each and must issue a three-month forecast. Units are the target, but the source data also record stockout flags, product family, planned price, planned promotions, and lifecycle status. The first task is to compare forecast methods, not to select a favorite algorithm.

Use four three-month rolling origins:

Origin A: train months 1 to 12, forecast months 13 to 15
Origin B: train months 1 to 13, forecast months 14 to 16
Origin C: train months 1 to 14, forecast months 15 to 17
Origin D: train months 1 to 15, forecast months 16 to 18

At every origin, generate forecasts for these candidates:

1. Local naive, recent three-month available-demand average, simple exponential smoothing, and seasonal naive where month t minus 12 exists.
2. Croston, SBA, and TSB for products classified as intermittent, plus the same simple baselines.
3. A pooled regularized model for all non-cold-start products, using product family and attributes, lagged available demand, calendar, availability, and only commercially planned future inputs.
4. An attribute-based pooled cold-start model or analog prior for products without usable history.
5. Product and family forecasts reconciled to the factory total, if that total is a valid planned aggregate.

The comparison table below uses invented values only to show how to make a choice. It is not evidence that one method will perform this way for another factory.

The selection is not “the pooled model wins, deploy it everywhere.” Route smooth and regular products to the pooled model if it consistently improves their backtest and remains calibrated. Route intermittent items to the best validated intermittent method. Keep a naive or lifecycle rule for items that none of the models can beat. For every route, generate 50%, 80%, and 95% prediction intervals or quantiles, check coverage on the rolling folds, and feed the selected forecast distribution into a lead-time inventory simulation.

The takeaway is that 18 observations are not enough to discover every product’s private law of motion. They can still support a disciplined decision when simple baselines, portfolio-level learning, pattern-specific methods, and leakage-free evaluation work together.

A practical implementation sequence

1. Audit the target. Reconcile invoices, orders, shipments, returns, stock availability, backorders, and product status. Label censored months and decide whether the forecast is for sales, demand, or production requirement.

2. Build a baseline scoreboard. Implement naive, moving-average, exponential-smoothing, seasonal-naive, and zero or lifecycle policies before a complex model.

3. Classify and route demand. Identify intermittent, new, obsolete, promotional, regular, and possible seasonal products. Keep rule reasons in the data so a planner can challenge them.

4. Develop a small pooled challenger. Add category and product attributes, known calendar and commercial-plan inputs, availability, and carefully created lags. Start with strong regularization and a limited feature set.

5. Add hierarchy and intervals. Forecast relevant aggregate levels, reconcile valid totals, and produce calibrated ranges instead of only point forecasts.

6. Use rolling origins. Compare every method at the actual horizon, by item slice and business importance. Log the as-of date and feature availability for every fold.

7. Simulate the decision. Convert forecasts into the inventory or production rule actually used. Measure service, shortage, holding, expedite, and obsolescence effects.

8. Operate with guardrails. Monitor bias, interval coverage, stockout flags, model routing, overrides, product launches, discontinuations, and changes in commercial plans. Retrain or re-evaluate after a material change.

Limits and viable alternatives

Short history imposes a real ceiling on forecast precision. A better algorithm cannot recover demand that was hidden by stockouts, make a one-time promotion repeat, or infer a product’s seasonality from a single historical match. Where the signal is weak, a range, an analog prior, or a planner scenario is more honest than an overconfident point forecast.

If the portfolio contains only a handful of products, a global machine-learning model may not have enough cross-product examples either. In that case, rely on simple local methods, category or aggregate forecasts, expert judgment recorded as an override, and explicit scenarios. If the portfolio is large but internally heterogeneous, use partial pools or separate demand-process groups rather than one model dominated by high-volume products.

Do not treat automatic model selection as an unreviewable production decision. New products, discontinued products, policy changes, price shocks, lost customers, new contracts, and data-quality failures can invalidate historical relationships. A planner override can be appropriate when it has a documented reason and is measured against the baseline over time.