Hacker News new | ask | show | jobs
by tossaway842 2130 days ago
What matters is the aggregate amount over multiple trips. If you underpay on some trips and overpay on others and it is a net wash, then it doesn't really matter for the couriers if the payment algorithm is on the low side on some trips so long as it is on the high side on other trips.

Under or overpaying on trips is more of an interest to those engineers trying to optimize marketplace efficiency. Meal delivery businesses have as much of an interest in not underpaying as doing so reduces supply availability and therefore reliability and they have also an interest in not overpaying as that reduces profitability. The ultimate goal is optimal pricing in a three sided market to maximize liquidity as the business model does best when you optimize for volume of transactions. Maximizing liquidity amortizes fixed costs over more transactions. This applies as much to the meal delivery companies as to the restaurants involved.

At the end of the day, distance driven is very imperfect as you have issues like poor GPS signal and in cities you have the dilemma of urban canyons and tunnels. Also, drivers don't always take the suggested route. At vehicle speeds, it's hard problem to solve due to time between GPS pings. Another issue besides GPS inaccuracy is clock inaccuracy, especially with round-trip times between server and client and client and server aren't always symmetrical, especially on cellular networks, and this messes up all sorts of clock synchronization strategies. The peanut gallery on HN is seriously underestimating the complexity of measuring distance using GPS. It's pretty darn good when conditions are ideal, but when they aren't, good luck.

Another question is the magnitude of the underpayment in the 21% of trips. Are we talking about 1-2%, 5-10%, some other deviation? If it was something like 1-2%, we should all be amazed. Gage repeatability and reproducibility matters.

4 comments

I strongly suspect that, to a driver, it makes a huge difference that you can't rely on the app to accurately tell you what your take will be, even if you can validate that after 1000 rides, it's all a wash. And even if you don't care about drivers, that introduces a marketplace inefficiency if they don't expect $1 promised compensation to result in $1 actual compensation.
Exactly. Besides making the marketplace inefficient, underpaying participants in the marketplace and leaving them disappointed also creates churn. You want, as much possible, for marketplace participants in the system to experience a strong link between effort and reward.
If they are running a business, especially something at scale, and they are properly funded - they should be 'paying the right amount', there's really no excuses.

If they can snare people into driving for them, there are material switching costs for workers, and 'underpaying' on some level is actually something they can get away with.

At the 'low end of labour' workers generally have zero power, much less during covid, so it's not a 'marketplace' in the more broad sense. If it was, we wouldn't even need minimum wage laws, or Medicare for employed people etc..

If the technical challenge is 'insurmountable' then they need to figure something out: minimum guarnatees etc. , even over the aggregate, as you say.

Yeah, and also if Uber was doing this intentionally, they could’ve just as well lowered their $/mile rate if that’s what maximizes profit.
Lowering the "front page" $/mile rate could make the service immediately less attractive to workers, who can select between multiple services based on the apps on their phone. Lowering mileage paid is much harder for workers to detect, since it requires carefully checking each trip and measuring what's actually paid.

This could also be an "unintentional-intentional" bug, meaning its presence was just an accident -- but that the company has chosen to prioritize its engineering resources addressing issues that improve its revenue, rather than decreasing it.

In a business that is trying to optimize a marketplace, accurate measurability of everything matters as the performance of every marketplace optimization is degraded by having poor gage repeatability and reproducibility in its measurements. It's like trying to play darts when you're nearsighted and have 20/400 vision. This is process engineering 101 stuff.

There's way more money to be made in having accurate measurements than having inaccurate measurements that optimization engineers can't rely on. The more accurate the measurements, the more confidence you have that your marketplace optimization algorithms are producing the desired marketplace dynamics.

1. I tend to doubt they did it intentionally.

2. I could see a company with various ethical lapses like Uber not prioritizing an unintentional bug for a speedy fix.

3. In the intentional scenario, it'd be a case of https://en.wikipedia.org/wiki/Salami_slicing (popularized by Superman 3 / Office Space). Easier to get away with than a public rate cut, with the downside of bad PR if you get caught.

It's probably a bug that no one will fix or talk about fixing because it makes the company money. Standard large company stuff. You don't get promoted for costing the company money.
Click through businessinsider to the sourced salon article, where they directly interview the driver. His initial case was a 75% underpayment, when he was paid for 1 mile on a 4-mile trip.

The interview seems to indicate it's an aggregate underpayment across all trips. The tool is available for examination if you are truly skeptical.

edit: also, you seem to have made your account just to comment on this thread. what's up?

I'm more interested in the data than the tool. What was the start and end point for the trip and other details.

For example, this makes no sense:

"I had this one delivery that was an hour-and-a-half long and I got paid $16 and I thought, 'There is no way that's right,'" Armin Samii, an unemployed computer scientist who has been working Uber Eats on the side, told Salon. "I looked into it and found out that Uber paid me for a one mile delivery instead of a four mile delivery. Of course it's all made worse because I'm on a bike and they don't account for that, but that's a separate issue."

A 11 mile hill climb of Mount Hamilton with 2700 of elevation gain takes me about 1.5 to 2 hours to do. A straight hill climb which you would only find in cities like Hong Kong or Rio de Janeiro is like the worst case scenario. A 4 mile trip in pretty much any major city should be maybe 20-25 minutes with stop signs and traffic lights. Not saying there wasn't an issue with that trip, but this makes no sense.

I have worked a lot with this stuff in my career, so I'm inclined to want to see the data myself so I can try and reverse engineer what may have happened.

Furthermore Armin Samii appears to have worked for a direct competitor of the company he's criticizing while developing this.