While matchmaking is a core lever of any marketplace business, data crunched by Uber, Airbnb, and other marketplaces shows that engineering an optimal marketplace sometimes defies common sense.
For example. You finish dinner and are ready to head home. You see plenty of Uber drivers, but you’re matched with a car 10 minutes away. It makes no sense!
Greedy and Network-Optimized Matching
In our Uber example above, the intuitive approach is to match each rider with the closest car, on a first-come, first-served basis. However, while such transaction-level optimization leads to the shortest possible time for customers in high-trafficked areas, it can also lead to a terrible experience for other customers and suboptimal aggregate wait times.
A better long-term solution, that takes into account the needs of the entire user base, is to predict imminent demand, and optimize matchmaking for a network-level variable such as aggregate wait time. This is exactly what Uber does, in a feature called batched matching.
Let’s consider the example below:
The figure on the left illustrates greedy matching, the intuitive expectation of most riders that find themselves in our scenario. This approach leads to the minimal wait time of just one minute for rider A, but makes rider B wait six minutes, for an aggregate wait time of seven minutes.
The figure on the right illustrates network-optimized matching, which is closer to how most ride-hailing apps assign riders to their pool of drivers. This approach leads to a longer, but still reasonable wait time of three minutes for rider A, and a short wait time of just two minutes for rider B, for an aggregate wait time of five minutes, a 33% improvement over greedy matching.
And since 2017, if a better match becomes available after you book a ride, Uber will automatically swap your trip — a feature internally branded as Trip Swap. This may be a nuisance to drivers when it first happens to them, but over the lifetime of their driving will earn them more money.
Fungibility and its Impact on Matchmaking
In a fungible marketplace, supply is interchangeable. Ignoring premium options, one Uber driver is broadly equivalent to another. Similarly, most customers will care little whether their Instacart carrot delivery comes from Aldi or Costco.
In a non-fungible marketplace, each supplier provides unique value. Airbnb hosts offer a very different experience from one another. Similarly, on the home-cooked food marketplace I’m currently launching, Pona, where we have home chefs who provide specialist dishes that are not available from other sellers on the platform. In reality, fungibility is not black and white, and whether a supplier is interchangeable with another can depend hugely on market expectations. Many businesses operate between these two extremes (think tradespeople on TaskRabbit, or business formation lawyers on LegalZoom).
Recognizing where your marketplace startup falls on the fungibility spectrum is crucial. It has major implications on how you approach matching, pricing, and other core aspects of your marketplace business.
The Airbnb recommendation engine is a good illustration of how optimal matching changes with fungible supply.
Most – especially high-value – customers won’t browse through pages of listings if the initial results fail to inspire confidence in the platform. It is, therefore, a priority for Airbnb to optimize the first five to 10 listings in your search results.
The greedy approach to ordering Airbnb listings would be to show properties that will result in an immediate booking by the user. Under this scenario, all customers would see broadly similar results with an exceptional cost-benefit ratio, and book them on a first-come, first-served basis.
Of course, there’s a better solution. Just as with our Uber example, Airbnb should, and most probably does, optimize search results for network-level variables (Airbnb’s website only says that there are “more than 50 factors that contribute to each set of search results”).
In the example above, if a property rental website optimizes at a transaction level, the first customer to make a booking can end up with a better property than they expected. That’s all good and well, but it may mean that a more picky customer making a booking just minutes later is left with no acceptable options.
If the website optimizes at a network level, on the other hand, the search algorithm could nudge the first user to book a different property that’s equally satisfactory for them and keep the exceptional option available for the picky customer who makes a booking about the same time.
Rather than “will the user make a booking?”, the Airbnb product team might ask something closer to “will showing these five properties lead to the highest aggregate number of bookings in this city?”. They might even optimize for aggregate Lifetime Value (LTV), taking into account that some customers are less price-sensitive than others.
The Impact of Bias
Why don’t companies such as Uber and Airbnb prioritize best-behaved, repeat customers in their matching? Wouldn’t it be a good idea for Uber to reward its best customers with faster service? Or for Airbnb to highlight Superhosts above all other results? Just as with greedy matching, bias in matchmaking can lead to suboptimal outcomes at a network level.
This is what we found out at Pona. Most of our cooks specialize in regional, international, and experimental cuisine that is not sold in restaurants, which makes our supply less fungible than for other delivery apps. For example, we only have one Ethiopian home cook in our service area, and she is also one of our top-rated and best-selling chefs. She can only cook a limited number of dishes per day, and always sells out.
On the demand side, the greedy, unbiased approach would be to display her profile to all customers, ordering search results either randomly, or based on distance. A better, network-optimized algorithm might nudge buyers to try food from a different chef each day, or take into account how picky each customer is about their food choices.
In either case, there is a strong temptation to introduce bias into the search results. For example, we could show our top chefs to high-value customers first, as a reward for their loyalty.
Bias can also creep in as a side-effect of a seemingly unrelated feature. For example, some of our customers have asked for a way to follow their favorite chefs, so they can see them at the top of their search results. But what seems like an obvious, and rather benign little feature has the potential to wreak havoc at the network level.
Just imagine if a dozen customers “favorite” our Ethiopian chef. If we had surplus demand, as in the illustration above, our Ethiopian chef and other top sellers would make all the sales. This would prompt new entrants to leave and in turn, reduce the variety of food available on the platform. If we had surplus demand, new Pona users would never get to see our Ethiopian chef, or taste her cuisine, and would be banished to new and less exceptional sellers.
An unbiased approach allows us to ensure sales are more evenly distributed across all our chefs. If you’ve ever wished that Airbnb allowed filtering based on user reviews, now you have a better idea as to why the feature is unlikely to be introduced any time soon.
To further complicate matters, Pona orders are made at least 24 hours in advance, and our sellers have no overhead costs such as rent or staff. Our chefs say they would prefer to cook one large batch of soup, sell it all on a single day, and enjoy their free time for the rest of the week, rather than sell one portion every day of the week (even if it meant fewer sales overall).
In a surplus supply scenario illustrated above, the ideal matching algorithm would cluster sales on a different day for each cook, which would be impossible if search results were biased by favorites, or a ratings-based ordering.
I know all this can be overwhelming, and as a startup with limited resources you can’t have a team of data scientists optimizing your every match. Fortunately, top academics and product teams at Uber, Airbnb and the like have done a lot of the work for you.
Although each marketplace is different, and you will want to run your own simulations and A/B tests down the line, it’s worth keeping the considerations above in mind as you build your product. Developing a matching algorithm? Think about whether distance is the best variable to base it on. Launching a new feature? Consider how it might inadvertently bias your search results. And as you grow, make sure to dedicate ample resources to these questions.
This article was in part inspired by a talk by Uber product manager Tanvi Surti
