When companies use Google Maps Platform for very specific use cases, we sometimes need to refine our maps data, add new types of info, or combine a variety of different data points to come up with new ways of solving their challenges. In this installment of Beyond the Map, we asked the author of our last post, Eli Danziger, for a better understanding of how mapping for rides and deliveries use cases is different than general mapping.
What is it about the experience of calling a car or having food delivered that makes the type of information we need to deliver to customers, different than the info we have in the consumer Google Maps app?
A couple things. First, these experiences often come at critical times in people’s lives–some might call them micro-moments–when the stakes are high to deliver a great product experience. When you’re rushing to get to the airport on time, getting matched to a nearby driver and seeing real-time ETA can mean the difference between making or missing your flight. And of course, we all know that when we don’t get our food on time, we get hangry. Then there’s the fact that our customers often have customers of their own, who are paying for these experiences. When you pay for an experience, your expectations are immediately much higher. Because of the nature of these experiences and interactions, our customers need to be able to set the right expectations and transparency throughout the process which means we need to provide different types of data and features than that are available in consumer Maps.
How does this translate into different types of maps data or Google Maps Platform capabilities?
Because rides and deliveries customers serve users at these critical times, they need extremely detailed data about the world to help riders meet their drivers, or couriers deliver a meal at the right time. So that’s why we’ve done things like adding two-wheeler routes in Southeast Asia, which we mentioned in our last Beyond the Map post. In that particular region, two-wheelers are commonly used for ridesharing and making deliveries. Without those routes in Maps, customers wouldn’t be able to route their two-wheeler drivers adequately.
Going beyond our maps data, we also need to do things like make sure our APIs work as effectively as possible for scenarios unique to rides and deliveries. For example, users hailing a ride often start typing their location and then choose from an option surfaced through the use of Places Autocomplete. To make that process as helpful and quick as possible, we’ve developed a new ranking model for our Places Autocomplete results to make sure the options that surface first are the most relevant to people trying to call a ride.
Finally, because the rides and delivery space is on-demand we need to provide our customers and their end users with the freshest possible information. For an end user ordering the best burrito in town, that’s being able to see where their meal is in real-time on the map (hopefully that also staves off the hanger). And for our customers, that’s being able to do things like send their drivers alerts and notifications or get a better overall look at drivers’ navigation behavior in real-time.
What are some key terms we should know to understand the world of mapping for rides and deliveries?
There are quite a few terms we use when talking about mapping for ridesharing that we don’t commonly use in other areas of our mapping work. The one concept that people who use ridesharing services might be familiar with, and that I’ve already mentioned, is pickup points. It’s pretty self-explanatory–it’s the location of a ridesharing pickup. But the simplicity of the term is a bit misleading, because it’s one of the most integral parts of getting a ridesharing experience right. And there’s nothing simple about accurately determining the right pickup point–whether it’s the entrance to a building or the right side of the street so the rider doesn’t have to cross over and the driver doesn’t have to u-turn. It’s something our customers have invested heavily into getting right, and we’re always looking for new ways that our data can support their efforts to make the pickup experience as seamless as possible.
On the other hand, allocation is a function that we as consumers don’t often think about. We just expect a car to pull up to where we are, or for our food to get to us nice and hot. But in order for that end result to happen, the service you’re using needs to be able to find the right driver for your specific request. Evaluating real time traffic, identifying the driver closest to you, or the restaurant you ordered from–that all goes into the process of matching drivers and riders, or couriers and orders.
And then there’s the acronym ETA, which I mentioned earlier. It stands for estimated time of arrival. And though it’s not exclusive to the rides and delivery space, it’s a concept that’s core to both the business and end user experience. Having real-time ETAs from driver to rider pick-up and then from pick-up to rider destination not only enables a ridesharing provider to efficiently utilize their fleet--which is great for both the driver and the business–but it makes for a positive rider experience too. So when ETAs are right, everyone wins.
Why is latency important to deliver a positive experience to customers and their end users?
We’ve seen time and time again that faster is better when it comes to user experiences. What this means is that the lowest possible latency on APIs and services are needed because customers can’t build experiences that are faster than their slowest component. We’ve made a lot of progress on this front, and are committed to continuing to improve.
Ridesharing has scaled into a global industry with unique requirements. But it’s a relatively recent mode of transportation with an associated set of evolving technologies. We’re always working closely with our customers to make sure we understand their challenges and goals, so we can deliver the location-based data and solutions they need.
For more information on Google Maps Platform, visit our website.
