Forecasting and Time-Series Analysis Questions

Direct answer
Forecasting a demand or capacity metric (like viewing hours, order volume, or active users) with strong seasonality and event-driven spikes calls for the same core toolkit as any seasonal demand forecast: a classical or ML model chosen to fit the seasonality's complexity, explicit handling of known future events (releases, holidays, campaigns), and evaluation against the operational decision the forecast actually supports (a capacity or staffing plan), not just a generic accuracy number.

Structured elaboration

• Model choice, classical vs ML: for one series with clean weekly+monthly seasonality and no meaningful external drivers, SARIMA or Holt-Winters are strong starting points. Once you need to incorporate known upcoming events (a title release, a new-market launch, a promotional campaign) as explicit regressors, or you're forecasting many related series together (many titles, many regions, many order channels), a model that supports exogenous features and pooling - Prophet with regressors, or a gradient-boosted model over lag/calendar/event features trained across all series - is the better fit.
• Handling known future events: build an explicit event/release-calendar feature (a flag, or a decaying "days since release" feature capturing the post-spike decline) rather than hoping the model infers a one-off spike from history alone; a genuinely new event type (first-ever release in a new content category) has no historical analogue for the model to learn from, so pair the model output with a judgmental adjustment or an analogue-based estimate for events without a clean precedent.
• Evaluating forecast accuracy for planning purposes: report error metrics AT THE GRANULARITY the planning decision needs (e.g. hourly RMSE if staffing is scheduled hourly, not just an aggregated daily/weekly number that could hide a systematically-missed daily peak), and evaluate coverage of the prediction interval specifically around event days, since those are exactly when planners most need the interval to be trustworthy and are also where models are most likely to be poorly calibrated.
• Scaling considerations when the metric feeds a real capacity decision: because under-forecasting a spike has an asymmetric cost (a capacity shortfall vs a modest over-provisioning cost), it's often appropriate to plan off a higher quantile of the forecast distribution (e.g. the 90th percentile) rather than the point median, and to build in an explicit contingency/fallback plan (manual override, rapid-scale trigger) for events materially larger than anything in the training history.

Worked example
Growth-style capacity questions (e.g. planning for user growth from 100k to 2M over 12 months) are a related but DISTINCT variant: at that scale of change, a pure time-series extrapolation of recent history is unreliable because the growth is driven by a step-change in the business (a new market, a new channel), not organic continuation of an existing trend, so a growth-curve or scenario-based model (grounded in comparable prior launches, if any exist) is usually more defensible than SARIMA/ETS extrapolation alone, with prediction intervals presented explicitly as scenario bands rather than a single confident number. A supply-side shock (e.g. a courier strike suddenly reducing available capacity) is the mirror-image problem: the DEMAND forecast may still be accurate, but the operational decision needs a separate supply-constraint model layered on top, since the two are not interchangeable.

Trade-offs & pitfalls
The most common mistake is validating the forecast on average-case error while the capacity decision actually depends on TAIL behavior (event days, growth inflection points, supply shocks); a model that looks excellent on an aggregate accuracy metric can still be dangerously wrong exactly when the capacity plan needs it most. Report event-day accuracy and interval coverage separately from the steady-state number, and be explicit with stakeholders about which regime (steady-state vs event-driven vs step-change growth) a given forecast is actually reliable for.

Direct answer
MAPE handling requires masking out zero-actual periods explicitly (dividing by zero is undefined) and disclosing how many periods were excluded; a rolling window applies the same masked calculation over a trailing subset of periods; aggregating across SKUs means computing per-SKU MAPE first and then averaging (or better, weighting by volume) rather than pooling all errors into one undifferentiated calculation.

Structured elaboration and worked example (executed)

import numpy as np

def mape_safe(y_true, y_pred):
    y_true, y_pred = np.asarray(y_true, float), np.asarray(y_pred, float)
    mask = y_true != 0
    excluded = int((~mask).sum())
    ape = np.abs((y_true[mask] - y_pred[mask]) / y_true[mask])
    return float(np.mean(ape) * 100), excluded

