La retención como el mejor proxy de valor real

Descripción

Ya sabes calcular una curva (lección 3), leer su meseta (lección 4), evitar el engaño del promedio (lección 5), y leer una tabla completa por fila y columna (lección 6). Falta una última pieza antes de que el módulo pueda cerrar: definir con precisión qué significa "retención en el día N" — porque, sorprendentemente, esa frase tan común tiene al menos dos definiciones distintas y no intercambiables, y usarlas sin aclarar cuál da números que ni siquiera hablan del mismo fenómeno.

Con esa definición ya precisa, esta lección cierra el módulo con el argumento central: de todas las métricas que un equipo de producto puede medir, la retención es, probablemente, la que mejor aproxima el valor real que un producto entrega. Una tasa de conversión alta te dice que alguien completó una acción hoy; una retención alta te dice algo mucho más difícil de fingir: que esa misma persona, después de haber probado el producto y de tener todas las razones del mundo para no volver, decidió volver de todos modos.

Conexión con el módulo. Esta lección cierra el arco conceptual completo del módulo — cohorte (lección 2), curva (lección 3), meseta (lección 4), por qué el agregado engaña (lección 5), tabla completa (lección 6) — con la pregunta de fondo que justifica haber invertido seis lecciones en esto: ¿por qué importa tanto? El mini-proyecto de la lección 8 aplica todo el marco sobre datos reales de Mercado.

Una analogía: la cita exacta contra la cita abierta

Imagina que le pides a un amigo: "avísame el día 7". Esa frase, sin más contexto, admite dos lecturas completamente distintas. Puede significar "avísame exactamente el día 7, ni un día antes ni un día después" —una cita puntual, y si te avisa el día 9, técnicamente no cumplió—. O puede significar "avísame en algún momento a partir del día 7 en adelante" —una ventana abierta, y si te avisa el día 9, cumplió perfectamente bien—. Las dos interpretaciones son razonables, las dos usan las mismas palabras ("avísame el día 7"), y sin embargo describen compromisos completamente distintos: uno es mucho más fácil de cumplir que el otro.

"Retención D7" tiene exactamente ese mismo problema de ambigüedad. Puede significar "el usuario volvió exactamente el día 7 después de entrar" —la cita puntual—, o puede significar "el usuario volvió el día 7 o en cualquier día posterior" —la ventana abierta—. Un equipo que reporta "D7 = 50%" usando la primera definición y otro equipo que reporta "D7 = 80%" usando la segunda podrían estar describiendo, en realidad, exactamente la misma cohorte con exactamente el mismo comportamiento — la diferencia está solo en qué pregunta se hizo, no en qué tan bien retiene el producto.

Ejemplo trabajado: el mismo dato crudo, dos definiciones de D7

El registro de actividad de 10 usuarios de la cohorte del 6 de julio, con los días exactos (desde su entrada, día 0) en los que cada uno abrió Mercado. Vamos a calcular la retención D7 de dos formas distintas sobre exactamente el mismo dato:

// El registro crudo de actividad de 10 usuarios de la cohorte del 6 de julio:
// cada arreglo son los DIAS (desde su entrada, dia 0) en los que ese usuario abrio
// la app. Observamos hasta el dia 21.
const users = [
  { id: 'u01', activeDays: [0, 1, 2, 3, 7, 15] },
  { id: 'u02', activeDays: [0, 1, 9, 10] },
  { id: 'u03', activeDays: [0, 5, 6, 7] },
  { id: 'u04', activeDays: [0] },
  { id: 'u05', activeDays: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10] },
  { id: 'u06', activeDays: [0, 3, 12] },
  { id: 'u07', activeDays: [0, 1, 7, 14, 21] },
  { id: 'u08', activeDays: [0, 2, 4, 6, 8, 10, 12] },
  { id: 'u09', activeDays: [0] },
  { id: 'u10', activeDays: [0, 7] },
];

// D7 EXACTO: activo justo el dia 7, ni antes ni despues.
function exactDayRetention(users, day) {
  const returned = users.filter((u) => u.activeDays.includes(day));
  return { returned: returned.map((u) => u.id), rate: (returned.length / users.length) * 100 };
}

