How should you scale 3,000 SKU series whose volumes span four orders of magnitude for one shared forecaster?

## Why scaling is not optional here A global forecaster shares one set of weights across thousands of series. The recurrent cell has one input weight matrix, one set of saturating non-linearities and one learning rate, and it sees a value of 2 from one SKU and 20,000 from another. Without scaling, the large series drive the activations into saturation, the gradient magnitudes across the batch differ by orders of magnitude, and training is unstable or simply ignores the small series. ## Why a pooled scaler is the wrong fix The reflex is to fit one standardiser on all the data. Consider what that does with a pooled mean around, say, 400 units and a pooled standard deviation of several thousand. The 20,000-unit SKU occupies a wide range of scaled values. The two-unit SKU maps to something like -0.13 every single day; its entire dynamic range — the difference between a good day and a bad day — is a rounding error in scaled space, smaller than the noise the weight initialisation introduces. Under a squared-error loss the model gets almost no gradient from it, so the cheapest policy is to output the same near-constant for it forever. You will see this as a portfolio where the top hundred SKUs are forecast well and the long tail is a flat line. ## Per-series scaling schemes **Mean scaling.** Divide each series (and its targets) by that series' training-period mean, usually `1 + mean` to survive zeros. Every series then averages around 1 regardless of size. This is the workhorse for demand data: it is robust, cheap, and inverts by a single multiplication. **Per-series standardisation.** Subtract that series' own training mean and divide by its own training standard deviation. Works well for roughly symmetric series; less well for intermittent demand, where the standard deviation is dominated by rare spikes. **Log then centre.** For volumes spanning four orders of magnitude, `log1p` compresses the range before any centring and turns multiplicative variation into additive variation. Remember that a model trained on log targets and inverted naively predicts something closer to a median than a mean — decide whether that is what the business wants. **Window-relative (instance) scaling.** Divide each input window *and its target* by a statistic of that window — its mean, or its last value. Now the model predicts a ratio to the current level rather than an absolute magnitude, which handles trending series and level shifts, and lets forecasts exceed anything seen in absolute training units. You multiply the level back in at inference. ## Give the model back what scaling removed Scaling deliberately erases size, but size is informative: a 20,000-unit SKU is smoother, more predictable and differently seasonal than a two-unit one. Feed the log of the series scale back in as a static feature alongside category, price band and store. The model then learns size-dependent behaviour explicitly instead of having to infer it from magnitudes it can no longer see. ## Leakage, cold start and inversion - **Fit on training data only.** Computing a series' mean over its whole history, evaluation period included, leaks future level into every training row and flatters the backtest. Compute per series on the training window, store the scales, apply them unchanged afterwards, and recompute them at each scheduled refresh. - **Cold start.** A SKU with three weeks of history has no stable scale. Borrow one: the median scale of its category, price band or store cluster, and pass the group identity as a feature. Estimating a scale from a handful of noisy points is worse than inheriting a stable one. - **Invert before you report.** Errors measured in scaled units are meaningless to the business and not comparable across series. Multiply the forecast back into units before any accuracy or inventory calculation. ## The consequence nobody mentions Per-series scaling makes every series contribute roughly equally to the loss. That is usually what you want for long-tail accuracy, but it is a business decision disguised as preprocessing: a tiny SKU now counts as much as a flagship. If the objective is revenue-weighted error, re-weight the loss explicitly by volume or margin rather than letting the scaler choose the priority for you. Scaling is where a multi-series forecaster silently decides what it cares about.