Forecasting and Time-Series Analysis Questions

Direct answer
Moving beyond raw accuracy, a forecast's business value can be measured through KPIs like stockouts prevented, holding-cost reduction, and revenue uplift - each computed by comparing what actually happened (with the forecast-driven decision in place) against a credible counterfactual of what would have happened under a naive or prior approach, with attribution challenges handled by isolating the forecast's specific contribution from other simultaneous operational changes.

Structured elaboration

• Stockouts prevented: compare the actual stockout rate under the current (forecast-informed) inventory policy against a counterfactual - either the stockout rate the OLD policy would have produced on the same demand realization (if you can simulate it), or a controlled holdout where a subset of SKUs/stores continued using the old approach as a genuine comparison group.
• Holding-cost reduction: compute the excess inventory carried under the old policy versus the new forecast-informed one, valued at the business's actual holding-cost rate (capital cost, storage, spoilage/obsolescence risk) - this requires the SAME kind of counterfactual comparison as stockouts, not just "inventory went down," since inventory could fall for unrelated reasons (a demand drop, say).
• Revenue uplift: the incremental revenue attributable to better availability/staffing/allocation decisions the improved forecast enabled, computed similarly by comparison against a credible counterfactual rather than simply period-over-period revenue growth (which conflates many causes).
• Computing these from historical forecasts and actuals: requires not just the forecast and the actual outcome, but a record of what DECISION the forecast drove (the resulting inventory order, staffing level, allocation) so you can quantify the downstream operational consequence, not just the raw forecast error - a forecast can be numerically accurate yet drive a poor decision if the decision rule built on top of it (e.g. the safety-stock formula) is miscalibrated.
• Attribution challenges when multiple changes happen simultaneously: if inventory policy, pricing, AND the forecasting model all changed in the same quarter, isolating the forecast's specific contribution to any observed improvement requires either staggering the rollouts (so each change's effect window is at least partially separable), a genuine holdout/control group that kept the old forecast while everything else changed identically, or, at minimum, an honest acknowledgment in the reporting that the estimate is a joint effect of several changes rather than the forecast's alone.

Worked example
A holding-cost-reduction claim of "$500K saved this quarter" is only credible if it's benchmarked against a stated counterfactual (e.g. "versus the safety-stock levels the prior policy would have required for the same realized demand") - reported without that counterfactual, the number is really just "inventory happened to be lower," which could equally reflect a demand slowdown having nothing to do with forecast quality.

Trade-offs & pitfalls
The recurring failure mode across all three KPIs is presenting a raw before/after comparison as if it were the forecast's isolated causal contribution, when in a real operating business, demand, pricing, promotions, and policy all move simultaneously - treat any business-value number without an explicit counterfactual or control group as a directional estimate, not a precise measurement, and say so plainly when reporting it.

Direct answer
Regression to the mean is the statistical tendency for an unusually extreme observation to be followed by a less extreme one, simply because part of what made it extreme was noise that isn't expected to repeat - not because of any real change in the underlying process; failing to account for it makes forecasts and post-campaign evaluations systematically over-optimistic when they extrapolate from a good period, or overly pessimistic when they extrapolate from a bad one.

Structured elaboration

• The mechanism: any observed value is (true underlying level) + (noise); an unusually extreme observation is likely to have both an unusually favorable true level AND unusually favorable noise. The true-level part tends to persist into the next period, but the noise part does not - so the next observation, on average, falls back partway toward the mean, purely from the noise component reverting, with no real underlying change required.
• Numerical example: suppose a metric's true underlying weekly level is stable at 100 with random noise of standard deviation 15. A week that happens to land at 130 (2 standard deviations above the mean, largely luck) will, on average, be followed by a week closer to 100 again - not because anything changed, but because it would be a coincidence for the SAME lucky noise draw to repeat. Naively forecasting "next week will be like this week, ~130" ignores this and will be systematically too optimistic.
• Implications for evaluating one-off campaigns or initiatives: a campaign launched right after an unusually LOW period will look artificially successful (the metric was always going to bounce back somewhat, campaign or not) - regression to the mean alone can generate a misleading "before/after" success story with no real causal effect present. Symmetrically, a campaign launched right after an unusually HIGH period can look like it failed, when the metric was always going to soften somewhat regardless.
• Misleading naive YoY forecasting from a single extreme observation: if last year's same period happened to be an outlier (an unusually strong or weak one-off promotion, say), a naive year-over-year forecast that simply extrapolates last year's number forward inherits that noise directly, systematically over- or under-forecasting; this specifically argues for basing a YoY-style forecast on a smoothed or averaged recent baseline (or an explicit model that separates trend from noise) rather than a single prior data point.
• How to adjust for this risk: use a baseline drawn from MULTIPLE periods (an average or a model-based expected value) rather than a single extreme observation, and when evaluating a campaign or initiative launched near an extreme period, compare against a proper counterfactual (a comparable unaffected cohort, or a model-based expected trajectory) rather than a naive before/after comparison - the same counterfactual-thinking discipline that separates forecasting from causal inference generally.

