Input metrics: las palancas que mueven a la North Star

Descripción

Elegir weeklyGMVPerActiveBuyer como North Star (lección 3) contesta qué mide el éxito de Mercado. Pero un número solo no le dice a nadie qué hacer el lunes por la mañana — nadie puede "trabajar directamente" sobre la North Star, de la misma forma en que un piloto no mueve el altímetro con la mano: mueve los controles que, indirectamente, cambian la altura. Las input metrics son esos controles: las palancas concretas, más chicas, que el equipo puede mover con trabajo real, y que en conjunto explican por qué la North Star sube o baja.

Esta lección hace dos cosas: descompone matemáticamente weeklyGMVPerActiveBuyer en sus componentes exactos (no una intuición — una identidad algebraica que se puede verificar), y después identifica las palancas de nivel superior que mueven a esos componentes — muchas de las cuales ya conoces de los módulos anteriores.

Conexión con el módulo. Esta lección conecta directamente con las lecciones 2 y 3: las candidatas que "perdieron" la carrera por la North Star —como weeklyPurchasingBuyers, que falló solo en reflectsValue— no se descartan, se convierten en insumos de este árbol. Y conecta hacia adelante con las lecciones 5 y 6: entender qué mueve a la North Star es el paso previo indispensable para entender cómo se la puede optimizar mal (lección 5) y qué hay que vigilar mientras se la optimiza bien (lección 6).

Una analogía: el tablero del auto, ahora con el motor abierto

En el módulo 1 (lección 6) ya viste la analogía del tablero del auto: la North Star es la aguja del velocímetro, el número que resume si vas bien o mal. Hoy abrimos el capó. La velocidad de un auto no se controla directamente — no hay una palanca llamada "velocidad" — se controla con el acelerador, los cambios de marcha, y el freno, que juntos determinan qué tan rápido vas. Un mecánico que entiende el motor no mira solo el velocímetro: sabe exactamente qué combinación de combustible, aire y encendido produce cada kilómetro por hora.

Las input metrics son esa combinación de combustible, aire y encendido. weeklyGMVPerActiveBuyer es la velocidad — el resumen—; averageOrderValue y ordersPerActiveBuyer son el acelerador y la marcha — los dos controles que, multiplicados, producen exactamente ese resumen, sin intuición de por medio, con una fórmula que se puede verificar.

Ejemplo trabajado: la descomposición exacta de weeklyGMVPerActiveBuyer

A diferencia de HEART o AARRR (módulo 1), donde elegías métricas candidatas por criterio, aquí hay una identidad matemática exacta que conecta la North Star con dos de sus inputs directos:

weeklyGMVPerActiveBuyer = averageOrderValue × ordersPerActiveBuyer

Es decir: el valor promedio que genera cada comprador activo en la semana es, exactamente, cuánto vale cada orden que hace (averageOrderValue) multiplicado por cuántas órdenes hace en la semana (ordersPerActiveBuyer). No es una correlación que observaste en los datos — es álgebra: GMV / activeBuyers = (GMV / orders) × (orders / activeBuyers), y los dos términos de la derecha son, precisamente, averageOrderValue y ordersPerActiveBuyer.

Con los números de esta semana de Mercado:

Variable	Valor
averageOrderValue	$44.50
ordersPerActiveBuyer	1.18
weeklyGMVPerActiveBuyer (calculado)	$44.50 × 1.18 = $52.51
weeklyActiveBuyers	4,100
weeklyGMV total (calculado)	$52.51 × 4,100 = $215,291

Qué esperar. Verificando a mano: 44.50 × 1.18 = 52.51 — la North Star de esta semana es $52.51 por comprador activo. Multiplicando ese resultado por los 4,100 compradores activos de la semana, el weeklyGMV total (la versión sin normalizar, la que el módulo 1 dejó como tentativa) sale en $215,291. Este segundo cálculo confirma algo importante: weeklyGMVPerActiveBuyer y weeklyGMV no son números independientes — están conectados por la misma identidad algebraica (weeklyGMV = weeklyGMVPerActiveBuyer × weeklyActiveBuyers), y por eso, como viste en el ejercicio 3 de la lección anterior, es tan fácil confundir cuál de los dos usar como North Star: cualquier cosa que mueva a uno tiende a mover al otro.

