Forecast Next-Minute Ride Requests per Geohash at Each Price Multiplier

A ride-hailing app wants a short-horizon demand forecast at a fine spatial resolution. For the last 5 minutes you have, per area of the city: - **Sessions**: the number of app sessions, that is, times riders opened the app. - **Requests**: the number of ride requests riders submitted. - **Geohash**: the city is divided into geohash cells of roughly 1.2 km × 600 m, and sessions and requests are counted per cell. - **Premium multipliers**: the price premium on a ride takes one of five levels: 0%, 15%, 50%, 70% or 100%. For each geohash, predict how many ride requests the app will receive in the next minute under each of the five premium levels, that is, one forecast for every geohash × premium pair. Choose a model and explain your modeling approach in terms of the business setting: how you define the target, which data and features you use, how you train and evaluate the model, and how it runs in production. The report presents this as an open-ended ML design and demand-forecasting case, in which the choice of model has to be justified by the business setting rather than just named. It does not say how the forecasts are consumed or which other data exist. This version assumes that historical logs of the same per-cell signals are available for training, that a premium of 50% means a rider is quoted 1.5 times the base price, and that forecasts are refreshed every minute. ```hint What the logs never show In any past minute a cell had one premium in effect, not five. Ask how you would learn what requests would have been at the other four levels. ``` ```hint Where price acts A rider opens the app before seeing a price. Think about which of the two counts the premium can change within the same minute. ``` ```hint Small counts A cell covers less than one square kilometer and the horizon is one minute, so many counts are 0, 1 or 2. Consider what that means for the loss function and for cells with little history. ``` ### Constraints and Clarifications - One forecast per geohash cell and premium level for the next one-minute interval, produced every minute for every cell in the city. - The forecast for a premium level is the expected number of requests in the cell if that level were in effect there for the next minute, whatever level is actually chosen. - Inputs at prediction time include the per-minute sessions and requests of the last five minutes and the premium currently in effect in each cell. ### Clarifying Questions - Is the premium in the logs set per cell and minute, or can riders in the same cell be quoted different premiums, for example by ride type? - Has the premium ever been varied independently of demand, for example in pricing experiments, or has it always been set by the pricing system in response to supply and demand? - Is a request counted once per rider, or does a rider who cancels and requests again count twice? - Who consumes the forecasts: a pricing system choosing the next minute's premium, driver positioning, or both? Does the consumer need the level of demand, the shape of its response to price, or both? - Is driver supply per cell, such as available drivers or pickup times, available as an input? - Is a session assigned to the cell where the rider is, or to the pickup location they enter? ### What a Strong Answer Covers - A precise target definition per cell, minute and premium, and a framing that separates how much demand arrives from how it responds to price - Recognition that premiums are set in response to demand, so historical data confound the price effect, with a concrete plan to identify the response at all five levels - Features at several time and spatial scales, and a way to handle sparse counts and cells with little history - A model and loss suited to small counts, justified against simple baselines and heavier alternatives - Time-respecting evaluation of both forecast accuracy and the price-response curve, followed by an online validation plan - Minute-level serving: feature freshness, latency, fallbacks and monitoring ### Follow-up Questions - The pricing system chooses premiums using your forecasts. How does that feedback loop change the data you will train on next month, and what would you do about it? - In some cells your model predicts more requests at a 50% premium than at 15%. What would you check, and how would you prevent it? - When a large event ends, sessions in one cell jump several-fold within a minute. How does your model respond, and what would make it react faster? - How would you measure accuracy at premium levels that are rarely in effect in a given cell?