Personalizing Swiggy POP Recommendations

Abhay Shukla
Swiggy Bytes — Tech Blog
7 min readMar 3, 2020

By Abhay Shukla and Mithun T M with inputs from Jairaj Sathyanarayana

Personalizing Swiggy POP Recommendations
Source: undraw.co

Swiggy POP’s value proposition is that we want to offer a menu of curated and personalized single-serve, quick-checkout meals to our customers for when they are pressed for time. Imagine a busy professional with a 30-minute lunch break and looking for a quick but high-quality suggestion on what to eat. That’s the need POP wishes to solve.

POP differs from Swiggy’s main marketplace offering in a couple of important ways — many POP dishes are standalone meal combos designed specifically for POP. POP takes a dish-centric approach vs. the restaurant-centric approach of the rest of our marketplace.

Up until recently, POP menus were the same for all customers in a given geographic area (we call them polygons) throughout a given slot of the day (breakfast is a slot, so are lunch, dinner and evening snack-time). With hundreds of cities and tens of zones per city and several slots per day, the process of creating and keeping the menus fresh was a fairly cumbersome process requiring manual intervention and coordination.

Over the past 5–6 months, we have been working on taking out some of the above inefficiencies by building more robust tech and ML-driven optimizations. In this post, we present details about a) the multiplay, multi-armed bandit based solution that serves as the candidate-generation step, and b) dish/restaurant/customer embeddings based relevance models that do the personalized ranking.

POP Menu Creation

Under the hood, POP menu creation is achieved in 3 steps:

  1. Eligibility
  2. Serviceability
  3. Personalization

Serviceability is an engineering layer that ingests candidate list of items and filters out items that do not satisfy hyperlocal marketplace constraints (like dish out of stock, restaurant not open, etc.) in real-time. In this post, we will specifically focus on Eligibility and Personalization as they are primarily ML-driven.

Eligibility

Eligibility is the candidate generation step where we select a subset of items from the POP catalog which are marked as available for a given day and slot. This is a critical step in the process and needs to satisfy some specific requirements/constraints detailed below.

Diversity and Popularity

If the selected subset is heavily biased towards a few cuisines, there may not be enough relevant items for customers with a taste not aligned with these cuisines or customers who like to explore and discover new types of dishes. On the other hand, if there is a balanced representation of all cuisines but the selected items are not popular among customers, it will lead to poor customer experience and potentially loss of revenue. To strike a balance between diversity and popularity, the Eligibility algorithm and sourcing strategy of dishes both need to account for it.

Restaurant Choices

Along with items and cuisines, customers need to be provided with choices of restaurants as well. This is important not only for better customer experience but also to provide a fair opportunity to restaurant-partners participating in the POP program.

Cold Start for Restaurants and Items

New restaurants and items are regularly on-boarded to POP. This fresh supply needs to be exposed to relevant customers quickly to add to their experience of diversity, discovery, and choice of restaurants which in turn helps restaurants find relevant customers on the platform.

Business Rules

Temporal and strategic business rules may also be needed to be satisfied when deciding whether an item is eligible or not. This can be due to campaigns during festivals or popular sporting events or seasonal dishes offered on Swiggy.

Personalizing Swiggy POP — from data to personalized recommendations
Customer, item, restaurant and transaction data among others are passed to POP Eligibility Algorithm which generates a candidate list of items picked from each restaurant. These items constitute the eligible list. In real-time items that meet hyperlocal constraints are picked and L2R ranking algorithms create the personalized menu on POP.

Considering the requirements discussed above, several candidate approaches were evaluated which broadly fell under three themes:

  1. Propensity modelling of items
  2. Linear/nonlinear optimization
  3. Multi-Armed Bandits

We zeroed in on Multi-Armed Bandit as a choice for Eligibility, meeting most of the requirements while providing a flexible framework to satisfactorily address others. However, for POP, we should note that,

  1. One or more items can be picked from the same restaurant, therefore the framework which suits this problem is a multiplay multi-armed bandit
  2. An arm can be pulled at most once since arms represent dishes and pulling the same arm again will lead to duplication in the menu
  3. Dish discovery is an inherent feature of POP offering and therefore the exploration should be perpetual

