Como prever churn (evasão de clientes) com dados

O cliente que some raramente avisa, mas o padrão dele já está na sua base#

Quase ninguém manda um e-mail dizendo que vai cancelar. O cliente simplesmente reduz o uso, atrasa a renovação, para de abrir o aplicativo e, um belo dia, o time comercial descobre que a receita já saiu. Saber como prever churn (evasão de clientes) com dados é inverter essa ordem: usar o comportamento que a pessoa já gera dentro dos seus sistemas para estimar, com antecedência, quem tem risco alto de sair, quanto isso custa e o que dá para fazer enquanto ainda há tempo. Não é bola de cristal. É ler sinal de atrito que já mora no dado transacional, só que ninguém organizou para enxergar.

Este artigo é para quem tem dados espalhados entre CRM, ERP, faturamento e atendimento e quer transformar isso em um processo de retenção que a diretoria acompanhe. Vou ser direto sobre o que funciona, onde os modelos falham e a diferença entre um dashboard bonito e uma operação que de fato segura cliente.

Como prever churn (evasão de clientes) com dados começa por definir o evento e a janela#

O erro mais comum não está no algoritmo, está na definição. Antes de treinar qualquer coisa, o time de negócio precisa responder a duas perguntas: o que conta como churn e em que janela você quer prever.

Definir o evento parece óbvio, mas quase nunca é. Em uma assinatura, churn pode ser o cancelamento formal. Em uma conta que não tem cancelamento explícito, churn costuma ser inatividade: sem compra por 90 dias, sem login por 60, saldo médio abaixo de um piso. Cada régua gera um alvo diferente para o modelo e uma ação diferente para o negócio. Um cliente sem compra há 90 dias é churn ou é sazonalidade? Essa decisão é de negócio, não de ciência de dados, e define tudo o que vem depois.

A janela é o segundo ponto que trava projetos. Prever que alguém vai sair "algum dia" não serve. Você precisa de um horizonte útil, por exemplo, a probabilidade de churn nos próximos 60 ou 90 dias, porque é esse prazo que dá tempo para a retenção agir. Isso obriga a montar o dado com disciplina temporal: as variáveis são calculadas até uma data de corte e o rótulo (saiu ou ficou) é observado na janela seguinte. Misturar informação que só existiu depois do corte é o vazamento de dados clássico, o modelo fica excelente no teste e inútil na produção.

Decisão	Pergunta que ela responde	Quem decide
Evento de churn	O que conta como perda de cliente	Negócio
Janela de previsão	Para quantos dias à frente prevejo	Negócio e dados
Data de corte	Até quando calculo as variáveis	Dados
Granularidade	Prevejo por cliente, conta ou produto	Negócio

As variáveis que preveem churn: recência, frequência, valor, engajamento e atendimento#

Pesquisa de satisfação ajuda a entender o clima, mas chega tarde e responde quem quer responder. O sinal antecedente de verdade está no comportamento. A base histórica que quase toda empresa já tem cobre cinco famílias de variáveis, e é a combinação delas que dá previsão boa, não uma isolada.

• Recência: há quanto tempo foi a última compra, o último login, a última interação. É o sinal mais forte na maioria dos negócios e o mais barato de calcular.
• Frequência: com que ritmo o cliente compra ou usa, e principalmente se esse ritmo está caindo. Tendência importa mais que média.
• Valor: ticket médio, receita acumulada, margem e o valor do tempo de vida (LTV). Serve tanto de variável quanto de critério para priorizar quem vale reter.
• Engajamento: uso do produto, adoção de funcionalidades, abertura de e-mail, sessões no app. Engajamento em queda costuma anteceder a saída em semanas.
• Atendimento: número de chamados, reclamações, tempo de resolução, reabertura de tickets. Histórico de atrito no suporte é um dos preditores mais subestimados.

O trabalho pesado aqui não é o modelo, é a engenharia de dados que transforma eventos brutos em uma tabela por cliente com essas variáveis calculadas na data de corte. Sem uma base histórica confiável e versionada, o modelo herda todo o lixo da origem. É por isso que projeto de churn sério começa por engenharia de dados, não por notebook.

Família	Exemplo de variável	O que costuma indicar
Recência	Dias desde a última compra	Distanciamento recente
Frequência	Variação de pedidos nos últimos 3 meses	Perda de hábito
Valor	LTV e ticket médio em queda	Downgrade silencioso
Engajamento	Logins e uso de funcionalidades	Migração para concorrente
Atendimento	Reclamações e tickets reabertos	Insatisfação acumulada

Onde treinar o modelo: Azure Machine Learning ou a Data Science do Fabric#

