Forecasting and Time-Series Analysis Questions

Direct answer
When sales leaders dispute a statistical forecast, the right response is a structured process, not a unilateral defense of the model or a silent capitulation: validate the underlying data first, surface and reconcile the specific assumptions being disputed, produce side-by-side scenarios so both views are visible rather than argued in the abstract, propose a documented compromise where warranted, and use the resolution to rebuild trust for future cycles rather than treating it as a one-off argument to win.

Structured elaboration

• Validating the data: before engaging on the substance of the disagreement, confirm the forecast's inputs are actually correct (no stale data, no broken pipeline, no missed recent event) - a meaningful fraction of forecast disputes turn out to be legitimate data-quality catches, not a genuine model-vs-judgment disagreement, so ruling this out first is both fast and often the actual resolution.
• Reconciling assumptions: identify precisely WHERE the statistical model and the sales leaders' intuition diverge - is it a different read on a specific deal, a market condition the model has no way to see (a competitor's recent move), or genuine overconfidence on one side? Naming the specific assumption in dispute turns a vague "the number feels wrong" into something concrete enough to actually resolve.
• Producing side-by-side scenarios: rather than picking one number, present the model's forecast AND a scenario reflecting the sales leaders' adjustment, with the specific assumption difference driving the gap made explicit - this respects both inputs and lets the eventual decision-maker see the trade-off rather than a black-box disagreement.
• Proposing compromise approaches: a blended forecast (weighting the statistical model and human judgment, as in collaborative forecasting more broadly) is often defensible when both sides have genuine signal the other lacks; document the blend and the reasoning, not just the final number.
• Restoring trust for future cycles: track which side (model or human adjustment) was closer to the eventual actual, and feed that back explicitly into the NEXT cycle's process - if human overrides have systematically been closer to actuals recently, that's a real signal the model may be missing something structural; if the model has been closer, that's useful evidence too, and either way, closing the loop with actual outcomes (rather than re-litigating the same disagreement from scratch each cycle) is what actually builds durable trust in the forecasting process.

Worked example
This is the same underlying discipline as any collaborative forecasting workflow where human adjustments (sales judgment, marketing input) are layered onto a statistical base: the productive version tracks whether those adjustments, on average, have actually improved on the model's own accuracy over time, rather than treating every override as automatically valuable or automatically suspect - a defensible process measures this explicitly (comparing overridden vs. non-overridden forecast accuracy against eventual actuals) instead of relying on anecdote or seniority to settle the disagreement.

Trade-offs & pitfalls
The most damaging failure mode here is NOT reconciling anything and instead quietly picking whichever number is more politically convenient in the moment - that erodes the forecasting process's credibility either way (with the modelers if judgment always wins with no accountability, or with the business side if the model always wins with no acknowledgment of real on-the-ground signal it can't see). A durable process needs to be able to point to a track record, not just a single episode, to settle these disputes over time.

Direct answer
Additive seasonality assumes the seasonal swing is a roughly constant absolute amount regardless of the series' level; multiplicative seasonality assumes it scales proportionally with the level. Choosing the wrong one distorts both baselines (an additive model under-predicts the seasonal swing at a high level, or over-predicts at a low one) and anomaly thresholds (a fixed-width band around an additive baseline will be too tight during high-level periods and too loose during low-level ones).

Structured elaboration

