Casi todos los dueños de un negocio por suscripción tienen una teoría de por qué se les van los clientes. "Es el precio." "Es que se les cae la tarjeta." "Es que no usan la función nueva."
La mayoría de esas teorías resulta falsa cuando se mira bien. En el último caso que trabajé escribimos seis hipótesis y sobrevivieron dos.
Esta guía es el método que uso cuando una empresa me pide entender su churn. No es teoría: es el orden exacto en que hay que hacer las cosas para no llegar a una conclusión falsa.
Está escrita para quien sabe SQL o tiene a alguien que lo escriba. No vas a encontrar consultas listas para pegar —tu esquema no es el mío— sino los patrones y, sobre todo, las trampas donde este análisis se rompe en silencio.
Un aviso desde el principio: la mayoría de las hipótesis que tengas sobre tu churn van a resultar falsas. Eso no es un fracaso del análisis, es el análisis funcionando.
Paso 1 · Escribe tus hipótesis antes de mirar los datos
Suena a formalidad. No lo es.
Si abres la base de datos sin haber escrito qué esperas encontrar, vas a encontrar exactamente lo que ya creías. Los datos casi siempre tienen algún corte que confirma cualquier corazonada, y sin un registro previo no vas a poder distinguir un hallazgo de una casualidad que te gustó.
Escribe entre cuatro y ocho frases del tipo:
"Creo que perdemos clientes porque se les cae el cobro." "Creo que los que no usan la función X se van más." "Creo que el problema es el precio."
Guárdalas con fecha. Al final vas a marcar cada una como confirmada, descartada o reformulada, y ese documento vale más que cualquier gráfico: es lo que te va a evitar gastar tres meses arreglando el problema equivocado.
Paso 2 · Define "cliente" y "baja" una sola vez
Aquí se arruinan más análisis que en ningún otro paso, y de la peor manera: sin errores, sin avisos, con números que se ven perfectamente razonables.
Tres preguntas que tienes que responder por escrito:
¿Qué es un cliente? Casi siempre tu tabla de usuarios tiene registrados que nunca pagaron. Si tu base dice 2.000 usuarios y 500 pagan, cualquier tasa calculada sobre 2.000 está mal. Busca la columna que marca inequívocamente al cliente de pago —la fecha de creación en tu pasarela suele servir— y úsala en absolutamente todas las consultas.
¿Qué es una baja? Distingue la fecha en que el cliente pidió la baja de la fecha en que perdió el acceso. Pueden estar separadas por semanas. Si usas la segunda, tu análisis te va a avisar cuando ya no puedes hacer nada.
¿Cuándo empezaste a registrar? Si tu log de eventos arrancó hace un año pero tu negocio tiene tres, todos los clientes anteriores van a aparecer como "cero uso" y vas a concluir que la inactividad es letal. Es un artefacto, no un hallazgo.
Señal de alarma. Si el total de bajas cambia entre una consulta y otra —166, después 169, después 173— no lo dejes pasar. Significa que tienes dos definiciones conviviendo y las comparaciones que hagas van a ir descuadrándose de a poco hasta que ya no sepas cuál creer.
Paso 3 · Separa el churn involuntario del voluntario
Son dos fenómenos distintos con soluciones opuestas, y mezclarlos hace que ninguno se vea.
- Involuntario: se cayó el cobro, nadie actualizó la tarjeta, la suscripción murió sola. Se arregla con reintentos y avisos, no con ofertas.
- Voluntario: el cliente decidió irse. Se arregla con producto, precio o retención.
La regla operativa: si hubo un cobro exitoso después del último fallo, el cliente no murió por el pago. El patrón es este:
WITH ultimo_ok AS (
SELECT cliente_id, MAX(fecha) AS f FROM pagos
WHERE estado = 'aprobado' GROUP BY cliente_id
),
ultimo_fallo AS (
SELECT cliente_id, MAX(fecha) AS f FROM pagos
WHERE estado <> 'aprobado' GROUP BY cliente_id
)
SELECT
CASE
WHEN uf.f IS NULL THEN 'nunca falló'
WHEN uo.f IS NOT NULL AND uo.f >= uf.f THEN 'falló y se recuperó'
WHEN DATEDIFF(c.fecha_baja, uf.f) BETWEEN -5 AND 30 THEN 'INVOLUNTARIO'
ELSE 'voluntario'
END AS tipo,
COUNT(*) AS bajas
FROM clientes c
LEFT JOIN ultimo_ok uo ON uo.cliente_id = c.id
LEFT JOIN ultimo_fallo uf ON uf.cliente_id = c.id
WHERE c.fecha_baja IS NOT NULL
GROUP BY tipo;
Prepárate para que el resultado te desilusione. En el último caso que analicé, la expectativa era que el churn involuntario fuera 40% del total. Fue 15%. Y el 63% resultó ser gente con la tarjeta al día que simplemente dejó de necesitar el producto.
Un detalle importante al leer los códigos de rechazo: no todos son causas. Los códigos del tipo "excedió el límite de reintentos" son el certificado de defunción, no la enfermedad — vienen precedidos de otros rechazos. Contarlos como causa independiente es contar dos veces al mismo cliente.
Paso 4 · Arma un panel, no una tabla plana
Este es el paso que separa un análisis que sirve de uno que engaña, y el que casi nadie hace bien.
Lo que la mayoría hace: una fila por cliente, con una columna se_fue en 0 o 1.
Por qué está mal: te da un dataset diminuto, no responde cuándo se van, y sobre todo te empuja al error de la fecha de referencia.
El error de medir el pasado desde el futuro
Supón que quieres saber si la inactividad predice la baja. Calculas "días sin entrar" para cada cliente y lo cruzas con si se fue.
Para el que se fue, mides hasta su fecha de baja. Para el que sigue activo, mides hasta hoy. Y ahí se rompe todo: el que canceló usó el producto hasta poco antes de irse, así que aparece como activo. El que abandonó hace ocho meses pero nunca canceló aparece como silencioso y sano.
El resultado sale invertido: a más silencio, menos churn. Cuando un análisis te da algo imposible, casi siempre es esto.
La estructura correcta
Una fila por cada par (cliente, corte semanal). En cada corte:
- El universo son los clientes de pago que estaban vivos en esa fecha.
- Las variables se calculan usando solo información anterior al corte.
- El objetivo es si se dieron de baja en los N días siguientes.
WITH RECURSIVE cortes AS (
SELECT DATE('2025-11-01') AS corte
UNION ALL SELECT corte + INTERVAL 7 DAY FROM cortes WHERE corte < '2026-07-16'
),
base AS (
SELECT c.corte, u.id, u.fecha_baja
FROM cortes c
JOIN clientes u
ON u.fecha_alta IS NOT NULL
AND u.fecha_alta < c.corte -- ya existía
AND (u.fecha_baja IS NULL OR u.fecha_baja >= c.corte) -- seguía vivo
)
SELECT
b.corte, b.id,
-- toda feature con tope estricto: ... AND ev.fecha < b.corte
(b.fecha_baja IS NOT NULL
AND b.fecha_baja < b.corte + INTERVAL 30 DAY) AS churn_30d
FROM base b;
Las tres condiciones del JOIN son las que evitan el leakage. El tope < corte en cada subconsulta de features es lo que impide que el pasado vea el futuro.
Cómo dimensionar las ventanas. Necesitas historia hacia atrás para las variables y hacia adelante para el objetivo, y ambas te comen rango. Si tu log tiene 11 meses y usas 90 días de cada lado, te quedan 6 cortes mensuales: nada. Con 60 días atrás y 30 adelante, cortes semanales, te quedan más de 30 fotos por cliente. Un objetivo de 30 días es además más accionable: "se va este mes" te dice qué hacer, "se va este trimestre" no.
Lo que tienes que saber sobre tu tamaño de muestra. Si el panel te da 400 filas positivas, no tienes 400 eventos. Cada cliente que se va aparece marcado en las 4 semanas previas a su baja, así que tienes unos 90 eventos reales. Eso limita drásticamente cuántas variables puedes usar, y obliga a que el corte de entrenamiento y prueba sea por fecha, nunca aleatorio — o el mismo cliente queda en ambos lados.
Paso 5 · Mide lift, no porcentajes
Un dato suelto no significa nada. "El 32% de los que hacen X se van" es inútil hasta que sepas cuántos se van sin hacer X.
lift = tasa de churn en el segmento ÷ tasa base
Cómo interpretarlo, con los umbrales que uso:
| Lift | Lectura |
|---|---|
| Bajo 1,2× | Ruido. Descártalo. |
| 1,2× a 1,5× | Probablemente sesgo de antigüedad disfrazado de señal. |
| 1,5× a 2,5× | Señal real pero débil. Sirve combinada. |
| Sobre 2,5× | Accionable por sí sola. |
Sobre ese sesgo de antigüedad: quien lleva más tiempo tiene más transacciones, más chance de haber fallado alguna vez y más chance de haberse ido. Casi cualquier variable acumulativa va a mostrar 1,3× por esa razón sola. Si tu señal está en ese rango, probablemente no tengas nada.
Paso 6 · Haz un barrido univariado antes de modelar
Antes de entrenar nada, materializa el panel en una tabla y corre la misma consulta sobre cada variable candidata:
SELECT mi_variable,
COUNT(*) AS filas,
SUM(churn_30d) AS churn,
ROUND(100*SUM(churn_30d)/COUNT(*), 2) AS pct,
ROUND(SUM(churn_30d)/COUNT(*)/0.0387, 2) AS lift -- tu tasa base
FROM panel GROUP BY 1;
Diez minutos de esto te dicen si hay un modelo posible o no. Y a veces la respuesta es que no, lo cual también es un resultado: te ahorra dos meses.
Variables que vale la pena probar en un negocio por suscripción:
- Acciones que señalan el fin de la necesidad (cancelar un servicio, cerrar un proyecto, dar de baja un recurso dentro de tu producto)
- Uso de la función central, no el login genérico
- Días desde la última actividad, en tramos
- Tendencia: eventos de los últimos 15 días sobre los últimos 60
- Antigüedad, en tramos
- Tipo de plan, mensual contra anual
- Días hasta la próxima renovación
- Fallos de cobro recientes
Paso 7 · Busca interacciones, no solo variables
Este es el paso que más rendimiento da y el que casi todos se saltan.
En el último análisis, medidas por separado:
- Silencio de más de 14 días → 1,05×. Ruido.
- Cierta acción de fin de necesidad → 2,33×. Señal moderada.
- Las dos juntas → 4,09×.
El silencio aislado no significaba nada. Condicionado a que existiera un motivo para el silencio, casi duplicaba la señal. El silencio no significa nada hasta que hay una razón para el silencio.
Cruza tus dos o tres mejores variables en tablas de cuatro celdas. Es aritmética elemental y encuentra cosas que un modelo con veinte variables entierra.
Paso 8 · Distingue el momento de predecir del momento de actuar
Prepárate para un resultado incómodo: la señal suele ser más precisa después de que se cerró tu ventana de influencia.
En el caso que vengo citando, la predicción mejoraba mientras más tiempo pasaba desde el evento gatillante: 1,89× a los 14 días, 3,46× a los 45. Pero el cliente abandonaba el producto a los 17 días y solo formalizaba la baja a los 46. A los 45 días la predicción era excelente y ya no servía de nada: la persona hacía un mes que no entraba.
La causa de fondo es que estás prediciendo un evento administrativo —la cancelación, cuya fecha la define tu ciclo de facturación— con señales de comportamiento. Entre uno y otro hay semanas de desfase que ninguna variable puede anticipar.
La consecuencia práctica: usa umbrales distintos para cada cosa.
- Actuar temprano, con precisión baja, cuando la acción cuesta cero. Un mensaje dentro del producto en el momento del evento gatillante no necesita acertar: no molesta a nadie.
- Actuar tarde, con precisión alta, cuando la acción cuesta caro. Un contacto humano, una oferta o un descuento sí exigen estar bastante seguro.
Paso 9 · Deja un grupo de control
Tu análisis te dice quién tiene riesgo. No te dice quién es persuadible. Son cosas distintas: hay clientes que se van igual y clientes que se quedaban solos y a los que les acabas de regalar un descuento.
La única forma de saber la diferencia es no intervenir a todos. Durante dos o tres meses, contacta al 80% de tus alertas y deja el 20% sin tocar. Con eso mides el efecto real en vez de asumirlo.
Sin control vas a ver que "el 40% de los contactados se quedó" y no vas a tener idea de cuántos se habrían quedado igual. Ese número te va a llevar a escalar una campaña que quizá no hace nada.
Checklist de errores
Revisa cada punto antes de presentar resultados:
- El universo son clientes de pago, no usuarios registrados
- La fecha de baja es la de solicitud, no la de fin de acceso
- Sé desde cuándo tengo datos y excluí lo anterior
- Separé churn involuntario de voluntario
- Toda feature tiene tope estricto anterior al corte
- El total de bajas es el mismo en todas mis consultas
- Reporté lift, no solo porcentajes
- Sé cuántos eventos reales tengo, no cuántas filas
- El split de validación es temporal, no aleatorio
- Ningún resultado me salió al revés de lo esperable sin explicación
- Marqué cada hipótesis del paso 1 como confirmada, descartada o reformulada
Un resultado que tienes que estar dispuesto a aceptar
A veces la conclusión honesta es que tu churn no es predecible con los datos que tienes, y eso no es un defecto del análisis.
Si la mayoría de tus bajas son clientes que pagaban bien, usaban lo que tenían que usar, y un día dejaron de necesitar el producto por un hecho externo que tú no registras, entonces ninguna variable disponible va a anticipar ese momento.
La respuesta correcta ahí no es un modelo mejor. Son dos o tres reglas simples bien ejecutadas, y trabajo de producto para que exista más de una razón para volver.
Con menos de cien eventos de baja, además, una regresión logística con diez variables rinde prácticamente lo mismo que cualquier modelo sofisticado, con más interpretabilidad y sin riesgo de sobreajuste. Si alguien te propone gradient boosting con cuarenta features sobre noventa eventos, no te está ayudando.
Hasta dónde llega esta guía
Con estos nueve pasos puedes llegar a tener tu panel armado, tus hipótesis contrastadas y una o dos reglas accionables. Eso ya es más de lo que tiene la mayoría de las empresas de tu tamaño.
Hay cuatro cosas donde este método se topa con su límite y conviene mano experta:
Instrumentar lo que no estás registrando. Casi siempre la variable más valiosa no existe todavía en tu base. Decidir qué empezar a loguear —y hacerlo sin ensuciar lo que ya tienes— es un trabajo de diseño, no de consulta.
Diseñar el experimento. Un grupo de control mal armado es peor que ninguno, porque te da confianza en un número falso. El tamaño, la asignación y el criterio de corte tienen reglas.
Modelos de uplift. Pasar de "quién tiene riesgo" a "a quién le sirve que lo contacte" es otra disciplina, y requiere haber corrido el experimento antes.
Ponerlo en producción. Un análisis que corres una vez envejece en semanas. Convertirlo en alertas automáticas que llegan al canal correcto es donde el trabajo empieza a rendir de verdad — el mismo principio que aplico cuando convierto un reporte manual en reportes de ventas automáticos cada lunes o un P&L atrasado en un tablero de cash flow en tiempo real.
Preguntas frecuentes sobre analizar el churn
¿Necesito un data scientist para hacer esto? Para los pasos 1 al 7, no. Necesitas a alguien que escriba SQL con cuidado y que entienda las trampas de este artículo. Los pasos 8 y 9 —umbrales de acción y diseño del grupo de control— son donde la experiencia empieza a pesar de verdad.
¿Cuántos clientes necesito para que este análisis tenga sentido? Lo que importa no es cuántos clientes tienes, sino cuántas bajas reales hay en tu ventana de datos. Con menos de 50 eventos, quédate en los pasos 1 al 3 y en el barrido univariado: sirve para descartar hipótesis, no para construir un modelo.
¿Sirve esto si mi negocio no es SaaS? Sí, siempre que haya una relación recurrente con fecha de inicio y fecha de término: membresías, planes de servicio, contratos de mantenimiento, retainers. Cambia el vocabulario, no el método.
¿Puedo saltarme el panel y usar una tabla de una fila por cliente? Puedes, pero vas a obtener el resultado invertido que describo en el paso 4 y no lo vas a notar. Ese error no produce ningún mensaje de error: produce un número razonable y equivocado.
¿Y si mi conclusión es que no hay señal? Es un resultado válido y te ahorra meses. La respuesta ahí no es un modelo más sofisticado: es instrumentar lo que hoy no estás registrando y trabajar el producto para que exista más de una razón para volver.
¿Puedo automatizar esto para que corra solo? Sí, y es donde el trabajo empieza a rendir: el panel se recalcula cada semana y las alertas llegan al canal donde tu equipo ya trabaja. Antes de automatizarlo conviene haber validado que la señal existe — el mismo error que veo en pilotos de IA que nunca llegan a producción.
Si llegaste hasta acá, ya sabes que el problema no es la falta de datos: es el orden en que se miran. Si quieres que revisemos juntos qué te dicen los tuyos —o que armemos el panel y las alertas para que corran solos— escríbeme por WhatsApp. Sin costo, sin compromiso.
Esta guía se basa en un análisis real de una plataforma SaaS chilena. Las cifras citadas son de ese caso; las tuyas van a ser distintas, y ese es exactamente el punto.