Métricas accionables frente a métricas de vanidad: cómo saber si el motor de crecimiento elegido está funcionando de verdad
En la lección 9 elegiste qué motor de crecimiento aplica a tu producto (pegajoso, viral o pagado) antes de invertir en canales de adquisición.
Qué vas a aprender hoy
En la lección 9 elegiste qué motor de crecimiento aplica a tu producto (pegajoso, viral o pagado) antes de invertir en canales de adquisición. Hoy vas a aprender a comprobar si ese motor está funcionando de verdad, en lugar de fiarte de números que suben solos aunque el producto no mejore. Vas a salir con un criterio concreto —los “tres A” de una métrica útil— y con la diferencia práctica entre mirar un total acumulado y mirar una cohorte.
Conceptos base
Métrica de vanidad (vanity metric): un número que casi siempre sube y que hace sentir bien, pero que no te dice qué acción tomar ni por qué subió. El ejemplo clásico es el total acumulado de usuarios registrados desde el lanzamiento: solo puede crecer o quedarse igual, nunca bajar, así que no refleja si el producto está mejorando o empeorando ahora mismo.
Métrica accionable (actionable metric): un número que, cuando cambia, te dice qué hacer. Eric Ries, en el libro que dio nombre a todo este enfoque, propone un filtro de tres condiciones para distinguirla de una métrica de vanidad: debe ser accionable (si repites el experimento que la produjo obtienes resultados comparables, y ves con claridad qué causó el cambio), accesible (cualquiera del equipo la entiende sin depender de un informe de un especialista) y auditable (los datos de origen son creíbles: puedes rastrear de dónde sale cada número y verificarlo) [1].
Cohorte: un grupo de usuarios agrupados por el momento en que hicieron algo en común, normalmente registrarse. “La cohorte de usuarios que se registró en julio” es un grupo cerrado: puedes seguir qué fracción de ese grupo exacto sigue activa en agosto, septiembre y octubre, y comparar esa evolución con la cohorte de agosto. Un agregado (como “usuarios activos este mes”, mezclando gente que se registró hace tres años con gente que se registró ayer) no permite esa comparación.
Coeficiente de viralidad: el número medio de usuarios nuevos que trae cada usuario existente a través de invitaciones o compartidos, ya lo viste en la lección 9 si tu motor es viral. Lo importante hoy es que este número solo es útil si se mide por periodo o por cohorte, no acumulado desde el origen.
Desarrollo
Por qué un total acumulado engaña
Imagina una app ficticia —los números que siguen son solo un ejemplo para explicar el mecanismo, no datos reales de ninguna empresa— que pasa de 10.000 a 50.000 y luego a 100.000 usuarios registrados en total a lo largo de un año. Visto así, parece una curva de crecimiento imparable. Pero un registro acumulado nunca baja: aunque el 95% de esos usuarios abandonara la app a la semana de entrar, el número total seguiría subiendo mientras entre gente nueva. El total acumulado no te dice si el producto retiene a nadie, solo que alguna gente lo ha probado alguna vez.
La alternativa es mirar la misma app por cohortes de registro. Cohorte de enero: 100 personas se registran; a los 30 días, 20 de esas 100 (un 20%) siguen activas. Cohorte de febrero: 150 personas se registran; a los 30 días, solo 15 de esas 150 (un 10%) siguen activas. El total de usuarios sigue subiendo (100 + 150 = 250 personas han pasado por la app), pero la retención real está empeorando cohorte a cohorte. Esa es la señal que importa, y es invisible si solo miras el total acumulado.
Los tres motores de la lección 9, vistos con la métrica correcta
Cada motor de crecimiento que viste la semana pasada tiene una métrica accionable específica, y en los tres casos el error típico es el mismo: medir el acumulado en vez de medir por cohorte o por periodo.
- Motor pegajoso (sticky engine): la métrica no es “usuarios totales”, es la tasa de abandono (churn rate) de cada cohorte de registro, medida a un plazo fijo (por ejemplo, a 30 días). Si quieres crecer con este motor, tu tasa de crecimiento natural tiene que superar a tu tasa de abandono; para saber si eso ocurre necesitas el dato por cohorte, no el total.
- Motor viral: la métrica no es “número total de invitaciones enviadas”, es el coeficiente de viralidad de cada cohorte y el tiempo que tarda un ciclo completo (invitar → que el invitado se registre → que el invitado invite a otros). Un coeficiente alto pero con un ciclo muy largo crece mucho más despacio de lo que parece.
- Motor pagado: la métrica no es “ingresos totales menos gasto en publicidad total desde el inicio”, es el coste de adquisición de cliente (CAC) frente al valor de vida del cliente (LTV) calculados por cohorte de adquisición, porque el CAC y el comportamiento de los clientes cambian con el tiempo y con el canal.
Estas tres métricas específicas de cada motor encajan dentro de un vocabulario más amplio que probablemente te vas a encontrar si lees sobre analítica de producto: el marco AARRR (Adquisición, Activación, Retención, Referidos, Ingresos), que agrupa cualquier métrica de un producto digital en una de esas cinco etapas del embudo. El marco se popularizó a partir de una charla de Dave McClure en 2007 y hoy aparece documentado y ampliado en libros de analítica de producto; lo útil de conocerlo no es memorizar las cinco letras, sino tener una forma común de nombrar en qué etapa del embudo está la métrica que acabas de definir, para poder hablar de ella con el resto del equipo sin ambigüedad [4]. La retención de la que hablábamos en el motor pegajoso es la “R” de Retención; el coeficiente de viralidad es la “R” de Referidos; el CAC del motor pagado nace en la “A” de Adquisición y se compara contra la “R” de Ingresos.
Un proceso para decidir la métrica antes de mirar el panel
Un riesgo habitual, sobre todo cuando ya tienes herramientas de analítica instaladas (Google Analytics, Mixpanel, Amplitude, lo que sea), es mirar el panel primero y “encontrar” una métrica que suba, en vez de decidir antes qué pregunta necesitas responder. Un equipo de investigación de Google formalizó un proceso para evitar justamente esto, pensado originalmente para medir experiencia de usuario a gran escala: primero se fija el objetivo de negocio o de producto (Goal), después se identifican las señales observables que indicarían que ese objetivo se está cumpliendo (Signal), y solo al final se elige la métrica concreta que captura esa señal de forma medible (Metric). El orden importa: si empiezas por “qué puedo medir fácilmente” en vez de “qué objetivo tengo”, acabas optimizando lo que es fácil de medir en vez de lo que importa [2].
Ese mismo equipo propuso además cinco categorías de objetivos de experiencia de usuario que suelen aplicar a casi cualquier producto digital con usuarios recurrentes: felicidad (satisfacción declarada), engagement (frecuencia e intensidad de uso), adopción (nuevos usuarios que empiezan a usar una función), retención (cuántos vuelven) y éxito en la tarea (task success, si completan lo que vinieron a hacer) [2]. No necesitas medir las cinco a la vez; sirven como lista de comprobación para no dejarte ninguna categoría relevante fuera al definir qué vas a medir.
Si usas Google Analytics (GA4) en un proyecto real, el informe de análisis de cohortes es la implementación directa de todo esto: agrupa a los usuarios por la semana o el mes en que llegaron y te deja ver cómo evoluciona su comportamiento con el tiempo, en vez de darte solo el agregado del periodo [3].
Dónde está el límite de esto
Conviene ser honesto sobre una cosa: no existe un consenso cerrado sobre cuántas métricas debe vigilar un equipo a la vez ni sobre si conviene reducirlo todo a una sola “métrica estrella” o vigilar varias en paralelo. Lo que sí tiene respaldo sólido, y es lo que importa para esta lección, es el criterio para descartar una métrica mala (el filtro de los tres A) y la técnica para no dejarte engañar por un acumulado (cohortes en vez de agregados). Cómo reducir eso a un número o a cinco depende del producto y no hay una receta única verificable.
Aplicación práctica
Coge una métrica que ya estés mirando ahora mismo, de cualquier proyecto personal, side-project, o incluso de tus propios experimentos conectando modelos de IA o agentes con Python o Node (por ejemplo: “número de llamadas a la API”, “agentes desplegados”, “repositorios con el agente integrado”). Si no tienes ninguna en marcha, usa una app que uses a diario e imagina que fueras su responsable de producto.
Pasos:
- Escribe la métrica tal cual la mirarías hoy (probablemente un total acumulado: “total de X desde que empecé”).
- Pásala por el filtro de los tres A: ¿Es accionable? Si el número sube o baja, ¿sabrías qué hiciste para que pasara eso, o podría ser casualidad? ¿Es accesible? ¿La entenderías sin tener que pedir explicación a nadie? ¿Es auditable? ¿Sabes exactamente de dónde sale cada dato que la compone?
- Si falla alguno de los tres filtros, redibuja la métrica como una métrica por cohorte o por periodo en vez de acumulada. Por ejemplo, de “total de agentes desplegados” a “de los agentes que desplegué esta semana, cuántos siguen funcionando sin que haya tenido que tocarlos siete días después”.
- Escribe en una frase qué decisión tomarías si esa métrica nueva bajara el mes que viene, y qué decisión tomarías si subiera. Si no puedes contestar con una acción concreta para ambos casos, todavía no es una métrica accionable: vuelve al paso 2.
Errores comunes
Confundir “el número que solo sube” con progreso real. Cualquier contador acumulado (registros totales, descargas totales, seguidores totales) tiene esa propiedad por construcción, así que no puede decirte si algo ha mejorado o empeorado esta semana.
Mirar el promedio o el agregado global en vez del dato por cohorte. Un agregado puede esconder que la cohorte más reciente lo está haciendo peor que las anteriores, porque el buen comportamiento de las cohortes antiguas compensa el dato en el promedio general.
Medir muchas cosas a la vez sin haber decidido antes qué objetivo responde cada una. Un panel con veinte gráficas no es más riguroso que uno con dos; si no sabes de antemano qué acción tomarías ante cada cambio, el panel entero son métricas de vanidad con buen diseño.
Fuentes
- Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Crown Business, 2011. Capítulo sobre métricas accionables frente a métricas de vanidad y el criterio de las “tres A” (accionable, accesible, auditable).
- Kerry Rodden, Hilary Hutchinson y Xin Fu, “Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications”, Google Research / CHI 2010. https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications/
- Google, “Ver los datos de Análisis de cohortes” (Centro de ayuda de Google Analytics). https://pss.support.google.com/analytics/answer/6074676
- Alistair Croll y Benjamin Yoskovitz, Lean Analytics: Use Data to Build a Better Startup Faster, O’Reilly Media. Capítulo sobre el marco AARRR (Adquisición, Activación, Retención, Referidos, Ingresos) y su origen en la charla de Dave McClure. https://www.oreilly.com/library/view/lean-analytics/9781098168179/ch05.html
Para la próxima lección
En la próxima lección de esta pista veremos el marco Bullseye del libro Traction de Gabriel Weinberg y Justin Mares, para elegir y probar canales de adquisición sin gastar todo el presupuesto probándolos todos a la vez.