As a result, the setting of MAB for POP is as follows.

Swiggy POP — MAB Settings

Following the notation defined above, the pseudo-code of POP MAB is described below.

Swiggy POP MAB Algorithm

The output of the Eligibility algorithm is a candidate list of items that are eligible for personalized item recommendations on POP. This list serves as the input to the Serviceability step which picks a subset of items that are currently-serviceable when the customer launches the app.

Personalization

In POP the ranking algorithm trims down the eligible and serviceable list of 60–80 items to 30–40 most relevant to the customer.

Features

Features from customers, restaurants, items and their interactions are key in making recommendations useful. In our models, along with derived features, these entities themselves are represented directly. We use Word2Vec to learn embeddings for categorical entities. Items’ embeddings learned from our transactional data can be visualized in Figure 1 below. Items belonging to the same cuisines, e.g. Pasta and Risotto show more similarities than items from different cuisines, e.g. Dosa and Chicken Biryani.

Visualizing Embeddings
Figure 1: A visual representation of dish embeddings shows the similarity between dishes of the same cuisine and differences with others. E.g. Risotto and Pasta have many matching attributes while Risotto and Dosa do not. These embeddings help in representing the food profiles of customers and restaurants.

All iterations of the Personalization models are built using these rich and dense features. The evolution of these models is briefly described below.

Baseline

The baseline for our recommendation model was ranking simply based on the sales of an item on POP. Higher the sales of an item, higher its position in the menu. As a result, all customers in a geographic area are served with the same menu.

Cosine Similarity-Based

Next up was a utility-function type approach in which the relevance of an item to a customer is simply a function of the cosine similarity between their respective embeddings. The similarity is weighted by the popularity of the item. Mathematically,

Cosine Similarity-Based Model

With this model, the conversion rate improved by 1.3% compared to baseline.

While this utility-function is easy to interpret and quick to train, it has limitations in capturing nuanced choices made by customers. For example, a customer may have a different preference for the same item during breakfast and dinner. Accounting for such behavioural preferences will entail enumerating all such possibilities and formulating them into the utility function which is neither scalable nor makes sense.

Learning to Rank

Learning to Rank (L2R) methods are popular for contextualized recommendation settings such as ours and have been successfully implemented in large-scale recommender systems. There are three major types of L2R methods namely, pointwise, pairwise and listwise. In POP we use the pointwise version implemented using Gradient Boosted Trees in Spark ML.

This model further improved the conversion rate by over 14.3% compared to the cosine similarity based model.

Results

As shown in Figure 2, when Eligibility and Personalization went live pan India, we observed an average increase of 16.6% in orders on POP.

Swiggy POP — Order Trends
Figure 2: Orders from POP plotted against time shows a 16.6% jump in orders after MAB Eligibility and L2R Personalization both went live across all cities serving POP.

Future Directions

As discussed, we observed significant gains in conversions on POP by implementing MAB based Eligibility and L2R methods for Personalization. But along with the objectives of relevance and diversity, customer experience is impacted by many other factors such as delivery time, recent ratings of restaurants and items, etc.

Common industry practice is to post-process the ranking scores to meet these objectives. However, this often involves human judgment which may be hard to justify and validate. We are working towards addressing personalization as a multi-objective optimization problem that jointly solves for important factors that impact a customer’s experience on POP.

User-research has also shown that certain customer segments prefer more diverse options on weekends vs. weekdays. Exploration strategy on MAB can be modified to adapt to such customer expectations and improve their discovery and ordering experience.

Sign up to discover human stories that deepen your understanding of the world.

Published in Swiggy Bytes — Tech Blog

Stories on how technology enables Swiggy to provide unparalleled convenience to consumers

No responses yet

What are your thoughts?