// D7 UNBOUNDED ("on or after"): activo el dia 7 o CUALQUIER dia despues, sin techo.
function unboundedRetention(users, day) {
  const returned = users.filter((u) => u.activeDays.some((d) => d >= day));
  return { returned: returned.map((u) => u.id), rate: (returned.length / users.length) * 100 };
}

console.log('=== D7 exacto vs D7 unbounded, mismo dato crudo ===\n');
const exact = exactDayRetention(users, 7);
const unbounded = unboundedRetention(users, 7);

console.log('D7 EXACTO (activo justo el dia 7):');
console.log('  usuarios: ' + exact.returned.join(', '));
console.log('  D7 exacto = ' + exact.returned.length + '/10 = ' + exact.rate.toFixed(1) + '%\n');

console.log('D7 UNBOUNDED (activo el dia 7 o despues, sin limite):');
console.log('  usuarios: ' + unbounded.returned.join(', '));
console.log('  D7 unbounded = ' + unbounded.returned.length + '/10 = ' + unbounded.rate.toFixed(1) + '%\n');

console.log('Mismo dato crudo, misma cohorte, mismo "D7" en el nombre -- dos numeros');
console.log('distintos segun la definicion. Reportar "D7 = ' + exact.rate.toFixed(0) +
  '%" sin decir cual de las dos se uso deja al lector adivinando.');

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== D7 exacto vs D7 unbounded, mismo dato crudo ===

D7 EXACTO (activo justo el dia 7):
  usuarios: u01, u03, u05, u07, u10
  D7 exacto = 5/10 = 50.0%

D7 UNBOUNDED (activo el dia 7 o despues, sin limite):
  usuarios: u01, u02, u03, u05, u06, u07, u08, u10
  D7 unbounded = 8/10 = 80.0%

Mismo dato crudo, misma cohorte, mismo "D7" en el nombre -- dos numeros
distintos segun la definicion. Reportar "D7 = 50%" sin decir cual de las dos se uso deja al lector adivinando.

Una diferencia de 30 puntos porcentuales —50% contra 80%— sobre exactamente los mismos 10 usuarios, sin que ninguno de los dos números esté "mal calculado". u02 (activo los días 0, 1, 9, 10) nunca abrió la app justo el día 7, así que no cuenta para el D7 exacto — pero sí volvió después (los días 9 y 10), así que sí cuenta para el D7 unbounded. Lo mismo pasa con u06 y u08. La documentación de Mixpanel, de hecho, prefiere la definición "unbounded" (a la que llama "On or After") como opción por defecto, precisamente porque —como dice su propia documentación— "la mayoría de los productos no exigen que el usuario vuelva en cada unidad de tiempo exacta" para haber recibido valor real. Ninguna de las dos definiciones es "la correcta" en abstracto; lo que es un error real es no decir cuál se está usando.

Por qué la retención es el mejor proxy de valor real

Con la definición ya precisa, cierra la pregunta de fondo: ¿por qué darle a la retención tanto peso, comparado con conversión o con cualquier otra métrica del embudo? La razón tiene que ver con qué tan difícil es fingir cada una.

Una tasa de conversión alta puede lograrse con trucos que no reflejan valor real: un descuento agresivo de primera compra, un diseño que empuja al usuario hacia el checkout, una oferta de tiempo limitado que genera urgencia artificial. Todos esos trucos pueden subir checkoutConversionRate sin que el producto haya mejorado en absoluto. La retención es mucho más difícil de fingir de la misma forma: para que alguien vuelva la semana que viene, sin ningún descuento ni urgencia empujándolo, tiene que haber recibido algo de valor real la primera vez — encontró lo que buscaba, confió en el proceso, o simplemente le resultó útil. Casey Winters y Lenny Rachitsky, después de sintetizar el criterio de 20 expertos de crecimiento de distintas industrias, llegaron a benchmarks concretos de qué cuenta como "buena" y "excelente" retención según el tipo de negocio — la evidencia de que la industria entera trata la retención, no la conversión, como la vara con la que se mide si un producto de verdad funciona.

Esto no significa que la retención sea inmune a manipulación — un aluvión de notificaciones push puede subir el número sin que el usuario reciba más valor real, exactamente el tipo de "optimizar la métrica en vez del negocio" que el módulo 4 desarrolla con los guardrails—. Pero, comparada con una tasa de conversión de una sola sesión, la retención exige que el valor se sostenga en el tiempo, y eso la vuelve, en la inmensa mayoría de los casos, la señal más honesta que un equipo de producto tiene disponible.