Worked example
Marketing sees a campaign-cohort's performance spike, then decline in subsequent periods, and worries the campaign is "losing effectiveness" - but if the cohort was selected or analyzed BECAUSE it had an unusually strong initial period, some of that decline is pure regression to the mean, not a genuine effectiveness drop; modeling expected future performance with an approach that explicitly accounts for this (shrinking the initial extreme observation toward a broader baseline before projecting forward, rather than extrapolating the peak directly) avoids over-reacting to noise as if it were a real trend.

Trade-offs & pitfalls
The practical discipline this all points to is the same one: never treat a single extreme data point as your baseline for either a forecast OR a causal before/after comparison - always ask whether some of what you're observing is simply the ordinary reversion of noise, and build your baseline (and your evaluation design) to be robust to that possibility.

Direct answer
Converting a probabilistic demand forecast into a safety-stock and reorder-point policy means quantifying how much extra inventory you need to cover demand variability over the lead time at your target service level; under a normality assumption there's a clean closed-form formula, but non-normal or skewed demand (very common for real products) requires either a distribution-appropriate formula or a simulation-based approach instead.

Structured elaboration

• Required assumptions: a specified lead-time DISTRIBUTION (how long between placing and receiving an order, and its variability) and a target SERVICE LEVEL objective (e.g. "we want to avoid stockout in 95% of replenishment cycles"), which translates to a specific critical value (z-score, under normality) you're willing to hold inventory against.
• Safety stock formula under normality: the general formula, when BOTH per-period demand and the lead time itself are random (matching the "lead time distribution" assumption stated above), is $SS = z \cdot \sqrt{L \cdot \sigma_{d}^2 + \bar{d}^2 \cdot \sigma_{L}^2}$, where $z$ is the standard-normal critical value for the target service level (e.g. z≈1.65 for 95%), $\sigma_d$/$\bar d$ are the standard deviation and mean of PER-PERIOD demand, $L$ is the mean lead time, and $\sigma_L$ is the standard deviation of the lead time itself - this last term is what actually uses the lead-time DISTRIBUTION (not just its average). If lead time is genuinely constant ($\sigma_L = 0$), this collapses to the simpler, commonly-quoted special case $SS = z \cdot \sigma_{LT}$ with $\sigma_{LT} = \sigma_d \sqrt{L}$ (assuming independent demand periods) - but that simplification silently drops the lead-time-variability term, and understates true safety stock whenever the lead time itself is variable (e.g. an unreliable supplier), since lead-time variance contributes its own, often sizeable, share of the combined variance. Reorder point $= \text{expected demand over lead time} + SS$.
• Non-normal distributions and skew: intermittent or heavy-tailed demand (exactly the kind Croston/TSB or quantile-based methods are built for) violates the normality assumption the formula above relies on - for such series, either derive the safety-stock quantile directly from the demand distribution's ACTUAL shape (e.g. read the desired service-level quantile straight off a fitted or empirical distribution rather than assuming Normal), or use a probabilistic/quantile forecasting approach directly: concretely, quantile regression (gradient-boosted trees such as LightGBM or XGBoost, or even a plain linear quantile regression) trained with a pinball/quantile loss AT the target service-level quantile (q=0.95 for a 95% service level), or a distributional forecaster like DeepAR or NGBoost that predicts a full demand distribution for each future period. Either way, you read the demand value at the target quantile directly off the fitted model for every period in the lead time and set safety stock as that quantile forecast minus the mean forecast - this sidesteps the normal-approximation formula entirely, because the quantile comes from the model's own fitted distributional shape (which can be skewed or heavy-tailed) rather than an assumed Gaussian z-score.
• Validating the policy using historical simulation: replay the policy (safety stock + reorder point, as computed) against HISTORICAL demand and lead-time realizations, simulating what would have actually happened (stockouts, holding costs) under that policy - this is the practical check that catches a policy whose theoretical service level doesn't hold up against genuine historical variability (e.g. because the normality assumption was a poor fit, or lead-time variability was underestimated).

