Uber has been disruptive in many ways. One way, which has been a great disappointment, is the effect on public transit systems. It was once hoped that ride hailing would provide an assist to public transit, as a gateway to abandoning car ownership. There have also been hopes that suburban commuters would use ride-hailing as their connection to public-transit which is not accessible by walking in these areas. Multiple studies have confirmed these hopes have largely not materialized, and public-transit has been weakened.
Cities have reacted, mostly by putting barriers to ride-hailing growth. Sometimes they are collecting extra fees, sometimes placing new requirements. But mostly these efforts don't do much to change the relationship between ride-hailing and public-transit.
I work with a local group that spends time thinking about automated car policy, how to get the most good and the least bad. We've discussed a proposal that fits ride-hailing, in the here and now, just as well. If you want public-transit and ride-hailing to integrate, the place to start is the apps users use. If you open the Uber app, you see Uber vehicles, not public-transit. If you actually want to riders to use ride-hailing as a connection, it needs to be easier to discover and plan out the connection. As it is today, in most places you need two apps, and fair bit of swapping back and forth and a good understanding of each system.
The regulation that is most urgently needed in regards to ride-hailing is a requirement that ride-hailing services integrate public transit data into their apps. They are unlikely to do this without a prod, because they work to build loyal users, and have very little incentive to tell those users about other options that drive business away from their core. But from a city perspective, it is absolutely what we want. Even from a user perspective.
It's quite doable. There are a few niche examples of it in practice. LA had an app (though now discontinued). BART has it in their app. But these efforts by cities to add ride-hailing to their own apps will never quite accomplish the goal. While they are providing the information necessary, they are doing it to loyal transit users, which misses the group most in need of connecting to. Lyft has done some of this, driven by their investments in bikeshares and scooters.
Cities should further this approach, shaping the providers apps as a requirement of operating in the city. Cities with major public transit infrastructure, should pass ordinances requiring providers to utilize their publically available transit data to display alternatives to the providers service within 6 months. If they fail to, remedies could be either revoking their license or requiring large daily penalties that are used to fund the public transit system until they are compliant.
A few things about how these integrations should be designed, which would be useful to regulators ensuring the providers comply with the intent of these ordinances:
- Integrations should forecast, time of arrival, time of departure, total cost for each alternative.
- Integrations should provide ride-hailing, public transit, walking, biking options. Moreover, they should provide options combining these options. Provide an option substituting a ride-hail or bike ride to reach the public transit stop instead of walking.
- Google Maps today assumes if you're using public transit that you're walking to the stop. This creates some ridiculous time estimates for public transit in suburban areas. For example: 1 hour to walk 3 miles.. then board the train for a 20 minute journey, total time 1h20m. This estimate would be better displayed as: pay $5 for a 10 minute trip (5 for pickup, 5 for travel) to the train for a total time of 30 minutes and cost of $7.50. Users would then be able to compare that against a 30 minute drive into the urban center with a cost of $30. If I have a need to arrive quickly, I'd pay $27.50 to save 50 minutes. But I'd never pay $22.50 for no time advantage.
- Integrations default view should provide all options in a single view. Initial default sort should be based on cost. Users can switch this to time. Apps can provide a user configurable time/cost tradeoff metric to rank options, i.e. $20/hour. But absolutely, the initial sort should be based on cost. Cost is the metric most likely to favor public transit. Ride hailing providers might be incented to make that information hard to access as a result. It's easier to make this default sort requirement than to police every other way they could make it hard to access cost data. Apps can provide other views, but the default view for a new user must be, all options, ranked by cost.
- Apps should let users indicate they have monthly passes for transit, reducing marginal transit costs to $0.
- Ride-hailing options should include the pickup time in estimated trip time. Apps today do not include any estimate of pickup time in early estimates. If you're comparing a bus ride and a ride-hail in Google Maps, the bus estimate includes the time you'll wait for the bus to arrive. But the ride hail option assumes you'll start immediately.
- Driving options should include parking time/walk estimates in estimated trip time. If you live in a Suburb with giant parking lots everywhere, yes, the drive time is an accurate estimate. But if you live in an urban area where transit is an option, a drive time estimate that simply estimates travel time is generally inaccurate. I'm going to bet that Google has already collected enough information on average time to park to provide useful information here. I've been persuaded more than once to drive somewhere instead of taking transit "because it's faster", only to end up arriving later once parking was handled.
- While at it, track where your car is. Do you have to walk 3 minutes to a parking spot first? Is it in a valet only garage? These urban concerns may seem foreign to those outside a urban environment, but this is a post about public transit.
Inspired by reading British Columbia Gives Uber a Cautious Go Ahead...