Click any component to explore it in the full case study.

Per-Ride Prophet Training + Inference Pipeline
Step 1
Training Data View
prophet_ready_data_view (BigQuery SQL) joins: historical waits, weather, schedules, metadata. Per-ride filtering.
Step 2
Per-Ride Training
N separate Prophet models (one per attraction). Additive seasonality: daily, weekly, yearly. Linear growth mode. All 50+ regressors via m.add_regressor().
Step 3
Future Context Build
NWS 24hr forecast, park hours, time decomposition features. Rolling/lag features imputed to 0 at inference (v8 limitation).
Step 4
Prediction
24-hour horizon at hourly resolution. yhat + yhat_lower + yhat_upper confidence interval. Written to prophet_predicted_wait_times (BigQuery).
⚠️ Why v8 Was the Final Iteration
Rolling mean and lag features unavailable at inference time — had to be imputed to 0, causing systematic underestimation. Prophet per-ride models solved recursive error from v6, but feature imputation failure introduced a different systematic bias. Training data infrastructure directly informed the PostgreSQL aggregate schema used in production today.
['Lag imputation = 0 at inference', 'Systematic underestimation (rolling features)', 'v6 recursive error → solved', 'v8 imputation error → new blocker', 'Training infra → informed PG aggregate schema', 'Per-ride isolation = key learning']
ride-whisperer.html#version history
N×1
Per-ride models
50+
Regressors per model
24hr
Forecast horizon
v8
Final iteration
StackFacebook ProphetBigQueryGCP Cloud StoragePythonNWS forecast APIHistorical CSV data (2015–2021)Additive seasonality