def rolling_mape(df, window=3):
    return [mape_safe(df.iloc[max(0,i-window+1):i+1]["y_true"],
                       df.iloc[max(0,i-window+1):i+1]["y_pred"])[0] for i in range(len(df))]

Run against a 12-month synthetic series with 2 zero-actual months injected:

overall MAPE (excluding 2 zero-actual months): 8.43%

and a direct demonstration of why the zero-handling matters, isolating one near-zero actual (2.0) against a normal one (100.0):

per-point APE with a near-zero actual (2.0): [5.0, 200.0] %   <- the second point alone contributes 200% APE

A single near-zero actual contributes 200% absolute-percentage-error on its own - left unmasked, one such point can dominate an averaged MAPE and make an otherwise-good forecast look far worse than it is; masking (with the excluded count disclosed) is essential, not optional.

• Zero handling: exclude periods where the actual is exactly zero from the MAPE calculation (as shown), and report the exclusion count alongside the metric - a MAPE computed over 10 of 12 months without disclosing that 2 were dropped is a materially different (and less trustworthy) number than one that discloses it.
• Rolling 3-month MAPE: recompute the same masked calculation over each trailing 3-month window, which surfaces whether accuracy is degrading recently even if the all-time average still looks fine.
• Aggregating rolling MAPE across multiple SKUs: compute MAPE per SKU (each with its own zero-handling), then aggregate - a simple average across SKUs treats every SKU equally regardless of size, while a REVENUE- or VOLUME-weighted average better reflects overall business impact; report both if audiences differ (an ops team may want the simple per-SKU average to catch problems anywhere, while a finance-facing summary may want the volume-weighted number).
• The SQL equivalent: the same zero-handling logic translates directly to SQL - exclude (or NULLIF-guard) zero-actual rows in the WHERE/CASE logic, and explicitly surface an excluded-row count column (e.g. rows_excluded_zero) alongside the computed MAPE, exactly mirroring the Python function's excluded return value, so a downstream consumer of the SQL output has the same disclosure a Python caller would.

Trade-offs & pitfalls
Silently computing MAPE with a naive (actual - pred) / actual and letting a zero actual produce an infinite or NaN value (rather than deliberately masking and disclosing it) is the single most common implementation bug in this space; always test the zero-handling path explicitly, not just the happy path, since a metrics pipeline that silently drops NaN rows can quietly change WHICH periods are being scored without anyone noticing.

Direct answer
A 12-week revenue forecast for finance needs: a clear specification of inputs and features, a short list of candidate model classes matched to the data's size and structure, a rolling-origin backtest to validate them, an explicit way to present uncertainty (not just a point number), and a defined deployment/monitoring plan so the forecast stays trustworthy after handoff.

Structured elaboration

• Data inputs and features: the historical revenue series itself at the right granularity (weekly, to match the 12-week ask), plus any known drivers over the forecast window - planned promotions, pricing changes, seasonality (day-of-week/month effects), and macro or pipeline signals if available (e.g. sales-pipeline coverage for a B2B business).
• Model classes to consider: for a single well-behaved series with a year or more of clean weekly history and some seasonality, ETS or SARIMA are strong, quick, interpretable starting points; if there are meaningful external drivers (promotions, pricing), SARIMAX or a gradient-boosted model on engineered features can incorporate them; if this is one of many similar revenue lines, a pooled/global model trained across all of them usually outperforms any single-series model.
• Validating with time-series cross-validation: backtest with rolling-origin evaluation at the SAME horizon you'll actually deploy (12 weeks), not a shorter proxy horizon, since forecast error typically grows with horizon and a model validated at 1-step-ahead can look artificially strong.
• Presenting uncertainty to stakeholders: never hand finance a bare point number; show a prediction interval (from residual-based, bootstrap, or quantile methods) and, ideally, a short plain-language explanation of what's driving the width (e.g. "wider in week 10-12 because we're extrapolating further from known data").
• Deploying and monitoring: define a retraining cadence (e.g. refresh weekly as actuals arrive), track realized forecast error against the backtested expectation, and set an explicit escalation trigger if realized error meaningfully exceeds the backtested distribution (a sign the underlying pattern has shifted).

