Forecasting and Time-Series Analysis Questions

Direct answer
For a quick, defensible baseline with clear weekly seasonality, compute a seasonal-naive forecast (repeat the value from the same weekday last week/period) and a simple moving average, present both, and be explicit that the seasonal naive is the harder bar to beat, not the moving average.

Structured elaboration

• Seasonal naive: forecast next Monday's value as last Monday's value (or the same period one full seasonal cycle ago). Advantage: costs nothing to compute, respects the seasonal pattern by construction, and is the standard baseline every more sophisticated model should be measured against (this is literally the denominator MASE uses). Limitation: it ignores trend entirely, so it will systematically lag a genuinely growing or shrinking series, and it's a single historical point so it's sensitive to one noisy week.
• Moving average: forecast next period as the average of the last N periods. Advantage: smooths out noise better than a single seasonal-naive point. Limitation: a plain moving average IGNORES seasonality unless N is chosen to span a full seasonal cycle, so on a series with clear weekly seasonality a short moving average will systematically miss the weekly pattern (e.g. under-forecasting weekend spikes).
• Presenting uncertainty and relative performance to non-technical stakeholders: show both baselines' historical forecast errors (e.g. "seasonal-naive has typically been off by about $12K/week over the last 3 months") next to the point forecast, rather than presenting a bare number; a simple error band drawn from the historical error distribution communicates the same idea as a formal prediction interval without requiring the audience to know what one is. Frame it explicitly as "this is our floor: any model we build should beat this."

Worked example
For weekly sales with a clear weekly seasonal cycle (e.g. this metric IS itself weekly-periodic, so "weekly seasonality" here really means a recurring pattern across weeks, like a monthly or quarterly cycle within the weekly series), the seasonal-naive baseline uses last cycle's same-position value directly. A 4-week moving average, in contrast, would blend across positions in the cycle and blunt exactly the recurring pattern you're trying to respect - for a series with strong periodicity, the moving average is the WEAKER of the two baselines, which is worth stating plainly to a stakeholder who might otherwise assume "more averaging = safer."

Trade-offs & pitfalls
Presenting only a point number without ANY baseline comparison is the single most common failure mode here - a stakeholder has no way to judge whether "next quarter: $1.2M" is a good forecast without a reference point. The second most common failure is silently using a moving-average baseline when the series has real seasonality, which understates how good a properly seasonal-aware model actually needs to be to add value: if your fancier model only modestly beats a moving average but doesn't beat seasonal-naive, it isn't adding real value yet.

Direct answer
Integrating exogenous covariates (promotions, price, macro indicators) into a forecasting model means engineering them into usable features, choosing the right lag, being careful to distinguish genuine causal drivers from merely correlated ones, watching for multicollinearity among the regressors, and - critically - ensuring every regressor is actually KNOWN in advance for the periods you're forecasting.

Structured elaboration

• Feature engineering: represent a promotion or price change as a flag (on/off) or a magnitude (percent discount), and consider a decaying "days-since-event" feature if the effect lingers past the event itself (a promotion's lift often doesn't end cleanly the day the promotion does).
• Lag selection: some covariates affect the target immediately (same-day price change), others with a delay (an ad-spend campaign's effect on sales may lag by 1-2 weeks); choose lags with domain knowledge first, then validate empirically (cross-correlation analysis, or simply comparing model fit across a small grid of candidate lags).
• Causality vs correlation: a covariate correlated with the target isn't necessarily driving it - both could be responding to a third factor (e.g. both sales and a competitor's price move together because both react to the same seasonal demand pattern). Where possible, prefer covariates with a clear causal mechanism and, ideally, some exogenous variation you didn't control for elsewhere (e.g. use a genuinely externally-driven macro indicator, not one your own team also influences).
• Multicollinearity: several promotional or pricing covariates can be highly correlated with each other (a "sale" flag correlated with a "discount percentage" covariate); this doesn't hurt a model's PREDICTIVE accuracy much but does make individual coefficient estimates unstable and hard to interpret - if interpretability matters, consider combining correlated covariates or using regularization.
• Handling covariate availability for future periods: the single most important practical constraint - a regressor you'll be genuinely FORECASTING with must be known (or itself forecastable with acceptable uncertainty) at the time you need to produce your forecast. A promotion calendar planned weeks in advance is usable directly; same-day weather is NOT usable for a same-day forecast unless you're willing to forecast the weather too (and propagate that extra uncertainty).
• The critical leakage trap: backtest design: when constructing a backtest that includes event/holiday regressors, using the ACTUAL, historically-realized event dates for both training and the held-out test window is fine (event dates are typically known in advance), but naively including a covariate whose value for the test window was only knowable in hindsight (e.g. the actual realized promotional lift, rather than the planned promotion) inflates backtested accuracy in a way that won't hold up in production; and because event dates recur on a calendar (a holiday every year, at slightly varying dates), single-day event flags for a NEW year's holiday need a validated encoding scheme (e.g. matching by holiday name/offset, not raw calendar date) or the model has effectively never seen that exact feature value before.

