Dynamic Pricing for a Ride-Hailing Marketplace: Supply-Demand Model, Algorithm, Metrics

Design a dynamic pricing system for a ride-hailing marketplace, in which riders request trips, drivers fulfil them, and the price of a trip can change with current conditions. The interviewer asks you to analyse the problem with a supply and demand model, to propose the pricing algorithm, and to define the metrics you would use to evaluate it. The case was given in a statistics-focused screen for a machine learning engineering internship. The report gives only this outline, so the objective, the pricing levers and the constraints are open: settle them with the interviewer before designing. ### Clarifying Questions - What should pricing optimise: completed trips, gross bookings, short pickup times, or a combination with guardrails? - Is the price a multiplier on a base fare set per area and time interval, or a separate price for every request? - Does a higher rider price also raise driver pay, so that it can attract supply, or does it only ration demand? - At what spatial and temporal granularity must prices be set, and how quickly must they react to change? - Are there caps, smoothness requirements, or situations such as emergencies in which prices must not rise? ### Part 1 — Model supply and demand Describe how rider demand and driver supply in an area respond to price over a short time interval, and use the model to explain what happens when requests exceed the drivers available and what a price change does about it. ```hint Two sides, two speeds Consider which side of the market reacts to a price within minutes and which reacts only over a longer horizon, and what riders experience when neither has adjusted yet. ``` #### What This Part Should Cover - Demand as a function of price through rider conversion (price elasticity), and supply as available drivers plus their response to price - How an imbalance shows up as long pickup times and failed requests, and how a price change rebalances the market - Short-run versus long-run responses of riders and drivers - Spillovers between neighbouring areas and adjacent time intervals ### Part 2 — Choose the pricing algorithm Propose how the system sets the price for each area and interval: what it predicts, what it optimises, and how it turns the predictions into a price. ```hint Why history misleads Ask why regressing past conversion on past prices does not measure how riders react to price, given when high prices were shown. ``` ```hint What riders and drivers see Think about what happens if the price jumps between neighbouring areas or from one minute to the next. ``` #### What This Part Should Cover - Short-term forecasts of demand and supply, and a model of conversion as a function of price - An explicit objective with constraints, and how the price is chosen from it - How the price effect is estimated despite confounding - Smoothing, caps and fallbacks when inputs are stale or missing ### Part 3 — Evaluate it Define how you would know that the pricing system works, offline before launch and online after it. ```hint Shared drivers Think about why randomly splitting riders in one city into two pricing groups at the same time could give a misleading result. ``` #### What This Part Should Cover - Offline metrics for the forecasts and the conversion model - An online experiment design that copes with interference between riders who share the same drivers - Primary metrics for riders and drivers, plus guardrails ### What a Strong Answer Covers - Objective and constraints agreed before a method is chosen - A supply and demand model that links price to conversion, driver supply and pickup times - A concrete algorithm: forecasting, price-response estimation and an optimiser with smoothing and caps - Correct handling of the causal problem in estimating how riders respond to price - Metrics for both sides of the marketplace, an experiment design that handles interference, and monitoring after launch ### Follow-up Questions - Prices spike during a sudden event such as a storm or a stadium emptying. What safeguards would you add? - How would you estimate rider price sensitivity if the current system has never randomised prices? - Drivers start moving towards areas they expect to become expensive. How does that change the model? - How would you check that pricing does not systematically disadvantage some neighbourhoods?