Errores comunes

Retención N-day mal definida: ¿exactamente el día N, o hasta el día N? Qué pasa: dos reportes citan "D7 = X%" con números distintos para la misma cohorte, y nadie en la sala puede explicar por qué no coinciden. Por qué pasa: la frase "retención D7" suena autoexplicativa, y rara vez alguien se detiene a preguntar cuál de las dos definiciones —exacta o unbounded— se usó para calcularla. Cómo detectarlo: exactamente el escenario del ejemplo de hoy — el mismo dato crudo produce 50% con una definición y 80% con la otra, y ambos números "suenan" razonables por separado. Cómo corregirlo: siempre declara la definición exacta junto al número —"D7 unbounded: 80%"—, nunca solo "D7: 80%". Es la misma disciplina que exige el DISEÑO de esta guía para cualquier aproximación estadística: nombra el método, no solo el resultado.

Usar D1 como la métrica principal de salud cuando el producto tiene un ciclo semanal o mensual. Qué pasa: un equipo de Mercado —donde comprar es, típicamente, un evento semanal o incluso mensual, no diario— obsesiona sobre la retención D1 (¿volvió al día siguiente?), un horizonte de tiempo que tiene sentido para una app de mensajería o redes sociales, pero no para un marketplace de compras ocasionales. Por qué pasa: D1 es el número que más rápido se puede medir —solo hace falta esperar un día—, y esa velocidad lo vuelve tentador como métrica principal, aunque no encaje con el ciclo real de uso del producto. Cómo detectarlo: la ventana de retención que se reporta como "la" métrica de salud no coincide con la frecuencia natural con la que un usuario típico usaría el producto. Cómo corregirlo: elige la ventana de retención (D1, D7, D30) según el ciclo natural del producto — para Mercado, algo como D30 o incluso D90 tiene mucho más sentido que D1, porque nadie compra en un marketplace todos los días.

Tratar la retención como un fin en sí mismo, sin conectarla con el valor real. Qué pasa: un equipo optimiza agresivamente por subir el número de retención —más notificaciones, más recordatorios, más ganchos de re-engagement— sin preguntarse si esas tácticas están generando valor real o solo interrumpiendo al usuario hasta que abre la app una vez más. Por qué pasa: la retención, como cualquier métrica, se puede "gamear" (inflar artificialmente) si se optimiza sin cuidado, exactamente el mismo riesgo que corre cualquier métrica de este módulo. Cómo detectarlo: la retención sube, pero otras señales —quejas, desinstalaciones, tiempo real usando el producto una vez abierto— empeoran al mismo tiempo. Cómo corregirlo: recuerda por qué la retención importa —es difícil de fingir cuando nace de valor real—, y vigila que las tácticas para mejorarla no la vuelvan, ellas mismas, una métrica fácil de fingir. El módulo 4 formaliza esta protección con los guardrails.

Ejercicios

Ejercicio 1 — Calcula D14 con ambas definiciones. Usando los mismos 10 usuarios del ejemplo de hoy, calcula a mano la retención D14 exacta (activo justo el día 14) y D14 unbounded (activo el día 14 o después).

Ver solución

D14 exacto: solo u07 tiene el día 14 exacto en su lista ([0, 1, 7, 14, 21]) — 1/10 = 10.0%. D14 unbounded: usuarios con algún día ≥ 14 son u07 (14, 21) — solo uno, porque revisando el resto: u01 llega hasta el día 15 (que es ≥ 14) así que también cuenta. Los activeDays de cada usuario: u01 hasta 15 (cuenta), u02 hasta 10 (no), u03 hasta 7 (no), u04 hasta 0 (no), u05 hasta 10 (no), u06 hasta 12 (no), u07 hasta 21 (cuenta), u08 hasta 12 (no), u09 hasta 0 (no), u10 hasta 7 (no). D14 unbounded = 2/10 = 20.0%. La brecha entre ambas definiciones (10% vs 20%) se mantiene, aunque más chica que en D7, porque a los 14 días quedan menos usuarios activos en general.