Prever churn é, tecnicamente, um problema de classificação: para cada cliente, o modelo estima a probabilidade de pertencer à classe "vai sair". Regressão logística, árvores e algoritmos de gradient boosting resolvem a maioria dos casos com folga. Você não precisa de rede neural para isso, e desconfie de quem começa a conversa por deep learning.

Na stack Microsoft, há dois caminhos maduros. O Azure Machine Learning é o ambiente dedicado de MLOps: você treina, compara experimentos, versiona o modelo, registra no workspace e publica um endpoint para escoragem, com AutoML disponível para acelerar a linha de base. É a escolha quando você quer governança de modelo, reuso entre projetos e um pipeline de retreino formal.

A Data Science do Microsoft Fabric traz notebooks, Spark e integração com MLflow dentro do mesmo lakehouse onde os dados já vivem. A vantagem é a proximidade: os dados que a engenharia preparou nas camadas do lakehouse estão a um passo do treino, e o resultado escrito de volta como tabela alimenta direto o Power BI. Se a sua plataforma de dados já está no Fabric, treinar ali reduz movimentação e atrito. Vale entender a plataforma antes de decidir, e escrevi sobre ela em Microsoft Fabric: o que é e vale a pena em 2026.

Critério	Azure Machine Learning	Data Science no Fabric
Foco	MLOps e governança de modelo	Ciência de dados junto ao lakehouse
Onde os dados ficam	Fora, precisam ser conectados	No mesmo lakehouse
Melhor cenário	Muitos modelos, retreino formal	Plataforma já centralizada no Fabric
Saída para o BI	Endpoint ou tabela escorada	Tabela no lakehouse

Escolha por onde seus dados já estão e pela maturidade de MLOps que você precisa, não pela moda. Nos dois casos, a métrica que importa não é acurácia. Em churn, as classes são desbalanceadas, poucos clientes saem por mês, então um modelo que chuta "ninguém sai" acerta a maioria e não serve para nada. Olhe precisão e recall na classe de churn, a área sob a curva e, acima de tudo, o quanto o modelo ajuda a priorizar a lista de retenção. Esse desenho de solução é o que tratamos em analytics avançado.

O Power BI é onde o escore de risco vira decisão#

Um modelo que produz uma probabilidade e ninguém olha não muda nada. O escore precisa chegar a quem age, e o lugar natural é o Power BI, onde o time comercial e a diretoria já vivem. O padrão que funciona é o modelo escrever, a cada rodada, uma tabela com identificador do cliente, probabilidade de churn, faixa de risco e as principais variáveis que puxaram o escore. O Power BI consome essa tabela e transforma número em rotina.

Na prática, isso vira uma lista acionável e não um gráfico bonito de enfeite. O gestor filtra por faixa de risco alta cruzada com LTV alto, vê os motivos que o modelo apontou e distribui os casos para a equipe. A régua de faixas é decisão de negócio, calibrada pela capacidade da operação de atender.

Faixa de risco	Probabilidade estimada	Ação sugerida
Alta	Acima de 70%	Contato ativo prioritário e oferta de retenção
Média	Entre 40% e 70%	Nutrição, benefício direcionado, acompanhamento
Baixa	Abaixo de 40%	Monitorar sem custo de abordagem

Evite o dashboard que empurra centenas de clientes de risco sem ordem de prioridade. O valor está em cruzar risco com valor do cliente e com capacidade de atendimento, para que a operação ataque primeiro onde perder dói mais. E deixe visível o histórico do escore por cliente: ver a probabilidade subindo mês a mês diz mais do que uma foto isolada.

Sem ação de retenção, o modelo é só um relatório caro#

Prever é metade do trabalho. O ciclo só fecha quando a previsão vira contato, oferta, ajuste de plano ou resolução de um problema de atendimento que estava corroendo a relação. E aqui vem a parte que ninguém gosta de ouvir: a previsão precisa ser medida contra o resultado.

Monte um grupo de controle. Separe uma parcela dos clientes de risco alto que não recebem a abordagem e compare a taxa de saída com o grupo tratado. Sem isso, você nunca vai saber se a retenção funcionou ou se aqueles clientes ficariam de qualquer jeito. É desconfortável não abordar gente que o modelo apontou, mas é a única forma honesta de provar que o investimento em retenção paga. Um modelo pode estar certíssimo e a ação de retenção ser inútil, e você só descobre medindo.

Feche o loop também no dado: a resposta de cada abordagem (aceitou, recusou, ficou, saiu mesmo assim) volta para a base e alimenta o próximo retreino. É esse ciclo, previsão, ação, medição e reaprendizado, que separa um projeto vivo de um relatório que envelhece rápido.

Viés, explicabilidade e LGPD não são detalhes, são o projeto#

