La mayoría de empresas saben exactamente cuándo un cliente va a cancelar. Lo saben 30 días antes. Y no hacen nada. No porque no les importe, sino porque sus dashboards están diseñados para mostrarles el pasado disfrazado de insights.
El cliente que cancela no te sorprende. Te avisa con datos de comportamiento que tu herramienta de analytics convierte en gráficos bonitos que nadie revisa hasta que ya es tarde. Este artículo es el sistema para leer esas señales cuando todavía podés hacer algo.
Un dato de contexto: el 70% del churn es voluntario (el cliente decide irse) y el 30% involuntario (pagos fallidos). La parte involuntaria se recupera con dunning automation. La voluntaria es donde se pierde la batalla real. Y la mayoría pelea esa batalla haciendo "exit interviews" a clientes que ya se fueron mentalmente hace un mes.
No necesitás Gainsight ni ChurnZero. Necesitás entender qué datos mirar y cómo convertirlos en alertas que lleguen a tiempo.
Tabla de contenido
- Por qué el análisis de cohortes tradicional no predice nada
- Los 5 tipos de cohortes que deberías estar midiendo
- El framework de 4 pasos para detección temprana
- Señales de alerta: qué medir en los 30 días previos al churn
- Cómo automatizar alertas sin herramientas caras
- Benchmarks de churn por industria B2B
- Preguntas frecuentes
- El primer paso (no el sistema completo)
Por qué el análisis de cohortes tradicional no predice nada
La mayoría de empresas tienen dashboards de retención que les dicen exactamente cuántos clientes perdieron el mes pasado. Eso y una reunión de 45 minutos donde todos asienten pero nadie hace nada.
El problema fundamental: el análisis de cohortes tradicional está diseñado para explicar el pasado, no para anticipar el futuro. Mirás una matriz de retención con colores degradados de verde a rojo, y lo único que ves es el cementerio de clientes que ya se fueron.
Hay datos que miden lo que ya pasó (indicadores lagging): churn rate del mes pasado, retención por cohorte, MRR perdido. Útiles para reportes, para benchmarking, para explicarle al board por qué el número es lo que es. Pero no te ayudan a cambiar nada.
Y hay datos que predicen lo que va a pasar (indicadores leading): caída en frecuencia de login, features core abandonadas, tickets de soporte sin respuesta, silencio sostenido. Estos te dan ventana de intervención.
Amplitude, Mixpanel, tu dashboard custom en Metabase: todos muestran datos hermosos sobre retención. Ninguno te manda una alerta diciendo "Juan de Acme Corp no ha usado el feature principal en 12 días y su contrato renueva en 3 semanas". Muestran datos. No activan intervenciones.
Sobre la granularidad: depende del ciclo de vida de tu producto. SaaS con contratos mensuales debería analizar semanalmente. Enterprise con contratos anuales puede trabajar con granularidad mensual. La regla: tu granularidad de análisis debe ser al menos 4x más frecuente que tu ciclo de contrato.
El costo de enterarte tarde es brutal. Para cuando el cliente cancela, ya pasó por semanas de desengagement invisible. Ya evaluó alternativas. Ya tomó la decisión emocionalmente. La llamada de retención es un formalismo, no una negociación.
Los 5 tipos de cohortes que deberías estar midiendo
No todos los análisis de cohortes son iguales. El tipo que uses determina qué preguntas podés responder y qué acciones podés tomar.
Cohortes de adquisición
La más común y la menos útil para predicción.
Agrupa usuarios por fecha de signup. Enero 2024, Febrero 2024. Te permite medir el impacto de campañas específicas y cambios de producto sobre la retención a largo plazo. Si lanzaste una feature en marzo y las cohortes de marzo retienen mejor que las de febrero, tenés señal.
La limitación: no captura diferencias de comportamiento dentro de la misma fecha. Dos usuarios que se registraron el mismo día pueden tener patrones completamente diferentes. Uno completó onboarding en 2 horas, el otro nunca lo terminó. La cohorte de adquisición los trata igual.
Cohortes de comportamiento
Las cohortes de comportamiento son las que predicen churn.
Agrupa usuarios por acciones clave realizadas (o no realizadas). "Usuarios que completaron onboarding en los primeros 7 días" vs "Usuarios que no lo completaron". "Usuarios que invitaron a un compañero de equipo" vs "Usuarios individuales". "Usuarios que usaron Feature X al menos 3 veces en el primer mes" vs "Usuarios que nunca la tocaron".
Los patrones de uso preceden al churn. Siempre. Un usuario que dejó de usar el core feature de tu producto no está en riesgo de irse: ya se fue mentalmente. Solo no canceló todavía.
Cohortes de revenue
Agrupa por plan, MRR, o rango de ticket.
Los clientes de mayor ticket suelen tener menor churn. Más inversión significa más compromiso, más stakeholders involucrados, más costo de switching. Pero cuidado con asumir que enterprise = retención garantizada. Un cliente enterprise con onboarding incompleto puede tener churn explosivo. Y cuando se va un enterprise, se va un pedazo importante de tu MRR.
La cohorte de revenue te ayuda a priorizar. Si tenés que elegir a quién llamar primero cuando ambos están en riesgo, llamás al que representa más revenue.
Cohortes de suscripción
Agrupa por tipo de contrato: mensual, anual, freemium.
Los contratos anuales te dan más tiempo de intervención. Un cliente mensual en riesgo tiene días para decidir. Un cliente anual tiene semanas o meses. Eso cambia tu estrategia de retención completamente.
Un dato que genera confusión: setup fees no cuentan como upsell ni afectan churn rate. Son revenue reconocido de forma diferente. Si cobrás $2,000 de setup y $500/mes de suscripción, tu churn rate se calcula sobre los $500, no sobre los $2,500.
Cohortes geográficas
Las menos usadas pero críticas en expansión internacional.
Las diferencias culturales en expectativas de soporte afectan retención de formas no obvias. Clientes en LATAM pueden esperar respuesta inmediata por WhatsApp. Clientes en Alemania pueden preferir documentación detallada. Clientes en USA pueden asumir que todo se resuelve con un email a support.
Si tu churn en una región específica es significativamente mayor que en otras, no es casualidad.
El framework de 4 pasos para detección temprana
Suficiente contexto. Esto es lo que hacés el lunes.
Paso 1: definir tus cohortes predictivas
No uses solo fecha de signup. Combina con comportamiento.
La pregunta que querés responder: "Qué tienen en común los clientes que se fueron?" Y después: "Quién de mis clientes actuales tiene esas mismas características?"
Ejemplos de cohortes predictivas útiles:
- Usuarios que no usaron Feature X en los primeros 14 días
- Usuarios que completaron menos del 50% del onboarding
- Usuarios que nunca invitaron a un segundo usuario
- Usuarios con menos de 3 logins en el primer mes
- Usuarios que abrieron ticket de soporte y nunca recibieron respuesta satisfactoria
La combinación es donde está el poder. "Usuarios de plan Starter que no completaron onboarding Y no usaron Feature X en 21 días" es una cohorte mucho más predictiva que cualquiera de esos factores por separado.
Query de SQL básico para arrancar:
-- Obtiene comportamiento de usuarios en primeros 30 días
SELECT
u.user_id,
u.email,
u.created_at as signup_date,
-- Cuenta usos de feature principal
COUNT(CASE WHEN e.event_type = 'feature_x_used' THEN 1 END) as feature_x_usage,
-- Cuenta logins totales
COUNT(CASE WHEN e.event_type = 'login' THEN 1 END) as total_logins,
MAX(e.created_at) as last_activity
FROM users u
LEFT JOIN events e ON u.user_id = e.user_id
AND e.created_at >= u.created_at
AND e.created_at <= u.created_at + INTERVAL '30 days'
WHERE u.subscription_status = 'active'
GROUP BY u.user_id, u.email, u.created_at
Paso 2: identificar las señales que preceden al churn
Estas son las métricas leading que deberías estar trackeando:
Login frequency: Una caída del 40% o más comparada con el baseline del usuario es alerta roja. No compares con el promedio general. Compará con cómo ese usuario específico usaba la plataforma antes.
Growth MarketingTodo lo que publico aquí es gratis. Implementarlo contigo tiene precio.
Si algo de lo que leíste te hizo pensar "esto me está pasando", hablemos. Te respondo el mismo día.
Agendar 30 min →Feature adoption: Si las funciones core no están siendo usadas, el valor percibido está en caída libre. Identificá las 2-3 features que correlacionan con retención y monitoréalas.
Support tickets: Más tickets pre-churn = más engagement = menor riesgo. El usuario que se queja está invertido emocionalmente. Quiere que el producto funcione. El que dejó de quejarse ya decidió irse. El silencio es la señal más peligrosa.
NPS/CSAT scores: Un detractor sin seguimiento es un churn en progreso. Un passive es un churn esperando la oferta correcta del competidor.
Patrones de uso por día: Usuarios que dejan de usar en días laborales (solo acceden fines de semana) están en transición. El producto dejó de ser parte de su workflow diario.
Paso 3: configurar el sistema de alertas
La alerta sin acción es entretenimiento con datos.
Slack webhooks + SQL queries programados: Un cron job que ejecuta el query diariamente y manda los resultados a un canal de Slack. Costo: $0. Tiempo de implementación: un par de horas.
Google Sheets con importación de datos: Exportá los datos semanalmente, usá fórmulas para calcular un risk score, aplicá conditional formatting. Verde, amarillo, rojo. No escala después de 1000 usuarios activos, pero para empezar funciona.
Segmentos dinámicos en tu CRM: HubSpot, Salesforce, Pipedrive permiten crear propiedades custom que se actualizan con webhooks. Armá un workflow que asigne un "risk score" basado en las señales que identificaste.
Paso 4: protocolo de intervención
Define escalas basadas en urgencia:
Alerta temprana (30 días antes de renovación): Email personalizado. No el template genérico de "vimos que no estás usando X". Un email que demuestre que entendés el contexto del usuario y ofrezca ayuda específica.
Alerta media (15 días): Llamada de Customer Success. No de ventas. Para entender qué está pasando y si hay algo que puedan hacer para que el producto funcione mejor.
Alerta crítica (7 días): Oferta de retención. Pero solo si vale la pena retener. No todos los clientes merecen descuento. Algunos deberían irse.
Este framework conecta directamente con la automatización de marketing con IA para escalar las intervenciones sin multiplicar el equipo de CS.
Señales de alerta: qué medir en los 30 días previos al churn
No todas las señales tienen el mismo peso. Algunas te dan 30 días de anticipación. Otras solo 3.
Señales de actividad
Reducción en frecuencia de logins: Comparalo con el baseline del usuario, no con el promedio general. Si Juan entraba 4 veces por semana y ahora entra 1, tiene una caída del 75%. Si María entraba 1 vez y sigue entrando 1 vez, está estable.
Tiempo en la aplicación: Una caída sostenida es más significativa que un pico único. Si el usuario pasó de sesiones de 20 minutos a sesiones de 3 minutos durante 2 semanas seguidas, algo cambió.
Acciones por sesión: Entran pero hacen menos. El producto dejó de resolver el problema que resolvía antes. O encontraron una forma más eficiente de hacerlo afuera.
Señales de engagement
Features core no usadas en 7+ días: Si tu producto tiene 3 features principales y el usuario dejó de usar las 3, no está "ocupado". Está desenganchado.
Nuevo usuario no completa onboarding en la ventana esperada: Si tu onboarding está diseñado para completarse en 48 horas y el usuario lleva 10 días sin terminarlo, no va a terminarlo. Y su probabilidad de churn es significativamente mayor.
Power users que pasan a usage casual: Un usuario que hacía 50 acciones diarias y ahora hace 5 está en transición activa hacia la salida.
Señales de sentimiento
NPS detractor o passive sin seguimiento: Si alguien te puso un 6 en NPS y nadie le escribió para entender por qué, tenés datos que no usás para nada.
Tickets de soporte sin resolver por más de 48h: Cada hora que pasa es erosión de confianza.
Respuestas negativas en surveys in-app: "No me sirvió" o "No encontré lo que buscaba" son gritos de ayuda que la mayoría ignora.
La señal más peligrosa: el silencio
Usuarios que no se quejan, no piden features, no abren tickets. Los que simplemente dejaron de hacer ruido.
Si un usuario estaba activo en la comunidad, pedía mejoras, reportaba bugs, y de repente desapareció: no está satisfecho. Está resignado. Ya encontró la alternativa y está migrando sus procesos antes de cancelar.
Cuando el usuario deja de quejarse sobre la funcionalidad que falta, ya encontró quien sí la tiene.
Tabla de pesos por señal
Estos pesos están basados en análisis de productos SaaS con ciclos de contrato mensual. Ajustalos según tu data.
| Señal | Peso de riesgo | Ventana de detección |
|---|---|---|
| Login drop >50% | Alto | 14-21 días |
| Feature core abandonada | Alto | 21-30 días |
| Silencio post-ticket | Medio | 7-14 días |
| Acceso a billing sin upgrade | Bajo | 3-7 días |
| NPS detractor sin seguimiento | Medio | 14-21 días |
| Onboarding incompleto día 10+ | Alto | Inmediato |
Cómo automatizar alertas sin herramientas caras
Gainsight cobra mínimo $30k/año. ChurnZero arranca en $15k. Vitally es más accesible pero sigue siendo inversión significativa.
Si tenés menos de 500 clientes activos o menos de $1M ARR, esas herramientas son overkill.
Opción 1: SQL + Cron + Slack
Costo: $0
Tiempo de setup: 2-4 horas
Escala hasta: ~2000 usuarios activos
SELECT
user_id,
email,
company_name,
last_login,
DATEDIFF(CURRENT_DATE, last_login) as days_since_login,
feature_usage_30d,
-- Asigna nivel de riesgo basado en inactividad + uso de features
CASE
WHEN DATEDIFF(CURRENT_DATE, last_login) > 14
AND feature_usage_30d < 3 THEN 'CRÍTICO'
WHEN DATEDIFF(CURRENT_DATE, last_login) > 7
AND feature_usage_30d < 5 THEN 'ALTO'
WHEN DATEDIFF(CURRENT_DATE, last_login) > 3 THEN 'MEDIO'
ELSE 'BAJO'
END as risk_level
FROM (
SELECT
u.user_id,
u.email,
u.company_name,
MAX(e.created_at) as last_login,
COUNT(CASE WHEN e.event_type = 'core_feature_used'
AND e.created_at > CURRENT_DATE - INTERVAL '30 days'
THEN 1 END) as feature_usage_30d
FROM users u
LEFT JOIN events e ON u.user_id = e.user_id
WHERE u.subscription_status = 'active'
GROUP BY u.user_id, u.email, u.company_name
) user_activity
WHERE days_since_login > 3
ORDER BY
CASE risk_level
WHEN 'CRÍTICO' THEN 1
WHEN 'ALTO' THEN 2
WHEN 'MEDIO' THEN 3
ELSE 4
END,
days_since_login DESC
Configurás un cron job que ejecuta esto diariamente y manda el resultado a un webhook de Slack. Los CRÍTICOS llegan como mensaje urgente, los demás como reporte consolidado.
Opción 2: Google Sheets + Conditional Formatting
Costo: $0
Tiempo de setup: 1-2 horas
Escala hasta: ~1000 usuarios activos
Exportá los datos semanalmente. Creá columnas calculadas:
- Días desde último login:
=HOY()-F2 - Risk score:
=SI(G2>14;3;SI(G2>7;2;SI(G2>3;1;0))) - Color condicional: Verde (0), Amarillo (1), Naranja (2), Rojo (3)
Opción 3: CRM con scoring nativo
Costo: El que ya pagás
Tiempo de setup: 3-5 horas
HubSpot, Salesforce, Pipedrive tienen scoring built-in. Creá propiedades custom:
last_product_login(datetime)feature_usage_score(number)churn_risk_score(calculated)
Configurá webhooks desde tu producto que actualicen estas propiedades.
Opción 4: Herramientas especializadas
Solo tiene sentido si tenés 500+ clientes activos, ARR > $1M, o tu equipo de CS no puede manejar el volumen con las opciones anteriores.
Antes de eso, ese presupuesto rinde más en un CS dedicado a llamar clientes en riesgo.
La configuración de eventos en GA4 te da el fundamento de tracking necesario para alimentar cualquiera de estos sistemas.
Benchmarks de churn por industria B2B
Necesitás contexto para saber si tu churn es problema o es normal.
Churn rates por segmento
El churn rate promedio para B2B SaaS en 2025 es 3.5% anual. Pero ese número promedio esconde variaciones enormes.
El churn overall es 3.27%, con voluntario 2.41% e involuntario 0.86%. Ese 0.86% involuntario es pagos fallidos recuperables con dunning.
Enterprise SaaS tiene churn menor al 1% mensual mientras que SMBs tienen 3-7% mensual. La diferencia es abismal. Si vendés a SMBs y esperás churn de enterprise, estás en negación.
Según OpenView Partners, el churn aceptable para Series A es menor al 5% mensual, para Series B menor al 3%, y para empresas en crecimiento maduro menor al 2%.
Cómo interpretar estos números
Si tu churn está por encima del benchmark de tu industria, tenés un problema de producto, expectativas, o mercado.
Si está por debajo, primero verificá que estás calculando bien. Muchos calculan churn de forma optimista excluyendo clientes "especiales" o midiendo solo logo churn cuando el problema es revenue churn.
Logo churn vs revenue churn
Logo churn: Porcentaje de clientes que cancelan. 100 clientes, cancelan 5 = 5% logo churn.
Revenue churn: Porcentaje de MRR perdido. $100k MRR, perdés $3k = 3% revenue churn.
Podés tener logo churn alto pero revenue churn bajo si los que se van son clientes pequeños. Lo que duele es lo inverso: perder los clientes grandes.
Net Revenue Retention (NRR) > 100% significa que la expansión de clientes existentes supera el churn. El santo grial de SaaS.
El Head of Growth tiene responsabilidad directa sobre estas métricas.
Preguntas frecuentes
Cuánto tiempo toma implementar este framework
Depende de tu stack. Si tenés acceso a los datos y alguien que escriba SQL, una semana para algo funcional. Si dependés de ingeniería y hay cola de prioridades, un mes.
Funciona para B2C también
Sí, pero los tiempos cambian. En B2C el ciclo es más corto: días, no semanas. Ajustá la ventana de 30 días a 7-14 días.
Qué pasa si no tengo suficientes datos históricos
Empezá a medir hoy. En 3 meses vas a tener suficiente para identificar patrones básicos. Mientras tanto, usá proxies: frecuencia de login, tickets de soporte, NPS.
Debería intentar retener a todos los clientes en riesgo
No. Algunos clientes no son rentables de retener. Validá: LTV restante, costo de retención, probabilidad de éxito. Si el CAC de retención supera el LTV restante, dejalo ir.
Cuál es la diferencia entre churn prediction y churn prevention
Prediction te dice quién está en riesgo. Prevention es lo que hacés al respecto. Las cohortes y señales son la predicción, el protocolo de intervención es la prevención. Pero la predicción sin acción es solo entretenimiento con datos.
Cómo manejo el churn involuntario
Dunning automation. Retry los pagos fallidos 3-4 veces con intervalos crecientes. Mandá emails claros explicando el problema. Ofrecé formas alternativas de pago.
El primer paso (no el sistema completo)
Un framework es tan útil como tu capacidad de ejecutarlo consistentemente.
Revisá los últimos 20 clientes que cancelaron. Buscá patrones en los 30 días previos. Qué features usaron (o dejaron de usar). Cuántas veces entraron. Si abrieron tickets. Si respondieron surveys. Ahí está tu punto de partida.
Tu primer paso concreto: abrí tu base de datos y corré el query de la sección 5. Si no podés hacer eso hoy, tu problema no es churn prediction. Es acceso a datos.
© 2026 Andres Ospina
