How Swiggy Predicts Customer Value With 350+ Features and a Simple MLP

Swiggy, the Indian food delivery and quick commerce (Instamart) giant, published details of an internal predicted lifetime value (pLTV) model that estimates a customer's long-term value even before the first order. The case, reported by InfoQ, is a dense study in production feature engineering and a counterintuitive architecture decision: adding a second prediction task to shrink the model, not grow it.

For those building ML systems in Brazil, what matters here isn't the business outcome itself, but the engineering choices behind it: how to handle scarce signal, a skewed target, and how to evaluate a model when standard regression metrics don't work.

The problem: predicting before the first order

The business goal is to use the predicted customer value in ad bid optimization, rather than relying on short-term conversion metrics. In other words, Swiggy wants, at the moment it pays for a click or an install, to have an estimate of how much that user will be worth over time, not just whether they will convert now.

This creates a hard technical problem. According to the company:

• Sparse initial signal: a large share of new users don't place any order in the first 30 days.
• Highly skewed target: a relatively small group of customers generates lifetime value far higher than the rest.
• Cold start: features must come from information available before the first order.

The model therefore needs to distinguish users who appear identical at first but evolve into completely different consumption patterns. It's the classic weak-signal-with-long-tail challenge.

350+ features generated before the first purchase

Swiggy's answer to the cold start was heavy feature engineering: more than 350 signals, all generated from information available before the first order. They are grouped into areas such as:

• Acquisition channel
• Device and fraud signals
• Geographic behavior
• Complaint history
• Category affinity on Instamart
• Order behavior
• Payment patterns
• Socioeconomic indicators

The takeaway here is that when the target is hard and the individual signal is weak, input width (quantity and diversity of features) does the heavy lifting, not architecture depth. It's the opposite of the trend of throwing a giant network at the problem.

The architecture move: shrinking with multitask learning

Here's the most interesting part for engineers. Instead of a complex architecture, Swiggy used a relatively simple multilayer perceptron (MLP): three shared hidden layers that learn common representations, followed by task-specific heads (Food and Instamart).

The twist was adding order count as an auxiliary prediction task, alongside lifetime value. The model became a four-head network. And the result surprises anyone who expects more tasks to mean more parameters:

| | Before | After | |---|---|---| | Prediction tasks | LTV | LTV + order count | | Parameters | 363,000 | 135,000 | | Reduction | | 63% | | Accuracy | baseline | marginally better |

As Soumyajyoti Banerjee, Staff Data Scientist at Swiggy, summarized in a LinkedIn post:

The twist: adding a second prediction task shrank the model by 63% and made it more accurate.

>

-- Soumyajyoti Banerjee, Staff Data Scientist at Swiggy

The logic behind this is multitask learning acting as regularization: predicting order count alongside value forces the shared layers to learn more general and useful representations, which reduces the need for extra capacity and decreases overfitting. It's a practical reminder that model engineering isn't just about stacking layers.

Evaluating when MAE and MAPE don't work

Another lesson comes from evaluation. According to Jayshmi A, a Swiggy engineer, conventional regression metrics like MAE (mean absolute error) and MAPE (mean absolute percentage error) weren't sufficient, precisely because of the huge number of zero-value users and the long tail of high-value customers. A low MAE can hide a model that gets the zeros right and gets badly wrong on the tail that matters.

The solution was to change the question: instead of how close the score is to the real value, measure whether the model can correctly rank customers by value. The evaluation splits predicted and actual values into ten quantiles (deciles) and measures how often users fall into the corresponding predicted and actual groups, which is visualized in a decile coverage matrix (heatmap).

As the team itself put it:

The problem wasn't producing a score; it was producing a score that would survive scarce initial signals.

The reported results:

• Spearman correlation above 0.75 for both Food and Instamart.
• 70% to 80% coverage on the diagonal of the decile matrix (users falling into the correct predicted decile).

For anyone who has struggled trying to evaluate value models with a sparse target, the lesson is direct: choose the metric that reflects actual use. If the goal is to rank customers to differentiate bids, ranking correlation (Spearman) and decile coverage say more than pointwise error.

In production: pLTV feeding ad bidding

In operation, the pLTV signal is used with Google's target return on ad spend (tROAS). The intended flow is to rank customers by predicted value and let the ad system differentiate bids based on that ranking, paying more for those who tend to be worth more.

Swiggy also ran A/B tests in production comparing the internal model with a third-party pLTV platform. The trade-off appeared clearly:

| Criteria | Swiggy's internal model | External platform | |---|---|---| | Retention per acquired user | higher | lower | | Gross order value per user | higher | lower | | Users acquired per dollar | lower | higher | | Platform cost | no additional cost | platform cost |

In other words, the external platform brought more users per dollar spent, but the internal model brought better users (more retention and more order value) without a license cost. Which strategy wins depends on the business goal, and that's exactly the decision an engineering team needs to make explicit to the product team.

What this means for those building in Brazil

No part of this case depends on exotic infrastructure: it's an MLP, tabular features, and a ranking metric. It's perfectly reproducible by Brazilian teams that already have transactional data, whether in food delivery, fintech, e-commerce, or subscriptions. The three transferable takeaways:

1. Multitask learning as a regularizer, not just as a convenience for serving two objectives, can reduce parameters and improve generalization.
2. The metric has to match the use case (customer ranking = Spearman/deciles, not MAE), especially with a sparse target and long tail.
3. Build vs. buy is a measurable trade-off, and an honest A/B test exposes which optimization matters (acquisition volume vs. customer quality).

Swiggy says the next step is moving from point estimates to probabilistic pLTV predictions, representing uncertainty in customer value and incorporating that uncertainty into bidding decisions. It's the natural evolution: stop answering how much it's worth and start answering how much it's worth, with what confidence.