Google Product Time-Series Forecasting And Anomaly Detection

What's being tested

A strong candidate must translate an ambiguous product-monitoring request into a precise time-series target, forecast horizon, anomaly definition, and decision policy. The interviewer is probing whether you can distinguish genuine product changes from seasonality, trend, data-quality artifacts, and expected experimentation effects. For a Data Scientist, Google cares about this because trustworthy anomaly detection informs incident response, product launches, experimentation interpretation, and prioritization—not merely model accuracy.

Core knowledge

• Metric specification comes first: define the numerator, denominator, population, timestamp semantics, aggregation window, and alert consumer. “Search success” might mean query-level success rate, user-level next-action rate, or a ratio of aggregated counts; these have different variance and business meaning.

• Time-series decomposition separates level, trend, seasonality, and residual:
  $y_t = T_t + S_t + R_t$
  or, for multiplicative behavior, $y_t = T_tS_tR_t$. Use additive structure when seasonal amplitude is stable and multiplicative or log-scale structure when volatility grows with the metric level.

• Seasonality may be daily, weekly, annual, holiday-driven, or event-driven. A Monday-to-Sunday comparison is often more meaningful than a prior-day comparison. Include calendar features such as day of week, hour, holidays, school breaks, and known launches, but avoid encoding future information unavailable at prediction time.

• Baselines are essential and often competitive: seasonal naïve forecasting predicts $y_t$ from the same weekday and hour in the prior week; a robust baseline can use the median of the last $k$ comparable periods. Compare every sophisticated model against these before claiming improvement.

• Forecasting models span exponential smoothing, ARIMA/SARIMA, dynamic regression, gradient-boosted trees, and global neural models. Prophet-style trend-plus-seasonality models are convenient, while XGBoost with lag, rolling, and calendar features can perform well across many related product metrics; complexity should match data volume and horizon.

• Anomaly detection should operate on forecast errors or prediction intervals, not raw values alone. If $\hat y_t$ is the expected value, define the residual $e_t=y_t-\hat y_t$ and alert when $e_t$ exceeds a calibrated bound, such as
  $|e_t| > z_{1-\alpha/2}\hat\sigma_t.$
  Use robust scale estimates such as MAD when residuals contain outliers.

• Prediction intervals express uncertainty: a point forecast can be accurate on average while still producing poor alert boundaries. Evaluate empirical coverage—whether a nominal 95% interval contains roughly 95% of future observations—and interval width; narrow, under-covering intervals create noisy alerts.

• Backtesting must respect temporal order. Use rolling-origin evaluation: train through time $t$, forecast the next horizon, advance the cutoff, and repeat. Random cross-validation leaks future patterns and typically overstates performance, especially when trends, launches, or autocorrelation exist.

• Metrics should match the operational goal. Use MAE or RMSE for point forecasts, WAPE or MASE for scale-normalized comparisons, and pinball loss for quantiles. For anomaly alerts, measure precision, recall, time-to-detection, alert volume, and false alerts per metric-day; “accuracy” is usually misleading under extreme class imbalance.

• Robustness matters more than average error. Segment performance by geography, device, traffic volume, product surface, and forecast horizon. Check behavior around holidays, traffic spikes, zeros, missing intervals, denominator changes, and metric-definition changes; a model that wins globally may fail for a high-value segment.

• Causal interpretation is separate from detection. An anomaly identifies an unusual change, not its cause. Diagnose with metric decomposition, cohort slices, funnel steps, experiment assignments, and correlated product metrics; use controlled experiments or quasi-experimental methods before claiming that a feature caused the movement.

• Alert policy should reflect cost asymmetry and persistence. Require two or more consecutive breaches, use hysteresis to prevent repeated open/close alerts, and prioritize by estimated user impact. A practical score can combine standardized deviation, affected volume, duration, and business criticality rather than ranking solely by statistical significance.

Worked example

Design a forecasting and anomaly-detection approach for a Google product metric is a representative framing for this topic. In the first 30 seconds, clarify the metric definition, sampling frequency, forecast horizon, alert latency, expected anomaly labels, and whether the goal is incident detection, capacity planning, or experiment monitoring. State an assumption such as hourly query-success rate for a major product surface, with alerts needed within two hours and strong weekday seasonality. Organize the answer around four pillars: a seasonal-naïve baseline, a forecasting model with calendar and lag features, residual-based prediction intervals, and an evaluation and diagnosis plan. Explicitly separate metric movement from root-cause analysis by proposing cohort and funnel slices after an alert fires. One key tradeoff is sensitivity versus alert fatigue: tighter intervals detect smaller regressions but can overwhelm responders, so calibrate thresholds against historical incidents and a false-alert budget. Close by saying that, with more time, you would validate subgroup coverage, test holiday and launch robustness, and estimate the user impact of missed versus spurious alerts.

A second angle

A different framing is detecting anomalies in a sparse, low-volume metric across many countries. Here, raw percentage changes are unstable because a small denominator can create enormous swings, so model numerator and denominator jointly or use binomial or beta-binomial uncertainty. Partial pooling or hierarchical models can borrow strength across related countries while preserving meaningful local deviations. The operational goal may also favor ranking the most credible anomalies rather than producing a binary alert for every series.

Common pitfalls

Pitfall: Treating every deviation from the previous hour as an anomaly ignores daily and weekly seasonality, trend, and changing variance. Use a seasonal baseline or forecast residual and validate its interval coverage.

A tempting analytical mistake is to report lower RMSE as proof that the alerting system is better. Forecast accuracy and detection quality are different objectives; evaluate precision, recall, detection delay, alert volume, and business impact separately.

Pitfall: Saying “the model will identify the root cause” overclaims what forecasting can do. Detection should trigger structured segmentation, funnel analysis, experiment checks, and causal investigation.

A communication mistake is jumping immediately to ARIMA, Prophet, or a neural model without defining the metric and decision. Interviewers generally reward an explicit target, horizon, baseline, validation design, and alert policy before model sophistication.

A depth mistake is ignoring uncertainty and data sparsity. Point forecasts alone cannot set reliable thresholds, and a 5% change in a high-volume count is not statistically equivalent to a 5% change in a tiny cohort.

Connections

An interviewer may pivot to causal inference, experiment analysis, metric design, or hierarchical modeling. They may also ask about change-point detection, multiple-testing correction across thousands of monitored metrics, or how to distinguish product regressions from measurement changes.

Further reading

• Forecasting: Principles and Practice — Hyndman and Athanasopoulos’s practical treatment of decomposition, backtesting, intervals, and forecast evaluation.

• S. S. Vallis, J. Hochenbaum, and A. Kejariwal, “A Novel Technique for Long-Term Anomaly Detection in the Cloud” — introduces the Seasonal Hybrid ESD approach used for robust seasonal anomaly detection.

• S. Aminikhanghahi and D. J. Cook, “A Survey of Methods for Time Series Change Point Detection” — useful taxonomy for distinguishing isolated anomalies from persistent regime changes.