NOTE: To maintain the confidentiality, sensitive company information are masked/removed from this document. This case study examines surge pricing in ride-hailing platforms, with a focus on UBER's hexagonal indexing system (H3). The study explores the challenges of implementing this system in Snapp, particularly H3's inability to adapt to extreme fluctuations. More precisely, having a prefixed hexagon resolution level for each city is not always optimal, as it would result in considerable no-decision cases due to the lack of signals. To address this issue, the author proposes a machine learning based approach and discusses the impact of launching this solution into production.

1. Case Study:
Dynamic Pricing in
Ride-Hailing Platforms
Hamed Shams
Product Manager at

2. Abstract
Over the past decade, ride-hailing platforms revolutionized urban transportation. However,
one of the most significant challenges faced by these platforms is the constantly fluctuating
supply & demand volumes which causes serious issues in dynamically setting prices.
This case study examines surge pricing in ride-hailing platforms, with a focus on UBER's
hexagonal indexing system (H3). The study explores the challenges of implementing this
system in Snapp, particularly H3's inability to adapt to extreme fluctuations. More precisely,
having a prefixed hexagon resolution level for each city is not always optimal, as it would
result in considerable no-decision cases due to the lack of signals.
To address this issue, the author proposes a machine learning based approach and discusses
the impact of launching this solution into production. This product resulted in a 27%
decrease in no-decision cases, showcasing the effectiveness of the approach.

3. Introduction
Dynamic pricing is the study of finding the optimum price of products / services in a
frequently adjusting manner, which applies to both online services (e.g., e-commerce,
platforms) and brick-and-mortar stores.
Nowadays, technologies have paved the way for setting prices more accurately by
considering many factors, and also much more frequently (almost real-time).
With this specific definition, we can say “dynamic pricing” emerged in the 1980s, driven by
technological innovations. It was pioneered by the airline industry, which used factors like
departure time, destination, and season, to automate their pricing.

4. Ride-Hailing Platforms

5. Ride-Hailing Platforms

6. Passengers’ Expectation
• Lowest Fare
• Lowest Waiting Time
Pricing in Ride-Hailing Platforms
Drivers’ Expectation
• Maximum Earning

7. The Price is Upfront…
A fare estimation of the ride price before it start.

8. 1. Distance Factor
Price = [ Base Factor
+ ( Price per Km * Km ) ]
e.g in Tehran
Price = [ 4000 + ( 750 * 8.1 ) ] = 10,000

9. 2. Time Factor (ETA)
Price = [ Base Factor
+ ( Price per Km * Km )
+ ( Price per Min * Min ) ]
e.g in Tehran
Price = [ 4000 + ( 350 * 8.1 ) + ( 300 * 30 ) ] = 16,000

10. How about the Marketplace imbalance?

11. 3. Surge Factor
Price = [ Base Factor
+ ( Price per Km * Km )
+ ( Price per Min * Min ) ] * Surge
E.g., Surge = 80%
Price = [ 4000 + (350 * 8.1) + (300 * 30) ] * 1.8

12. # Ride Request events
# Price Check events
Demand Rate =
# Accept events
# Ride Request events
Supply Rate =
Measured by:

13. 7:00 7:10 7:20 7:30 7:40 7:50 8:00 8:10
Time Boundaries
Space Boundaries

14. The procedure of ordering a ride is a series of location-based actions over a
period of time. Therefore, Supply and Demand conversion rates need to be
defined over a specific unit of space and time.
To be more accurate, all the events need to be collected and processed with
respect to a predefined space and time unit; Otherwise, no conversion rate
can be calculated. Without a clear definition of space/time, nothing can be
interpreted nor compared.
Time and Space Boundaries

15. Time and Space Boundaries:
“No-Decision” Cases
A minimum number of “price check” events is required within a predefined
time/space unit, in order to consider the conversion rates coming from those
price checks as valid.
Therefore, whenever the number of available events within a time/space
boundary is lower than this minimum threshold, we consider it a “no-decision”
case, because we can not make any decision for adjusting the price.

16. Time and Space Boundaries:
How to Define?
The behaviour of supply and demand is directly tied to the number of
available drivers and passengers within a given area, which of course changes
over time, based on many factors, such as traffic patterns.
One of these two dimensions must be tightly defined (as a hard constraint) so
we can start playing with the other in a more dynamic manner, and hopefully,
achieve an optimum solution ultimately. By considering a fixed time window
(say 10-minute intervals) we can start defining the units of space; in other
words, indexing the geospatial data.

