AI Demand Forecasting and Dynamic Pricing for a Ride-Hailing Platform
Industry: Mobility, ride-hailing
Project type: Machine learning demand forecasting, dynamic pricing, production incentive service
Context
Ride-hailing economics come down to two things: how many trips each driver completes, and how well supply and demand are balanced at every point in the city. Both depend on accurate demand forecasting.
Drivers have a hard cap of 13 hours online per day, set by regulation. The platform wants each driver to catch as many orders as possible within those hours: higher utilization means more driver earnings and more commission for the platform. Time spent online without a passenger is time nobody gets paid for.
The ideal shift is a driver going online and getting an unbroken stream of orders for all 13 hours, with each drop-off point becoming the next pickup. One hundred percent utilization. That never happens in practice, but it is the target the platform optimizes toward.
Performance is tracked through proxy metrics: average trips per driver and average trip length. If a driver's typical daily earnings equal roughly five average fares, then five trips becomes the proxy for revenue. Any single day may land higher or lower, but statistically the trip count predicts the money well before the actual revenue data arrives.
The Problem: Volatile Surge Pricing
The platform already used driver incentives to steer supply across the city. For example: complete an order and receive a guaranteed payout of 1,000, even if the fare came to 800. Incentives varied by geography, order volume, and time of day. Their purpose was driver dispatch and allocation: getting drivers online at the right time in the right place.
Only supply can be managed. Demand is when people want to ride, and the platform can only adapt to it.
The core metric is the demand-to-supply ratio, known as surge — the platform's form of dynamic pricing. The target corridor sits around 1:1, with demand running slightly ahead of supply. That is the point of maximum efficiency: conversion to a completed trip is high, nearly every rider gets a car, and those who don't get one immediately wait a little and ride anyway. Almost nobody drops off.
The problem was volatility. Rain starts, drivers are short, prices triple, and riders decide the service is gouging them and don't book at all. The goal was to hold the ratio inside the target corridor as precisely as possible, with a demand forecast driving where and when incentives go out.
The Solution
Building the demand forecasting model
Early on, the calculation ran on a fixed formula. The analytics team then replaced it with a machine learning model for demand and supply forecasting.
The approach: first work out what actually drives demand, then feed the model every data source within reach.
Time of day and day of week. The distribution is clear on the charts: morning commutes to work, evening commutes home, late-night Friday and Saturday traffic out of clubs.
Demand heat map. Certain locations light up with request volume — nightlife districts, restaurant clusters. The map turns red.
Traffic data from a mapping service. The mapping service already runs its own congestion forecasting model, which was used to project upcoming road load in specific districts.
Historical ride demand by time and day of week.
Weather forecast as an additional factor. If one part of the city is forecast for rain and another isn't, demand in the rainy area will likely spike. Nobody wants to get wet, especially far from a subway station.
Fare tiers. Not one product but a lineup: economy carries most volume, but in large cities a meaningful share of riders book Comfort, Comfort+, Premium, and Business.
Driver supply forecast — who has booked shifts and who hasn't.
Car sharing — where shared cars are located at the moment, with a short-term forecast, as an alternative to a ride.
Road infrastructure — construction and road work.
The final demand forecasting model ran on hundreds of smaller parameters.
Training and validating the forecasting model
Data is loaded into a data warehouse and labeled: every column and every table gets a documented definition of what it holds.
Historical data is then split in two. The model trains on two thirds and is validated on the remaining third: it forecasts what will happen, and the forecast is compared against what actually happened, which is already known from history.
A baseline machine learning model comes together fairly quickly and gets roughly 70% of the way there. The remaining 30% is the hardest part and the most valuable one — that is where most of the money sits. The closer the forecast tracks reality, the more revenue the platform earns, the better the service performs, and the more often riders come back. Getting there takes careful, methodical tuning.
Tuning works like this: the model processes all the data and assigns its own weights to each parameter. During retraining, analysts strengthen or weaken specific parameters and measure how that changes the final forecast.
Why the physics of the data matters
It isn't enough to understand the data as numbers; the team has to understand what the data physically represents. Traffic isn't just a column of values. During training, adjusting the traffic weight can push the model into error, which shows that congestion needs heavier weighting in certain conditions. Then rain starts — and when rain coincides with heavy traffic, the city locks up entirely, and no incentive can fix that. Understanding how parameters interact is what makes precise tuning possible.
Moving the forecasting model to production
Once the model was ready, engineering took over. The model went into production, rolled out to a couple of cities, and was monitored. The team then built the service layer and supporting infrastructure that let analysts plug in new demand forecasting models on their own — deploy a new version to a specific city and measure how it performs.
Impact was validated on two closely matched cities using A/B tests and switchback tests.
The handoff between teams worked like this: analytics comes with a model and proposes a production test. Engineering defines the infrastructure needed — where the algorithm runs, where the model lives, how the service connects to it, and how it will behave in a given city.
Where production goes wrong
Load. It is easy to underestimate the load on the model and on data processing — throughput, and the hardware needed to handle the data volume. The model has to respond fast; users need results without delay.
SLA. If the SLA requires an operation to complete in five seconds and it takes six, the implementation is wrong.
Data architecture. If a single table holds a million rows and every query hits it, processing slows to a crawl. The right approach is to split the data — customers in one table, their transactions in another — to reduce joins and speed everything up. This is the job of data architects: estimating potential data volume, deciding which metrics and data feed the model and where they come from. Traffic signal data may come from a municipal API, weather from a weather service API. All of it has to connect and flow correctly, and the volume determines the hardware. This is mathematical and engineering work in equal measure.
Deployment. A release can break the service. Say another feature in production already depends on the same data, and the new build doesn't account for it — the deploy breaks that feature. That's why large companies run a team of architects, one per domain, and keeping releases from colliding is a substantial job in its own right.
Scaling
Running the solution in one or two cities is relatively simple; the infrastructure holds. Scaling to every city is a separate and harder problem. But by that point the effect has already been proven on real data, and the economic case can be calculated: how much additional revenue the platform will earn and how much the service will improve. From there it's design, implementation, and rollout.
Results
- +5% revenue immediately after launch. Gains slowed after that — this is a long, effectively continuous optimization process.
- Timeline: about one year.
Team and Scale
- About 20 people on testing and about 20 people effectively on implementation.
- The platform's full economics function (engineering, analytics, B2C and B2B products, QA) — about 200 people.
- Project cost: about €10 million.
What Would Change If Built Today With AI
Architecture design is the biggest opportunity. AI remembers and knows more, can propose a partially built solution to refine instead of designing from scratch, and surfaces gaps that are easy to miss during design. In practice, the architecture gets worked out in conversation with the model.
Background model search. Give AI a dataset and leave it running for a week to search for the optimal model architecture and weights — automated hyperparameter search. Previously, a person did this manually: think, try, review, redo.
Code. Faster code and SQL. In a large system, writing code is hard because there is a lot to keep track of and nothing can be missed.
Team reduction — up to 20%, primarily in QA and part of analytics.
Where AI Demand Forecasting Applies
Any business that forecasts cyclical demand or costs, where data is generated by large numbers of people through transactions, orders, or sales. The same demand planning and forecasting approach carries over directly.
- Banking and fintech — credit scoring models. For fintech this is core business, so these models are often built in-house.
- Insurance.
- Delivery and logistics.
- Retail demand forecasting and site selection. Where to open a store based on foot traffic, nearby competitors, local purchasing power, and tourism.
- Neighborhood scoring for real estate. Services that aggregate city-level data — crime, public amenities, resident requests to local government, construction plans — to model demand, district load, and housing prices, and to judge whether a new development will find demand while the site is still in the approval stage.
Client profile: mid-market and larger. Smaller businesses have less data and don't need patterns at this level.
Adjacent service: data parsing and labeling for the client's specific task — much of the data companies have is not collected in a usable form.
Related Case Studies
- Local Market Analysis: De-Risking a Multi-Location Expansion
- Competitor Price Tracking Software: Recovering 12% of Retained Margin
About the Author
Alexander Soldatov — Product Lead, Building Agentic
Ten years in product leadership at Yandex, AliExpress, and Tinkoff. Built Yandex.Scooters operations from zero and scaled the team to 23 specialists; led Yandex.Shuttle; ran cross-border logistics products at AliExpress, launching China and Turkey corridors that delivered 3.5% GMV growth and 25% faster order fulfillment. At Building Agentic he owns hypothesis validation and MVP scoping — deciding what gets built first and what gets cut.
