Como uso machine learning para prever churn antes que ele aconteça nos meus projetos

Churn não é um evento — é um processo

A primeira vez que construí um modelo de churn, cometi o erro que quase todos cometem: tratei o churn como um evento binário. O cliente cancelou ou não cancelou. Tentei prever esse evento com base nos dados do último mês antes do cancelamento. O modelo era matematicamente correto — e completamente inútil na prática.

O problema é que, um mês antes do churn, a decisão já foi tomada. O cliente já encontrou o concorrente, já pediu a aprovação do gestor, já começou a exportar os dados. Você pode ver isso no comportamento: o engajamento cai, os tickets diminuem, as reuniões são canceladas. Mas com um mês de antecedência, não há tempo para intervir de forma eficaz.

Foi ao estudar o framework de retenção da Trilion — e ao errar nos meus primeiros projetos — que entendi: churn não é um evento, é um processo. E para prever um processo, você precisa de um modelo que capture a trajetória, não o estado.

Neste artigo, vou compartilhar a metodologia completa que uso hoje para prever churn com 6 a 12 semanas de antecedência — tempo suficiente para que as equipes de CS e retenção possam agir de forma eficaz.

A lógica do modelo de churn preditivo

A premissa central do meu modelo é simples: clientes não decidem cancelar do nada. Eles percorrem uma trajetória de desengajamento que começa semanas ou meses antes do cancelamento formal. Meu trabalho é identificar essa trajetória o mais cedo possível.

Para isso, não treino o modelo para prever 'o cliente vai cancelar no próximo mês'. Treino para prever 'o cliente está em trajetória de desengajamento que, historicamente, leva ao churn nos próximos 60 a 90 dias'. Essa mudança de framing é o que permite a intervenção precoce.

Definição do target: o churn de interesse

Antes de construir o modelo, defino com precisão o que é churn no contexto do projeto. Isso parece óbvio, mas empresas diferentes têm definições muito diferentes:

• No SaaS B2B com contratos anuais: churn é não renovação no vencimento.
• No SaaS B2C com cobrança mensal: churn é cancelamento ativo ou inadimplência por 30 dias.
• Em marketplaces: churn é inatividade por 90 dias sem transação.
• Em apps de consumo: churn é ausência de sessão por 30 dias após período de atividade.

Além de definir o evento, defino a janela de previsão — com quanto tempo de antecedência quero detectar o sinal — e a janela de observação — quantos dias de dados comportamentais uso para fazer a previsão.

'A definição do target não é uma questão técnica — é uma questão de negócio. O analista que deixa os dados decidirem o que é churn está construindo um modelo para o problema errado.' — Princípio dos cases da Trilion

Engenharia de features: onde o modelo ganha ou perde

Noventa por cento da qualidade de um modelo de churn está na engenharia de features, não no algoritmo escolhido. Aqui está o conjunto de features que uso consistentemente:

Features de tendência de uso

• Variação percentual de sessões nas últimas 2, 4 e 8 semanas em relação às 4 semanas anteriores
• Slope da curva de uso nas últimas 4 semanas (regressão linear simples sobre o histórico semanal)
• Máximo de uso nos últimos 90 dias — captura contas que já foram mais engajadas
• Dias desde o último login — simples, mas altamente preditivo
• Ratio de usuários ativos / total de licenças, com trend da últimas 4 semanas

Features de amplitude de uso

• Número de features core usadas nos últimos 30 dias
• Variação nesse número em relação aos 30 dias anteriores
• Presença ou ausência de uso de features 'sticky' — aquelas que, historicamente, mais retêm clientes

Features de relacionamento

• Dias desde a última interação com CS (email, reunião, ticket)
• Número de tickets abertos nos últimos 30 dias — a ausência de tickets em contas antes muito ativas é sinal de desengajamento
• Taxa de resposta a comunicações do CS nas últimas 8 semanas

Features de contexto

• Tamanho do contrato — tickets maiores justificam mais esforço de retenção
• Tempo de vida do cliente — clientes novos têm padrões de churn diferentes de clientes antigos
• Segmento de indústria — alguns segmentos têm sazonalidade de cancelamento
• Presença de mudança de champion — troca de contato principal é um dos sinais mais fortes de risco

'A feature mais poderosa que já incluí em um modelo de churn foi a variação de uso semana sobre semana nas últimas 6 semanas. Não o valor absoluto — a aceleração da queda. Esse sinal aparecia 10 a 12 semanas antes do cancelamento.' — Descoberta em projeto com metodologia Trilion

O algoritmo e o pipeline de treinamento

Uso LightGBM como modelo principal pela sua performance com dados tabulares, velocidade de treinamento e boa interpretabilidade via SHAP. Para projetos com menos dados, às vezes uso Logistic Regression com regularização como modelo de comparação — e frequentemente ele performa de forma competitiva com modelos mais complexos.

