LAB 03

UBER
DEMAND FORECASTING

A forecasting lab that models ride demand near WWU using historical weekly data, backtesting, and operational decision analysis.

Course MIS 432
University Western Washington University
Backtest Window 104 Weeks
Model MAE 18.9 trips/week
01 · The Business Problem

Why Forecasting
Is Everything

Every time someone opens the Uber app, two things have to happen in the right order: a rider needs a car, and a driver needs to be close enough to make that pickup worthwhile. If Uber gets the timing wrong — too few drivers near a stadium when a game ends, or too many idling downtown on a slow Tuesday — riders wait, drivers waste gas, and the company loses money on both ends. Demand forecasting is the system that prevents that mismatch. It looks at years of historical trip data, identifies when and where demand reliably spikes, and gives operations teams a specific number of drivers to pre-position, hours before the first person even thinks about requesting a ride. Without it, surge pricing becomes reactive noise and driver deployment is guesswork. With it, Uber turns unpredictable human behavior into a logistics problem it can actually solve — and that is the difference between a platform that works and one that doesn't.

Time-Series Forecasting Operations Research Surge Pricing Logic Driver Positioning MAE Validation
02 · The Data & The Model

Training on
Two Years of Fridays

In Steps 1 and 2, I pulled two years of historical Friday night trip data anchored near the WWU campus in Bellingham — 104 weeks in total. From that data, I identified the underlying trend (gradual growth in rideshare usage over time) and the seasonality (predictable weekly cycles and holiday dips), then used both signals to train a forecasting model. The backtest split the data at week 78, holding back the final 26 weeks as unseen test data, so the model had to earn its predictions the same way it would in production — with no knowledge of what came next.

Friday Night Trip Demand — WWU Campus Area · 104-Week Backtest
100 200 300 400 500 trips Wk 1 Wk 26 Wk 52 Wk 78 Wk 91 Wk 104 Weeks (Jan 2023 – Dec 2024) Wk 78 cutoff gap
Actual Friday Night Trips
Model Prediction (backtest period)
Week 78 Train/Test Cutoff
±15% Tolerance Band
The dashed line is what the model predicted. The solid line is what actually happened. The gap between them is the model's error — and the honest measure of how much to trust it.
03 · The Concert Night Prediction

The Actual
Operations Memo

Here is the actual operations recommendation the model produced for the Death Cab for Cutie, Sleater-Kinney, and ODESZA homecoming concert at WWU.

441
Predicted Trips (10–11 PM)
169
Drivers for Full Surge Cover
+122
Driver Supply Gap at Base
18.9
MAE Trips/Week (Validated)
Uber Bellingham — Operations Memo
DATE : Friday, April 25, 2026 FROM : Demand Forecasting / Analytics TO : Bellingham Operations Manager RE : Concert Friday Night — WWU Campus Area EVENT Death Cab for Cutie / Sleater-Kinney / ODESZA Sold-out show at WWU · Show ends 10:00 PM DEMAND FORECAST (10pm–11pm peak window) Predicted trips : 441 trips Planning range : 375 (low) – 507 (high) DRIVER RECOMMENDATION Pre-position : 147 drivers near campus by 9:45pm Standby pool : 22 additional drivers on alert Full surge cover : 169 drivers if demand hits ceiling SURGE PRICING Recommendation : ACTIVATE SURGE PRICING Trigger threshold : >25 drivers needed (current supply) Supply gap : +122 drivers undersupplied at base forecast UPSIDE RISK A simultaneous late-night bar rush combined with post-concert demand, limited parking near campus, or cold/wet weather could push rideshare demand 20–30% above the upper bound. MODEL NOTE This forecast is based on historical Friday night patterns (104 weeks, MAE validated in backtest at 18.9 trips/week). It does NOT include a concert-specific demand multiplier — actual demand may run 15–25% higher than the model's base estimate for sold-out events. Operations judgment should be applied accordingly.
04 · Stress-Testing the Forecast

How Fragile
Is the Recommendation?

Before sending that memo, I stress-tested the key assumptions to understand how fragile the recommendation was.

