Cómo predecir el abandono de clientes con machine learning

Un modelo con 80 % de acierto que no detecta a nadie

Imagina que Ficticia Commerce entrena su primer modelo de churn y obtiene un 80 % de accuracy. Suena bien. El equipo lo celebra, prepara la presentación para dirección y se dispone a lanzar las primeras campañas de retención. El problema aparece cuando alguien mira qué hay realmente detrás de ese número.

Si en su base de clientes solo el 20 % abandona en el periodo analizado, existe un modelo trivial que alcanza exactamente ese 80 % sin haber aprendido nada en absoluto: predecir que nadie se va, jamás, en ningún caso. Ese modelo acierta en todos los que se quedan —el 80 % de la base— y falla en todos los que se van. Su accuracy es objetivamente excelente y su utilidad para el negocio es exactamente cero, porque no detecta ni a un solo cliente de los que de verdad importan: los que están a punto de marcharse.

Este es el corazón del problema de la predicción de abandono y el motivo por el cual muchas de las estrategias de predicción fallan en el minuto uno por un problema de concepto del propio churn, y conviene interiorizarlo antes que cualquier otra cosa. El churn es, por suerte para el negocio, el evento minoritario: se van muchos menos clientes de los que se quedan. Esa misma asimetría que es buena para la empresa es una trampa para el modelado, porque convierte la métrica más intuitiva —el porcentaje global de aciertos— en un indicador profundamente engañoso. Cuanto más raro es el abandono, más fácil es construir un modelo con un accuracy altísimo y completamente inútil.

La matriz de confusión: los cuatro resultados que importan

Para salir de la trampa hay que dejar de mirar un solo número y empezar a mirar los cuatro resultados posibles de cualquier predicción de churn. Cuando el modelo evalúa a un cliente, puede acertar o fallar de dos maneras distintas cada una, y la herramienta que ordena esos cuatro casos es la matriz de confusión. No es un concepto estadístico abstracto: es, literalmente, el mapa de aciertos y errores que cuestan dinero.

El modelo trivial que predice «nadie se va» vive entero en la columna derecha: acumula verdaderos negativos y falsos negativos, y nunca produce un solo verdadero positivo. Por eso su accuracy engaña: la columna de los que se quedan es tan grande que domina el promedio, mientras la columna que de verdad importa —la de los que abandonan— queda completamente desatendida. La matriz de confusión hace visible justo lo que el accuracy esconde, y por eso es el punto de partida real de cualquier evaluación seria.

Las métricas que sí importan, con números

De la matriz de confusión salen las tres métricas que dan la imagen real, y entenderlas no requiere matemática avanzada: requiere pensar en términos de esos cuatro cuadrantes. La precisión responde a «de todos los clientes que el modelo marcó como en riesgo, ¿cuántos se iban de verdad?» y se calcula como verdaderos positivos dividido entre todos los positivos predichos. El recall —o sensibilidad— responde a la pregunta inversa, «de todos los clientes que realmente abandonaron, ¿a cuántos detectó el modelo?», y es verdaderos positivos entre todos los abandonos reales. El F1 combina ambas en su media armónica, útil cuando necesitas un único número para comparar modelos sin sacrificar del todo ninguna de las dos.

Veámoslo con números concretos. Supongamos que Ficticia Commerce tiene 1.000 clientes en su conjunto de prueba, de los cuales 200 abandonan de verdad. Un modelo marca a 250 clientes como en riesgo; de esos 250, acierta en 180 que efectivamente se van y se equivoca en 70 que se iban a quedar. La precisión es 180 entre 250, es decir 0,72: casi tres de cada cuatro alarmas eran correctas. El recall es 180 entre 200, o sea 0,90: el modelo capturó al 90 % de los desertores reales. Y los 20 que se le escaparon —los falsos negativos— son clientes que perdió sin tener ninguna oportunidad de intervenir.

En churn, la métrica que manda es el recall, y la razón es puramente económica. Un falso negativo es una pérdida consumada: no hubo ninguna oportunidad de actuar porque el modelo nunca avisó. Un falso positivo solo cuesta el precio de una campaña de retención dirigida a alguien que no la necesitaba. Como vimos al desglosar cuánto cuesta realmente perder un cliente, esa asimetría es enorme: dejar escapar a un cliente sin verlo es mucho más caro que molestar a uno que se iba a quedar de todas formas. Por eso, ante la duda, preferimos un modelo que peque de exceso de alarma a uno que se quede corto detectando.

Feature engineering desde la lógica de negocio

Un modelo solo es tan bueno como las variables que le das, y aquí la ventaja no la tiene quien sabe más estadística, sino quien entiende mejor el comportamiento del cliente. Las señales que más predicen el abandono no son exóticas: son traducciones directas de cómo se relaciona un cliente con el negocio. La recencia —cuánto hace que no compra—, la frecuencia con la que compraba, el valor monetario acumulado, el número de quejas, la antigüedad de la relación o la frecuencia de uso en el caso de servicios. Muchas de estas señales son justamente las que identificamos al analizar el churn en ecommerce, donde la ausencia de un evento de cancelación obliga a leer el comportamiento para detectar la fuga.