Ejercicio 2 — Elige la ventana correcta. Para cada producto, decide si D1, D7 o D30 es la ventana de retención más sensata como métrica principal, y justifica en una frase: (a) una app de meditación diaria, (b) Mercado (marketplace de compras ocasionales), (c) un software de declaración de impuestos anual.

Ver solución

(a) D1 (o incluso D-diaria continua) — una app de meditación diaria espera uso todos los días; si alguien no vuelve al día siguiente, ya es una señal de alerta temprana. (b) D30 — Mercado es un marketplace de compras ocasionales, no algo que se use a diario; medir D1 penalizaría injustamente a usuarios perfectamente sanos que simplemente no necesitan comprar todos los días. (c) Ninguna de las tres tiene sentido como métrica principal — un software de declaración de impuestos anual tiene un ciclo de uso de doce meses; D30 seguiría siendo demasiado corto, y la métrica de retención relevante sería algo como "D365" o, más precisamente, "¿volvió la próxima temporada de impuestos?". El principio general: la ventana de retención debe reflejar el ciclo natural de uso del producto, no un número estándar de la industria.

Ejercicio 3 — Defiende la retención frente a un escéptico. Un colega dice: "prefiero optimizar por conversión — es más fácil de medir, y sube más rápido con menos esfuerzo que la retención". En 3-4 frases, con el argumento de esta lección, explica por qué eso puede ser una trampa a mediano plazo.

Ver solución

Una respuesta razonable: "Es cierto que la conversión sube más rápido y con menos esfuerzo —un descuento agresivo o un diseño más insistente pueden mover ese número en una semana—, pero esa misma facilidad es la señal de alarma: si es fácil de mover con trucos que no cambian el producto, no está midiendo si el producto genera valor real. La retención es más lenta y más difícil de mover precisamente porque exige que el usuario, sin ningún incentivo artificial empujándolo, decida volver por su cuenta. Optimizar solo por conversión puede producir un negocio que atrae mucha gente una vez y la pierde para siempre —el balde con fugas de la lección 4—, mientras que una mejora real de retención construye una base de usuarios que se sostiene sin necesitar reinversión constante en adquisición."

Resumen y siguiente paso

En esta lección precisaste una fuente de confusión que parecía trivial y no lo era: "retención D7" puede significar "exactamente el día 7" o "el día 7 o después", y ambas definiciones, sobre el mismo dato de Mercado, dieron 50% y 80% respectivamente. Con esa precisión resuelta, cerraste el argumento central del módulo: la retención es difícil de fingir con trucos de una sola sesión, y por eso es, de todas las métricas de este módulo, la que mejor aproxima el valor real que Mercado entrega — con el cuidado de no convertirla, ella misma, en una métrica fácil de gamear.

Antes de avanzar deberías poder: distinguir la retención N-day exacta de la unbounded y calcular ambas sobre un dato crudo, elegir la ventana de retención correcta según el ciclo de uso de un producto, y explicar por qué la retención es más difícil de fingir que la conversión.

Con las seis lecciones de contenido completas, la lección 8 —el mini-proyecto— te pone frente a la tabla de cohortes real del lanzamiento de recommendations en Mercado: vas a calcular la curva, encontrar la meseta, y comparar de forma descriptiva la cohorte que vio recomendaciones contra la que no.

Recursos

• Casey Winters y Lenny Rachitsky, "What Is Good Retention: An Exhaustive Benchmark Study" — lennysnewsletter.com/p/what-is-good-retention-issue-29. La síntesis de 20 expertos de crecimiento en benchmarks concretos de "buena" y "excelente" retención según el tipo de negocio — la evidencia detrás del argumento central de esta lección. En inglés.
• Andrew Chen, "The Power User Curve" — andrewchen.com/power-user-curve. Extiende la idea de retención como valor real hacia los usuarios más comprometidos: la forma de "sonrisa" que distingue a un producto con un núcleo sólido de usuarios genuinamente enganchados. En inglés.
• Mixpanel, "Retention: Measure engagement over time" (documentación oficial) — docs.mixpanel.com/docs/reports/retention. La fuente técnica de la distinción "On" (exacto) vs. "On or After" (unbounded) que esta lección desarrolla con el ejemplo de Mercado. En inglés.