Ganar el experimento no es lo mismo que lanzar el producto

Descripción

recommendations ganó. El z-test de la guía de métricas lo confirmó con un p-value de 0.0114: la diferencia en checkoutConversion entre control y variant no es azar. Es tentador leer eso y pasar directo a "entonces préndelo para todos" — como si la significancia estadística fuera, por sí sola, el permiso para exponer al 100% de la base de Mercado. Esta lección existe para frenar ese salto y mostrar, con números concretos, por qué "ganó" y "está listo para todos" son dos afirmaciones distintas.

Conexión con el módulo. Esta lección abre el arco temático del módulo con el error que todas las lecciones siguientes van a ayudarte a evitar: la lección 3 reformula el lanzamiento como una decisión de riesgo (no un interruptor que se enciende porque el experimento dio bien), la lección 4 pone número exacto a cuánta gente queda expuesta según cuánto expandes el lanzamiento, y la lección 7 cierra el módulo aplicando todo esto al caso específico de recommendations. Hoy construyes el argumento más simple de los cuatro: el experimento, por diseño, solo probó una fracción de la gente que la feature eventualmente va a tocar.

Una analogía: la prueba de manejo y la carretera completa

Antes de aprobar un modelo de auto nuevo para venta masiva, un fabricante lo prueba en pista cerrada, con conductores entrenados, en condiciones controladas: cierto rango de velocidades, cierto tipo de pavimento, cierto clima. Si el auto se comporta bien ahí —frena a tiempo, no se sale de control, el motor no falla—, el fabricante tiene evidencia real de que el diseño funciona. Lo que no tiene todavía es evidencia de cómo se comporta ese mismo auto con diez millones de conductores distintos, en carreteras de montaña, bajo lluvia, manejado por gente cansada a las tres de la mañana. La pista cerrada no fue una pérdida de tiempo — fue exactamente el paso correcto antes de vender el auto—. Pero "pasó la pista" y "ya se puede vender en todo el país sin ningún control adicional" son dos afirmaciones distintas, y ningún fabricante serio confunde la una con la otra.

El A/B test de recommendations es la pista cerrada de Mercado: condiciones controladas, una porción acotada de usuarios, un periodo definido. El p-value de 0.0114 dice que el auto se comportó bien en la pista. No dice, todavía, cómo se comporta con el resto de los diez millones de conductores.

Ejemplo trabajado: exposureGap() sobre el experimento real de recommendations

La guía de métricas cerró el z-test con dos números concretos: 12,000 usuarios en control y 12,000 en variant — 24,000 personas en total pasaron por el experimento—. Mercado, como negocio, tiene una base de compradores alcanzable de 250,000 personas para esta feature (la misma cifra que ya viste cuando se dimensionó la oportunidad en product-thinking-for-engineers-guide). Vamos a medir la brecha entre esas dos cifras:

// exposureGap: cuantos usuarios el experimento realmente probo, contra cuantos
// existen en la base total alcanzable por la feature. El z-test (guia hermana,
// product-metrics) ya confirmo que el efecto es real DENTRO de esa muestra; esto
// mide que tan chica es esa muestra frente al total.
function exposureGap({ testedUsers, totalUsers }) {
  const untestedUsers = totalUsers - testedUsers;
  const multiplier = Math.round((totalUsers / testedUsers) * 10) / 10;
  return { testedUsers, totalUsers, untestedUsers, multiplier };
}

// Los mismos numeros que cerraron el A/B test en product-metrics: 12,000 en
// control + 12,000 en variant = 24,000 probados, contra una base alcanzable de
// 250,000 compradores.
const recommendationsTest = { testedUsers: 24000, totalUsers: 250000 };
const gap = exposureGap(recommendationsTest);

console.log('=== Lo que el A/B test de recommendations realmente probo ===\n');
console.log('Usuarios en el experimento (control + variant): ' + gap.testedUsers.toLocaleString('en-US'));
console.log('Usuarios totales alcanzables por la feature: ' + gap.totalUsers.toLocaleString('en-US'));
console.log('Usuarios que NUNCA vieron variant durante el test: ' + gap.untestedUsers.toLocaleString('en-US'));
console.log('Si lanzas a 100%, expones a ' + gap.multiplier + 'x mas gente que la que el experimento cubrio.');

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

=== Lo que el A/B test de recommendations realmente probo ===

Usuarios en el experimento (control + variant): 24,000
Usuarios totales alcanzables por la feature: 250,000
Usuarios que NUNCA vieron variant durante el test: 226,000
Si lanzas a 100%, expones a 10.4x mas gente que la que el experimento cubrio.