La construcción de estas variables a partir de datos transaccionales en crudo es, en la práctica, más de la mitad del trabajo de un proyecto de churn. No requiere algoritmos sofisticados; requiere agregaciones bien pensadas. Partiendo de una tabla de pedidos con una fila por transacción, las tres señales del núcleo RFM se construyen con una sola agrupación por cliente, como muestra el siguiente fragmento.

import pandas as pd

# Tabla de pedidos en crudo: una fila por transacción
pedidos = pd.read_csv("pedidos.csv", parse_dates=["fecha_pedido"])
hoy = pedidos["fecha_pedido"].max()

# Agregación por cliente: de transacciones a señales de comportamiento
features = pedidos.groupby("customer_id").agg(
    recencia=("fecha_pedido", lambda f: (hoy - f.max()).days),
    frecuencia=("order_id", "count"),
    valor_monetario=("importe", "sum"),
).reset_index()

# A esto se le unen señales de otras fuentes: quejas, antigüedad, logística
print(features.head())

Lo importante de este paso no es el código, que es deliberadamente sencillo, sino el criterio detrás de cada variable. La recencia mide alejamiento del patrón de compra; la frecuencia, el grado de hábito; el valor monetario, lo que está en juego. A estas tres se les suman después señales de otras fuentes —el número de incidencias de soporte, los meses de antigüedad, la distancia logística— hasta formar el perfil que el modelo aprenderá a leer. El modelo viene después y es, casi siempre, la parte fácil. Quien domina esta fase domina el proyecto.

El pipeline base en Python

Con las métricas claras y las variables construidas, el pipeline mínimo de Ficticia Commerce cabe en unas pocas líneas. El siguiente código carga el histórico de clientes ya enriquecido con las features, separa los datos respetando la proporción de churn, entrena un modelo base y —esto es lo importante— lo evalúa con las métricas correctas, no con el accuracy.

import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report, confusion_matrix

# Histórico de clientes de Ficticia Commerce, ya con sus features
df = pd.read_csv("clientes_ficticia_commerce.csv")

features = ["recencia", "frecuencia", "valor_monetario",
            "antiguedad_meses", "num_quejas", "dist_almacen_km"]
X = df[features]
y = df["churn"]              # 1 = abandonó, 0 = sigue activo

# Separación estratificada: conserva la proporción de churn en train y test
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=42
)

# Modelo base. class_weight compensa que abandonan muy pocos
modelo = RandomForestClassifier(
    n_estimators=300,
    class_weight="balanced",
    random_state=42
)
modelo.fit(X_train, y_train)

# Evaluación con las métricas correctas, nunca solo con accuracy
y_pred = modelo.predict(X_test)
print(classification_report(y_test, y_pred))

# La matriz de confusión hace visible el coste real de cada error
tn, fp, fn, tp = confusion_matrix(y_test, y_pred).ravel()
print(f"Desertores detectados (VP): {tp}")
print(f"Desertores no detectados (FN): {fn}")  # los más caros

Dos detalles marcan la diferencia entre este pipeline y uno ingenuo. El parámetro stratify=y garantiza que la escasa proporción de clientes que abandonan esté igual de representada en los datos de entrenamiento y de prueba; sin él, podrías acabar con un conjunto de test casi sin casos de churn y métricas sin ningún sentido. Y class_weight="balanced" le dice al modelo que preste más atención a la clase minoritaria, compensando parcialmente el desbalance que, si no, lo empujaría hacia el modelo trivial que ignora a los desertores. La línea final, que extrae los falsos negativos de la matriz de confusión, es la que de verdad deberías vigilar versión tras versión: es el recuento de clientes que el modelo deja escapar.

Por qué Random Forest es un buen punto de partida

El modelo elegido no es casual y lo primero de todo deberíamos de poder distinguir conceptualmente entre modelos de aprendizaje supervisado y no supervisado. Un Random Forest es, en esencia, un conjunto de muchos árboles de decisión entrenados sobre muestras distintas de los datos, cuyas predicciones se combinan por consenso. Esa estructura le da una robustez notable: tolera bien los datos desequilibrados, no exige escalar las variables a un rango común, captura relaciones no lineales sin que se lo pidas explícitamente y, de regalo, te dice qué variables pesan más en sus decisiones a través de su importancia de características.

Como primer modelo, es difícil de superar en relación esfuerzo-resultado. Da una línea base sólida contra la que medir cualquier mejora posterior, funciona razonablemente con su configuración por defecto y, en muchos proyectos pequeños, es directamente suficiente para empezar a actuar sobre los clientes en riesgo. La regla práctica es sensata y vale la pena tatuársela: empieza por el modelo más simple que funcione y solo añade complejidad cuando los números demuestren, sobre tu conjunto de prueba, que la necesitas de verdad.

Con un pipeline base bien planteado, features construidas desde el negocio y una evaluación honesta por recall en lugar de por accuracy, Ficticia Commerce ya tiene un sistema que detecta abandono de forma útil. Pero si miras cualquier comparativa seria de modelos de churn, hay uno que aparece sistemáticamente por encima del Random Forest, a veces por un margen amplio en la métrica que más nos importa. ¿Por qué XGBoost gana casi siempre en este problema, qué hace distinto por dentro y cuándo no merece la pena dar el salto?