Smart Photos

Mike Hall

By Mike Hall, Machine Learning Lead

It’s amazing how quickly an idea can go from a thought to a fully realized product. Last January, Tinder announced its first internal hackathon. Anyone in the company could pitch their idea, gather a team, build it, and the winning idea would get on the product roadmap. Ideas started popping up from all over the company. I knew instantly what I wanted to pitch.

I wanted to help Tinder users who were struggling, the ones who weren’t reaching their best potential on Tinder. I had a decision to make: go for the win with the most visible new features in the app, or go for the idea I thought could make a difference, and quietly help our users.

I chose the latter.

The Problem

All Tinder users have seen it: that one profile you come across with a pic that doesn’t quite do it for you. You tap into the profile, and you’re greeted with a fantastic photo that you would have insta-swiped-right on. If only you had seen it first. You ask yourself, “Why did they choose that as their first photo?” or even worse, “What if I’ve chosen the wrong first pic on my own profile?”

People can be very bad at choosing their own profile photos. Our resident sociologist at Tinder, Dr. Jess Carbino, has looked into this very problem and come up with several reasons for why a photo in which you look good may actually be the wrong choice. In fact, people tend to swipe left more frequently if you are:

  • Not smiling
  • Covering your face, even a small portion
  • In a group of people
  • Wearing a hat
  • Wearing any kind of glasses

This made me question my own ability to choose correctly. I wanted to help, and apparently, I wasn’t alone. The pitch session went wonderfully and my team was one of the first to be filled. I had Drew, product manager, Mike, backend engineer and Cormac from data science team. The four of us went to hunt down someone from mobile (they can be elusive when you need them), and within minutes we had our missing link, Robera, our iOS engineer.

The Solution

After a bit of research into projects that did not fit into the one-week time frame of the hackathon, I landed on the age-old process of A/B testing. We could set up an experiment, showing a different photo each time a user’s profile was viewed, giving us a good idea which photo will get swiped right on the most frequently.

Multi-armed Bandit

I framed the problem as a multi-armed bandit optimization problem. This is a thought experiment dating back to the 1950s wherein you are given a bank of several slot machines, each with a cost to play and a different return rate. But, you don’t know the return rate on each one. How do you maximize your return by discovering the machine with the best return without wasting a lot of money on the other substandard machines?

It seems to fit our problem perfectly. Let’s discover which profile photo results in the most right swipes, without wasting views on the low performing ones.

Epsilon Greedy

After reading some excellent blog posts by yhat and others, it seemed like epsilon greedy would be the best and quickest algorithm to implement. The main component of epsilon greedy is the decision between explore mode, in which we test photos to see which is best, and exploit mode, where we show the best performing photo. For this solution, we define performance to be the swipe-right-rate (SRR) on a photo, or:

This decision is determined by a value, epsilon ε, ranging from 0.0 to 1.0. It specifies the rate at which we choose explore over exploit, testing your alternate photos, 0.0 meaning no exploration, and 1.0 meaning pure exploration. If explore is chosen, we then choose among all possible photos in your profile. Over time, as a winner emerges, we allow epsilon to decay so that we spend more and more time on the best photo, and less on the rest.

Altered from http://blog.yhat.com/posts/the-beer-bandit.html

We made two alterations to this classic algorithm to better fit the Tinder space.

Epsilon Decay Function

The standard way to decay epsilon is based on the number of impressions across all photos. This means simply that the more swipes you have on the photos, the less time you spend in explore mode, and the more right swipes we will get you while exploiting your best photo. The decay function looks something like this (thanks again, yhat!):

Recreated from http://blog.yhat.com/posts/the-beer-bandit.html

We wanted to see if we could reach an answer a little sooner than that, so we decided to focus more on the difference between the first and second photo. If a large gap occurred early between photo 1 and 2, we want to spend more time exploiting the first photo. However, if first and second place are neck-and-neck, we wanted to explore as much as possible to more aggressively discover their performance.

We keep the element of time, represented by total swipes on the user, but we also add in the gap in the performance of the first and second place photos, in the form of the square difference between their SRRs. This yields the following preferred decay for varying gaps in SRR:

Explore Mode Photo Selection

One other minor tweak we made to the algorithm was to the rate by which we select each photo in explore mode. The reason for this was that our users tend to add and remove photos on a somewhat regular basis. When a new photo is added, if epsilon is very low, we won’t test out the new photo at a very quick rate. Thus, if we have any swipes at all, we take the complement of the proportion of swipes that have gone to that photo.

We then use these rates to determine how frequently each photo should be selected in explore mode, yielding a bigger proportion of views to those that are lacking.

Takeaways

The only changes to our existing backend were forwarding the swipes into the Kinesis log and an endpoint to post the new photo orders to. Beyond that, we had the queue, processing, and storage up on day one of the hackathon, the algo and backend changes mostly complete by day three, and two whole days to work on our presentation.

We were off to a solid start with just a little tweaking and tuning. Now, we are able to leverage Tinder’s massive volume of swipes in order to get very good results in a relatively small amount of time, and we are convinced that Smart Photos will give our users a significant upswing in the number of right swipes they are receiving with more complex and fine-tuned algorithms as we move forward.

The Final Verdict

Tinder made sure we had all the resources we needed: hackathon contenders received sleeping masks and first dibs on all of the couches, although we planned well enough not to need a sleepover. And while we didn’t end up winning the hackathon, the experience was certainly empowering—our idea became the first to get into the product roadmap. We tried to put ourselves in the user’s shoes, identifying and solving a real-world problem through technology and innovation. With Smart Photos, the users get their best outcome, while for us, as engineers, an effective solution is its own reward. Everybody wins.

Now, as we look to the future, we will work hard to improve our algorithm and continue to focus on retention as well as growth. The most important thing I learned from creating the Smart Photos algorithm was that when all is said and done, we never really know what will get the best response from others until we put it to the test. And once we do, a clear winner emerges. So keep swiping!