El árbol completo: de la identidad exacta a las palancas reales

averageOrderValue y ordersPerActiveBuyer son inputs directos —conectados por álgebra pura—, pero ninguno de los dos es, todavía, algo que un ingeniero pueda "programar" un lunes por la mañana. Hace falta un nivel más: las palancas concretas que el equipo mueve, y que a su vez mueven a esos dos componentes.

                       weeklyGMVPerActiveBuyer ($52.51)
                    = averageOrderValue x ordersPerActiveBuyer
              ┌─────────────────┴─────────────────┐
    averageOrderValue ($44.50)            ordersPerActiveBuyer (1.18)
              │                                     │
    ┌─────────┴─────────┐               ┌───────────┴───────────┐
  product mix /      recommendations  checkoutConversionRate  cartAbandonmentRate
  bundles (catalogo)  (cross-sell,       (M2: menos friccion    (M2: menos fuga
                       upsell)            en el checkout)        antes de pagar)

Cuatro palancas de nivel inferior, todas ya conocidas de módulos anteriores: checkoutConversionRate y cartAbandonmentRate (módulo 2) explican cuántas de las visitas de un comprador activo terminan siendo una orden completada, y por lo tanto empujan ordersPerActiveBuyer. El mix de catálogo y las recomendaciones —el propio recommendations que esta guía está midiendo de punta a punta— empujan averageOrderValue: un carrusel que sugiere bien un producto complementario sube el ticket promedio de la compra. Y hay una quinta palanca, de movimiento más lento, que no aparece en el diagrama de esta semana pero que importa a mediano plazo: retentionD30 (módulo 3) — un comprador que no vuelve el mes que viene deja de contar como "comprador activo" en absoluto, así que la retención determina, semana tras semana, quién sigue formando parte del denominador de toda esta cuenta.

Fíjate en algo: ninguna de estas cuatro o cinco palancas ganó la carrera por la North Star en la lección 3 —de hecho, checkoutConversionRate, cartAbandonmentRate y retentionD30 fallarían el criterio reflectsValue exactamente por la misma razón que weeklyPurchasingBuyers: miden una parte del comportamiento, no el valor total—. Pero eso no las descalifica del árbol: perder la carrera por el trono y ser una input metric excelente no son contradictorios. Al contrario: son, casi siempre, la misma métrica vista desde dos preguntas distintas.

Qué hace bueno a un input (y qué lo descalifica)

No cualquier número que "se mueva junto" con la North Star merece un lugar en este árbol. Un buen input cumple dos condiciones adicionales, más allá de estar conectado matemática o causalmente:

• Es accionable de forma independiente. El equipo puede mover checkoutConversionRate sin necesariamente mover averageOrderValue al mismo tiempo —son palancas distintas, con causas distintas—. Un input que siempre sube y baja exactamente junto con otro input ya presente en el árbol no aporta información nueva; es un duplicado con otro nombre.
• Es un leading indicator, no un reflejo tardío. checkoutConversionRate de esta semana te dice algo antes de que termine de reflejarse en weeklyGMVPerActiveBuyer — puedes reaccionar a una caída de conversión el martes, sin esperar a ver el número agregado del domingo. Un input que se mueve exactamente al mismo tiempo que la North Star, ni un día antes, no cumple su función de alerta temprana.

Errores comunes