Worked example
For a fast-moving, roughly-normally-distributed item with a FIXED (zero-variance) 2-week lead time and weekly demand standard deviation of 50 units targeting 95% service level - i.e. the deterministic-lead-time special case above: $\sigma_{LT} = 50\sqrt{2} \approx 70.7$, so $SS \approx 1.65 \times 70.7 \approx 117$ units. For an intermittent, heavy-tailed item, that same formula would badly understate the true safety stock needed at the tails - the probabilistic-vs-deterministic framing matters here specifically because a deterministic (point-forecast-only) approach has no principled way to derive a safety-stock number at all; it needs an explicit distributional or quantile-based input to do this calculation honestly.

Trade-offs & pitfalls
The most common real-world failure mode is applying the normal-distribution safety-stock formula uniformly across a whole catalog without checking which SKUs actually have roughly-normal demand and which are meaningfully skewed or intermittent - a one-size-fits-all formula will systematically under-protect the skewed/intermittent tail of the catalog (exactly the SKUs most prone to stockouts) while potentially over-protecting (holding excess inventory for) the well-behaved, normally-distributed majority.

Direct answer
ARIMA(p,d,q) models a series as a combination of three pieces: AR(p), autoregression on the series' own past p values; I(d), the number of times you difference the series to make it stationary; and MA(q), a moving average of the past q forecast errors. You identify p and q by reading the ACF and PACF plots of the (differenced) series, and you add seasonal terms (SARIMA) when the ACF/PACF still show a repeating spike pattern at the seasonal lag after ordinary differencing.

Structured elaboration

• AR(p): today's value is a linear function of the last p values plus noise. A PACF that cuts off sharply after lag p (with earlier lags significant) points to an AR(p) term, because the PACF isolates the direct effect of each lag after removing the effect of the lags in between.
• I(d): the number of times you difference $y_t$ (i.e. work with $y_t - y_{t-1}$, or the second difference) before the series is stationary. You determine d with a stationarity test (ADF/KPSS) rather than by eye: difference until the test says stationary, and stop as soon as it does. Over-differencing (d too large) introduces artificial negative autocorrelation and inflates forecast variance.
• MA(q): today's value depends on the last q forecast errors, not raw values. An ACF that cuts off sharply after lag q (while the PACF decays slowly) points to an MA(q) term.
• Order identification in practice: plot ACF and PACF of the differenced series. AR signature = PACF cuts off, ACF tails off. MA signature = ACF cuts off, PACF tails off. Mixed ARMA signatures (both tail off) are common in practice, so analysts usually also compare a small grid of candidate (p,d,q) by AIC/BIC rather than trusting the plots alone.
• When to add seasonal terms (SARIMA): if, after taking the ordinary difference, the ACF/PACF still show significant spikes at the seasonal period (e.g. lag 7 for daily-with-weekly-seasonality data, lag 12 for monthly-with-yearly-seasonality), a plain ARIMA hasn't captured the seasonal structure. SARIMA adds seasonal AR/MA/differencing terms $(P,D,Q)_s$ operating at multiples of the seasonal period s, on top of the ordinary $(p,d,q)$ terms.