• Additive: $y_t = \text{trend}_t + \text{seasonal}_t + \text{residual}_t$ - the seasonal swing stays roughly the same size in absolute units no matter what the trend level is doing.
• Multiplicative: $y_t = \text{trend}_t \times \text{seasonal}_t \times \text{residual}_t$ - the seasonal swing grows or shrinks proportionally with the trend level; a multiplicative model can be fit as an additive one on the LOG of the series, since $\log(y_t) = \log(\text{trend}_t) + \log(\text{seasonal}_t) + \log(\text{residual}_t)$.
• Which metrics favor which: revenue-style metrics that grow substantially over time, where the seasonal spike naturally grows alongside the business (e.g. a December bump that's proportionally consistent but has grown from $10K to $50K as the business scaled), are usually multiplicative. Metrics with a roughly stable base level and a genuinely fixed-size seasonal effect (e.g. a fixed number of extra support tickets every Monday, regardless of overall ticket volume trend) are more often additive.
• Testing which model fits better: the simplest visual test is whether the peak-to-trough seasonal amplitude visibly GROWS alongside the trend on a raw plot - if it does, additive is the wrong assumption. More formally, fit both, compare residual variance (an additive fit on a genuinely multiplicative series will show residual variance that itself grows with the level, a clear diagnostic on a residual-vs-fitted plot), or simply compare backtested forecast error between the two.
• Why the choice matters for baselines/anomaly detection: an anomaly-detection threshold built on additive-model residuals (e.g. "flag anything more than 3 residual-standard-deviations away") implicitly assumes constant residual variance across the whole series; if the true process is multiplicative, that fixed threshold will be too sensitive (false positives) during low-level periods and too insensitive (missed real anomalies) during high-level periods.

Worked example
Two metrics side by side: daily active users growing from 10,000 to 100,000 over two years, with a weekend dip that's always been roughly 15% below the weekday average - that's multiplicative (the absolute size of the dip has grown 10x alongside the user base, but the RATIO has stayed constant). A metric like "number of scheduled maintenance windows per week," with a fixed operational cadence unrelated to overall traffic growth, is more likely additive.

Trade-offs & pitfalls
Log-transforming to convert a multiplicative problem into an additive one is convenient (lets you reuse additive-model tooling) but changes how you have to interpret and back-transform prediction intervals - a symmetric interval in log-space becomes an ASYMMETRIC interval once exponentiated back to the original scale, which is correct behavior (uncertainty genuinely should be asymmetric on a multiplicative series) but is easy to get wrong if you forget to back-transform properly.

Direct answer
A practical decomposition-residual anomaly detector: run seasonal decomposition, compute the Median Absolute Deviation (MAD) of the residual, flag points whose residual is more than a chosen number of MADs from the median (a robust z-score), and treat known holidays as either excluded from threshold-fitting or modeled explicitly rather than left to trip the same generic threshold as an unexplained anomaly.

Structured elaboration and worked example (executed)
Against a synthetic 180-day daily series (seed=0: linear trend + weekly sinusoidal seasonality + Gaussian noise) with 3 known injected anomalies (two +300 spikes at indices 60 and 120, one -300 drop at index 150):

import numpy as np, pandas as pd
from statsmodels.tsa.seasonal import seasonal_decompose

np.random.seed(0)
n = 180
t = np.arange(n)
y = 1000 + 2*t + 50*np.sin(2*np.pi*t/7) + np.random.normal(0, 15, n)
y[60] += 300; y[120] += 300; y[150] -= 300

result = seasonal_decompose(pd.Series(y), model="additive", period=7, extrapolate_trend="freq")
resid = result.resid.dropna()
mad = np.median(np.abs(resid - np.median(resid)))
robust_z = 0.6745 * (resid - np.median(resid)) / mad
flagged = resid.index[np.abs(robust_z) > 3.5]

Executed result:

Injected anomaly indices: [60, 120, 150]
MAD-flagged indices (threshold 3.5): [60, 120, 121, 150, 151]
True positives: [60, 120, 150]
False positives: [121, 151]

All 3 injected anomalies were correctly detected at threshold 3.5, with 2 false positives immediately adjacent to two of the true anomalies - a real and expected pattern: weekly seasonal decomposition can partially "smear" a sharp anomaly's effect into an adjacent day's residual through the seasonal-averaging step, which is a genuine practical trade-off (a tighter threshold reduces these adjacent false positives but risks missing smaller genuine anomalies).

• Selecting thresholds to control false positives: MAD-based robust z-scores are preferred over plain standard-deviation z-scores because the SD itself is inflated by the very anomalies you're trying to detect, while the median-based MAD is robust to them; the threshold (here 3.5) trades off sensitivity vs false-positive rate, and should be tuned against a labeled historical set of known true/false anomalies where available, rather than picked by convention alone.
• Handling known holidays or seasonal events: a fixed weekly-seasonal decomposition has no way to represent a one-off holiday's effect, so a holiday will look like a large residual and either get flagged as a false-positive "anomaly" or, if severe enough, distort the fitted seasonal profile itself. Two practical fixes: exclude known holiday dates from the data used to FIT the seasonal profile (so they don't contaminate the baseline), and either give holidays their own separate explicit effect (as Prophet's holiday component does) or accept they'll always need to be checked against a holiday calendar before treating a flagged residual as unexplained.

Trade-offs & pitfalls
MAD-on-residuals is a solid default but is still a GLOBAL threshold across the whole series - if residual variance itself changes over time (heteroskedasticity), a single global MAD will be too loose during low-variance periods and too tight during high-variance ones; a rolling-window MAD, recomputed locally rather than once over the whole history, addresses this at the cost of needing enough local history to estimate a stable MAD in each window. Always validate any chosen threshold against a small set of known true anomalies (as done above) rather than trusting a textbook multiplier (like "3 sigma") without checking it against your own data's behavior.

Direct answer
Resolving a cross-functional disagreement about retrain frequency and prediction TTL means making the trade-off (accuracy vs compute cost vs operational stability) explicit and quantified rather than argued in the abstract, aligning stakeholders around a shared decision framework rather than a single number, and building in a defined process to revisit the decision as conditions change rather than treating it as permanently settled.

Structured elaboration

• Evaluating the trade-off: quantify how much forecast accuracy actually degrades as prediction TTL (time-to-live, how long a forecast is served before being refreshed) increases - this is directly measurable via backtesting (compare accuracy of a forecast used immediately vs one used N days stale); quantify the COMPUTE cost of more frequent retraining (a real, budgetable number); and separately name the OPERATIONAL STABILITY cost of frequent changes (a forecast that changes too often can itself be disruptive to downstream planning processes that expect some consistency, distinct from either accuracy or raw compute cost).
• Aligning stakeholders: bring Product, Ops, and Data Engineering into a SHARED view of the actual trade-off curve (accuracy degradation vs TTL, compute cost vs retrain frequency) rather than each side arguing from its own priority in isolation - a concrete, data-grounded trade-off curve turns an abstract disagreement ("we need fresher forecasts" vs "retraining is expensive") into a specific, negotiable point on a shared curve.
• Making and communicating a data-driven recommendation: propose a specific retrain cadence and TTL grounded in where the accuracy-degradation curve starts to bend meaningfully (the point past which staleness costs materially more accuracy than it saves in compute/stability), explicitly stating the trade-offs being accepted at that point, so the decision is legible and defensible to all three stakeholder groups rather than feeling arbitrary to whichever side "lost."
• A process for revisiting the decision: define explicit triggers for reconsidering the choice (a monitored accuracy-degradation signal crossing a threshold, a meaningful compute-cost change, a business requirement shift) rather than either revisiting it constantly (churn, instability) or never revisiting it (staleness accumulating silently) - this closes the loop the same way ongoing calibration/drift monitoring does for a model's outputs, applied here to an operational POLICY decision rather than the model itself.

Worked example
A concrete quantified trade-off might show that forecast accuracy degrades only mildly from a 1-day to a 3-day TTL, but meaningfully more from 3 to 7 days, while retrain compute cost scales roughly linearly with frequency - this evidence supports a recommendation of a 3-day TTL as the point where you're not leaving much accuracy on the table relative to daily retraining, while meaningfully reducing compute cost and operational churn relative to it, a specific, defensible number rather than either extreme position (daily retraining "because fresher is always better," or infrequent retraining "because compute is expensive") argued from principle alone.

Trade-offs & pitfalls
The most common failure in this kind of cross-functional disagreement is treating it as a one-time negotiation to "win," rather than establishing a durable, revisitable process - a decision made once and never revisited will eventually become wrong as the underlying trade-off curve itself shifts (compute costs change, the business's tolerance for staleness changes, the model's own accuracy characteristics change), and a stakeholder group that felt unheard in the original decision is far more likely to escalate the disagreement again later if there's no defined mechanism for it to be legitimately reconsidered.

Direct answer
Stationarity means a series' statistical properties (mean, variance, autocorrelation structure) don't change over time; classical models like ARIMA require it because their AR and MA coefficients are assumed to be constant, which only makes sense if the process they're describing is itself stable. ADF tests the null hypothesis that a UNIT ROOT is present (i.e., non-stationary); KPSS tests the opposite null hypothesis, that the series IS stationary - so the two tests can and do disagree, and understanding why matters more than running either one alone.

Structured elaboration

• Why stationarity matters: if the mean or variance drifts over time, a model with fixed coefficients fitted on history will systematically mis-extrapolate; forecasting theory and inference (confidence intervals, hypothesis tests) for ARMA-family models is built on the assumption of a stable underlying process.
• ADF (Augmented Dickey-Fuller): $H_0$: the series has a unit root (is non-stationary); a LOW p-value lets you reject $H_0$ and conclude the series is likely stationary.
• KPSS: $H_0$: the series IS (trend-)stationary; a LOW p-value lets you reject $H_0$ and conclude the series is likely non-stationary - the null hypothesis is flipped relative to ADF.
• Interpreting conflicting results: because the two tests have opposite nulls, "fail to reject" on either one is weak evidence (absence of evidence, not evidence of absence). Four outcomes are possible: both agree stationary (strong evidence for stationarity), both agree non-stationary (strong evidence to difference), ADF says stationary but KPSS says non-stationary (or vice versa) - the disagreement usually means the series is borderline, e.g. trend-stationary (stationary around a deterministic trend) rather than cleanly one or the other, and you should look at the actual plot and residual structure rather than trust either test blindly.
• Practical preprocessing steps once non-stationarity is confirmed: first-difference the series ($y_t - y_{t-1}$) to remove a stochastic trend; take a log transform first if the variance is growing with the level (stabilizes variance before differencing addresses the mean); apply seasonal differencing ($y_t - y_{t-s}$) if the non-stationarity is seasonal rather than a smooth trend. Re-run the tests after each transformation and stop as soon as they indicate stationarity - over-differencing introduces artificial negative autocorrelation and inflates forecast variance rather than helping.

Worked example
A quarterly revenue series with a clear multi-year upward trend and strong Q4 seasonal spikes: ADF on the raw levels will very likely fail to reject its null (non-stationary, due to the trend), consistent with what the eye already sees. After first-differencing, ADF should reject its null (stationary); if a seasonal signature still shows up strongly in the ACF of the differenced series at the seasonal lag, a further seasonal difference (or a seasonal ARIMA term) is warranted rather than continuing to regular-difference, which would over-correct.

Trade-offs & pitfalls
A subtlety that catches people out: standard hypothesis tests like a t-test assume independent observations, and when a metric is strongly autocorrelated over time (as most business time series are), that independence assumption is violated even before you get to the stationarity question - comparing two periods with a plain t-test on autocorrelated data will understate the true uncertainty and can flag a "significant" difference that's really just normal serial correlation; using a model that accounts for the autocorrelation (or a block-bootstrap / time-series-appropriate test) avoids this trap.