Forecasting and Time-Series Analysis Questions

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.

Direct answer
MAE, RMSE, MAPE, and MASE trade off differently on outlier sensitivity, scale (in)dependence, and interpretability. MAE and RMSE are in the series' own units (scale-dependent) so they can't compare across products of different sizes; MAPE and MASE are scale-independent and can. RMSE is the most outlier-sensitive of the four (it squares errors); MAPE breaks down when actuals are near zero; MASE is the most robust general-purpose choice for comparing forecast quality across many series.

Structured elaboration

• $\text{MAE} = \frac{1}{n}\sum_{t=1}^{n} |y_t - \hat{y}_t|$ - average absolute error, in the series' native units. Robust to outliers (linear penalty), easy to explain to a business partner ("we're off by about $X on average"), but not comparable across series with different scales.
• $\text{RMSE} = \sqrt{\frac{1}{n}\sum_{t=1}^{n} (y_t - \hat{y}_t)^2}$ - also in native units, but squaring means a few large misses dominate the score; use it when large errors are disproportionately costly (e.g. a huge single stockout matters more than several small ones).
• $\text{MAPE} = \frac{100\%}{n}\sum_{t=1}^{n} \left|\frac{y_t - \hat{y}_t}{y_t}\right|$ - scale-independent (a percentage), intuitive to business partners, but undefined when $y_t = 0$ and numerically unstable when $y_t$ is close to zero, since a tiny denominator inflates the percentage error arbitrarily.
• $\text{MASE} = \frac{\text{MAE of your forecast}}{\text{MAE of a naive (or seasonal-naive) forecast on the training data}}$ - scale-independent AND well-defined even with zeros or near-zero actuals, since the denominator is the naive-forecast's error, not the actual value itself. A MASE below 1 means you're beating the naive baseline; above 1 means you're doing worse than just repeating the last (seasonal) value.
• When to prefer which: report MAE/RMSE to a technical audience deciding between models on ONE series; report MAPE to a business partner who wants "how far off, in percent" on a series with no near-zero values; use MASE whenever you're comparing forecast quality ACROSS multiple series of different scale, or on any series that legitimately has zero or near-zero periods.

Worked example (executed)
On a monthly-revenue-style series with actuals [120, 135, 0, 150, 160, 2, 170, 180, 190, 0, 210, 220] and forecasts [125, 130, 3, 155, 158, 6, 172, 178, 188, 4, 208, 225]: excluding the two zero-actual months, nine of the ten remaining points have an absolute percentage error under 5% (typical case: actual=170, predicted=172, APE = |170-172|/170 = 1.18%), but the one near-zero point (actual=2, predicted=6) has APE = $|2-6|/2 = 200\%$. Averaging all ten non-zero points together gives an overall MAPE of 21.9%, roughly 18x the typical point-level error, purely because that single near-zero denominator dominates the average. MASE, computed against a naive baseline's own error, doesn't have this failure mode since it never divides by the actual value.

Trade-offs & pitfalls
Never report MAPE on a series with zero or near-zero actuals without either excluding those points explicitly (and disclosing how many were excluded) or switching to MASE/WAPE instead; a silently-computed MAPE on such a series is a common way forecast quality gets systematically misreported. When several metrics disagree on which of two models is "better," that disagreement is informative, not a bug - a model that wins on MAE but loses on RMSE typically means it's slightly worse on a few large misses while being better on average, which is exactly the kind of trade-off a business stakeholder needs to weigh in on, not something to average away.

Direct answer
Transformer-based forecasting models (Temporal Fusion Transformer, Informer, Autoformer) adapt the attention mechanism, originally built for language, to time series by letting the model directly attend to any past time step when producing a forecast, capturing long-range dependencies more directly than an RNN's sequential state-passing; they also provide explicit architecture for incorporating both STATIC covariates (features that don't change over time, like a store's region) and TIME-VARYING covariates (features that change per time step, like daily promotions), at the cost of more training complexity and reduced interpretability relative to classical statistical models.

Structured elaboration