Stress Test Findings

What the stress test revealed is that the surge call was very stable — it stayed on across every scenario tested and never flipped off. Even when I moved driver availability from 10 drivers to 60 drivers, surge still stayed on because the system was never close to having enough supply for the predicted demand. At 60 drivers with 3 trips per hour, capacity was only 180 trips, but the base demand was still 850 trips, leaving a 670-trip shortfall.

Demand level had the bigger effect on the recommendation: moving from the low to high demand scenario changed the shortfall from 648 trips to 902 trips — a larger swing than varying driver availability across its full range. The main condition that would change the surge recommendation is if actual demand came in much lower than expected. Based on the current numbers, the safer business decision is to plan for surge and pre-position as many drivers as possible before the concert crowd exits.

A real analyst runs stress tests before committing to a recommendation because the model's output is only as trustworthy as its weakest assumption. If a single parameter flip reverses the call, the recommendation was never solid — and stress testing is the fastest way to find that out before operations acts on it.

05 · When the Algorithm Decides

The Prediction–
Decision Gap

Once the forecast number is produced, Uber's algorithm takes over and automatically sets the surge multiplier — no human review, no pause button. The system sees demand spike and supply drop, calculates the ratio, and publishes a price within seconds. When the model is right, this is elegant: prices rise exactly when they need to, drivers are incentivized to move toward demand, and the market clears. When the model is wrong, the consequences arrive just as fast and with just as little friction.

⚠ Earthquake Scenario — Bellingham, 5.8 Magnitude

During a 5.8 magnitude earthquake in Bellingham, the algorithm fired a 4.8× surge multiplier because it only saw what it was built to see: demand spiking as panicked residents requested rides, and supply collapsing as frightened drivers pulled off the road. There was no emergency flag, no human with an override key, no mechanism to distinguish a crisis from a concert. The people who needed to evacuate the most were charged the most — not because anyone decided that was acceptable, but because no one had designed the system to decide otherwise.

06 · When the Model Breaks

Distribution
Shift

Six weeks after the concert, the world the model had learned quietly became the wrong world: WWU enrollment dropped, a new apartment complex opened in Cordata pulling residential demand away from campus, and Lyft entered the Bellingham market for the first time — three structural changes the model had no sensors for. The MAE jumped from 23 trips per week to 796 trips per week, and the model ran wrong for ten weeks before the monitoring alert fired. In those ten weeks, drivers followed the model's predictions to locations where demand no longer existed — they earned less. Riders opened the app and waited longer than they expected, or switched to Lyft to get what Uber used to provide. Nobody told them why. The model didn't know it was wrong, so it didn't say anything — it just kept producing confident numbers from a distribution that had already shifted beneath it.

23
MAE Before Shift (trips/wk)
796
MAE After Shift (trips/wk)
10
Weeks Model Ran Wrong
3
Structural Changes Missed
07 · My Analysis

What This
Lab Showed Me

Step 8 reflection — in my own words, exactly as submitted.

What this lab showed me, at least from how I worked through it, is that every step of Uber's AI system connects, starting with the data the model learns from. In Step 1, the data I collected determined what patterns the model could understand, and in Step 2 those patterns became the forecast that was tested against past Friday nights. By Step 3, that forecast turned into a real business recommendation for the WWU concert, including how many drivers should be near campus and whether surge pricing should activate.

Then in Step 4 and Step 5, it became clear that the forecast does not just stay as a number, because it can trigger pricing decisions automatically — like when the algorithm fired a 4.8× surge during an earthquake just because it saw demand spike and supply drop. Step 6 and Step 7 showed the longer-term risk, because when the model was wrong for 10 weeks or sent drivers to the wrong area, riders waited longer, drivers earned less, and the system kept making decisions before anyone fully understood what had changed.

If I were building this forecasting system for a real Bellingham business, the one thing I would add is a local event and emergency override system that flags concerts, unusual demand spikes, or emergencies like earthquakes, and pauses or adjusts automatic surge decisions before they affect what riders pay and what drivers earn.