Modelo de churn decide onde a empresa gasta esforço de retenção, e isso tem consequências. Três frentes precisam de atenção desde o começo, não como apêndice.

Viés: se o histórico embute um padrão injusto, o modelo aprende e repete. Cuidado especial com variáveis que sejam procuração para características sensíveis. O objetivo é prever comportamento de churn, não segregar clientes por atributo que não deveria entrar na conta.

Explicabilidade: o gestor que vai ligar para o cliente precisa saber por que aquele caso subiu na lista. Um escore sem explicação vira caixa-preta e perde a confiança do time comercial na primeira ligação que não faz sentido. Técnicas de importância de variáveis, disponíveis no Azure ML e no Fabric, existem para isso.

LGPD: você trata dado pessoal para prever comportamento, e a Lei nº 13.709/2018 se aplica integralmente. Isso exige base legal clara, finalidade específica, minimização (não jogue todo dado disponível no modelo só porque existe) e transparência. Decisão automatizada que afete o cliente pede atenção redobrada. Trate privacidade como requisito de arquitetura, não como formulário para preencher no final.

Uma última dose de honestidade: previsão de churn tem teto. Se a causa da evasão é preço fora de mercado, produto que não entrega ou concorrente muito melhor, nenhum modelo resolve, ele só coloca um número no problema. O modelo é ótimo para priorizar esforço e antecipar sinais, péssimo para consertar um negócio que perde cliente por mérito.

Perguntas frequentes#

Quantos dados históricos preciso para prever churn? Depende do volume de eventos de churn, não apenas do número de clientes. O modelo aprende com quem saiu, então você precisa de casos suficientes de saída ao longo do tempo para o algoritmo enxergar padrão. Como referência prática, é comum trabalhar com pelo menos um a dois anos de histórico para capturar sazonalidade e ter volume de churn que sustente treino e teste separados. Base pequena e churn raro pedem modelos mais simples e cautela redobrada com o desbalanceamento.

Preciso de Azure Machine Learning ou dá para fazer só no Fabric? Os dois entregam um modelo de classificação bom. Se a sua plataforma de dados já está no Microsoft Fabric, a Data Science dentro do lakehouse reduz movimentação e leva o resultado direto ao Power BI. Se você precisa de MLOps mais formal, versão de modelo, endpoints dedicados e retreino governado, o Azure Machine Learning é mais completo. A escolha é de arquitetura e maturidade, não de qualidade do algoritmo.

Qual algoritmo é o melhor para churn? Não existe campeão universal, mas gradient boosting e regressão logística resolvem a maioria dos casos com ótimo custo-benefício. Comece pela regressão logística como linha de base, porque é interpretável, e evolua para modelos de árvore se o ganho justificar. Rede neural raramente compensa em churn tabular e cobra caro em explicabilidade, que é justamente o que o time comercial vai exigir.

Como sei se o modelo é bom se ele acerta a maioria? Acurácia engana em churn porque as classes são desbalanceadas. Um modelo que diz que ninguém sai acerta a maioria e é inútil. Olhe precisão e recall na classe de churn, a área sob a curva e, principalmente, se a lista priorizada pelo modelo concentra os clientes que realmente saíram. A prova final é operacional: a retenção guiada pelo escore reduz a evasão medida contra um grupo de controle?

O modelo pode discriminar clientes injustamente? Pode, se o histórico embutir viés e você não controlar. Variáveis que funcionam como procuração para características sensíveis devem ser evitadas, e o modelo precisa ser auditado quanto ao comportamento entre grupos. Somado a isso, a LGPD exige base legal, finalidade e minimização no tratamento do dado pessoal. Ética e conformidade não são etapa final, são requisito de projeto desde o desenho das variáveis.

Prever churn resolve o problema de evasão? Não sozinho. O modelo antecipa e prioriza, mas quem retém é a ação: contato, oferta, ajuste de plano, correção de um atendimento ruim. E se a evasão vem de preço, produto ou concorrência, nenhum modelo conserta a causa, ele apenas mostra o tamanho do problema. Trate a previsão como ferramenta de priorização dentro de uma estratégia de retenção, nunca como substituta dela.

Para fechar#

Prever churn não é sobre o algoritmo mais sofisticado. É sobre definir com clareza o evento e a janela, montar boas variáveis de recência, frequência, valor, engajamento e atendimento, treinar um modelo de classificação onde seus dados já vivem, levar o escore ao Power BI e transformar previsão em ação medida. Feito com honestidade sobre limites, viés e LGPD, vira um dos projetos de dados com retorno mais direto que existe.

Quer montar esse ciclo de previsão e retenção na sua operação, do dado ao escore no Power BI? Fale com a gente e veja também nossas soluções.