Módulo 1: What To Measure

Métricas accionables vs métricas de vanidad

Descripción

Toda esta guía se apoya en una distinción que parece obvia hasta que la aplicas a un dashboard real: no todas las métricas sirven para decidir algo. Una métrica de vanidad (vanity metric) es un número que sube, se ve bien en una presentación, y no te dice qué hacer distinto mañana. Una métrica accionable (actionable metric) es un número que, cuando cambia, te dice algo sobre el comportamiento real de tus usuarios —y por lo tanto te sugiere una acción concreta—.

La trampa no es que las métricas de vanidad sean falsas. totalRegisteredUsers —el total histórico de gente que se registró en Mercado— es un dato real, verificable, que probablemente costó esfuerzo real conseguir. El problema es otro: no cambia lo que harías después. Si totalRegisteredUsers pasa de 550,000 a 551,000 esta semana, ¿qué decides distinto? Nada, probablemente. Si checkoutConversionRate pasa de 3.2% a 2.8%, sí sabes qué hacer: investigar qué se rompió en el checkout.

Conexión con el módulo. Esta lección abre el módulo con la distinción central que las lecciones 3 a 7 van a desarrollar desde ángulos distintos: la lección 3 profundiza en por qué una tasa es más fuerte que un total (una de las dos señales que vas a usar hoy), las lecciones 4 y 5 te dan dos frameworks completos para elegir métricas con estructura, la lección 6 organiza métricas accionables en un árbol, y la lección 7 cierra con el criterio completo de qué hace buena a una métrica. Hoy construyes la herramienta más simple de todas —un clasificador de dos preguntas— y la corres sobre las primeras métricas candidatas de Mercado.

Una analogía: el odómetro y el velocímetro

Todo auto tiene dos números en el tablero que a veces se confunden. El odómetro —los kilómetros totales recorridos desde que el auto salió de fábrica— solo puede subir. Nunca baja, no importa qué tan mal manejes hoy. Es un dato real y hasta tiene su utilidad —por ejemplo, para saber cuándo toca el próximo service—, pero no te dice absolutamente nada sobre cómo estás manejando ahora mismo. Un auto con 200,000 km puede estar yendo a 40 km/h con cuidado, o puede estar por chocar a 160.

El velocímetro, en cambio, te dice la velocidad actual: un número que sube y baja, que refleja lo que estás haciendo en este momento, y sobre el que puedes actuar de inmediato —frenar, acelerar—. Nadie decide si va demasiado rápido mirando el odómetro. totalRegisteredUsers es el odómetro de Mercado: crece siempre, es historia acumulada, no acción. checkoutConversionRate es el velocímetro: te dice cómo estás manejando el negocio hoy, y te da algo sobre lo cual actuar si el número no te gusta.

Ejemplo trabajado: classifyMetric() sobre las primeras candidatas de Mercado

El equipo de Mercado, mientras arma el plan de medición de recommendations, junta una primera lista corta de métricas candidatas. Antes de decidir cuáles van al dashboard del experimento, vamos a construir un clasificador simple —una heurística de bolsillo, no un algoritmo estadístico— con dos señales:

  1. ¿Es un total acumulado que solo sube? Si nunca puede bajar porque suma desde el día 1, es una señal fuerte de vanidad.
  2. ¿Es una tasa (tiene numerador y denominador), comparable entre periodos, y está atada a una decisión real y reciente del usuario? Si sí, es una señal fuerte de que es accionable.

Cuando ninguna de las dos señales fuertes aplica —no es un total acumulado, pero tampoco es una tasa— usamos una señal de respaldo: si de todos modos refleja una decisión real y reciente (por ejemplo, un conteo que resetea cada semana, como cuántos compradores distintos compraron esta semana), la tratamos como accionable; si no, como vanidad.

