¡La era primaveral ha comenzado 😎

Es hora de actualizar el diseño con tonos cálidos que reconforten el alma. He reunido un nuevo diseño para que cada publicación irradie energía primaveral 🔥

Bueno, ahora pasemos a las preguntas sobre productos 👇

Te dan dos tablas: users y events. Y 20 minutos para la tarea:
«Calcula, querido, el retention por cohortes M0–M3»

Y aquí es donde se quedan atascados.
¿Por dónde empezar siquiera? 🤔

Lo más fácil no es con SQL, sino con una imagen mental. Imagina un gimnasio.
100 personas compraron un abono: esa es tu cohorte.
Normalmente, esa cohorte se toma como el 100%. Eso es M0.
Pero hay un matiz: no es una ley de la naturaleza, sino un acuerdo tácito.
Al día siguiente vinieron 60 personas: Día 1 = 60%.
A la semana vinieron 40: Día 7 = 40%.

La lógica no cambia.
Solo que en lugar de días, son meses.
Y en lugar de un gimnasio, es un producto.

1️⃣ Nivel junior: entender cuántas personas llegaron a cada cohorte
SELECT
  DATE_TRUNC('month', registration_date) AS cohort_month,
  COUNT(DISTINCT user_id) AS new_users
FROM users
GROUP BY 1
ORDER BY 1;

Si ya hay un error aquí, todo está perdido. Porque DATE_TRUNC y DISTINCT son la base del bloque de producto.
Al menos para PostgreSQL y dialectos similares.

2️⃣ Siguiente nivel: entender quién regresó
WITH cohort_dec AS (
  SELECT user_id, registration_date
  FROM users
  WHERE registration_date >= '2023-12-01'
    AND registration_date < '2024-01-01'
)
SELECT
  COUNT(*) AS cohort_size,
  COUNT(DISTINCT CASE WHEN event_date = registration_date + 1 THEN user_id END) AS day1,
  COUNT(DISTINCT CASE WHEN event_date = registration_date + 7 THEN user_id END) AS day7
FROM cohort_dec u
LEFT JOIN events e ON u.user_id = e.user_id;

Aquí hay trampas 🤔

Ese código es normal si tus fechas se almacenan como DATE, sin hora.
Pero si son TIMESTAMP, una simple igualdad puede romper el cálculo.
Porque un evento puede ser a las 2023-12-08 00:01 y otro a las 2023-12-08 19:42, y formalmente ya no son el mismo valor.

Por lo tanto, hay que convertir a fecha o calcular mediante rangos.
La lógica siempre es la misma:
✅ fijar la cohorte → ver quién regresó

Para M1, M2, M3 es casi lo mismo, pero hay un punto clave:
👉 no se comparan fechas simples, sino el desplazamiento en meses calendario respecto al mes de registro (suena complicado, ahora lo explico)

Es decir, no +30 días. Los meses tienen diferente duración, por lo que ese cálculo se desvía.
Para el retention mensual se mira el desplazamiento en meses calendario, no simplemente sumar 30 días.

❌ Otras trampas comunes

1️⃣ Cuentan eventos en lugar de personas
Un usuario hizo 5 eventos.
Y de repente tu retention supera el 100%.
Eso significa que no estás contando el regreso de personas, sino la actividad.

2️⃣ Usan INNER JOIN
Y en la selección solo quedan los que regresaron.
Los que se fueron simplemente desaparecen.
Obtienes una cifra bonita. Y una imagen completamente falsa.

3️⃣ No fijan la base de cálculo
El tamaño de la cohorte normalmente se toma como 100%, y a partir de ahí se calcula todo.
Si la base varía, los porcentajes se convierten en basura.

Y luego comienza el verdadero problema... la prueba de pensamiento y habilidades blandas. Ahí está el camino más espinoso si tienes poca experiencia.
Porque en la entrevista no te preguntarán:
«¿Cómo calcular el retention?»

Sino que preguntarán:
«D30 cayó. ¿Por qué?»

Llegamos... Y aquí el SQL ya no impresiona a nadie.

✅ Una línea de pensamiento normal sería:
- desglosar el retention por cohortes
- observar los canales de adquisición
- verificar la activación
- entender si el onboarding se rompió
- comparar el comportamiento antes y después de los lanzamientos
Se puede profundizar más, pero para empezar estas bases son suficientes.

❌ Respuesta que arruinará tu diálogo de inmediato
«Bueno… el retention bajó porque los usuarios empezaron a regresar menos…»

Gracias, señor Capitán. Pero eso no es una respuesta de analista, sino una suposición.

En palabras simples:
El retention no se trata de SQL, se trata de comportamiento.
SQL es solo una pala con la que cavas para obtener el número.

Si no puedes explicar por qué la gente dejó de regresar,
entonces tus porcentajes por sí solos no dicen nada 🤷‍♀️

¿Han tenido problemas en el bloque de producto? ¿Les gusta el área de producto o prefieren más la parte de ingeniería? 👇