Worked example
For a daily-sales model with an upcoming NEW holiday (e.g. a company's first year running a promotion tied to a newly-observed holiday), the model has literally zero historical examples of that specific date's effect - estimating its impact requires either treating it as generically similar to comparable past promotional events (an analogue-based judgmental adjustment) rather than trusting the model's native extrapolation, or explicitly flagging the forecast for that period as lower-confidence.

Trade-offs & pitfalls
The single highest-value discipline in this whole sub-area is a simple gut-check before including any regressor: "will I actually have this value, known with reasonable confidence, at the moment I need to produce the forecast?" - a covariate that fails that test needs to either be dropped, replaced with its own forecast (with propagated uncertainty), or moved to a nowcasting-style approach rather than a standard forecasting pipeline.

Direct answer
Spectral analysis and wavelet transforms detect periodicities by moving from the time domain into the frequency domain: spectral/periodogram methods identify which frequencies carry the most signal power (revealing hidden or multiple periodicities), while wavelets extend this to LOCALIZED frequency content, capturing periodicities that change or only appear during part of the series - and for irregularly-sampled data specifically, the Lomb-Scargle periodogram generalizes standard spectral analysis to unevenly-spaced observations.

Structured elaboration

• Standard periodogram/spectral analysis: decomposes a (regularly-sampled) series into its constituent frequencies and shows how much variance each frequency explains; a sharp peak at a specific frequency confirms a stable periodicity at the corresponding period (e.g. a peak at frequency 1/7 confirms weekly seasonality), and can reveal periodicities you didn't already suspect from visual inspection alone, or confirm MULTIPLE simultaneous periodicities (e.g. both weekly and yearly peaks in the same spectrum).
• Lomb-Scargle periodogram: standard spectral methods assume regular, evenly-spaced sampling; Lomb-Scargle generalizes the same underlying idea to IRREGULARLY sampled data (missing observations, unevenly-timed sensor readings) by fitting sinusoids directly to the actual observed time points rather than assuming a regular grid - use it whenever your series genuinely has gaps or non-uniform timestamps and you still need to detect periodicity reliably.
• Continuous wavelet transform (CWT): unlike a standard periodogram, which gives one global frequency spectrum for the WHOLE series, CWT gives a time-frequency decomposition - showing which frequencies are present AND when, which matters for a periodicity that isn't stable across the whole history (e.g. a weekly pattern that only emerged after a certain point, or a periodicity that comes and goes). Useful specifically when you suspect the seasonal/periodic structure itself is non-stationary.
• Preprocessing steps: detrend the series first (a strong trend otherwise dominates the spectrum with power at very low frequencies, obscuring genuine periodic structure at higher frequencies); handle missing/irregular timestamps explicitly (either via Lomb-Scargle directly, or by interpolating to a regular grid first if the irregularity is mild, with the trade-off of introducing interpolation artifacts).
• Interpreting results for seasonality and anomaly detection: a genuine, stable seasonal period shows as a sharp, well-defined peak; a broader or less well-defined peak (or one that shifts over time, visible in a CWT scalogram) suggests either an unstable/evolving periodicity or a genuinely cyclical (non-fixed-period) rather than seasonal pattern; for anomaly detection specifically, an unusual, unexpected localized burst of energy at a frequency NOT normally present (visible in a CWT's time-frequency map) can itself be a signature of an anomalous event distinct from the series' normal periodic structure.

Worked example
Applying this to detect and confirm daily, weekly, and yearly seasonality across several years of hourly web-traffic data: a standard periodogram on the full series would show peaks at all three corresponding frequencies if the seasonality is stable across the whole history; checking whether those peaks (particularly the yearly one) are consistently strong across each individual year separately (rather than just in the aggregate spectrum) is the direct way to confirm the seasonality is genuinely STABLE across years and regions, rather than an artifact of one unusual year dominating the aggregate spectral estimate.

Trade-offs & pitfalls
The most common mistake is running spectral analysis on a series with a strong, un-removed trend and either missing genuine periodicity (drowned out by the trend's low-frequency power) or mis-attributing trend-driven low-frequency energy as if it were a very-long-period seasonal effect - always detrend (or at minimum visually confirm the trend isn't dominating) before interpreting a periodogram's peaks as genuine seasonal/cyclical structure.

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.