As soon as we place an order on Swiggy, our eyes are glued to the tracking screen to see how distant our food is in realtime. Seeing the food getting prepared and being a short while away has a sense of pleasure. Nonetheless, this shouldn’t be the case when the food gets delayed and is a good time away. We often reach out to the shopper care executives to seek out out the whereabouts of our order. This ends in a not so great customer experience and in addition increases the operation costs borne. Consumer research suggests that customers often anchor themselves to the ETA) shown on the tracking screen once they perceive whether the order is delayed or on time. Hence, the ETA shown on the tracking screen becomes a vital input for patrons to guage our delivery experience and in addition shapes how often the shopper decides to succeed in out to us via chat or call and/or decides to cancel the order.
On this blog, we’re going to discuss the info science models and their architectures that powers the ETA model for food delivery in Swiggy within the backend.
The Data Science team at Swiggy built an ML powered ETA service that works with real-time on-ground signals from task strategy, restaurant stress, delivery executive location pings and provides probably the most accurate & smooth post-order time estimates to our customers.
The ETA architecture is a mix of 4 different models for the corresponding 4 different legs within the order journey with the predictions being refreshed at fixed time intervals, allowing the model to eat all the newest information available. The 4 order legs are- . The diagram below depicts a summary of a typical order’s journey at Swiggy. You possibly can learn more in regards to the order journey via this blog
The tracking screen ETA model is built on top of the Service Level Agreement (SLA) promise prediction shown to the shopper at cart and improves on that by incorporating real time signals because the order progresses through its journey. These are additional real-time signals beyond what is taken into account for cart predictions. A order at any point of time might be in any certainly one of the next stages:
- Time period for the reason that order is placed on Swiggy till it’s assigned to a Delivery Executive (DE).
- Time period between task of an order and the DE’s arrival on the restaurant or the First Mile (FM) time.
- DE’s Wait Time (WT) on the restaurant to select up the order.
- Picked As much as Delivered time or the Last Mile time.
The alternative to go together with 4 different models for tracking screen ETA stems from the undeniable fact that the model feature space varies for the various stages of an order. The underlying hypothesis behind the identical is that different inputs impact an order’s progress at different stages — for instance, when a DE shouldn’t be assigned to an order, model makes use of network and task features to supply an accurate prediction , whereas when the order is picked up, the model uses DE’s pings and the corresponding speed/distance features derived from it. Hence, to enhance the general accuracy of the ETA these features have to be utilized in isolation in 4 different models.
The ETA Ordered Stage model is named when the order is received by Swiggy till it’s assigned to a DE. The block diagram below explains the features consumed by the model.
The ETA OR model is built on top of the SLA prediction provided to the shopper at cart where a number of restaurant and item has been made by the shopper and a final cart page is created with billing information. The model consumes food preparation & travel time predictions made at cart together with network features like variety of DEs available, their average distance from the restaurant to give you an accurate prediction.
If the variety of Delivery Executives (DEs) within the vicinity of the restaurant are high as above, the model would adjust accordingly and supply a lower prediction value as in comparison with if there was a scarcity of it.
The model also utilizes other realtime features like system & restaurant stress, time elapsed to reinforce the predictions further. Rare cases like rain & possibility of rejections by delivery executives are also provided as inputs to the model to cope with long tail cases.
The ETA Assigned Stage model is named in the course of the time period from DE’s task of the order to the DE’s arrival on the restaurant. The model uses real-time DE pings and features built on top of it to give you an accurate ETA estimate. The block diagram below explains the features consumed by the model.
The ETA assigned stage model is the subsequent stage of the ETA after the ordered stage. Much like the ordered stage, it’s built on top of the SLA prediction provided at cart. Nonetheless, since a DE is assigned to the order at this stage, all travel time predictions have a DE component to it making them more accurate. Information on how familiar the DE is with the restaurant and customer locations, his/her mode of transportation (bike/bicycle/others) and historic trends are used to enhance on the present predictions. These leg-wise predictions together with features engineered using realtime DE pings like current speed, global speed, distance traveled mix to supply an accurate prediction. More details in regards to the ping features are discussed within the second a part of the blog where we discuss the LM stage intimately. The model also inputs realtime features like RX confirm flag, stress on the restaurant to reinforce the predictions further.
There is perhaps cases wherein you see an ETA of 37 mins turning into 25 mins post the task of a DE. These cases are generally when the task of DE happens sooner than previously expected (example- a DE just logged in for his or her shift).
The WT Stage of the model is named when the DE’s waiting on the restaurant to select up the order. The block diagram below explains the features consumed by the model.
The predictions from ETA WT are built on the leg-wise predictions of WT & LM. Real time features like restaurant stress, live order count on the restaurant and item count can also be utilized by the model. Features like time elapsed since food preparation began and time elapsed within the wait leg are introduced with a view to make the predictions more complete.
The model also takes into consideration stress on the restaurant which is of paramount importance. During weekend dinner slots, the restaurants are at a better than usual stress and even a small latest order might take high preparation times on account of kitchen stress. Compared, weekday snacks slots are generally stress free as depicted within the illustration above. The model understands these patterns and provides an accurate prediction taking all the bottom realities into consideration.
On this blog we discussed how we built a machine learning-powered ETA service — combination of 4 different models corresponding to different legs within the order journey, which refresh their predictions at fixed time intervals. The service is built on top of the Service Level Agreement (SLA) promise prediction shown to customers on the cart and improves on that by incorporating real-time signals because the order progresses through its journey. We discussed three of the 4 stages of the model intimately. We’ll return with a follow-up blog post that delves into the last stage of the ETA architecture together with the evaluation metrics and impact of the answer, because the blog is incomplete without discussing these crucial features. We may even discuss the longer term improvements which can be planned to reinforce the accuracy of ETA estimates even further.