Prophet
Piecewise growth, Fourier seasonality, changepoints, uncertainty, failure modes
Most time series forecasting tools require deep domain expertise to configure — choosing ARIMA orders, specifying seasonal structure, diagnosing residuals. Prophet was built to solve a specific operational problem at Meta: let analysts without time series expertise produce sensible forecasts for thousands of business KPIs without model-by-model tuning. It achieves this by encoding strong structural assumptions: piecewise linear growth with sparse changepoints, Fourier seasonality at weekly and annual periods, and an explicit holiday calendar. These assumptions work well for typical business metrics (daily active users, weekly revenue, annual seasonal sales).
The mistake is treating Prophet as a general-purpose forecaster. Feed it a volatile financial series, a mean-reverting series, or anything where recent trend doesn't extrapolate linearly, and it will produce confidently wrong forecasts. Knowing the failure modes matters more than knowing the feature list.
Key points
- Prophet is a structural additive regression model: y(t) = g(t) + s(t) + h(t) + ε_t. g(t) is piecewise linear (or logistic) growth, s(t) is Fourier seasonality, h(t) is holiday effects. Each component is a separate, interpretable regression. This makes Prophet easy to inspect and debug — you can plot each component and check whether the trend extrapolation, seasonal pattern, and holiday effects make domain-knowledge sense.
- Piecewise linear growth: rate changes δ_j at potential changepoints are regularised with a Laplace prior, so most changepoints have δ ≈ 0 — sparsity by design. Changepoints are placed automatically across the first 80% of training data. This means the last 20% of training data has few changepoints — recent trend changes go undetected. changepoint_prior_scale (default 0.05) controls how aggressively trend changes are allowed; it is the single most consequential hyperparameter. Too large → overfits recent trend at the forecast boundary; too small → sluggish response to genuine structural breaks.
- Seasonality is modelled via Fourier series: S(t) = Σ [aₙ cos(2πnt/P) + bₙ sin(2πnt/P)] with N=10 harmonics for yearly (P=365.25) and N=3 for weekly (P=7). These coefficients are fitted by OLS as part of the additive regression. Not spectral estimation — just linear regression on engineered features. This is why Prophet works natively with non-integer periods like 365.25, where seasonal dummies are impractical.
- changepoint_prior_scale is the most consequential hyperparameter because it controls trend extrapolation. Too large: the model fits every recent zigzag as a changepoint and extrapolates the last slope aggressively — produces trend explosions at the forecast boundary. Too small: the model ignores genuine structural breaks and forecasts with a stale trend. Don't leave it at the default without running cross-validation and checking whether the trend extrapolation at the forecast horizon makes domain-knowledge sense.
- Uncertainty in Prophet comes in two forms. MAP estimation (the default) is fast but prediction intervals capture only observation noise and future changepoint sampling uncertainty — they do not propagate parameter uncertainty. MCMC (mcmc_samples > 0) gives full posterior uncertainty and properly calibrated intervals. For business forecasts where interval width drives decisions (inventory safety stock, budget reserves), MAP intervals are systematically too narrow. Always check empirical coverage via cross-validation before reporting intervals.
- Prophet's failure modes are predictable from its structural assumptions. Mean-reverting series (stock spreads, some financial metrics): Prophet assumes piecewise linear trend; a mean-reverting series has no long-run trend and the piecewise linear model will produce upward-drifting forecasts. Multiplicative seasonality: supported via seasonality_mode="multiplicative" but only as a global mode — all seasons are multiplicative or none are. External shocks: add_regressor is too rigid for series dominated by unpredictable events. Less than 1-2 years of history: annual seasonality identification degrades significantly.
- add_regressor adds exogenous features as linear terms in the regression. The critical production trap: the regressor must be available at forecast time. If you add observed weather as a regressor during training and backtesting, the model appears accurate — but in production, you'd need weather forecasts for the forecast horizon. Substituting forecast weather for actual weather introduces regressor error that inflates MAPE. Always backtest with the same information available at deployment time.
- Prophet's cross-validation: prophet.diagnostics.cross_validation() with initial (training window), period (spacing between cutoffs), and horizon. This is rolling-origin evaluation, not random train-test split. performance_metrics() summarises MAPE/RMSE/MAE by forecast horizon — essential for understanding where accuracy degrades. Empirical interval coverage from this output tells you whether MAP or MCMC intervals are needed.
Prophet is a specific tool for a specific problem: business KPIs with trend + weekly + yearly seasonality, designed for analysts who need sensible forecasts without deep time series expertise. Its failure modes are predictable from its structural assumptions — trend explosion at the forecast boundary when changepoint_prior_scale is too high, silently using future regressor values during backtesting, and underconfident MAP intervals. changepoint_prior_scale is the single most consequential hyperparameter and must be validated via rolling-origin cross-validation rather than left at the default.
Recap
- Prophet = structural additive regression: `y(t)=g(t)+s(t)+h(t)+ε` — growth + Fourier seasonality + holidays.
- Built for analysts: sensible KPI forecasts (DAU, revenue) without per-series tuning.
- Piecewise linear growth, changepoints only in first 80% of data → recent trend shifts undetected.
- changepoint_prior_scale (default 0.05) is THE hyperparameter: too high → trend explosion at boundary; too low → sluggish.
- MAP intervals (default) are too narrow — capture only noise + changepoint sampling, not parameter uncertainty; use MCMC.
- add_regressor trap: regressor must exist at forecast time — backtesting with actuals inflates accuracy.
- Fails on mean-reverting / volatile series and <1-2yr history; validate via rolling-origin CV.
Check your understanding
Q1. Your Prophet model produces a forecast for next quarter that shows a sharp trend acceleration starting exactly where your training data ends. What is the likely cause and how do you fix it?
- A) The Fourier seasonality terms are constructively interfering right at the forecast boundary; increase the number of yearly harmonics from N=10 to N=20 to smooth out the transition point.
- B) A changepoint artifact: Prophet places changepoints only in the first 80% of training data, so recent trend shifts go undetected. Fix: lower changepoint_prior_scale and set changepoint_range=0.95.
- C) The acceleration is simply a correct forecast in this situation; Prophet's piecewise linear growth reliably captures genuine trend accelerations that ARIMA would otherwise miss entirely, so no intervention is needed at all.
- D) The sharp acceleration indicates over-differencing inside the internal trend model; set growth="flat" to fully disable trend extrapolation and re-fit the entire model from scratch.
Q2. You add daily temperature as an external regressor to Prophet to forecast energy demand. During backtesting, MAPE is 3%. In production, MAPE is 22%. What happened?
- A) The model overfit to the temperature signal during training; simply remove the regressor entirely and retrain on the demand series alone to restore production-level accuracy immediately.
- B) The energy demand series developed a structural break between the backtest period and production deployment; the temperature regressor itself is not responsible for the observed degradation.
- C) The changepoint_prior_scale is set too high, causing a trend explosion in production that dominates and drowns out the temperature regressor signal; reduce it to 0.001 and retrain from scratch.
- D) Lookahead bias: backtesting used actual observed temperatures, but production needs forecasts. Substituting forecast temperature inflates MAPE. Backtest using only forecasts beyond each cutoff to simulate production.
Q3. A manager wants a 90% prediction interval for monthly revenue 6 months out. Which TWO statements about producing and limiting well-calibrated Prophet intervals are correct?
- A) Enabling MCMC sampling and evaluating coverage via cross_validation() at the target horizon is the right approach to check whether the 90% interval actually achieves its nominal coverage rate empirically.
- B) MAP estimation, the default, does not propagate full parameter uncertainty into the interval, so its width is systematically too narrow compared to properly sampled posterior-based intervals from MCMC.
- C) MAP estimation is fully sufficient for calibrated intervals in every case; set interval_width=0.9 and report directly — MCMC sampling is only ever needed for horizons beyond 12 months out.
- D) Prophet's prediction intervals are always well-calibrated by construction because the Laplace prior on changepoints is a proper Bayesian prior, so no additional calibration steps are ever needed.
Try it interactively
ML Systems Lab is a free interview-prep platform for ML engineers — work through the full interactive module, quizzes, and drills.
Open ML Systems Lab →