7 min de lectura
Una empresa de suscripción identifica a sus clientes en riesgo de abandono y les envía una oferta de retención. Tres meses después, la mitad de los clientes que recibieron la oferta nunca tuvieron intención de irse. Su tarjeta de crédito había expirado y nadie les había pedido que la actualizaran.
El modelo había etiquetado correctamente a los clientes que dejaron de renovar. El problema no estaba en la predicción, sino en la intervención. Un descuento de fidelización no resuelve un método de pago caducado.
El abandono voluntario y el involuntario tienen el mismo aspecto en los datos cuando no se separan desde el diseño del modelo. La distinción importa porque las intervenciones que funcionan para uno no funcionan para el otro, y entrenar un solo modelo sobre una etiqueta que mezcla los dos tipos lleva a hacer la pregunta correcta al conjunto de datos equivocado.
Lo que distingue los dos tipos
El abandono voluntario es una decisión. El cliente evaluó el servicio, encontró que no valía lo que pagaba, o encontró una alternativa mejor, o cambió de necesidades, y eligió marcharse. Las señales pueden aparecer con semanas de anticipación. La frecuencia de uso cae, el tiempo entre sesiones aumenta, las funcionalidades que antes se usaban con regularidad quedan sin actividad.
El involuntario es fricción. La tarjeta expiró, el banco rechazó el cobro automático, el cliente olvidó actualizar los datos al cambiar de tarjeta. El sistema perdió acceso al método de pago. El cliente seguía siendo cliente en su mente, sin saber que el proceso técnico lo había expulsado.
Las señales son distintas entre los dos tipos. El abandono involuntario no suele acumular semanas de desenganche previo al evento; el cambio es abrupto y está ligado a un problema de pago específico. Identificarlo en retrospectiva es relativamente directo si hay registro de los intentos de cobro fallidos. Identificarlo antes de que ocurra requiere predecir cuándo fallará el método de pago, no cuándo se desenganchará el cliente.
Un modelo entrenado sobre una etiqueta que mezcla los dos tipos aprende algo técnicamente correcto pero comercialmente ambiguo. Predice quién va a dejar de pagar. Lo que no aprende es por qué, que es la información que determina qué acción tiene sentido tomar.
Por qué las intervenciones no son intercambiables
La intervención adecuada para el abandono voluntario apunta a revertir una decisión. Puede ser un descuento, una propuesta de suspensión temporal en lugar de cancelación, o una comunicación de retención que entienda el motivo del desenganche. El objetivo es cambiar la evaluación que el cliente hizo del servicio.
La intervención adecuada para el involuntario apunta a eliminar la fricción. Una notificación de pago fallido con acceso directo a la actualización del método de cobro. Un recordatorio preventivo cuando la tarjeta registrada está próxima a caducar. El objetivo es que el cliente, que no tiene intención de marcharse, pueda seguir siendo cliente sin que un problema técnico lo expulse.
Mandar un descuento a alguien cuya tarjeta expiró es ruido. El cliente no canceló porque el precio le parecía alto. El sistema dejó de cobrar porque el método de pago era inválido. El descuento se gasta sin cumplir función, y en algunos casos genera desconcierto. El cliente puede leer la oferta de retención como una señal de que algo inesperado ocurrió en su cuenta, con un efecto peor que no haber enviado nada.
La dirección contraria produce el mismo tipo de problema. Enviar una alerta de cobro fallido a alguien que decidió conscientemente no renovar no resuelve nada. Es una comunicación que no aborda el motivo real del desenganche.
Separar los dos tipos en el diseño del modelo no es un refinamiento técnico. Es la condición para que las intervenciones tengan alguna probabilidad de funcionar.
La definición del evento es una decisión de negocio
El modelo aprende a partir de cómo se etiquetan los datos históricos. Si un pago fallido sin recuperación posterior y una cancelación explícita en la plataforma llevan la misma etiqueta de churn, el modelo no puede distinguir entre los dos patrones. La limitación no es técnica; el diseño del conjunto de entrenamiento los declaró equivalentes.
La definición del evento de abandono es una decisión que se toma antes de procesar ningún dato. Qué cuenta como churn determina qué aprende el modelo y qué clientes acaban en la lista que recibe el equipo de retención.
Dos preguntas concretas lo estructuran. La primera es si un pago fallido sin recuperación en los días siguientes cuenta como churn definitivo o como un evento de riesgo con posibilidad de recuperación. La respuesta cambia el tamaño y el perfil de la población objetivo. Si el modelo aprende que el churn incluye eventos recuperables, va a etiquetar a clientes que el equipo de retención no necesita contactar. La segunda es si el cliente que cancela y vuelve a contratar en los noventa días siguientes es un cliente recuperado o si ese patrón debe quedar fuera del conjunto de entrenamiento. Eso determina si el modelo aprende a reconocer esas secuencias como señales relevantes o como ruido.
Ninguna de estas preguntas tiene una respuesta técnicamente correcta. Son decisiones de negocio que definen el objeto del modelo. El equipo de datos puede presentar las opciones y sus implicaciones, pero la elección corresponde a quien va a actuar sobre los resultados.
Cuándo tiene sentido construir dos modelos
Si las intervenciones son distintas y el volumen de cada tipo lo justifica, construir dos modelos separados suele ser más transparente que entrenar uno con una variable adicional que intente capturar el tipo de evento.
Un modelo para el abandono voluntario trabaja sobre señales de desenganche acumuladas con anticipación. Las más informativas tienden a ser el volumen de uso, la frecuencia de sesiones y el tiempo transcurrido desde la última interacción significativa con el servicio. A veces incluye también el perfil de funcionalidades que el cliente dejó de usar, que puede indicar si el desenganche es gradual o repentino. Un modelo para el involuntario trabaja sobre el historial de pagos del cliente, la antigüedad del método de cobro registrado y los intentos fallidos anteriores, si los hubo.
La alternativa es un modelo único con una variable que registre si hubo un intento de cobro fallido antes del evento de churn. Esa variable introduce parte de la información que separa los dos tipos sin requerir dos modelos distintos. Es una solución más compacta y funciona razonablemente bien cuando el volumen de uno de los tipos es pequeño.
La elección depende del volumen de cada tipo y de cuánto divergen las señales entre ellos. Si el abandono involuntario representa una fracción pequeña del churn total, el modelo único con la variable adicional puede ser suficiente. Si los dos tipos tienen volumen comparable y señales distintas, la separación produce resultados más nítidos y una lógica de intervención más clara para el equipo que actúa sobre los resultados.
Lo que se acuerda antes de etiquetar
Antes de que el equipo de datos empiece a explorar el histórico, vale la pena acordar qué va a hacer el equipo de retención con los resultados. Si la intervención es la misma para todos los clientes que el modelo identifique como en riesgo, la distinción entre tipos puede no importar. Si hay acciones distintas para cada perfil, la distinción determina qué modelo tiene sentido construir.
El diseño del evento de abandono no es un paso técnico previo a la fase interesante del proyecto. Es donde se decide qué problema va a resolver el modelo. Un modelo que aprende a predecir con precisión el evento equivocado no produce valor, aunque sus métricas técnicas sean sólidas.
Acordar esa definición con el equipo de negocio antes de tocar los datos es también una protección para el proyecto. Cuando el modelo llega a producción y el equipo de negocio pregunta por qué la lista incluye clientes que claramente no iban a irse, la respuesta "así estaban etiquetados en el entrenamiento" llega tarde. Las definiciones que no se fijaron al principio se fijan después, cuando el sistema ya está funcionando y el costo de cambiarlo es real.