AI Suits Up for Sport Beach

Sport Beach is Stagwell’s flagship event of the summer at Cannes Lions, featuring panels, events and speakers at the intersection of sports, technology and culture. After a successful 2023 inaugural event, Stagwell wanted to make an even bigger splash in 2024, from the pre-event marketing to giving visitors a unique experience at the beach itself.

Code and Theory’s machine learning team was tasked with building the Sport Beach app from scratch, highlighted by an AI-powered personalised guide that anticipated which events the user would enjoy. The catch: At kick-off, no users had signed up (Sport Beach hadn’t started), there was no historical data on event attendance and no events had been finalised (and they wouldn’t be finalised until shortly before Sport Beach began). So, we set out to build a machine learning-powered recommendation engine without data.

We needed to build an engine that matched users to events (i.e., “Based on your interests in rock climbing, you might like this event with Alex Honnold”) and events to events (i.e., “Because you attended this event with Shaun White, you may enjoy this event with American World Cup skier Mikaela Shiffrin”). This was especially challenging given that no users could register until Sport Beach began, and the events were being finalised right down to the wire.

Our solution? Fall back on the oldest item in the data scientist’s toolkit: simulations. Here’s how we did it in just three sprints.

SPRINT 1: Constraining the Problem

Before building solutions, constrain the problem.

We spent our first sprint working closely with the product management team to figure out exactly what feature space we could deal with. Looking at last year’s event descriptions and whatever information we had on hand for this year’s programming, we decided on — and cemented in place — feature tags that could describe both user interests and event descriptions (e.g., “sports clinics,” “one-on-ones” or “food and drink”). It needed to be a sparse feature space. We weren’t going to have many opportunities to accumulate signals, so we had to ensure that each feature was as descriptive as possible with as little overlap as possible, allowing us to be ultra-flexible in our modelling approach.

SPRINT 2: Simulating User Behavior for Precision Matching

Now that the feature set was locked in, we could hit the ground running. We developed recommendation algorithms in tandem with simulated user and event data.

We simulated user personas with increasing fidelity, which allowed us to understand the optimal engine architecture. We started by creating simple validation sets, using the scenario of one user per tag. As modelling progressed, we ramped up the complexity, adding a random second tag to each user, injecting white noise and developing more nuanced user personas. For instance, we considered what tags a tech CEO might select, integrating realistic (but also diverse) interests for such a persona. Finally, we injected noise into these personas, adding or subtracting one or two tags.

Events were much easier since we knew our product team would be tagging those as they were confirmed. We made sure that there was at least one simulated event per tag and always one that uniquely matched a test user — in validation, that one should always be recommended first.

We evaluated the average and standard deviation of top-N similarity scores between user tags and event tags for each validation set across different ML modelling approaches. We tried different clustering approaches, similarity matching algorithms and collaborative filtering and cross-validated against different parameter combinations for each. In the end, a version of cosine similarity matching proved to be the best option — something that, after all the above, we could claim with some confidence!

SPRINT 3: Building on Oracle Cloud Infrastructure

With our model in place, everything came down to plumbing. We had to configure a database to hold the events in an easily consumable format for the ML model. The database needed to be able to communicate with the model deployment, for which we chose to use serverless functions. This allowed us to quickly and horizontally scale our computing power. We took full advantage of Code and Theory’s partnership with Oracle, building a 100% Oracle Cloud Infrastructure (OCI) architecture. Below is a rough diagram of the system.

OCI Architecture Diagram

Launching the App

Three sprints later, our endpoint was in production, and the Sport Beach app was live on the App and Play Stores! Real user data started pouring in (the app briefly ranked as one of the most installed in iOS’s “Sports” category). The OCI Function could scale horizontally to accommodate spikes and troughs in user requests. This architecture provided tens of thousands of recommendations with an average latency of 100ms. Across the board, the event’s impact was exceptional:

• 89% user-registration completion rate (+50% over the industry average).
• 30M impressions from press in People Magazine, Ad Age, Adweek, Digiday, Page Six and more.
• The app and website were designed, engineered and launched in under five months.

Best of all, we built the Sport Beach app to be flexible and scale not only for Sport Beach 2025 (already on our radar) but any future events Stagwell spins off.

If this sounds complicated, that’s because it is! However, making the complex as simple and easy to navigate as possible is critical with any AI-driven project. Looking to discuss this project or another one in more depth? Get in touch.