Fuga de clientes
Un modelo que señala qué clientes están a punto de irse, y qué los empuja.
Datos y BI · Python · Demo navegable
El problema
Captar cuesta bastante más que retener, así que la pregunta rentable no es cuántos se fueron el mes pasado sino quién se va el mes que viene. Un recuento a toro pasado no deja margen para hacer nada; una probabilidad por cliente, sí.
Qué hace
- Construye un conjunto de datos etiquetado y lo prepara: codificación one-hot, selección de variables y normalización.
- Corrige el desequilibrio entre clases con pesos balanceados y una partición estratificada, para que la minoría que se va no quede ahogada.
- Entrena una regresión logística, elegida por encima de modelos más opacos porque sus coeficientes se leen directamente como causas de negocio.
- Publica un panel con la probabilidad de fuga por cliente y los factores que la explican.
Lo que se decidió al construirlo
- Regresión logística, y se dice por qué
- Se eligió por interpretabilidad: cada coeficiente se lee como una palanca de negocio. Un modelo de conjunto probablemente ordenaría algo mejor y no diría nada que un comité pueda usar. La decisión está declarada en el repositorio; lo que no hay es una comparación contra el modelo que se descartó.
- Pesos equilibrados: se prefiere avisar de más
- El umbral se mueve hacia cazar a quien se va, aunque eso llene la lista de falsos avisos. Cuatro de cada cinco señalados no se iban a ir. El intercambio es deliberado y solo compensa si una llamada de retención cuesta bastante menos que perder al cliente, y ese coste este repositorio no lo modela.
- Las métricas las escribe el código
- El informe de resultados se generaba a mano y se separó del código: llegó a publicar una precisión de un conjunto de datos que ya no existía, y ningún AUC. Ahora lo emite el script junto a los JSON del panel. Un número que nadie puede regenerar es un número que nadie debería publicar.
- Los tramos se ordenan por valor, no por letra
- Los tramos de importe son categorías ordenadas, así que cien a ciento veinte euros no se coloca antes que cuarenta a sesenta. Y los cuatro ficheros de segmento comparten una misma forma: emitir una clave distinta en cada uno fue lo que dejó tres de los cuatro gráficos sin rótulos en los ejes.
Hasta dónde llega
- Un AUC de 0,703 mide ordenación, no acierto: dados un cliente que se fue y otro que se quedó, el modelo pone por delante al que se fue el 70 % de las veces. La precisión real es 0,205, y predecir «no se va nadie» sacaría un 87 % de aciertos siendo inútil.
- Hay una sola partición de entrenamiento y prueba, sin validación cruzada. Las cifras publicadas son una realización, no una media con su intervalo: el recall de 0,615 son cuarenta aciertos sobre sesenta y cinco.
- Las variables son asociaciones, no causas. El generador construye la probabilidad de baja como una suma de indicadores conocida de antemano; el modelo la recupera de forma imperfecta. Que más incidencias acompañen a más bajas no autoriza a concluir que reducirlas retenga a nadie.
- No hay calibración de probabilidades ni elección de umbral por coste. Para usarlo de verdad haría falta poner precio a la llamada y a la baja, y ese cálculo no está aquí.
- 0,703 AUC-ROC
- 64,0 % de acierto
- 61,5 % de las fugas, detectadas
Construido con
- Python
- scikit-learn
- React
De dónde salen los datos
Datos sintéticos generados por el propio repositorio: no hay información de ningún cliente.