Fíjate en el número central: 226,000 personas —el 90.4% de la base alcanzable— nunca vieron variant durante el experimento. El p-value de 0.0114 es una afirmación sólida sobre esos 24,000. No dice nada, directamente, sobre esos otros 226,000 — no porque el experimento haya sido mal diseñado (12,000 por grupo es, de hecho, una muestra sana para el efecto que se buscaba detectar), sino porque ningún experimento se diseña para cubrir al 100% de la base antes de saber si vale la pena. Ese es precisamente el propósito de un experimento: aprender barato, sobre una fracción, antes de comprometer al resto.

Por qué el guardrail roto hace esto más urgente, no menos

Hay una segunda pieza que la lección 1 ya adelantó y que vuelve este punto todavía más importante: el guardrail de latencia (p95 de 650ms a 910ms, techo 800ms) ya se rompió dentro de esos 24,000 usuarios probados. No es una posibilidad teórica de lo que podría pasar al escalar — ya pasó, en la muestra controlada. Eso significa que, si expones a los 226,000 usuarios restantes de golpe, no estás apostando a que "tal vez" aparezca un problema nuevo: estás multiplicando por 10.4 un problema que ya está confirmado. La pregunta que abre el resto de este módulo no es "¿existe el riesgo de la latencia?" —esa ya la contestó el experimento, y la respuesta es sí—. La pregunta es "¿a cuánta gente se lo expones mientras decides qué hacer con eso?"

Errores comunes

Leer "p < 0.05" como "listo para producción completa". Qué pasa: en la reunión donde se presenta el resultado del experimento, alguien dice "ganamos, prendámoslo" en la misma frase donde se menciona el p-value, sin ninguna pausa entre las dos afirmaciones. Por qué pasa: un p-value bajo se siente como una autorización completa —después de todo, es "significativo"—, y separar "el efecto es real" de "es seguro exponer a todos" exige un paso mental adicional que es fácil saltarse bajo presión de tiempo. Cómo detectarlo: nadie en la sala puede contestar "¿y cuántos usuarios vio realmente el experimento, comparado con la base total?" sin buscar el número. Cómo corregirlo: como en el ejemplo de hoy, calcula siempre el exposureGap antes de decidir el siguiente paso — el multiplicador (10.4x en este caso) es el recordatorio concreto de cuánto más grande es el salto que estás por dar.

Tratar un guardrail roto en el experimento como si fuera una sorpresa que aparecerá "quizás" al escalar. Qué pasa: alguien argumenta "vamos a lanzar y ver qué pasa con la latencia", como si el resultado de la latencia todavía estuviera en duda. Por qué pasa: la atención del equipo se concentra en la métrica primaria (que ganó), y el guardrail roto se archiva mentalmente como "un detalle a vigilar después", en vez de "un hecho ya confirmado, ahora, sobre esta misma muestra". Cómo detectarlo: se habla del guardrail roto en tiempo futuro ("podría afectar la latencia") en vez de tiempo pasado ("ya afectó la latencia, en el experimento mismo"). Cómo corregirlo: nombra el guardrail roto como lo que es —un resultado medido, no una hipótesis— y trátalo con la misma seriedad que el resultado ganador de la métrica primaria.

Confundir el tamaño de muestra "suficiente para el z-test" con "suficiente para lanzar sin cuidado". Qué pasa: alguien defiende que 12,000 por grupo ya es una muestra grande, así que no hace falta ninguna precaución adicional al escalar. Por qué pasa: 12,000 sí es un número grande comparado con la intuición cotidiana, y es fácil olvidar que "suficiente para detectar el efecto con rigor estadístico" y "representativo de cómo se comporta el sistema completo bajo el 100% del tráfico" son dos preguntas distintas. Cómo detectarlo: la defensa de "ya es una muestra grande" no viene acompañada de ningún número que compare esa muestra contra la base total. Cómo corregirlo: usa siempre el multiplicador de exposureGap —no el tamaño absoluto de la muestra— como referencia de cuánto crece el radio de impacto al pasar de la muestra al 100%.

Ejercicios

Ejercicio 1 — Calcula la brecha para un experimento distinto. El equipo de vendedores de Mercado corre un experimento de sellerDashboard con 800 vendedores en control y 800 en variant, sobre una base alcanzable de 3,000 vendedores activos. Usa exposureGap() (a mano o mentalmente) para calcular untestedUsers y el multiplicador de exposición.

Ver solución