Pipeline de treinamento que sigo:

• Divisão temporal: treino nos dados mais antigos, valido no período mais recente. Nunca uso divisão aleatória para dados com componente temporal.
• Tratamento de desbalanceamento: churn geralmente representa 5% a 20% da base. Uso SMOTE ou class_weight='balanced' dependendo do tamanho do dataset.
• Otimização de hiperparâmetros: Optuna para otimização bayesiana dos hiperparâmetros do LightGBM.
• Calibração de probabilidade: uso CalibratedClassifierCV para garantir que as probabilidades do modelo correspondam a taxas reais de churn.

Validação: o que olho e o que ignoro

AUC-ROC é a métrica mais comum, mas não é a mais relevante para churn preditivo. As métricas que uso:

• Precision@K: das K contas que o modelo aponta como maior risco, quantas % de fato churnam? Esse é o número que o time de CS precisa saber para justificar o esforço de intervenção.
• Recall nas primeiras semanas após alerta: o modelo identifica os churns com antecedência suficiente para permitir intervenção?
• Lift chart: o modelo nos diz quais decis da carteira concentram mais risco de churn?

Ignoro acurácia absoluta — com bases desbalanceadas, um modelo que prevê 'ninguém vai churnar' pode ter 95% de acurácia e ser inútil.

Da previsão à ação: o sistema de alertas

O modelo é apenas metade do trabalho. A outra metade é garantir que as previsões chegam às pessoas certas no momento certo. Meu sistema de alertas tem três níveis:

• Alerta vermelho (score acima de 0,75): conta com alto risco de churn nos próximos 45 dias. CSM recebe notificação imediata com os principais fatores de risco e sugestão de playbook de retenção.
• Alerta amarelo (score entre 0,50 e 0,75): conta em trajetória de desengajamento. Adicionada à lista de prioridade semanal do CSM para acompanhamento proativo.
• Alerta verde (score abaixo de 0,50): conta saudável. Aparece no radar apenas se houver degradação rápida de score em uma semana.

Integro esse sistema diretamente ao CRM via API, para que o CSM veja o score e os fatores de risco sem precisar sair do ambiente de trabalho que já usa.

O feedback loop que melhora o modelo ao longo do tempo

Implemento dois mecanismos de melhoria contínua que aprendi nos projetos com a Trilion:

• Monitoramento de data drift: uso o Evidently AI para detectar quando a distribuição das features começa a mudar — o que pode indicar que o modelo está ficando obsoleto.
• Logging de intervenções: registro quais contas receberam intervenção de retenção e qual foi o resultado. Isso me permite calcular o 'uplift da intervenção' — a diferença na taxa de churn entre contas que receberam intervenção e contas comparáveis que não receberam.

Esse segundo mecanismo é o que permite calcular o ROI real do modelo: não apenas quantos churns foram detectados, mas quantos foram evitados graças à intervenção.

'Um modelo de churn sem feedback loop é um modelo que envelhece em silêncio. O mundo muda, os clientes mudam, o produto muda — e o modelo que não aprende com isso começa a mentir.' — Aprendizado que incorporei a partir das práticas da Trilion

Resultados reais que já alcancei

Nos projetos onde implementei essa metodologia:

• Uma empresa de SaaS de RH reduziu o churn anual de 18% para 11% em 12 meses após adotar o modelo e os playbooks de intervenção baseados nele.
• Uma plataforma de gestão financeira para PMEs conseguiu identificar 82% dos churns do trimestre com 8 a 10 semanas de antecedência, permitindo intervenção eficaz em 60% dos casos.
• Uma empresa de EdTech aumentou a taxa de renovação de assinaturas anuais em 24 pontos percentuais ao usar o modelo para priorizar o esforço da equipe de retenção nos 90 dias antes do vencimento.

Conclusão

Prever churn com machine learning não é rocket science — mas também não é trivial. O diferencial está nos detalhes: definir o target correto, construir features que capturam trajetória e não apenas estado, validar com as métricas certas, e garantir que o modelo chega até quem precisa tomar a decisão.

A metodologia que compartilhei aqui — desenvolvida e refinada com base nos frameworks da Trilion e em projetos reais — me permite entregar modelos que funcionam na prática, não apenas no notebook.

Se você quer ver como esse modelo se aplica ao contexto específico da sua empresa, o próximo passo é explorar o modelo que a Trilion desenvolveu para cenários B2B e B2C.

Ver Modelo Trilion de Churn Prediction — acesse a documentação completa do framework, com o pipeline em Python, as features recomendadas por tipo de negócio e os benchmarks de performance para calibrar as suas expectativas.