Robert here, Software Engineer at Scoop. After finishing my Ph.D. in Transportation Engineering from UC Irvine, I joined Scoop to lead the development of our matching algorithm. In layman’s terms, I work on the software that helps Scoop community members form carpools every day.
During my day-to-day work, it’s not uncommon for me to chat with Scoop commuters about their carpools. One of the most common topics that come up is the “Ride or Drive” option. Does it really lead to more carpools? Should I use it? The answer to both is a strong yes. To be honest, it’s one of our secret weapons when it comes to matching — so I decided to take the analysis a step further to explore how flexibility around “Drive or Ride” affects matching metrics in the Scoop ecosystem.
In particular, we’ll look at the match rate, a measure of the number of users that are being matched out of those who request carpools. We’ll also peek at two of our other favorite metrics: average added driving distance and average added time to the original driver trip due to carpooling. These are only two of the many variables that we consider when measuring the quality of carpools. By the end of this post, we will show that a small increase in the number of “Drive or Ride” requests has a massive impact on the entire Scoop community.
For this analysis, we looked at a sample of morning requests where the origin and the destination of the trips fall inside the highlighted areas below.
Out of the total users that scheduled a trip that morning, about 1.4% did it with the “Drive or Ride” option selected. All of these users got into a Scoop carpool! Sixty-four percent of them were matched as drivers and 36% of them as passengers. This is what we will consider as the base case scenario, against which we will compare the results of the simulations and measure the percentage change of the metrics of interest.
To simulate the impact of the percentage of “Ride or Drive” on the matching process, we defined five scenarios where the “Ride or Drive” percentage was adjusted to 5, 10, 15, 20 and 25% of scheduling users.
These percentages are simulated following a simple random sampling technique, which will sample the existing scheduled trips that need to be updated to have mode “Ride or Drive.” The simple random sampling ensures that all scheduled trips have an equal chance of being selected. In other words, we do not consider any particular property of the scheduled trip when sampling. Another sampling strategy could have been to use stratified sampling, defining the subpopulations or strata based on the original mode, or matching status for example. For each scenario, we repeated the sampling process 10 times and ran Scoop’s matching algorithm using the updated set of scheduled trips. We used the same algorithmic settings as the base scenario, and we measured the new metrics of interest.
The percentage change of each metric for the base case scenario is shown in the figure below. The values shown are the average of the 10 runs. Note that all the metrics follow a rather linear relationship concerning the percentage of “Ride or Drive” mode, being the steeper the match rate. As an example, if the number of trip requests with mode “Ride or Drive” were to be 10%, instead of the current 1.4%, the match rate would have increased by 8.2%, and the average detour distance and the average detour time would have decreased by 6.5% and 4.6%, respectively. These results are encouraging, as they show that we are not only able to match more people and provide a better experience for more users, but also, form better quality carpools.
Why do we observe such an impact on match rate and carpool quality?
The simple answer is that the number of possibilities increases dramatically for every user that schedules a trip with “Ride or Drive,” adding greater flexibility to the system and therefore, leading to more and higher quality carpools.
There are two main reasons for the increase in the number of possibilities. The first is that carpools that were not possible because of two users scheduling with the same mode (e.g., both were drivers) are now possible. In the absence of modal flexibility, these two carpoolers — who may have compatible locations and commute times — cannot go together because they have the same modality. By adding more “Ride or Drive” flexibility, the system can more effectively balance the supply (drivers) and demand (passengers) of the system.
The second reason for the increase is that carpools that were previously not possible because the Rider lived farther from work than the Driver are now feasible. In the base case, a Driver who lives closer will not want to “backtrack” to pick up the Rider, and so that carpool possibility is nullified. This changes when you increase the “Ride or Drive” flexibility. The openness of users to either modality allows two carpoolers — who previously were not logistical matches — to become compatible by switching the order of operations.
Awesome, right? Optimizing a carpooling system is a classically hard problem and one that has defied conventional social logic. In the case of Scoop, we know commuters already love Scoop—but are always eager to have more reliable and consistent matches. Our analysis shows just how we can meaningfully affect the performance of our matching system if the Scoop community is willing to be flexible around their commute mode. Of course, these conclusions extend well beyond Scoop and reinforce a core carpooling thesis that a little bit of user effort can be multiplied exponentially to take cars off the road.
I hope this blog post gives you some insight into our process andAND inspires you to choose “Ride or Drive” next time you schedule a Scoop carpool.