testedUsers = 1,600 (800 + 800). untestedUsers = 3,000 - 1,600 = 1,400. multiplier = round((3000 / 1600) * 10) / 10 = 1.9. Aunque el multiplicador (1.9x) es mucho más chico que el de recommendations (10.4x) —porque la base alcanzable de vendedores es mucho más pequeña que la de compradores—, la misma lógica aplica: el experimento probó 1,600 de 3,000, y lanzar a los 1,400 restantes de golpe sigue siendo un salto de exposición, aunque proporcionalmente más chico que el de recommendations.

Ejercicio 2 — Ubica el error. Un compañero de equipo dice: "El experimento tuvo 24,000 usuarios, que es una muestra gigante. No necesitamos ser tan cuidadosos al lanzar." ¿Qué error de esta lección está cometiendo, y qué pregunta le harías para corregirlo?

Ver solución

Está cometiendo el tercer error común: confundir "el tamaño de muestra fue suficiente para el z-test" con "el tamaño de muestra hace innecesaria la precaución al lanzar". 24,000 es, en efecto, una muestra sana para detectar el lift con rigor estadístico —eso ya lo confirmó la guía de métricas—. Pero sigue siendo solo el 9.6% de la base alcanzable (250,000). La pregunta correctora: "¿24,000 comparado con qué? ¿Cuántos usuarios totales va a tocar esta feature, y qué fracción de esos ya vio variant?" — la respuesta (10.4x más gente sin probar) es la que debería cambiar la conversación de "es una muestra gigante" a "es una muestra sana, y aun así una fracción chica del total".

Ejercicio 3 — El guardrail como evidencia, no como riesgo hipotético. En dos o tres frases, explica por qué decir "hay riesgo de que la latencia empeore al escalar recommendations" es una forma más débil —y menos precisa— de describir la situación real de Mercado que decir "la latencia ya empeoró, dentro del experimento mismo".

Ver solución

"Hay riesgo de que empeore" describe una posibilidad futura, no confirmada, sobre la que razonablemente se podría decir "vamos a lanzar y ver qué pasa" — como si fuera información que todavía falta. Pero el guardrail de latencia (p95 a 910ms, sobre el techo de 800ms) se midió dentro del experimento controlado, con los mismos 24,000 usuarios que confirmaron el resultado ganador. No es una proyección: es un dato ya observado. Describir la situación con precisión —"la latencia ya se rompió, en la muestra que ya probamos"— deja mucho menos espacio para posponer la precaución, porque no hay ninguna incertidumbre que resolver sobre si el problema existe; la única pregunta abierta es qué hacer con él antes de exponer a más gente.

Resumen y siguiente paso

En esta lección separaste dos afirmaciones que suenan parecidas pero no lo son: "el experimento ganó, con significancia estadística" y "está listo para exponer al 100% de la base". Con exposureGap() mediste la distancia real entre las dos en el caso de recommendations: el experimento probó 24,000 de 250,000 usuarios alcanzables —apenas el 9.6%—, y lanzar a toda la base de golpe multiplicaría por 10.4 la exposición a un guardrail de latencia que ya se rompió dentro de la muestra probada, no que "podría" romperse después.

Antes de avanzar deberías poder: explicar con tus propias palabras por qué la significancia estadística no equivale a estar listo para el 100% de exposición; calcular el exposureGap de un experimento dado su tamaño de muestra y la base total; y describir por qué un guardrail roto durante el experimento es evidencia confirmada, no una posibilidad hipotética.

La lección 3 toma esta brecha de exposición y la convierte en un marco de decisión completo: si lanzar no es "prender un interruptor", ¿qué es exactamente? Vas a ver el lanzamiento reformulado como una decisión de riesgo con dos ejes —qué tan grave si sale mal, qué tan fácil es volver atrás— y por qué ese marco, y no la estadística por sí sola, es el que decide cómo se lanza recommendations.

Recursos

• Ron Kohavi, Diane Tang y Ya Xu, Trustworthy Online Controlled Experiments — experimentguide.com. El sitio del libro de referencia en experimentación online; su capítulo sobre validez externa desarrolla, a nivel de industria, por qué el resultado de un experimento controlado no se traduce automáticamente al comportamiento del 100% del tráfico. En inglés.
• Google SRE Book, Capítulo 3, "Embracing Risk" — sre.google/sre-book/embracing-risk. El capítulo que define el error budget: cuánta "no confiabilidad" es aceptable antes de frenar. Un adelanto de cómo la industria piensa el riesgo aceptable, que retoma el módulo 6 de esta guía. En inglés.