Personalizing your TicketSwap experience
How we built a recommendation system to make sure our fans don’t miss the events they want to attend.
TicketSwap is used by millions of users around the world to find tickets for the concerts, the shows and the other events they wish to attend. Some fans are festival-goers, they do not want to miss a single edition from the festivals they love! Some fans prefer particular Jazz, Pop or Metal concerts. Some fans are there for inspiration, to discover new events they did not know they might like in the first place. You want a service that suits you.
It’s only natural that we would want our website and mobile apps to be personalized to cater to the different users according to their tastes and needs. While an off-the-shelf recommendation engine might have been effortless, you will see why we went for a bespoke solution.
Why didn’t we use an off-the-shelf recommendation system?
Spotify has a great recommendation engine. We take lots of inspiration from them, but there are some key differences. When you listen to an artist on Spotify, it doesn’t matter where you are at this moment in time. At TicketSwap, on the other hand, you are going to travel to attend a concert, and it is not very helpful if we recommend you an event on the other side of the globe — in fact, it makes the customer experience worse!
You can also base your decision on whether there are available tickets, and if any of your friends is going to attend the same concert. More than that, you probably listen to dozens of songs everyday, but you don’t buy as many tickets on TicketSwap each year. Thus, our recommendation has to capture your taste with a minimum amount of data.
Similarly, a recommendation engine built for an e-commerce website is built around the concepts of items; customers who bought these socks are also interested in this scarf. They do not have the notion of artists, venues, and event start times.
And finally, a user will likely forgive a weak music recommendation on a streaming service, if they can just skip to the next song on Spotify or to the next video on YouTube. But when they have to pay to get a ticket for an event, they may not have the same tolerance.
With all of this considered, we knew that we have to build our own recommendation system in house so that we could tailor it — and scale it — according to our needs.
Artists and organizers are the cornerstone of our recommendation system
We surveyed our fans, asking them about the main factors they base their event going decisions on. The organizers of the events, and the artist who is playing there, were their top priorities.
Technically, we also had to decide what to base our recommendations on. We had a wide range of choices here: On one end of the spectrum, we have the broad music genres; users who went to pop concerts will like all other pop concerts. Obviously, genres are very broad, and some of the bigger genres like pop or electronic music don’t mean much. On the other end of the spectrum, we have millions of events on our system, and basing our recommendation engine on specific events will not scale.
We needed a middle ground, and the response of our fans was music to the ears of our data team.
Solutions are as much organizational as they are technical
Before jumping to our technical implementation, that I’d explain in the next section, we had to do some groundwork first. We did not have enough artists in our database, and the ones we have were rarely listed in the events they play in. That’s why we needed the different teams in our organization to come together and solve the missing bits of our puzzle.
We looked for sources to enrich our content by adding the missing artists to our database. Then, we built a script to deduce the names of the bands and artists from the events they are playing in. We also used our internal models that predict the future demand for each event, to help our content team focus on the relevant events.
We wanted to bootstrap our data and quickly proof the value the recommendation system offers to our fans. And once we had a proven solution, we now have a better system in place with more accurate data.
Our neural embedding approach
Meanwhile, our machine learning team decided to go for a neural embedding approach for our recommendation system. If the term sounds a little cryptic to you, here is an explanation in a nutshell;
Computers are better at dealing with numbers, so computer scientists come up with ways to represent words in terms of numbers. It is important for these representations to also reflect the meaning of the words they represent. The numbers representing the words tree, plant, grass and bush should be closer to each other than they are to words like burger, fries and ice cream. To achieve this, models based on neural networks are used to come up with those new representations, better known as embeddings.
We used a similar system to represent the artists and organizers in our database. In our system, similar artists are represented by numbers close to each other. These numerical representations allow us to do mathematical operations on them. If you add the representations of two artists, say Ariana Grande and Shawn Mendes, you will get a new representation of a hypothetical artist that is liked by the fans of the two artists.
We implemented our neural embedding system using a Python library called Gensim. I wouldn’t get deeper into the implementation details here, but you can leave a comment if you have any further questions about our implementation.
For an event, we use the embeddings for its organizers and all the artists playing there to represent it. Similarly, a user’s taste is inferred from the events they have attended in the past. This way, we can recommend events to users, and also show similar artists and similar events on our artist and event pages respectively.
The success of the first iterations of our model, encouraged us to continue improving it. For example, we know that the geographical distances are not the only decisive factor for when our fans decide to travel. A resident of a smaller city is more likely to attend events in the bigger cities nearby than it is the other way around. Therefore, we had to build a way to measure the tendency of the fans in one city to travel to another city. This additional model was used to augment the decisions made by our recommendation system.
Of course, a recommendation system has no value if its results aren’t available to the users! The work of our designers and developers is what brought it to life by having it implemented and shown on the right parts of our platform.
Some final remarks before you try this at home!
Build a proof of concept early on: As we camp up with a plan for how to implement our recommendation system, we knew that our data was not ready yet. We needed to add more artists to our database and connect them to as many events as possible. Nevertheless, we could not wait fort months to decide whether our approach will work or not. Thus, we decided to build our system for the data we had then. We wanted to make sure it works with our limited data, while keeping in mind that it is going to improve when more data is added to our system. This brings us to the next point, how to test if your proof of concept works?
Be ready with you test criteria early on: We created a small test set where we manually put similar artists together. We used it to test our model while it is being developed. It also helped us fine tune the parameters of the Word2Vec model early on.
The proof of the pudding is in the eating: It is not enough that our model scores well on our toy dataset. It is essential that it actually meets our customer’s needs. That’s why we kept track of the page views and clicks. We wanted to measure how better is this model than our current status-quo. For the event pages, we used to show other popular events at the bottom of the page. Before replacing that with our recommended events, we had to make sure our new model improves the click-through rate as a proxy to how useful our recommendations are to our users. Our conversion rate was doubled with the new recommendations, by the way.
Be ready to iterate: The model works well for our existing users, but it knows nothing about our new users. Keep in mind that may purchase their tickets elsewhere away from our platform. To capture their taste early on, our product team introduce the ability for users to follow the artists they like, and event organizers they care about. This data helped us improve the model once the new feature was implemented a year ago.
Understanding the problem is half the solution. We wanted to give our users the best recommendations with a minimal amount of interaction data. We also knew that the quality of our model is dependent on the quality of the data we have. Thus, we have to bring multiple teams together to work on a long-term solution where we can build a system to understand our users and our content better. The joint effort resulted in a system used in different parts of our platform. We are proud of what we have built so far, and we are happy to hear your feedback to keep improving it.