Worked example
Demand forecasting more broadly answers business questions like supply/staffing planning, and the KPIs and horizons you report should match the DECISION being made, not just "what's easy to compute" - a same-day operational decision needs an hourly KPI, while a quarterly planning decision needs a weekly or monthly one. For a 12-week revenue number specifically: report the point forecast alongside the 80% interval, a one-line explanation of the biggest assumption (e.g. "assumes the current promotion cadence continues"), and the model's own historical accuracy at a 12-week horizon so finance can calibrate how much to trust it.

Trade-offs & pitfalls
Presenting model assumptions and limitations honestly to a non-technical audience matters as much as the model itself: lead with 3-5 concrete assumptions in plain language (e.g. "assumes no new competitor launches", "assumes the same seasonal pattern as last year"), because finance stakeholders act on the number, and unstated assumptions are exactly what turns into "the forecast was wrong" instead of "an assumption we flagged didn't hold." The most common failure mode in this whole workflow isn't model choice, it's backtesting at a horizon that doesn't match production use, which silently overstates how good the deployed forecast will actually be.

Direct answer
Responsible AI and governance for forecasting systems means checking whether the model treats different regions or product lines fairly (not just accurately on average), protecting the privacy of training data, and running the operational governance machinery - model cards, periodic audits, defined remediation processes - that make the whole system auditable and correctable rather than a black box that only gets scrutinized after something visibly goes wrong.

Structured elaboration