• Attention for long-range dependencies: an RNN/LSTM has to pass information through a sequential chain of hidden states, which can dilute or lose signal from far in the past by the time it reaches the current step; attention instead lets the model compute a direct, weighted connection between the current prediction and ANY past time step, regardless of distance, which is particularly valuable for time series with important long-range structure (a yearly effect in daily data, say) that a purely sequential architecture has to "remember" across many steps.
• Model-specific adaptations: the Temporal Fusion Transformer (TFT) explicitly separates static, known-future (e.g. calendar/promotion), and observed-past-only covariates into distinct input paths, with a variable-selection mechanism that learns which features matter most; Informer addresses the quadratic compute cost of standard attention (which scales poorly with long sequences) with a sparser attention mechanism designed for long-sequence forecasting; Autoformer builds decomposition (trend/seasonal, similar in spirit to classical decomposition) directly into the architecture rather than leaving the model to learn it implicitly.
• Integrating static and time-varying covariates: static covariates (store region, product category) are typically embedded once and combined with the sequence representation; time-varying covariates that are KNOWN in advance for the forecast horizon (a promotion calendar) are fed differently than ones only observed in the past (actual historical weather) - architectures like TFT make this distinction explicit in their input structure, which matters practically since it maps directly onto the "must be known at forecast time" constraint that governs any exogenous regressor.
• Trade-offs vs RNNs and classic statistical models: Transformer-based models generally need substantially more training data and compute than either RNNs or classical statistical models to realize their advantage, and are the LEAST interpretable of the three families (attention weights offer some insight but nowhere near the direct interpretability of a SARIMA coefficient or a Prophet component); their main payoff is when you have long sequences with genuine long-range dependencies AND enough data (often pooled across many related series) to train them well - on a single short series with simple seasonality, a classical model will very likely match or beat a Transformer while being far cheaper and more interpretable.

Worked example
A closely related architectural variant worth naming: a spatio-temporal Graph Neural Network (GNN) for forecasting demand across many geographically-adjacent zones, which extends the same "attend across many related sequences" idea from the temporal dimension (Transformers attending across TIME) into the spatial dimension as well (attending across geographically or logically related ZONES via an explicit adjacency/graph structure) - appropriate when neighboring zones' demand genuinely informs each other's forecast (e.g. spillover effects between adjacent delivery zones), a relationship a per-zone Transformer or RNN forecasting each zone independently has no native way to represent.

Trade-offs & pitfalls
The most common misapplication is reaching for a Transformer-based architecture on a problem that doesn't have the scale (many related series, long useful history) or genuine long-range dependency structure to justify its cost - validate the added complexity is earning its keep with a direct backtested comparison against a well-tuned classical or gradient-boosted baseline before committing to the heavier architecture and its associated training/maintenance burden.

Direct answer
Intermittent demand (many zero periods, occasional non-zero spikes) breaks standard smoothing/ARIMA-style forecasting; Croston's method, TSB, and modified-Croston variants are the classical purpose-built approaches, with ML alternatives (a two-stage occurrence-classifier plus size-regressor, or dedicated probabilistic count models) as a more flexible but heavier alternative.

Structured elaboration

• Croston's method: separately smooths (a) the average NON-ZERO demand size and (b) the average INTERVAL between non-zero demand occurrences, only updating each when a demand event actually occurs, then combines them (size ÷ interval) into a per-period forecast - the foundational method this whole family builds on.
• TSB (Teunter-Syntetos-Babai): updates the demand-occurrence PROBABILITY every period, including zero-demand ones, fixing a known bias where classic Croston's forecast doesn't decay appropriately during a long run of zeros for a genuinely slowing-down item.
• Modified Croston: various small bias-correction variants addressing Croston's known small-sample estimation bias (the original method's forecast is provably biased in expectation even under its own assumptions); useful mainly at scale across many SKUs where a small systematic bias, uncorrected, compounds into a meaningful aggregate error.
• ML alternatives: a two-stage model (classify whether demand occurs this period, then regress the SIZE conditional on occurrence) can incorporate features Croston/TSB structurally cannot (promotions, price, seasonality); dedicated probabilistic count models (zero-inflated Poisson/negative binomial) directly model the excess-zero structure statistically rather than via Croston's heuristic decomposition.
• Evaluation metrics for intermittent series: standard RMSE/MAPE both fail here (MAPE undefined at zeros, RMSE dominated by rare spikes); MASE against a seasonal-naive-of-zero baseline, or metrics that explicitly separate "did we predict an occurrence correctly" from "did we predict the right size given an occurrence," are more informative.
• Deployment considerations: Croston/TSB are cheap to fit and re-fit at scale across thousands of SKUs (simple closed-form updates, no heavy optimization); ML alternatives need a feature pipeline and more retraining infrastructure, which is worth the cost mainly when you genuinely have useful features (promotions, price) that Croston/TSB can't use at all.

