Como a Swiggy prevê o valor do cliente com 350+ features e um MLP simples

A Swiggy, gigante indiana de delivery de comida e quick commerce (Instamart), publicou os detalhes de um modelo interno de predicted lifetime value (pLTV) que estima o valor de longo prazo de um cliente antes mesmo do primeiro pedido. O caso, reportado pela InfoQ, é um estudo denso de engenharia de features em produção e de uma decisão de arquitetura contraintuitiva: adicionar uma segunda tarefa de predição para encolher o modelo, não aumentá-lo.

Para quem constrói sistemas de ML↳Machine learning39 conteúdosClassificador de Sentimentos – Azure MLData · abr 2019Inteligência Artificial e Machine Learning: O que você precisa saberAI · fev 2024Inteligência Artificial: seminário online da USP debate o futuro do aprendizado de máquinaGestão Dev & TI · jun 2021Ver tudo em AI → no Brasil, o que interessa aqui não é o resultado de negócio em si, mas as escolhas de engenharia por trás dele: como lidar com sinal escasso, target distorcido e como avaliar um modelo quando as métricas de regressão padrão não servem.

O problema: prever antes do primeiro pedido

O objetivo de negócio é usar o valor previsto do cliente na otimização de lances de anúncios, em vez de depender de métricas de conversão de curto prazo. Ou seja, a Swiggy quer, no momento em que paga por um clique ou uma instalação, ter uma estimativa de quanto aquele usuário vai valer ao longo do tempo, não apenas se ele vai converter agora.

Isso cria um problema técnico duro. Segundo a empresa:

• Sinal inicial escasso (sparse): boa parte dos novos usuários não faz nenhum pedido nos primeiros 30 dias.
• Target altamente distorcido (skewed): um grupo relativamente pequeno de clientes gera valor de vida muito superior ao resto.
• Cold start: as features precisam vir de informação disponível antes do primeiro pedido.

O modelo precisa, portanto, distinguir usuários que parecem idênticos no início mas evoluem para padrões de consumo completamente diferentes. É o clássico desafio de sinal fraco com cauda longa.

350+ features geradas antes da primeira compra

A resposta da Swiggy para o cold start foi engenharia de features pesada: mais de 350 sinais, todos gerados a partir de informação disponível antes do primeiro pedido. Eles estão agrupados em áreas como:

• Canal de aquisição
• Sinais de dispositivo e fraude
• Comportamento geográfico
• Histórico de reclamações
• Afinidade de categoria no Instamart
• Comportamento de pedido
• Padrões de pagamento
• Indicadores socioeconômicos

O ponto de aprendizado aqui é que, quando o alvo é difícil e o sinal individual é fraco, a largura da entrada (quantidade e diversidade de features) faz o trabalho pesado, não a profundidade da arquitetura. É o oposto da tendência de jogar uma rede gigante no problema.

A jogada de arquitetura: encolher com multitarefa

Aqui está a parte mais interessante para engenheiros. Em vez de uma arquitetura complexa, a Swiggy usou um multilayer perceptron (MLP) relativamente simples: três camadas ocultas compartilhadas que aprendem representações comuns, seguidas de heads específicas por tarefa (Food e Instamart).

O twist foi adicionar contagem de pedidos como tarefa auxiliar de predição, ao lado do lifetime value. O modelo virou uma rede de quatro heads. E o resultado surpreende quem espera que mais tarefas signifiquem mais parâmetros:

Como resumiu Soumyajyoti Banerjee, Staff Data Scientist da Swiggy, em post no LinkedIn:

A reviravolta: adicionar uma segunda tarefa de predição encolheu o modelo em 63% e o deixou mais preciso.

Soumyajyoti Banerjee, Staff Data Scientist na Swiggy

A lógica por trás disso é o aprendizado multitarefa funcionando como regularização: prever contagem de pedidos junto com o valor força as camadas compartilhadas a aprender representações mais gerais e úteis, o que reduz a necessidade de capacidade extra e diminui overfitting. É um lembrete prático de que engenharia de modelo não é só empilhar camadas.

Avaliar quando MAE e MAPE não servem

Outro aprendizado vem da avaliação. Segundo Jayshmi A, engenheira da Swiggy, métricas convencionais de regressão como MAE (erro absoluto médio) e MAPE (erro percentual absoluto médio) não eram suficientes, justamente por causa da quantidade enorme de usuários com valor zero e da cauda longa de clientes de alto valor. Um MAE baixo pode esconder um modelo que acerta os zeros e erra feio na cauda que importa.

A solução foi mudar a pergunta: em vez de quão perto o score está do valor real, medir se o modelo consegue ordenar corretamente os clientes por valor. A avaliação divide valores previstos e reais em dez quantis (decis) e mede com que frequência os usuários caem no grupo previsto e no real correspondentes, o que é visualizado numa matriz (heatmap) de cobertura de decis.

Como colocou a própria equipe:

O problema não era produzir um score; era produzir um score que sobrevivesse a sinais iniciais escassos.

Os resultados reportados:

• Correlação de Spearman acima de 0,75 tanto para Food quanto para Instamart.
• 70% a 80% de cobertura na diagonal da matriz de decis (usuários caindo no decil previsto correto).

Para quem já bateu cabeça tentando avaliar modelos de valor com target esparso, a lição é direta: escolha a métrica que reflete o uso real. Se o objetivo é rankear clientes para diferenciar lances, correlação de ranking (Spearman) e cobertura por decis dizem mais do que erro pontual.

Em produção: pLTV alimentando o lance de anúncio

Na operação, o sinal de pLTV é usado com o target return on ad spend (tROAS) do Google. O fluxo pretendido é ordenar clientes por valor previsto e deixar o sistema de anúncios diferenciar os lances com base nesse ranking, pagando mais por quem tende a valer mais.

A Swiggy também rodou testes A/B em produção comparando o modelo interno com uma plataforma de pLTV de terceiros. O trade-off apareceu claro:

Ou seja: a plataforma externa trazia mais usuários por real gasto, mas o modelo interno trazia usuários melhores (mais retenção e mais valor de pedido) sem custo de licença. Que estratégia vence depende do objetivo de negócio, e essa é exatamente a decisão que uma equipe de engenharia precisa deixar explícita para o time de produto.

O que fica para quem constrói no Brasil

Nenhuma parte deste caso depende de infraestrutura exótica: é um MLP, features tabulares e uma métrica de ranking. É perfeitamente reproduzível por times brasileiros que já têm dados transacionais, seja em food delivery, fintech, e-commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → ou assinatura. Os três aprendizados transferíveis:

1. Multitarefa como regularizador, não só como conveniência de servir dois objetivos, pode reduzir parâmetros e melhorar generalização.
2. A métrica tem que casar com o uso (ranking de clientes = Spearman/decis, não MAE), especialmente com target esparso e cauda longa.
3. Build vs. buy é um trade-off medível, e um A/B honesto expõe qual otimização importa (volume de aquisição vs. qualidade do cliente).

A Swiggy diz que o próximo passo é sair de estimativas pontuais para predições probabilísticas de pLTV, representando a incerteza no valor do cliente e incorporando essa incerteza nas decisões de lance. É a evolução natural: parar de responder quanto vale e passar a responder quanto vale, com que confiança.

Fonte: InfoQ