• Detecting bias across regions or product lines: check forecast accuracy and, separately, forecast BIAS (systematic over- or under-prediction) broken out BY segment (region, product line), not just in aggregate - a model that's unbiased on average can still systematically under-forecast one region while over-forecasting another, which is invisible to an aggregate accuracy check but very real in its downstream consequences.
• Mitigating detected bias: once a segment-specific bias is confirmed (not just suspected from a single period, but validated the way any bias-detection exercise should be, with a proper statistical check), remediation options range from a segment-specific recalibration correction to retraining with segment-balanced data or segment-aware features, chosen based on WHY the bias exists (a data-representation issue vs a genuine, harder-to-model difference in that segment's underlying dynamics).
• Fairness when forecasts drive allocation decisions: when a forecast feeds directly into an ALLOCATION decision (inventory, staffing, incentive dollars distributed across regions), a systematic forecasting bias against one region translates directly into that region being under-served - this is the concrete mechanism by which a "purely technical" forecasting bias becomes a real fairness issue, and it's the reason bias detection here needs to be checked specifically against WHATEVER downstream decision the forecast drives, not evaluated as an abstract accuracy statistic alone.
• Data retention and privacy: forecasting models trained on customer-level or location-level transaction data inherit the same retention-limits and privacy-handling obligations as any other system using that data - define and enforce a retention policy for training data, and ensure the model itself (and any cached intermediate features) doesn't become an unintended long-term store of data that should have been deleted under the organization's stated retention policy.
• Operational governance practices: model cards (a standardized, versioned document describing a model's intended use, known limitations, training-data characteristics, and validated performance across segments) make a model's fairness/bias characteristics legible to anyone who needs to evaluate or approve its use, rather than requiring a fresh investigation each time; periodic audits (a scheduled, recurring re-check of segment-level bias and accuracy, not just a one-time pre-launch check) catch drift into unfairness that emerges only after deployment; a defined remediation process (what happens, and who's accountable, once an audit finds a problem) ensures a detected issue actually gets fixed rather than merely documented.

Worked example
An automated demand-allocation system that systematically under-forecasts demand in lower-income neighborhoods (perhaps because those areas have historically been served by fewer marketing dollars, and the model has learned that pattern as if it were an accurate reflection of true underlying demand rather than a historical resourcing artifact) would, if left unchecked, perpetuate and even reinforce that under-service through the forecast-driven allocation decision itself - detecting this requires deliberately checking bias BY neighborhood income level (not something an aggregate accuracy metric would surface on its own), and the mitigation needs to address the root cause (the historical resourcing pattern baked into the training data) rather than just a numeric recalibration that treats the symptom.

Trade-offs & pitfalls
The most consequential governance gap is treating fairness/bias review as a one-time, pre-launch checklist item rather than an ongoing, periodically-repeated audit - a model that was checked and cleared at launch can still drift into segment-specific bias over time as the underlying data and business context evolve, and only a recurring audit cadence (not a single point-in-time check) catches that drift before it compounds into a real, sustained allocation harm.

Direct answer
To decide whether a sudden drop is expected seasonal/random variance or a real causal effect from a recent change, build an explicit statistical comparison: model what the series was EXPECTED to do this period (via seasonal decomposition, SARIMA, or a Bayesian structural time series model), quantify how far the observed drop is from that expectation in probabilistic terms, and corroborate with a control series unaffected by the change wherever one is available.

Structured elaboration

• Data selection: use enough history to estimate the seasonal pattern reliably (at least a few full seasonal cycles), and be careful to exclude any period that was itself anomalous (a past outage, a past unrelated shift) from the baseline used to estimate "expected" behavior.
• Candidate models for expected behavior: seasonal decomposition (STL or classical) gives a quick expected value plus an implicit residual-based sense of normal variance; SARIMA gives a formal predictive distribution with a prediction interval; Bayesian Structural Time Series (BSTS) is specifically well-suited here because it's designed for causal-impact style analysis - it produces a full counterfactual prediction ("what would the series likely have done without the change") with a credible interval, which is a more direct answer to "is this drop unusual" than a plain decomposition.
• Using a control series: if a comparable, unaffected series exists (an unaffected region, a cohort not exposed to the deployment), compare its behavior over the same window - if the control ALSO shows a comparable drop, that's strong evidence the true cause is something shared (broader seasonality, a macro event) rather than the specific change being investigated.
• Hypothesis testing and quantifying confidence: frame it explicitly as a hypothesis test - $H_0$: the observed value is consistent with the model's predictive distribution (i.e. explainable by normal variance); if the observed drop falls well outside the model's prediction interval (or, in a BSTS framing, the counterfactual credible interval), reject $H_0$ in favor of a real causal effect, and report the width of that interval so stakeholders understand HOW confident the conclusion is, not just the binary verdict.
• Multiple-cohort correction: if you're checking several cohorts or segments simultaneously for the same kind of drop, correct for multiple comparisons (e.g. a Bonferroni or FDR adjustment on the p-values) - checking 20 cohorts at the standard 5% significance threshold will produce roughly one false "significant" finding by chance alone if left uncorrected.

Worked example
A first practical filter before any formal modeling: distinguish a SUSTAINED trend from a TRANSIENT anomaly with a few concrete checks - does the metric recover within a day or two (favors transient/anomaly) or does the new level persist across multiple full seasonal cycles (favors a real, sustained shift)? Is the drop isolated to one segment (a specific platform, a specific region) consistent with a localized deployment, or does it appear everywhere (favors a shared, external cause like a broad seasonal effect)? Only once these quick checks are ambiguous does the fuller BSTS/control-series analysis earn its cost.

Trade-offs & pitfalls
The most common mistake is skipping straight to "is this significant" without first checking whether the model used to define "expected" was itself well-calibrated (a seasonal model fit on a short or contaminated history will produce an overconfident interval, making ordinary variance look like a dramatic anomaly). Equally common: attributing a drop to the most recent visible change (a deployment) purely because of timing, without checking a control series - correlation in timing alone is weak evidence, and a genuinely rigorous answer needs either a true experiment (if one exists) or a credible quasi-experimental comparison.