// classifyMetric: heuristica pedagogica de 2 senales fuertes + 1 senal de respaldo.
// NO es un clasificador estadistico ni una regla universal -- es una regla de bolsillo
// para auditar metricas candidatas antes de meterlas a un dashboard.
function classifyMetric(m) {
  // Senal 1 (fuerte): un total acumulado que solo sube desde el dia 1 -> vanity.
  if (m.cumulativeTotal) return 'vanity';
  // Senal 2 (fuerte): una tasa/ratio, comparable entre periodos, atada a una decision real -> actionable.
  if (m.isRate && m.tiedToRecentBehavior) return 'actionable';
  // Sin senal fuerte: ni total acumulado ni tasa. Es un conteo que resetea cada periodo.
  // Se salva SOLO si esta atado a una decision real y reciente del usuario.
  return m.tiedToRecentBehavior ? 'actionable' : 'vanity';
}

const candidates = [
  { name: 'totalRegisteredUsers', cumulativeTotal: true, isRate: false, tiedToRecentBehavior: false },
  { name: 'totalPageviewsAllTime', cumulativeTotal: true, isRate: false, tiedToRecentBehavior: false },
  { name: 'checkoutConversionRate', cumulativeTotal: false, isRate: true, tiedToRecentBehavior: true },
  { name: 'weeklyActiveBuyers', cumulativeTotal: false, isRate: false, tiedToRecentBehavior: true },
];

console.log('=== classifyMetric sobre 4 metricas candidatas de Mercado ===\n');
const results = candidates.map((m) => ({ ...m, label: classifyMetric(m) }));
results.forEach((r) => console.log('  ' + r.name.padEnd(24) + '-> ' + r.label));

const actionableCount = results.filter((r) => r.label === 'actionable').length;
const vanityCount = results.filter((r) => r.label === 'vanity').length;
console.log('\nTotal: ' + actionableCount + ' actionable, ' + vanityCount + ' vanity.');

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

=== classifyMetric sobre 4 metricas candidatas de Mercado ===

  totalRegisteredUsers    -> vanity
  totalPageviewsAllTime   -> vanity
  checkoutConversionRate  -> actionable
  weeklyActiveBuyers      -> actionable

Total: 2 actionable, 2 vanity.

Nota el caso de weeklyActiveBuyers: no es una tasa —es un conteo, 4100 compradores distintos, por ejemplo—, así que no dispara la señal 2. Pero tampoco es un total que solo sube: cada semana vuelve a empezar en cero y se recalcula solo con lo que pasó esa semana. Como además está directamente atado a una decisión real (comprar), la señal de respaldo lo clasifica como actionable. Compáralo con totalRegisteredUsers: ese número también podría, en teoría, contarse "por semana" —cuántos se registraron esta semana—, pero tal como está definido en el candidato de arriba es un acumulado histórico, y por eso cae directo en vanity por la señal 1, sin llegar siquiera a evaluar la segunda.

Por qué las métricas de vanidad son peligrosas, no solo inútiles

Podrías pensar: "bueno, si totalRegisteredUsers no ayuda a decidir nada, simplemente no lo miro, y ya está". El problema es más serio que eso. Una métrica de vanidad no es neutral: tiende a subir sola, casi sin importar lo que el equipo haga bien o mal, porque es un acumulado que rara vez baja. Eso la vuelve peligrosamente fácil de presentar como éxito. Un equipo puede tener un trimestre malo —conversión cayendo, retención cayendo, guardarropas de quejas creciendo— y aun así cerrar la presentación con "¡pasamos el medio millón de usuarios registrados!", una frase verdadera que oculta todo lo demás.

Esa es la razón real por la que este módulo empieza aquí, antes de cualquier framework o cualquier árbol de métricas: si no aprendes primero a detectar una métrica de vanidad, ningún framework te va a salvar de elegir mal, porque HEART y AARRR (lecciones 4 y 5) también tienen categorías donde es fácil colar un total disfrazado de progreso.

Errores comunes

