The largest global ride-sharing company might have to tap into its tech repertoire to convince this south american city to let it in. In this article, I use SQL and Python to explore one possible solution.
To begin, here’s a recap of my previous article: Uber was recently denied into Guayaquil, Ecuador by our city’s (highly popular) mayor. Meanwhile, Cabify, an Uber competitor, was allowed to operate. In the article, I explored Uber’s much greater media exposure as one possible aspect of this decision, specifically in relation to how it can potentially cause unfavorable -and skewed- preconceptions about the company. (link)
Uber now finds itself in an uncomfortable position in Guayaquil, trying to find a way into the city while its competitor starts building up a user and partner-driver base, although sub-optimally and with no apparent rush (more on that in a later piece). The company is well aware of the importance of the first mover advantage, especially in emerging market, such as this one, where many (if not most) citizens are very skeptical about sharing their credit card information online (they seldom do so) and where partner-drivers might find one ride-sharing app’s learning curve to be more than enough for them. This can clearly be seen in the high bonuses ride-sharing companies pay to partner-drivers that convert from one app to another, many times having to pay as much as twice the amount for drivers who switch from competing apps than they do for drivers that are new to the industry altogether. In other words, every partner-driver that Cabify captures during this head start will potentially have to be converted later by Uber for a much higher acquisition price.
So what can Uber Ecuador do?
Surely, there are many pieces that must come together to form a market-tailored solution, but one key factor will be to leverage the company’s technical capabilities to ensure a level of transparency arguably unattainable by the competition and sufficient to put out the imminent (and usual) outrage of the taxi syndicates.
The idea I propose below could be locally applicable to the uberX model, which in many countries (such as France) is targeted to professional drivers. Meanwhile, uberPOP, the model aimed at pretty much any human person (you literally don’t even need a car or smartphone, as the company many times finances these to partner-drivers) with a normal license, will be another battle altogether. Why? Well, because the former is at least similar to the already allowed and regulated “executive taxi” model.
Note: The executive taxi model is locally used by private transportation companies to provide on-call transportation services. Some years ago, these companies had to go through a legal gauntlet to be allowed to operate, as the taxi syndicates pushed for their ban. Finally, they found middle ground when the executive taxi companies agreed to not pick up passengers on the street but to only pick up clients who called the company phone to schedule/order a ride.
Yes, Uber is not a transportation company, but a technological platform, yet its uberX drivers will most likely end up having to abide by the “executive taxi” rules, although in this case benefiting from a much more efficient model and a logistics team which will work exhaustively to model demand and tell them preemptively the best time/place to be. This increases rides, fares, and thus driver-partner income.
On the other hand, uberPOP, which is aimed at regular-license drivers, will be playing a completely different ball game. A new ball game. One that will most likely have to go through a similar gauntlet to the one that executive taxi companies had to go through back in the day until they reached middle ground.
Unlike executive taxi companies, however, Uber could actually (and easily) prove that uberX drivers do not break the law by picking up un-scheduled passengers. With inferior technology and human-error-prone processes, executive taxi companies simple would not be able to offer the same transparency guarantees. This could be one less headache for the local government and some relief to taxi syndicates who want to make sure their “spontaneous pickup” edge is not violated.
The pickup report
As a fun Sunday exercise, I decided to imagine how this report could work and what it could potentially look like.
Since I didn’t have access to an Uber dataset, yet still wanted to create something that looked and felt like one, I decided to download an actual website events table and transform it into something that could resemble a partial ride-sharing events table.
Started with…
Wrote some SQL to change it into something more rideshare-esque…
And got a (partial) mock rideshare events table…
Wrote some Python to clean up and prepare dataframe for statistical analysis…
Plotted wait_time results with Seaborn (Stanford University) “distplot” visualization…
In the histogram above, we can quickly and intuitively see that no passengers were picked up immediately, but that the minimum wait time was 19 seconds. In reality, the minimum wait time (as well as the other two) will likely be significantly higher as there would have to be either 100% (or close) accurate supply/demand forecasting or a city covered by Uber driver-partners (who knows, maybe one day). Also, this visualization would allow monitoring of forecasting efficiency as one could compare results between custom time intervals to identify trends and optimize decision-making.