Search at Zomato

Restaurant search and discovery form the core of Zomato’s platform. Our hyperlocal delivery is built on a customer’s convenience to navigate Search easily. We understand how important this function is and how it affects the customer experience in many ways. 

As a product team, our mission is to make that experience perfect. With every feature we launch, we aim to make our search results more relevant and accurate while ensuring it takes less time to discover a dish, restaurant, or cuisine. 

Search is a system with infinite inputs – we power millions of search queries daily. With great numbers, comes great responsibility. This blog talks about some of the major features we launched recently to shoulder this responsibility.

What are you looking for – Delivery or Dining options? Introducing auto-suggest tabs

What is it? 

We introduced one-switch tabs on the auto-suggest search for easy and relevant discovery of restaurants, dishes, cuisines etc. for customer-specific requests – delivery or dining. 

Why did we build it?

We wanted to capture a customer’s search intent (which varies for Dining and Delivery) early in their search journey and remove unnecessary noise. For example, a customer’s favourite Biryani outlet might differ with a change in intent from Delivery to Dining.

How did we build it?

• We finetuned the auto-suggest to provide more contextual and relevant suggestions. For example, we eliminated dining and far away from restaurants (out-of-delivery radius outlets) in case of a delivery search.

• We further filtered restaurants based on delivery and dine-out flags, making the customer experience better and quicker (read more satisfactory). 

Building ‘Learn to Rank’ through ML. And boy! How and how much we learnt! 

What is it?  

LTR aka ‘Learn To Rank’ is an ML model used to rank search results based on their past popularity (clicks, taps, conversion etc.) at a regional level.

Why did we build it?

• While a specific rule was working fine for a region/ district sub-zone or particular scenario, the former ranking model wasn’t working well for all cases/ locations. We had to make it universal.
• Our focus was to improve the relevance of search results and in the process make net conversion better. 

How did we build it?

• The LTR model contains features based on the popularity of restaurant dishes in a particular region like Delhi-NCR or Pune, which incorporates factors such as historical ordering patterns, popularity information (both city and location level), keyword match, preferences etc. 
• We formulated the problem statement as a pairwise classification and set the relevance of data points based on the customer’s dropout factor.
• Our model was based on the methodology elaborated by the gradient boosting based model¹. 

Barger becomes burger, hangry becomes hungry – enabling autocorrect

What is it?

In case a customer misspells a query, this feature provides suggestions similar to the keyword. For example: showing ‘burger’ when someone types ‘barger’.

Why did we build it?

• We wanted to solve for relevance in the case of a misspelt query.
• We aimed to tackle the problem wherein only those cases were solved which had no return value in the search.

How did we build it?

• People generally make two kinds of spelling errors: phonetics-based and keyboard-based, so we knew what we had to solve for –
  • To solve phonetics, we designed a custom edit distance based on common phonetic mistakes
    • Paniir → Paneer
    • Chikan → Chicken
  • For keyboard typing errors, we sampled data based on the common mistakes such as typos with adjacent characters
    • Pixxa → Pizza
    • Oaneef → Paneer
• We use features based on dish names and edited distance based on special weightage given to phonetically similar characters (for example, ‘ee’ and ‘i’). For this, we decided to follow the Siamese network² model to measure similarity between any two dishes.

• When we become fairly certain that the customer’s original search query wouldn’t lead to the intended results, we provide an autocorrect version to show better search results, while also allowing the customer to check results for the original query using the “Search instead for” header.

• On the other hand, when we are not entirely sure if a customer has made a mistake in the original search query, then we show results for the original query while also providing a ‘did you mean’ header to better understand their ask.

Let’s search for impact, shall we? Learning and key takeaways!

Through our features, we have made it easier for our customers to locate dishes, cuisines, or restaurants. Our improvements have also helped us in making our Search more friendly for a variety of customers.

As for the business, it helped tremendously improve the overall Search order conversion. In simpler words, more people who came to Search on Zomato ended up ordering the dish as well. 

That’s all folks! For now, at least. Do wait for Part Two where we will discuss many more features that make the search experience smoother, easier, and faster. 

This is a two-part series on how and why we introduced new ‘search’ features on our app. It has been written by Himanshu Shukla and Saurav Singh in collaboration with Sandeep Veethu, Sonal Garg, Srinjay Kumar, and Shivansh Tamrakar.

If you are interested in solving similar problems with a customer-first eye and building features that impact millions, then connect with the authors on LinkedIn. We are always looking for good builders at Zomato.

_{All images are designed in-house.}

-x-

Sources: 

1. Complete Guide to Gradient-Based Optimizers in Deep Learning, analyticsvidhya.com
2. Siamese neural network, wikipedia.com