Worked example
A SKU with demand occurring in only 30% of weeks and zero the other 70% - this is a canonical Croston/TSB case, and the choice between them hinges on whether that occurrence RATE itself is expected to be stable (favors classic Croston, simpler and well-understood) or is itself trending (favors TSB's every-period-updated occurrence probability, which reacts faster to a genuinely slowing or accelerating item). At the scale of hundreds of such SKUs, an automated model-selection layer (fit both, backtest, pick the better one per SKU, or default to TSB as the generally more robust choice) is the practical way to avoid hand-tuning each series individually.

Trade-offs & pitfalls
The most consequential mistake is applying a standard smoothing or ARIMA model to intermittent demand without first checking the zero-fraction - it will neither represent the "typical" zero periods well nor the rare demand spikes well, producing a forecast that's not useful for either the routine restocking decision or the rare demand event it should be planning around. Always check zero-fraction as a first diagnostic step before choosing a modeling family for a new series.

Direct answer
A Bayesian Structural Time Series (BSTS) model for causal impact represents a series as an explicit state-space decomposition (trend, seasonality, and optional regression terms on control covariates), fit with MCMC to a PRE-intervention period, then projected forward as a counterfactual to compare against the actually-observed POST-intervention series - the gap between the counterfactual projection and reality, with its posterior uncertainty, is the estimated causal impact.

Structured elaboration

• Model components: a local-level or local-linear-trend component (capturing the series' baseline trajectory), a seasonal component (if relevant), and optionally regression terms on CONTROL series (other, unaffected series correlated with the target pre-intervention) that help the model build a better counterfactual by leveraging what those unaffected series were ALSO doing during the post-intervention window.
• Prior selection: priors on the state-space variances (how much the trend/seasonal components are allowed to drift period to period) meaningfully affect how flexible the counterfactual projection is - too-flexible priors let the model "explain away" a genuine intervention effect as ordinary trend drift, too-rigid priors produce an overconfident, poorly-fitting counterfactual; priors are typically chosen (or checked) via their effect on PRE-intervention backtested fit, before ever looking at the post-intervention period.
• MCMC sampling concerns and convergence diagnostics: run multiple chains from different starting points; check R-hat (should be close to 1.0 for every parameter, indicating the chains have converged to the same distribution) and effective sample size/ESS (should be reasonably large relative to the number of draws, indicating the chain isn't too autocorrelated to give a reliable posterior estimate) before trusting any posterior interval - skipping this check risks reporting a "confident" causal-impact estimate from a chain that never actually converged.
• Interpreting posterior intervals: the model's posterior distribution over the counterfactual (what the series WOULD have done without the intervention) directly gives a posterior distribution over the CAUSAL EFFECT (observed minus counterfactual) at every post-intervention time point, and can be cumulated over the whole post-period - report the credible interval on the CUMULATIVE effect, not just a point estimate, and treat an interval that comfortably excludes zero as the practical bar for "a detectable effect," analogous to (but not identical to) a frequentist significance test.
• Code outline (PyMC3/PyStan) and computational trade-offs: define the state-space structure (local level + seasonal + optional regression) as a PyMC3 TimeSeries-style model or equivalent, fit via NUTS/MCMC sampling on the PRE-period only, then use the fitted posterior to simulate forward counterfactual draws over the post-period; MCMC-based BSTS is meaningfully more compute-intensive than a point-estimate method (like a plain difference-in-differences regression), which matters if you need to run this analysis across many interventions/series rather than a single one-off causal question.

Worked example
A related, lighter-weight time-series causal-impact technique worth naming for comparison: interrupted time series (ITS) analysis via segmented regression, which tests for a level or slope CHANGE at a specific known intervention date using a simpler regression framework rather than a full Bayesian state-space model - appropriate when you want a faster, more transparent (if less flexible) causal-impact estimate and don't need BSTS's ability to incorporate unaffected control series as covariates.

Trade-offs & pitfalls
The single most important assumption to validate before trusting a BSTS causal-impact estimate: the model's PRE-intervention fit must be genuinely good (the counterfactual projection mechanism has to be trustworthy on data you can actually check it against) - a poor pre-period fit means the post-period counterfactual is unreliable regardless of how confident the posterior interval looks, so always report pre-period backtested fit quality alongside the causal-impact estimate itself, not as an afterthought.