Celebrar un total acumulado que solo sube como si fuera una señal de salud. Qué pasa: un reporte de producto abre con "llegamos a 550,000 usuarios registrados" como titular de éxito, sin mencionar ninguna tasa de comportamiento reciente. Por qué pasa: un número grande y creciente es fácil de comunicar y siempre "se ve bien", incluso en un trimestre malo. Cómo detectarlo: pregúntate si ese número pudo haber subido igual aunque el producto hubiera empeorado esta semana —si la respuesta es sí, es vanidad. Cómo corregirlo: exige que cada titular de reporte venga acompañado de al menos una tasa reciente y comparable, como hizo classifyMetric con checkoutConversionRate frente a totalRegisteredUsers.

Asumir que cualquier número que "suena a comportamiento" ya es accionable. Qué pasa: alguien defiende totalPageviewsAllTime diciendo "pero es gente usando el producto, ¿no?", tratando el uso pasado acumulado como si fuera comparable al uso reciente. Por qué pasa: "pageviews" suena a actividad real, y es fácil olvidar que sin acotar a un periodo, sigue siendo un total que solo crece. Cómo detectarlo: pregunta "¿esta métrica puede bajar la semana que viene si el producto empeora?" Si la respuesta es no —porque es un acumulado histórico—, no importa qué tan "activo" suene, sigue siendo vanidad. Cómo corregirlo: acota siempre a un periodo definido (pageviews esta semana, no pageviews desde el lanzamiento) antes de evaluar si además está atada a una decisión real.

Descartar por completo un conteo (no una tasa) solo por no ser un porcentaje. Qué pasa: en la dirección opuesta, alguien ve weeklyActiveBuyers —un número entero, no un porcentaje— y lo tacha de vanidad solo porque "las métricas buenas son tasas". Por qué pasa: la lección 3 (que viene después) va a insistir mucho en las tasas, y es fácil sobre-aplicar esa regla antes de tiempo. Cómo detectarlo: la objeción es "esto no es una tasa" sin preguntar si de todos modos resetea cada periodo y refleja una decisión real. Cómo corregirlo: como viste en el ejemplo de hoy, un conteo periódico (no acumulado) atado a comportamiento real —como weeklyActiveBuyers— sí puede ser accionable, aunque una tasa equivalente casi siempre sea más fuerte todavía. Eso es, precisamente, lo que la lección 3 explica a continuación.

Ejercicios

Ejercicio 1 — Clasifica a mano. Para cada métrica, decide si classifyMetric() la marcaría actionable o vanity, y explica con qué señal (1, 2, o la de respaldo):

  • (a) totalOrdersAllTime — el conteo histórico de todas las órdenes hechas en Mercado desde el lanzamiento, sin acotar a ningún periodo.
  • (b) monthlyReturnRate — el porcentaje de compras que terminan en devolución, calculado cada mes.
  • (c) newSellersThisMonth — cuántos vendedores nuevos se sumaron este mes (resetea cada mes, no es un porcentaje).
Ver solución
  • (a) vanity, por la señal 1. Es un total acumulado histórico (cumulativeTotal: true) que solo puede subir; ni siquiera llega a evaluarse la señal 2.
  • (b) actionable, por la señal 2. Es una tasa (isRate: true) con numerador (devoluciones) y denominador (compras), comparable mes a mes, y atada directamente a una decisión real de los compradores.
  • (c) actionable, por la señal de respaldo. No es un total acumulado (resetea cada mes) ni es una tasa, pero está atada a una decisión real (un vendedor decidió sumarse) y es comparable periodo a periodo, así que la señal de respaldo la clasifica como accionable.

Ejercicio 2 — Encuentra el disfraz. Un compañero de equipo propone medir el éxito de recommendations con totalRecommendationImpressionsAllTime —cuántas veces, en total, desde que se lanzó el carrusel, se le mostró una recomendación a algún usuario—. Explica, con el vocabulario de esta lección, por qué esta métrica es un disfraz de vanidad aunque "suene" relacionada con el feature.

Ver solución

