Todos os projetos

06 · Machine Learning

Prever o churn antes que ele aconteça.

Extensão do projeto TelecomX: depois de mapear quem cancelava e por quê, o próximo passo natural foi construir modelos de classificação supervisionada capazes de prever o churn individual, para que retenção pudesse ser proativa, não reativa.

PapelModelagem preditiva
Período2025
TipoClassificação binária
StackScikit-learn · Python
Matriz de confusão, Random Forest validação · 30% da base 1.428 TN · acerto não-churn 186 FP · alarme falso 204 FN · churn não detectado 421 TP · churn previsto certo previsto: não-churn previsto: churn real: não-churn real: churn

Contexto

Análise descritiva responde "o que aconteceu". Análise preditiva responde "o que vai acontecer". Depois de mapear churn na fase exploratória, o próximo movimento é antecipar o cliente que vai sair , enquanto ainda dá tempo de agir.

Problema

Construir um classificador binário que, dadas as variáveis comportamentais e contratuais do cliente, retorne a probabilidade dele cancelar nos próximos meses. Métrica prioritária: recall sobre churn , é mais caro deixar um cancelamento passar do que disparar um alerta falso.

Abordagem

  • Pré-processamento: encoding de variáveis categóricas, tratamento de desbalanceamento de classes.
  • Split estratificado: 70/30 preservando proporção da variável alvo.
  • Comparação de baseline: Logistic Regression, Decision Tree, Random Forest, KNN.
  • Avaliação criteriosa: acurácia não é o foco; recall, precisão e F1 sobre a classe minoritária (churn) são.
  • Análise de feature importance: quais variáveis o modelo aprendeu a usar?

Resultados

82%
Acurácia geral · Random Forest
67%
Recall sobre churn (a métrica que importa)
3
Variáveis dominantes: contrato, tenure, pagamento

O que aprendi com os modelos

  • Random Forest superou os baselines em recall sobre a classe minoritária, métrica que importa em retenção.
  • As três variáveis dominantes coincidem com os achados da fase exploratória: tipo de contrato, tempo de permanência, forma de pagamento.
  • Desbalanceamento de classes era real: sem tratá-lo, todos os modelos caíam em "prever sempre não-churn" e ainda assim ter 73% de acurácia.
  • Trade-off recall × precisão explícito: apresentei matriz de confusão para o decisor escolher onde calibrar o threshold.

Decisão

O modelo final não é "o mais acurado". É o que melhor responde à pergunta de negócio: dado o custo de um cancelamento, quanto vale um alarme falso? A escolha do threshold passou a ser deliberada, não default.

Entreguei o pipeline completo, pré-processamento, treino, avaliação, persistência, com documentação explicando como recalibrar o threshold conforme o orçamento de retenção mude.

Stack

Python Scikit-learn Pandas NumPy Random Forest Logistic Regression Matplotlib

Aprendizados

O aprendizado mais importante deste projeto foi tirar acurácia do pedestal. Em classes desbalanceadas, acurácia mente, um modelo burro que prediz sempre a classe majoritária pode ter 70%+ de acurácia. Recall, precisão e F1 contam a história real.

Aprendi também que modelo é só metade da resposta. A outra metade é apresentar o trade-off para o decisor: cada falso negativo custa X, cada falso positivo custa Y, e a escolha do threshold de probabilidade deveria refletir essa relação, não ser deixada no default de 0,5.