Proponer weeklyGMV (sin normalizar) como input de weeklyGMVPerActiveBuyer. Qué pasa: alguien agrega weeklyGMV total a la lista de inputs, razonando que "obviamente está relacionado". Por qué pasa: los dos números comparten casi el mismo nombre y están conectados por la misma identidad algebraica de esta lección, así que parece natural tratarlos como causa y efecto. Cómo detectarlo: si el input propuesto sube y baja en una proporción casi idéntica a la North Star, sin que el equipo pueda moverlo de forma independiente, no es un input real —es la misma señal con otro nombre, el mismo error que advirtió la lección 6 del módulo 1 sobre weeklyRevenue como input de weeklyGMV—. Cómo corregirlo: un input tiene que descomponer a la North Star en partes distintas y accionables por separado —como averageOrderValue y ordersPerActiveBuyer de hoy—, no repetir el mismo número agregado con otro nombre.

Acumular demasiadas palancas sin ninguna jerarquía. Qué pasa: el árbol de inputs crece a diez o doce métricas —cualquier cosa remotamente relacionada con una compra entra a la lista—, y el equipo termina revisando un dashboard tan largo como el que el módulo 1 ya advirtió que había que evitar. Por qué pasa: cada input individual se siente relevante, y es más fácil agregar uno nuevo que decidir cuáles de los ya existentes descartar. Cómo detectarlo: si nadie en el equipo puede nombrar, de memoria, los cuatro o cinco inputs principales sin mirar un documento, el árbol perdió su propósito de simplificar. Cómo corregirlo: prioriza los inputs conectados por álgebra exacta (como averageOrderValue y ordersPerActiveBuyer hoy) sobre los conectados solo por correlación intuitiva, y dentro de esos, elige los que de verdad son accionables de forma independiente — como se explicó arriba.

Elegir como input una palanca que el equipo de producto no puede mover. Qué pasa: alguien propone promedioDeGastoDisponibleDelConsumidor (una condición macroeconómica) como input, porque técnicamente está correlacionado con cuánto gasta la gente en Mercado. Por qué pasa: cualquier cosa que se mueva en la misma dirección que la North Star se siente, superficialmente, como una palanca útil. Cómo detectarlo: pregúntate si un ingeniero o diseñador de Mercado podría, con un cambio de producto concreto, mover ese número el mes que viene — si la respuesta es "no, eso depende de la economía del país", no es un input de producto, aunque esté correlacionado. Cómo corregirlo: reserva el árbol de inputs para palancas que el equipo controla directamente —como las cuatro de hoy—; factores externos que afectan a la North Star sin ser controlables por el equipo son contexto útil para interpretar los números, no inputs sobre los cuales diseñar una estrategia.

Ejercicios

Ejercicio 1 — Verifica la identidad con números nuevos. La semana siguiente, Mercado reporta averageOrderValue: $47.00 y ordersPerActiveBuyer: 1.15. Calcula a mano el weeklyGMVPerActiveBuyer de esa semana. ¿Subió o bajó respecto a los $52.51 de esta lección, y qué te dice eso sobre cuál de los dos componentes pesó más en el cambio?

Ver solución

47.00 × 1.15 = 54.05 — subió, de $52.51 a $54.05. El averageOrderValue subió (de $44.50 a $47.00, +5.6%) mientras que ordersPerActiveBuyer bajó levemente (de 1.18 a 1.15, -2.5%). El efecto neto es positivo porque la subida del ticket promedio pesó más que la baja en frecuencia de compra. Esto ilustra algo importante del árbol: los dos inputs directos pueden moverse en direcciones opuestas y aun así la North Star suba — por eso descomponerla en sus partes exactas importa más que mirar solo el número final: sin la descomposición, el equipo no sabría que la frecuencia de compra en realidad se debilitó esa semana, aunque el resultado general se vea bien.

Ejercicio 2 — Encuentra el input redundante. Un compañero de equipo propone agregar totalOrdersThisWeek (el conteo total de órdenes de la semana, sin dividir entre compradores activos) al árbol, además de ordersPerActiveBuyer que ya está ahí. ¿Por qué esta propuesta, aunque no sea técnicamente incorrecta, es una elección débil?

Ver solución