totalRecommendationImpressionsAllTime es un total acumulado desde el lanzamiento: solo puede subir, cada vez que se le muestra el carrusel a cualquier usuario, sin importar si ese usuario hizo clic, compró, o cerró la pestaña de inmediato. Cumple exactamente la señal 1 de classifyMetric (cumulativeTotal: true) y por lo tanto se clasifica vanity sin llegar a mirar nada más. El disfraz es que "impresiones de recomendaciones" suena directamente relacionado con el feature que se está midiendo —a diferencia de algo obviamente ajeno como totalPageviews—, pero estar relacionado con el feature no lo vuelve accionable: sigue sin decir si el carrusel está funcionando esta semana. La versión accionable equivalente sería algo como weeklyRecommendationClickRate (clics ÷ impresiones, por semana): ahí sí hay numerador, denominador, y una ventana de tiempo comparable.

Ejercicio 3 — Diseña el contraejemplo. Escribe un objeto de métrica (con los tres campos cumulativeTotal, isRate, tiedToRecentBehavior) que classifyMetric() clasifique como vanity a pesar de estar atada a una decisión real y reciente del usuario (tiedToRecentBehavior: true). ¿Qué te dice eso sobre cuál de las tres señales pesa más en el heurístico?

Ver solución

Cualquier métrica con { cumulativeTotal: true, isRate: false, tiedToRecentBehavior: true } sirve de contraejemplo —por ejemplo, totalPurchasesAllTime, el conteo histórico total de compras hechas en Mercado desde el lanzamiento—. Aunque cada compra individual sí es una decisión real y reciente del usuario en el momento en que ocurrió, classifyMetric() nunca llega a mirar tiedToRecentBehavior porque cumulativeTotal es true y la función corta en el primer if. Esto muestra que la señal 1 (cumulativeTotal) tiene prioridad absoluta en el heurístico: ninguna cantidad de "esto está atado a comportamiento real" salva a una métrica si está expresada como un acumulado histórico sin ventana de tiempo. La lección práctica: no alcanza con que el evento subyacente sea real y accionable —el purchase en sí lo es—; la forma en que agregas ese evento en una métrica (acumulado sin fin vs. tasa o conteo por periodo) es la que decide si la métrica resultante sirve para decidir algo.

Resumen y siguiente paso

En esta lección definiste la distinción central del módulo: una métrica de vanidad es un total que solo sube y no te dice qué hacer distinto; una métrica accionable es una señal —idealmente una tasa, y en su defecto un conteo periódico atado a comportamiento real— que cambia con lo que la gente hace y te sugiere una acción. Construiste y ejecutaste classifyMetric(), un heurístico de bolsillo con dos señales fuertes y una de respaldo, y lo corriste sobre las primeras cuatro métricas candidatas de Mercado: dos vanidad (totalRegisteredUsers, totalPageviewsAllTime), dos accionables (checkoutConversionRate, weeklyActiveBuyers).

Antes de avanzar deberías poder: explicar con tus propias palabras la diferencia entre un total acumulado y una tasa comparable; aplicar classifyMetric() a mano sobre una métrica nueva; y reconocer cuándo una métrica "suena" relacionada con un feature sin ser realmente accionable.

La lección 3 toma la señal 2 de hoy —"¿es una tasa?"— y la desarrolla a fondo: por qué un total absoluto, incluso uno que no es un acumulado histórico infinito, sigue siendo más débil que una tasa con su denominador visible.

Recursos

  • Alistair Croll y Benjamin Yoskovitz, Lean Analyticsleananalyticsbook.com/tag/vanity-metrics. El sitio oficial del libro que popularizó el término "vanity metric" y la distinción con las métricas accionables que esta lección desarrolla. En inglés.
  • Eric Ries, "Vanity Metrics vs. Actionable Metrics" (el argumento original de The Lean Startup, resumido) — citado y ampliado en el mismo libro de Croll y Yoskovitz de arriba; la idea de que "si una métrica no puede cambiar tu comportamiento, es una mala métrica" nace ahí.
  • ProductPlan, "Vanity Metrics" — productplan.com/glossary/vanity-metrics. Un glosario corto con ejemplos adicionales por industria, útil para practicar la clasificación con métricas fuera de Mercado. En inglés.