lección 4
Día 3 - Cohortes de retención y la paradoja de Simpson
Calculas cohortes reales por primera vez, descubres que los números agregados mienten, y preparas el briefing para Lucia y Pablo.
⏱ 55 min
### Jueves, 9:00 AM - El día de las cohortes
Hoy es jueves. El viernes es la demo. Tienes 1 día para construir la tabla de cohortes que Pablo y Lucía necesitan para el board review del lunes. No es un ejercicio académico: este número va a ir en un deck que ve el consejo de administración de TaskFlow. Si está mal, la credibilidad del equipo de datos se va al suelo.
Pero estás tranquilo. Tienes el pipeline funcionando (1.7M eventos cargados), la definición de usuario activo alineada con Sandra y Lucía, y los duplicados controlados. Las piezas están en su sitio. Hoy "solo" tienes que escribir la query correcta, validarla y presentar los resultados. Fácil en teoría. La realidad: vas a descubrir que los números cuentan una historia que nadie esperaba.
1#data-team | Jueves 9:10 AM23Pablo Herrera 9:10 AM4?? Standup jueves - sprint final5- Sandra: listos los modelos de activacion? Los necesita el nuevo6- Marcos: pipeline billing mergeado! ??7- Nuevo: HOY cohortes. Si necesitas algo de nosotros avisa8 temprano. No quiero sorpresas mañana.910Deadline recordatorio: demo viernes 16:00. Lucia estará.1112Sandra Vidal 9:12 AM13Mi modelo int_user_first_activity está listo ??14Lo puedes usar como base para las cohortes: tiene user_id,15signup_date, first_core_event_date, y first_event_type.16Esta en el schema analytics_int.1718Tu 9:14 AM19Perfecto Sandra! Lo uso como base. Objetivo de hoy:201. Query de cohortes semanales con retención W1-W12212. Validar números con Sandra223. Preparar visualización para la demo2324Pablo Herrera 9:15 AM25?? Me gusta ese plan. Avisame cuando tengas los primeros26números -- quiero verlos antes de que se los ensenes a Lucia.2728 ? 2
### 9:30 AM - Que es una cohorte de retención (la teoria)
Antes de escribir una sola línea de SQL, necesitas entender bien el concepto. No para ti -- ya sabes qué son las cohortes desde la formación. Sino para poder EXPLICARSELO a Lucía y Andrés en la demo. Si no puedes explicar un concepto de forma simple a alguien no técnico, probablemente no lo entiendes tan bien como crees.
Una cohorte es un grupo de usuarios que comparten una característica temporal: se registraron la misma semana (o mes, o día). La retención de una cohorte mide qué porcentaje de ese grupo sigue activo después de N períodos. Es la métrica MAS importante en SaaS porque te dice la "salud" de cada generación de usuarios por separado.
Por qué es mejor que un simple MAU? Porque el MAU agrega todo: mezcla usuarios nuevos (que siempre están activos la primera semana) con usuarios viejos (que ya decidieron quedarse). Si tu MAU sube puede ser porque captas muchos nuevos, no porque los retengas. La cohorte te dice la verdad: "de los que llegaron la semana 8, cuántos siguen aquí en la semana 12?" Esa pregunta específica es la que el CEO necesita para tomar decisiones.
### 10:00 AM - La query de cohortes
Ahora viene la parte técnica. Necesitas construir una query que: (1) agrupe usuarios por semana de signup, (2) para cada usuario determine si estuvo activo en cada semana posterior, y (3) calcule el porcentaje. Usas el modelo de Sandra int_user_first_activity como punto de partida para las fechas de signup.
1-- Cohortes de retención semanal2-- Cada fila = cohorte (semana de signup)3-- Cada columna = semanas_desde_signup (0, 1, 2, 4, 8, 12)4-- Valor = % de usuarios de esa cohorte que fueron core_active esa semana56WITH user_cohorts AS (7 -- Asignar cada usuario a su cohorte (semana de signup)8 SELECT9 user_id,10 DATE_TRUNC('week', signup_date) AS cohort_week,11 signup_date12 FROM analytics_int.int_user_first_activity13),1415user_weekly_activity AS (16 -- Para cada usuario, en que semanas fue core_active?17 SELECT18 e.user_id,19 DATE_TRUNC('week', e.event_timestamp) AS activity_week20 FROM staging.stg_product_events e21 WHERE e.event_category = 'core'22 GROUP BY e.user_id, DATE_TRUNC('week', e.event_timestamp)23),2425cohort_retention AS (26 SELECT27 uc.cohort_week,28 DATEDIFF('week', uc.cohort_week, uwa.activity_week) AS weeks_since_signup,29 COUNT(DISTINCT uc.user_id) AS active_users30 FROM user_cohorts uc31 INNER JOIN user_weekly_activity uwa32 ON uc.user_id = uwa.user_id33 AND uwa.activity_week >= uc.cohort_week34 GROUP BY uc.cohort_week, DATEDIFF('week', uc.cohort_week, uwa.activity_week)35),3637cohort_sizes AS (38 SELECT39 cohort_week,40 COUNT(DISTINCT user_id) AS cohort_size41 FROM user_cohorts42 GROUP BY cohort_week43)4445SELECT46 cr.cohort_week,47 cs.cohort_size,48 cr.weeks_since_signup,49 cr.active_users,50 ROUND(cr.active_users * 100.0 / cs.cohort_size, 1) AS retention_pct51FROM cohort_retention cr52JOIN cohort_sizes cs ON cr.cohort_week = cs.cohort_week53WHERE cr.weeks_since_signup IN (0, 1, 2, 4, 8, 12)54ORDER BY cr.cohort_week, cr.weeks_since_signup;
La query de cohortes: CTEs para claridad, JOIN para retener solo activos
Consejo de senior: está query usa 4 CTEs porque la claridad es más importante que la performance en análisis exploratorio. Cada CTE tiene una responsabilidad única: asignar cohortes, calcular actividad semanal, cruzar ambas y calcular tamaños. Si necesitas optimizar más adelante, materializa los CTEs como tablas intermedias en dbt.
### 11:30 AM - Los resultados y la paradoja de Simpson
Ejecutas la query y los números confirman el miedo de Pablo: la retención W1 (una semana después del signup) ha caido del 72% al 61% entre enero y marzo. Pero cuando segmentas por plan, descubres algo inesperado:
1Resultados segmentados por plan:23Plan FREE:4- Cohorte Ene: W1 = 65%, W4 = 38%, W8 = 25%5- Cohorte Mar: W1 = 58%, W4 = 30%, W8 = -67Plan PRO:8- Cohorte Ene: W1 = 82%, W4 = 68%, W8 = 55%9- Cohorte Mar: W1 = 80%, W4 = 65%, W8 = -1011Plan BUSINESS:12- Cohorte Ene: W1 = 91%, W4 = 82%, W8 = 76%13- Cohorte Mar: W1 = 89%, W4 = 80%, W8 = -1415DESCUBRIMIENTO:16La retención de cada plan individual casi NO ha cambiado.17Free bajo 7pp, Pro bajo 2pp, Business bajo 2pp.18Pero el AGREGADO bajo 11pp (de 72% a 61%).1920Por que? Porque la PROPORCION de usuarios free aumento.21En enero el 40% de signups eran free. En marzo el 65%.22Es la PARADOJA DE SIMPSON.
Esto es la paradoja de Simpson en acción: una tendencia que aparece en los datos agregados DESAPARECE o se invierte cuando segmentas por grupo. La retención "cayó" no porque el producto empeore sino porque MARKETING está trayendo más usuarios free (que naturalmente retienen menos). Es un insight crítico para Lucía.
Error clásico: reportar el número agregado sin segmentar y concluir "el producto está empeorando". Si llevas ese número al board sin contexto, el CEO puede tomar decisiones equivocadas (invertir en mejorar producto cuando el problema real es el mix de captación). SIEMPRE segmenta antes de concluir.
### 14:00 PM - Validacion con Sandra
La validación con un analytics engineer no es "mira si está bien". Es un PEER REVIEW analítico: Sandra va a cuestionar tus supuestos, buscar inconsistencias y comparar con datos que ella ya conoce. Si tus números no cuadran con los suyos, hay un problema que necesitáis encontrar juntos.
1Sandra Vidal (call, 14:00):23"A ver, enseneme esos números... Ajam. OK, la query está bien.4Pero tengo una pregunta: en la cohorte de enero, el tamaño5es 842 usuarios. Pero en dim_users tengo 891 signups esa6semana. De donde sale la diferencia?"78Tu: "Mi tabla solo tiene usuarios que hicieron al menos 19evento core. Los 49 que faltan se registraron pero nunca10hicieron nada -- ni crearon una tarea."1112Sandra: "Eso es correcto para el cálculo de retención. Pero13necesitamos documentar que la cohorte se define como14'usuarios que tuvieron al menos 1 evento core en su W0'.15Si no, alguien va a comparar con el dato de signups totales16y no va a cuadrar."1718Tu: "Hecho. Lo documento en el Notion."1920Sandra: "Bien. Siguiente pregunta: los usuarios que cambiaron21de plan durante el período... los pones en el plan actual o22en el plan que tenian en el momento del signup?"2324Tu: "Plan actual (dim_workspaces). Lo documente como25'plan a fecha de consulta, no plan histórico'."2627Sandra: "Correcto para un primer corte. Pero ojo: cuando28un usuario cambia de free a pro, su retención SUBE porque29ya está engaged. Si los pones en Pro retrospectivamente,30inflas la retención de Pro. Para la demo de mañana está31bien, pero el modelo definitivo necesita plan-at-signup.32Lo anoto como mejora."3334Tu: "Entendido. Lo resolvemos con la tabla de historial35de planes la semana que viene?"3637Sandra: "Exacto. Y lo de Simpson... buenisimo hallazgo.38Pablo va a flipar. Preparalo bien para la demo porque eso39cambia la narrativa completamente ??"
Esa segunda pregunta de Sandra sobre el plan histórico es un ejemplo perfecto de por qué la validación importa. Tú no habrías pensado en eso. Pero Sandra, con su experiencia en Cabify (donde los conductores cambiaban de categoría constantemente), sabe que los atributos que cambian en el tiempo distorsionan los análisis si los usas retrospectivamente. Eso es el valor de un peer review analítico.
### 15:30 PM - Lucía reacciona a los números
1Lucia Fernandez 15:32 PM2Ey, Pablo me ha adelantado los números de cohortes ??3Tengo unas preguntas:451. El 61% de W1... es solo free o incluye todos?62. Si los Pro retienen al 80%... por que no convertimos7 más gente a Pro? Que hacen diferente?83. Puedes calcular CUANDO churnan los free? Es en la9 primera semana o después?1011Sorry por el bombardeo pero esto es oro para el board ??1213Tu 15:45 PM14Hola Lucia! Te respondo:151. El 61% es el agregado (todos los planes mezclados).16 Free solo es 58%, Pro es 80%, Business es 89%.172. Esa es LA pregunta. Manana en la demo te presento18 un análisis de features: que hacen los Pro que no19 hacen los Free en su primera semana.203. Puedo calcular eso! Spoiler: la mayoria del churn21 free pasa entre día 3 y día 7. Si sobreviven la22 primera semana, la retención mejora mucho.2324Lucia Fernandez 15:47 PM25Ey esto es EXACTAMENTE lo que necesito26Lo del día 3-7 es super actionable. Si sabemos que27features usan antes de irse podemos hacer algo28Eres un crack ????2930 ?? 1 ?? 1
### 16:00 PM - Pablo válida el approach
1Pablo Herrera 16:05 PM (DM)2He visto tu conversacion con Lucia. Los hallazgos son3excelentes. ??45Dos cosas:61. Para la demo de mañana, empieza con Simpson. Es lo más7 impactante y va a captar la atención de Andres.82. El "aha moment" (automation_created) -- quiero que9 tengas cuidado con como lo comunicas. Di "correlaciona10 con" no "causa". Sandra va a preguntar exactamente eso.1112Buen trabajó está semana. Manana se lo demuestras a todos.1314Tu 16:10 PM15Gracias Pablo! Entendido -- correlación, no causalidad.16Tengo preparada una propuesta de A/B test por si preguntan17"y entonces que hacemos con esto?"1819Pablo Herrera 16:12 PM20?? Excelente. Eso es pensar un pasó adelante. Me gusta.
Fíjate: Pablo te está coaching sin que te des cuenta. "Di correlaciona con, no causa" es un consejo de comunicación que te va a salvar mañana cuando Sandra haga la pregunta incómoda. Y su "me gusta" cuando dices que tienes el A/B test preparado es un refuerzo positivo de tu proactividad. Los buenos managers no te dicen qué hacer -- te ayudan a ser mejor en lo que ya estás haciendo.
Consejo de senior: cuando presentes datos a producto, siempre piensa: "qué ACCION puede tomar alguien con este número?" Si la respuesta es "ninguna", el dato no es útil todavía. Necesitas segmentar más, contextualizar más, o encontrar la variable que explica la diferencia. Lucía te está enseñando esto en tiempo real.
## ejercicios
Query de cohortes de retención semanal
Escribe la query SQL que calcula la retención por cohorte semanal. Cada cohorte es un grupo de usuarios por semana de signup. Calcula el porcentaje activo en W0, W1, W2, W4.
Detectar la paradoja de Simpson
Calcula la retención W1 agregada y segmentada por plan. Demuestra que la caida agregada se debe al cambio en el mix de planes, no a una caida real por plan.
Analizar el timing del churn
Lucia quiere saber CUANDO churnan los usuarios free: en que día después del signup dejan de usar el producto. Calcula el "último día activo" de los usuarios free churned.
Escribir el resumen ejecutivo para Pablo
Pablo te pide un resumen de 1 parrafo con los hallazgos clave de las cohortes. Debe ser claro para alguien no técnico, incluir números concretos y sugerir siguiente pasó.
Regístrate para guardar tu progreso.
## comentarios
Reporta erratas, ayuda a otros o comparte tu opinión. Sé constructivo.
Inicia sesión para comentar y responder.
cargando comentarios...