totalOrdersThisWeek está casi completamente determinado por los dos números que ya están en el árbol: ordersPerActiveBuyer × weeklyActiveBuyers = totalOrdersThisWeek. No es un duplicado exacto de ninguno de los dos por separado, pero es una combinación mecánica de ambos, sin aportar una palanca nueva sobre la cual el equipo pueda actuar de forma distinta a como ya actúa sobre ordersPerActiveBuyer (con mejor checkout, menos abandono) o sobre weeklyActiveBuyers (con retención, adquisición). Agregarlo al árbol infla el conteo de inputs —el error del "demasiadas palancas" de arriba— sin sumar información de decisión nueva.

Ejercicio 3 — Ubica recommendations en el árbol. El carrusel de recomendaciones que esta guía mide de punta a punta, ¿en qué rama del árbol de hoy tiene más probabilidad de generar impacto: averageOrderValue o ordersPerActiveBuyer? Justifica con un argumento, no solo con una corazonada.

Ver solución

Las dos ramas son plausibles, pero por mecanismos distintos, y vale la pena nombrarlos por separado en vez de asumir uno solo. Si recommendations funciona sugiriendo productos complementarios dentro de la misma compra (por ejemplo, mostrar una funda de celular junto al celular que ya está en el carrito), el mecanismo esperado es subir averageOrderValue —cada orden individual vale más—. Si en cambio funciona ayudando a un comprador a descubrir algo que de otra forma no hubiera buscado y comprado por separado, más adelante en la semana, el mecanismo esperado es subir ordersPerActiveBuyer —el mismo comprador hace más órdenes distintas—. Los dos mecanismos no son excluyentes, y de hecho el A/B test que empieza en el módulo 5 es exactamente la forma de descubrir, con datos reales y no con argumento, cuál de los dos (o si ambos) está ocurriendo de verdad con recommendations.

Resumen y siguiente paso

En esta lección descompusiste weeklyGMVPerActiveBuyer en su identidad algebraica exacta —averageOrderValue × ordersPerActiveBuyer— y bajaste un nivel más para identificar las palancas reales que mueven esos dos componentes: checkoutConversionRate y cartAbandonmentRate (módulo 2), el mix de catálogo y recommendations, y retentionD30 (módulo 3) como palanca de movimiento más lento. Viste que perder la carrera por la North Star (lección 3) no descalifica a una métrica del árbol —al contrario, la mayoría de las candidatas que "perdieron" son, exactamente, las input metrics de hoy—.

Antes de avanzar deberías poder: escribir de memoria la identidad weeklyGMVPerActiveBuyer = averageOrderValue × ordersPerActiveBuyer; nombrar al menos tres palancas de nivel inferior que mueven a esos dos componentes; y explicar la diferencia entre un input real y un input redundante (que es, en realidad, la misma señal repetida).

Con la North Star y su árbol de inputs ya definidos, la lección 5 introduce la advertencia central del módulo: qué pasa cuando el equipo empuja cualquiera de estas palancas —o la North Star misma— sin ningún cuidado adicional. Esa advertencia tiene nombre: la ley de Goodhart.

Recursos

• Mixpanel, "Go beyond the North Star: How to operationalize your growth strategy with metric trees" — mixpanel.com/blog/beyond-north-star-metric-trees. Describe el árbol de métricas como "el mapa detallado" que conecta la North Star (la brújula estratégica) con sus input metrics — el mismo concepto de esta lección, con ejemplos fuera de un marketplace. En inglés.
• Amplitude, North Star Hub — amplitude.com/north-star-hub. Incluye una sección específica sobre cómo identificar y priorizar input metrics una vez que la North Star ya está elegida. En inglés.
• Sean Ellis, "Finding the Right North Star Metric" — medium.com/growthhackers/finding-your-north-star-metric-fc1c1f71cbcb. Incluye ejemplos de cómo Facebook y Uber descompusieron su North Star en un puñado de input metrics accionables por equipos específicos. En inglés.