17. Geospatial Indexing in Surge Pricing
1. Defining some Districts Manually
2. Hexagon Hierarchical Indexing

18. Problems with Manually Defined Polygons
1. High Variations within each Polygon
2. Phantom Demand

19. 1. High Variations within each Polygon
Imagine a football match is happening at the Azadi Stadium…
Azadi Stadium
Chitgar District

20. 1. High Variations within each Polygon
increase in the demand of ”Chitgar” increase in the price of “Chitgar”
Azadi Stadium
Chitgar District

21. 1. High Variations within each Polygon
Even for riders on the low-demand areas of this district, which is not fare.
Azadi Stadium
Chitgar District

22. 2. Phantom Demand
Azadi Stadium
Imagine a driver realize the demand of “Chitgar” district has raised (surged)
Chitgar District

23. 2. Phantom Demand
But, there may be no ride request since the real demand is on the other side
Azadi Stadium
Chitgar District

24. Solution:
A more granular and dynamic approach

25. https://www.uber.com/blog/h3

26. Advantages of Hexagonal Indexing
1. First and foremost, it is not manual!
2. More granularity in supply-demand (address problem #1)
3. Smooth gradients (address problem #2)
4. Symmetric shapes and equal partitions
5. Equal distance from the neighbors

27. Hexagon Resolution Level
H3 supports 16 different diameters. Each finer resolution, has cells with one
seventh the area of the coarser resolution. Hexagons cannot be perfectly
subdivided into seven hexagons, so the finer cells are only approximately
contained within a parent cell.

28. Hexagon Resolution Level

29. Critical Issue:
a single resolution can not work everywhere everytime
The behaviour of supply-demand is extremely fluctuating, which leads to
sudden rises and falls in the “price check” events. Therefore, by using a
specific (fixed) resolution level for each city, two things would happen:
• Hexagons are too small, so they rarely meet the predefined min threshold,
leading to no-decision cases.
• Hexagons are too big, resulting in the similar scenarios with the Manually
Defined Polygons. i.e., lack of granularity and smoothness.
H3 addressed this issue with the “K-Ring” function…

30. If the events within a hexagon does not meet the min ”price check” threshold
L1
H3’s Geo Expansion Function: “K-Ring”

31. Then, the hexagon will be expanded to its neighbors (L2)
L1
L2
L2
L2
L2
L2
L2
L1
K-Ring-1
H3’s Geo Expansion Function: “K-Ring”

32. L1
L2
L2
L2
L2
L2
L2
L1
L2
L2
L2
L2
L2
L2
L3
L3
L3
L3
L3
L3
L3
L3
L3
L3
L3
L3
L1
K-Ring-1 K-Ring-2
If the events are not enough yet, then it will get expanded another level (L3)
H3’s Geo Expansion Function: “K-Ring”

33. Problem Definition
While the Geo Expansion (K-Ring) approach has proven effective in mitigating
no-decision cases, our experiments have shown that it is insufficient to
handle extreme fluctuations. This often results in outdated surge factors and
unadjusted prices, causing an unbalanced marketplace.
The issue is particularly pronounced during rush hours in commercial regions,
where the system struggles to keep up with the influx of incoming "price
check" signals. Moreover, manually adjusting resolution levels for each city is
an impractical and potentially biased approach.
Therefore, there is a need for a more robust and automated solution that can
adapt to extreme fluctuations in a timely and effective manner.

34. Proposed Solution
To address the issues of outdated surge factors and unadjusted prices caused
by extreme fluctuations, an automated solution is required to minimize no-
decision cases and accelerate price adaptation. This can be achieved by
dynamically adjusting the resolution level in each city, based on the estimated
number of "price check" events in the next time interval.
To accomplish this, we developed a time series forecasting approach to
predict the number of "price check" events based on space and time. For
example, we can forecast the number of price check events in Tehran within
the next hour. To maintain confidentiality, we have omitted implementation
details from this document.

35. Business Impact
• About 27% decrease in the no-decision cases overall. The reduction rate
was much more considerable during midnight and rush hours.
• Resulting in a 6% increase in drivers’ earnings while improving rider’s
conversion. In other words, a more reasonable and fair pricing.