Worked example
Take daily retail sales with a weekly pattern. Fitting an ARIMA(1,1,1) leaves a residual ACF with a clear spike at lag 7 (and 14, 21) - the model has removed the trend (via d=1) but not the weekly repetition. Adding a seasonal term, e.g. SARIMA(1,1,1)(1,0,1)$_7$, lets the seasonal AR/MA terms absorb that lag-7 structure; after refitting, the residual ACF should show no significant spikes at multiples of 7. Concretely: raising d from 0 to 1 changes what "capturing p and q" even means, since AR(p)/MA(q) are now fit on the differenced series, not the raw one - a common early mistake is reading ACF/PACF on the raw series and getting orders that don't apply once differencing is applied.

Trade-offs & pitfalls
Adding seasonal terms multiplies the number of parameters and the search space (p,d,q,P,D,Q,s); over-specifying any one of them (especially D, seasonal differencing) can remove real signal along with the seasonality. A senior candidate will also flag that pure ACF/PACF reading is a starting point, not a final answer: automated order search guided by AIC/BIC (or pmdarima.auto_arima) is standard practice once the visual signature is ambiguous, and the final choice should always be checked with a residual diagnostic (no significant autocorrelation left, e.g. a Ljung-Box test) rather than trusted from the identification step alone.

Direct answer
Prophet is an open-source forecasting library built around an additive decomposable model: it explicitly represents a series as trend (piecewise-linear or logistic, with automatically-detected changepoints) plus yearly, weekly, and holiday seasonality components, is designed to be robust to missing data and outliers, and performs best on business time series with strong seasonality and several seasons of history.

Structured elaboration

• Trend changepoints: Prophet fits a piecewise-linear (or logistic-growth, for saturating series) trend and automatically detects a set of points where the trend's rate of change shifts, rather than assuming one fixed slope for the whole history. A changepoint_prior_scale parameter controls how flexible this trend is allowed to be - too high overfits to noise as spurious trend changes, too low misses real regime shifts.
• Yearly/weekly/holiday seasonality: yearly and weekly seasonality are modeled with Fourier series (a sum of sine/cosine terms), so the seasonal shape isn't restricted to a single simple sinusoid; holidays are modeled as a separate, explicit list of dates (with an optional window around each) that get their own additive effect, distinct from the smooth seasonal terms.
• Handling missing data and outliers: Prophet fits by default with a curve-fitting (not autoregressive) approach, so missing observations simply don't contribute to the fit rather than breaking a recursive dependency chain the way a naive ARIMA implementation might; outliers can be handled by treating them as missing (removing them before fitting) since Prophet doesn't require an unbroken regular grid.
• Which business time series it performs well on: series with strong, multiple seasonalities and a reasonably smooth trend, several seasons (ideally a year or more) of history, and meaningful holiday effects - the classic case Prophet was built for. It's also comparatively forgiving of messy real-world business data (missing days, occasional outliers) without heavy preprocessing.
• Limitations: Prophet is fundamentally a curve-fitting/decomposition model, not an autoregressive one, so it doesn't naturally capture short-term autocorrelation the way ARIMA does, and it can be less accurate than a well-tuned SARIMA or ML model on series with complex short-lag dynamics; it also needs enough history to estimate yearly seasonality reliably (a series with only a few months of data can't support a yearly term at all), and its automatic changepoint detection can occasionally latch onto noise as a false regime shift if not checked against domain knowledge.

Worked example
For a subscription business's daily signups with clear weekly seasonality, a yearly pattern (higher signups in January), and a handful of known promotional dates: Prophet would fit a smooth trend with changepoints around any real acquisition-strategy shifts, a weekly Fourier term capturing the day-of-week pattern, a yearly Fourier term capturing the January effect, and an explicit holiday/promo list for the known promotional dates - all separately inspectable, which is one of Prophet's practical advantages: you can plot each component and sanity-check it against what you know about the business, rather than trusting a single opaque number.

Trade-offs & pitfalls
The most common misuse is trusting Prophet's automatic changepoint detection uncritically on a series where you already know WHY the trend changed (a pricing change, a channel shift) - supplying those changepoints explicitly, rather than letting the algorithm guess, is usually more reliable and more interpretable. And because Prophet doesn't model short-term autocorrelation, on a series where yesterday's residual strongly predicts today's, a SARIMA-family model or a hybrid approach will often out-perform it even though Prophet is easier to operate at scale.