First things first: Why should you read this piece? Or, a better question: Why is it important to visualize your metrics on a map?
Because if you are a company that has moving vehicles or has operations in the physical world, a lot of your decisions involve an element of “where”.
Whether it is your users, or bikes, or cars, that is moving on the ground, analyzing metrics that are affected by their location is critical. My favourite example that I like to quote is Uber’s surge pricing model that we all have paid at some point in our lives.
The surge value is influenced by the supply-demand gap at the location where you are booking. In order words, what is the demand density in your area and how much supply is available to cater to the demand along with other parameters such as time, day, weather, traffic, city and so on.
Side Note: In case you want to delve deeper into Uber’s pricing model, check this out:
But, the question remains: Why it is important to analyze metrics by location? Why do we need to think of location as an additional parameter?
Every location has an inherent property of its own and therefore, our decisions and strategies need to take that “context” into account.
Critical Metrics for Ride-hailing Companies
In this section, we will deep dive into what are some of the most influential metrics for ride-hailing companies. Which geospatial distributions on a map makes the most sense for them?
Users Events: [Marketing/Growth teams]
- Installs: Where are people installing the app? Are you currently servicable in that area?
- Searches: Where are users searching for a ride? Do we have drivers in those hotspots? if not, how far are they?
- Bookings: Where do bookings take place? How long after the user searches for a ride? What is the booking frequency?
- Trips: Where do trips take place because of promotions? Where do discounted trips happen?
- Cancellations: Where are trips canceled by the user? Do they cancel because of the ETA?
- Churn: Where do people search but don’t book? Which step do they drop-off? Is it because they don’t get the right preference for the car or is it because of the price?
- Cohorts: Where do we get repeat customers from? Where do we get the most valuable customers from?
Driver Metrics: [Supply/City Teams]
- Total Supply: What is the total number of drivers & how many of them are off-duty or full-time drivers?
- Busy or Idle Driver: How many drivers are idle or busy right now? [This is only useful in real-time] How far are they from the area where we would get demand?
- Idle time or Busy Time: Where do partners spend the most amount of idle time? [This is useful historically] How far are they from the next demand hotspot?
- Cancellations: Where do drivers cancel the bookings? Is it because of the drop location or mode of payment?
- Earnings per Hour or Incentives: Where and when do drivers make the most amount of earnings or incentives?
Trips: [Strategy/Growth Teams]
- Trips Start: What are the most common types of pick up points? Which of them are repeatable? Where do power users start the trip from?
- Trips End: Where do the largest distance trip end? Where do long-duration trips end?
- Origin- Destination Pairs: What are the top O-D pairs in a city? What are the top O-D pairs of most profitable trips?
- Paths: What are the most common paths that repeatable users take?
- Flow: Flow analysis (or network analysis) is to understand how the city moves at different times of the day or even historically.
- Idle Spots: Where are the most common spots where drivers are idle while in trip?
- Walls: Every city has these theoretical “walls” or the combination of origin-destination that drivers don’t prefer to cross.
Business [CXO / Decision Maker]
- Revenue: How is revenue distributed in a city? What are the lowest revenue but the highest driver cost areas?
- Driver Utilization: How is driver utilization spread across city and how does that change with different times of the day?
- Total Kms Driven: How many kilometers have been driven? How is that spread across unique users and trips?
- Requests per hour: How many booking requests do we get per hour in different areas?
- Conversion Rate: What’s the conversion rate of those requests in terms of rider acceptance? Where and when do riders don’t accept bookings?
- Completion Rate: What’s the completion rate of the trips started?
Operations: [Operations/City Teams]
- Accidents: Which areas are the most accident-prone? What kind of behavior causes it?
- Frauds: What are the areas where drivers commit fraud? Refunds from the user’s side are where a lot of fraud happen, especially when they report of driver not reaching the right pick up location.
- Safety: What are the areas or routes which are not reported safe either for users or drivers?
Build vs Buy: How do you choose?
Locale.ai is a location analytics platform, which acts like your control center taking your marketing, supply, and trips data into one place to give you very precise, real-time insights.
Building it Internally
While working with some of the leading on-demand and micro-mobility companies, what we observed that they end up hacking around these open-source tools like Kepler itself or QGIS.
Sometimes developers also build their own internal tools, but most of the time they are not well suited for all different audiences inside the company and since the tools are not built in a scalable way, maintaining these suck up a lot of their bandwidth often!
A lot of times there is even a repetition of effort and the wheel keeps getting re-invented over and over again. As Jeff Lawson from Twilio said —
“It is easier than ever to build software but harder than ever to operate it”
Why Choose Locale.ai?
So, if you are a company that decides to build this internally, it would have to be built like a platform itself, (much like how Uber has done it) and with the following characteristics:
- Simple and intuitive user interface to carry out analyses, especially for business users
- Scalable geospatial visualizations with actionability
- ETL robust enough to handle streaming data as well as historical analysis to go back in time
This would require setting up a team of at least 6–7 (consisting of the front end and data engineers, geospatial analysts as well as data scientists). On top of that, the added pain of waiting for at least 6 months to build the platform and kickstart the analyses.