How we nearly doubled driver reliability | Hacker News Reader

How we nearly doubled driver reliability

aarjav.summon.com

36 pointsajju16 comments

This is an interesting article, and I dig the message of measurement and iteration. One big question that is left unanswered though is why drivers reject riders in the first place. Is it with the hope of getting a better rider soon (better rating, closer departure, longer trip), because they're busy and can't take a rider at the moment, some sort of prejudice or discomfort with some visible attribute of the rider?

Presumably drivers get paid per ride, so a 50% average ride acceptance rate seems like a strange situation to be in.

Rictic: I should have addressed this in the post! Our minimum reliability rate is 50% but a vast majority of our rides are done by what we call our exclusive drivers who have a 70% (soon 80%) reliability rate requirement with additional perks. I will update the post to clarify this!

There are multiple reasons why a driver might not accept a ride but they all revolve around the fact that drivers are not our employees and they often are unable to or forget to become unavailable when they should be:

- She just took a break to have lunch (should have turned the app to unavailable but forgot)

- She is a taxi driver (we have both taxi and personal drivers on the platform) and just picked up a ride on the street and got a 2nd ride before she could turn unavailable (we measure volume in rides/second at busy times)

- She drives for other platforms as well and accepted a ride request on it before she could turn unavailable

- Each driver has 15 seconds to accept a ride before it goes to another driver. Sometimes the real world intervenes and you can't accept the ride in 15 seconds, especially if you are driving and not pulled over.

One more data points:

- I can't speak for Uber/Lyft but if you talk to their drivers you will see that their requirements are similar if not lower.

15 seconds seems a bit low considering it can take a few seconds to open the app, have you tried testing other times? I know it's a balance between getting the rider an answer quickly and giving the drivers time however you may force an available driver to miss the dispatch if it's too low.

We have! It's an interesting tradeoff between making the riders wait too long for their ride to be matched to a driver (in many cities the waiting threshold after which a rider gives up on the app is firmly in seconds) and giving the driver enough time to safely accept the ride.

I see you work for iCracked =) I am a user, and have been seeing your iCracked cars around. Really interested in how your system works in analogous aspects!

Clicked to read how to increase the reliability of device drivers. Looks like neither one is an easy task.

The only device driver I wrote was in my advanced operating systems class in grad school nearly a decade ago, but I'll say amen to that :)

I'm not sure if I fully understand how the RR is calculated. I'm assuming that when a user requests a driver, the app pings 2-4 drivers nearby. If one driver out of the 2-4 pinged accepted, all but one should have their RR lowered, lowering the average RR across all drivers.

Is there a primary potential driver who gets docked in this case or have you guys simply reduced the number of pings to potential drivers per request (i.e. go from making 4 driver requests to 2)?

I'm also confused by this. My guess is either

1) Only one driver is pinged, and they have a narrow window to accept until the offer is removed and given to a different driver.

2) Multiple drivers are pinged. If any one of them accepts, the other drivers are not penalized (but lose the opportunity for accepting this offer). If no drivers accept, all of them are penalized.

Great question. Fundamentally, everyone who is pinged but does not accept gets their reliability rate lowered.

Our new system actually decides how many drivers to send the request to based on their reliability rate. So someone with a 100% reliability rate (or close enough) will be the only person getting a particular request.

> We offered temporary monetary incentives for drivers

Ah, so paying drivers more made them more interested in accepting rides?

Initially, yes. The incentive was more because we had screwed up in explaining the system to them the first time, and we wanted them to take a second look at our improve iteration.

This article makes me almost sure that this company will not exist for much longer. Such a complicated and twisted thinking about a conceptually simple microeconomic question is not a good sign.

Why not just force drivers to accept any ride? Congratulations you now have 100% reliability.

You can force an app to inform a driver that they must pick up a client.

You cannot force a person to turn the ignition and pick up a stranger. This is a choice that has to be incentivized.

JHH: Sorry you feel that way. We can't force drivers to accept a ride because they are not our employees, because they sometimes work with both us and another app, and because the real world intervenes to make 100 percent reliability impossible. However, I should definitely have explained this better in my post. Here's what I said to another commenter below.

Our minimum reliability rate is 50% but a vast majority of our rides are done by what we call our exclusive drivers who have a 70% (soon 80%) reliability rate requirement with additional perks. I will update the post to clarify this!

- She just took a break to have lunch (should have turned the app to unavailable but forgot)

- She drives for other platforms as well and accepted a ride request on it before she could turn unavailable

- Drivers have 15 seconds to accept a ride before it "goes away". Sometimes the real world intervenes and you can't accept the ride in 15 seconds, especially if you are driving and not pulled over.

One more data points:

- I can't speak for Uber/Lyft but if you talk to their drivers you will see that their requirements are similar if not lower.