Tamaño de muestra y power

Descripción

Con el MDE definido (lección 2) y alpha ya conocido del módulo 6 (el riesgo de falso positivo, 0.05 por convención), falta un solo ingrediente para poder calcular cuántos usuarios por variante necesita el experimento: el power (o 1 - beta). El power es la probabilidad de que tu experimento detecte un efecto real, dado que ese efecto de verdad existe y tiene el tamaño de tu MDE. Un power de 0.80 —el estándar de la industria, el mismo que vas a usar hoy— significa: si el efecto real es del tamaño de mi MDE, mi experimento lo va a detectar el 80% de las veces que lo corra.

Fíjate en la palabra "detectar" y en la condición "si el efecto real existe" — el power es la contraparte exacta de alpha, pero mirando en la dirección opuesta. Alpha contesta "¿qué tan seguido mi test grita 'hay un efecto!' cuando en realidad no hay ninguno?" (falso positivo). El power contesta "¿qué tan seguido mi test SÍ detecta un efecto que de verdad está ahí?" — y su complemento, beta (beta = 1 - power), es la probabilidad del error opuesto: un falso negativo, no detectar un efecto que sí existe. Con alpha, power y el MDE de la lección 2, por fin tienes los tres ingredientes completos de la fórmula de tamaño de muestra — el número que esta lección construye y ejecuta.

Conexión con el módulo. Esta lección construye sampleSize(), la función central de este módulo, reutilizada sin cambios en el mini-proyecto de la lección 8 para dimensionar el A/B test de recommendations desde cero. El alpha=0.05 que usa esta función es exactamente el mismo alpha que el módulo 6 usó para calcular el p-value de abTest() — dos caras de la misma decisión: qué tan dispuesto estás a equivocarte declarando un efecto que no existe.

Una analogía: la prueba de embarazo y sus dos formas de fallar

Una prueba de embarazo puede fallar de dos maneras completamente distintas. Puede dar positivo cuando en realidad no hay embarazo —un falso positivo—, o puede dar negativo cuando en realidad sí lo hay —un falso negativo—. Ningún fabricante de estas pruebas promete cero errores de ningún tipo; en cambio, publican dos números: qué tan seguido ocurre cada tipo de error. Una prueba con alpha muy bajo casi nunca da positivo por error — pero si además tiene poco power, también se le escapan embarazos reales con demasiada frecuencia, dando negativo cuando no debería. Una prueba bien diseñada busca las dos cosas a la vez: pocos falsos positivos (alpha bajo) y alta capacidad de detectar lo real cuando está ahí (power alto) — y lograr ambas cosas simultáneamente, como vas a ver hoy, es exactamente lo que exige una muestra suficientemente grande.

Un A/B test tiene la misma estructura de dos errores. Alpha (ya lo conoces del módulo 6) es la probabilidad de que el z-test diga "recommendations tiene un efecto" cuando en realidad no tiene ninguno — el falso positivo. Beta es la probabilidad de que el z-test diga "no hay evidencia de ningún efecto" cuando recommendations sí está generando el lift que buscabas — el falso negativo, el equivalente exacto de una prueba de embarazo que no detecta un embarazo real. El power (1 - beta) es la probabilidad de evitar ese segundo error: detectar el efecto cuando de verdad está ahí. Y aquí está la pieza que conecta todo con el MDE de la lección anterior: cuanto más chico es el efecto real que estás tratando de detectar, más se parece —igual que un embarazo recién empezado, apenas detectable— al ruido de fondo, y más "sensible" (más muestra) necesita tu prueba para no dejarlo pasar.

Ejemplo trabajado: sampleSize() sobre recommendations

La fórmula estándar de tamaño de muestra para comparar dos proporciones —la misma que usan calculadoras como la de Evan Miller o la de Optimizely— es esta:

n_por_variante = ((z_alpha/2 + z_beta)^2 * (p1*(1-p1) + p2*(1-p2))) / (p2-p1)^2

Donde p1 es el baseline (la tasa de control), p2 = p1 * (1 + MDE) (la tasa que quieres poder distinguir de p1), z_alpha/2 = 1.96 para un alpha de 0.05 a dos colas (el mismo valor crítico del z-test del módulo 6), y z_beta = 0.84 para un power de 0.80. El numerador combina cuánta confianza exiges (z_alpha/2 y z_beta, más grandes si quieres más rigor) con cuánto "ruido" natural hay en los datos (p1*(1-p1) + p2*(1-p2), la varianza combinada de las dos proporciones). El denominador es la brecha entre p1 y p2 elevada al cuadrado — y ese cuadrado, como vas a ver en la salida de hoy, es la razón matemática exacta de por qué un MDE chico exige tanta muestra.

// sampleSize: formula estandar de tamano de muestra para dos proporciones
// independientes (control vs variant), sin dependencias externas.
// z_alpha/2 = 1.96 (alpha=0.05, dos colas) y z_beta = 0.84 (power=0.80) son
// los valores criticos estandar de la distribucion normal para estos umbrales
// convencionales -- los mismos alpha=0.05 del z-test del modulo 6.
function sampleSize({ baseline, mde, alpha = 0.05, power = 0.80 }) {
  const zAlpha2 = 1.96;
  const zBeta = 0.84;
  const p1 = baseline;
  const p2 = baseline * (1 + mde);
  const numerator = Math.pow(zAlpha2 + zBeta, 2) * (p1 * (1 - p1) + p2 * (1 - p2));
  const denominator = Math.pow(p2 - p1, 2);
  return Math.ceil(numerator / denominator); // redondeo SIEMPRE hacia arriba
}

function fmt(n) {
  return String(n).replace(/\B(?=(\d{3})+(?!\d))/g, ',');
}

// Datos pedagogicos: checkoutConversionRate de Mercado, baseline=3.2% (la
// tasa de control, identica al modulo 5). Probamos los mismos MDE de la
// tabla de la leccion 2.
const baseline = 0.032;
console.log('=== sampleSize() sobre recommendations, baseline=3.2%, alpha=0.05, power=0.80 ===\n');
[0.20, 0.10, 0.05].forEach((mde) => {
  const n = sampleSize({ baseline, mde });
  const p2 = baseline * (1 + mde);
  console.log('MDE=' + (mde * 100).toFixed(0).padStart(2) + '%  ->  p2=' + (p2 * 100).toFixed(3) +
    '%  ->  n por variante = ' + fmt(n));
});

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

=== sampleSize() sobre recommendations, baseline=3.2%, alpha=0.05, power=0.80 ===

MDE=20%  ->  p2=3.840%  ->  n por variante = 12,997
MDE=10%  ->  p2=3.520%  ->  n por variante = 49,718
MDE= 5%  ->  p2=3.360%  ->  n por variante = 194,307

Ahí está, con números concretos, la relación que la lección 1 anticipó con la moneda apenas cargada: al pasar de un MDE de 20% a uno de 5% —cuatro veces más chico—, el tamaño de muestra necesario no se cuadruplica: se multiplica por casi 15, de 12,997 a 194,307 usuarios por variante. Esa explosión no es un accidente de estos números específicos — está escrita directamente en la fórmula: como el denominador es (p2-p1) al cuadrado, cuando reduces a la mitad la brecha entre p1 y p2, el denominador se achica a un cuarto, y el resultado completo (numerador dividido entre denominador) se multiplica, aproximadamente, por cuatro. Reducir el MDE no cuesta linealmente más muestra — cuesta cuadráticamente más.

Verificando la fórmula contra un caso conocido

Antes de confiar en cualquier implementación de una fórmula estadística, vale la pena confirmar que el orden de magnitud tiene sentido. Corremos sampleSize() sobre un segundo baseline, más alto (5%, un valor típico de conversión de e-commerce), con dos MDE distintos:

console.log('\n=== Verificacion: baseline=5%, un caso de referencia distinto ===\n');
[0.20, 0.10].forEach((mde) => {
  const n = sampleSize({ baseline: 0.05, mde });
  console.log('baseline=5%  MDE=' + (mde * 100).toFixed(0) + '%  ->  n por variante = ' + fmt(n));
});

Qué esperar.

=== Verificacion: baseline=5%, un caso de referencia distinto ===

baseline=5%  MDE=20%  ->  n por variante = 8,146
baseline=5%  MDE=10%  ->  n por variante = 31,196

Ambos números caen exactamente donde la intuición estadística dice que deberían caer: miles a decenas de miles de usuarios por variante para detectar lifts relativamente chicos (10-20%) sobre un baseline de un solo dígito — el mismo orden de magnitud que reportan calculadoras públicas de tamaño de muestra, como la de Evan Miller o la de Optimizely, para escenarios de conversión comparables. Si sampleSize() hubiera devuelto, por ejemplo, decenas en vez de miles, o millones en vez de miles, eso sería una señal clara de un error en la implementación — la fórmula está calibrada para producir números en este rango para conversiones de un solo dígito y MDEs de doble dígito, y confirmar eso, antes de confiar en el resultado sobre datos reales, es exactamente la disciplina de verificación que ya viste con abTest() en el módulo 6.

Errores comunes

Decidir la duración del experimento "a sentimiento", sin haber calculado el tamaño de muestra primero. Qué pasa: un equipo decide correr un experimento "dos semanas, para tener tiempo de ver algo" o "hasta que se sienta suficiente", sin haber calculado antes cuántos usuarios por variante hacen falta para el MDE que les importa. Por qué pasa: fijar una duración en calendario (semanas) se siente más natural y más fácil de planificar que fijar un número de usuarios, sobre todo antes de conocer la fórmula de esta lección. Cómo detectarlo: nadie en el equipo puede citar el n objetivo por variante, solo la fecha en la que "se va a revisar el resultado". Cómo corregirlo: siempre calcula sampleSize() primero, con el baseline, el MDE, alpha y power definidos de antemano — y después traduce ese n a una duración estimada, dividiendo entre el tráfico semanal esperado por variante. La duración es una consecuencia del tamaño de muestra, nunca el punto de partida.

Redondear el resultado de sampleSize() hacia abajo, "para ahorrar tiempo". Qué pasa: sampleSize() devuelve, por ejemplo, 12,997 usuarios por variante, y alguien decide redondear a 12,000 "para simplificar" o porque el tráfico disponible se queda un poco corto. Por qué pasa: la diferencia parece mínima (menos del 8%), y cortar unos días de espera al final del experimento se siente como una ganancia razonable. Cómo detectarlo: el n real usado en el experimento es menor al n que sampleSize() calculó para el MDE y power declarados. Cómo corregirlo: Math.ceil() en el código de hoy no es un detalle de implementación — es la garantía de que el power prometido (80% de probabilidad de detectar el efecto, si existe) se mantiene. Redondear hacia abajo reduce el power real por debajo del 80% declarado, sin que nadie lo haya decidido explícitamente — exactamente el tipo de atajo silencioso que hace que un experimento "pase raspando" en vez de estar bien dimensionado.

Confundir z_alpha/2 con z_beta, o usar un solo término en vez de la suma de ambos. Qué pasa: alguien reimplementa la fórmula usando solo z_alpha/2 (1.96) en el numerador, olvidando sumarle z_beta (0.84) — un error fácil de cometer porque alpha ya es familiar del módulo 6, mientras que z_beta es nuevo en esta lección. Por qué pasa: la fórmula del z-test de significancia (módulo 6) usa un solo valor crítico (z_alpha/2), y es fácil asumir, por costumbre, que el tamaño de muestra funciona igual. Cómo detectarlo: el n calculado sale sistemáticamente más chico de lo esperado — omitir z_beta reduce el término (z_alpha/2 + z_beta)^2 de 2.8^2 = 7.84 a solo 1.96^2 = 3.84, casi la mitad. Cómo corregirlo: recuerda que el tamaño de muestra depende de dos riesgos distintos —el falso positivo (alpha, ya conocido) y el falso negativo (beta, nuevo hoy)— y la fórmula necesita los dos valores críticos sumados, exactamente como en sampleSize() de hoy: Math.pow(zAlpha2 + zBeta, 2).

Ejercicios

Ejercicio 1 — Calcula el impacto de subir el power. Sin ejecutar Node todavía, predice: si mantienes baseline=3.2% y MDE=20%, pero subes el power de 0.80 a 0.90 (lo que sube z_beta de 0.84 a aproximadamente 1.28), ¿el n necesario sube o baja? Después, modifica sampleSize() para aceptar ese zBeta como parámetro y confirma tu predicción ejecutando el código.

Ver solución

El n necesario sube. Un power más alto (0.90 en vez de 0.80) exige una probabilidad mayor de detectar el efecto real si existe, lo cual siempre requiere más muestra, nunca menos — es una exigencia adicional sobre la misma prueba, no una relajación. Al modificar sampleSize() para usar zBeta=1.28 en vez de 0.84, el término (zAlpha2 + zBeta)^2 sube de 2.8^2=7.84 a 3.24^2=10.4976 — un incremento de aproximadamente 34%, que se refleja directamente en un n cerca de 34% más grande (de 12,997 a aproximadamente 17,400). La lección general: cualquier exigencia adicional de rigor —alpha más bajo, power más alto, MDE más chico— siempre se paga con más muestra, nunca al revés.

Ejercicio 2 — Traduce n a semanas de experimento. Si checkoutConversionRate de Mercado recibe, en promedio, 4,000 usuarios nuevos por semana repartidos parejo entre control y variant (2,000 por variante por semana), ¿cuántas semanas necesitaría el experimento para alcanzar el n=12,997 por variante del MDE=20% de hoy?

Ver solución

12,997 / 2,000 ≈ 6.5 semanas, redondeado hacia arriba a 7 semanas (nunca redondees la duración hacia abajo, por la misma razón del segundo error común de hoy: te dejaría por debajo del n objetivo y del power prometido). Nota que esto es muy cercano a las 6 semanas reales que usó el experimento de recommendations en los módulos 5 y 6 — una coincidencia que el mini-proyecto de la lección 8 va a explorar con más detalle.

Ejercicio 3 — Decide entre tres opciones con tráfico limitado. Mercado solo tiene 3,000 usuarios nuevos por semana disponibles para un experimento nuevo (1,500 por variante por semana), y el equipo quiere terminarlo en un máximo de 8 semanas (12,000 usuarios por variante en total). Con baseline=3.2%, alpha=0.05 y power=0.80, ¿qué MDE es el más chico que ese experimento puede permitirse detectar, usando la tabla de hoy como referencia? ¿Qué harías si el equipo insiste en poder detectar un MDE de 5%?

Ver solución

Con 12,000 usuarios por variante disponibles en 8 semanas, el experimento puede detectar, con power=0.80, un MDE de 20% (que necesita 12,997 — muy cerca del límite disponible) pero no puede detectar un MDE de 10% (que necesita 49,718) ni mucho menos de 5% (194,307) — ambos exigen muchísima más muestra de la que el tráfico permite en 8 semanas. Si el equipo insiste en un MDE de 5%, las opciones reales son: (a) extender la duración del experimento drásticamente —194,307 usuarios por variante, a 1,500 por semana, tomarían más de 129 semanas, casi dos años y medio, claramente inviable—; (b) aceptar un power más bajo (menos confiable, corre el riesgo de no detectar el efecto aunque exista); o (c), la respuesta correcta en la práctica, aceptar que con este tráfico el experimento solo puede dimensionarse con honestidad para un MDE más grande, y reservar la detección de efectos más chicos para cuando el producto tenga más tráfico. Fingir que se puede detectar un MDE de 5% con 12,000 usuarios sería, precisamente, la clase de atajo que el segundo error común de esta lección advierte.

Resumen y siguiente paso

En esta lección completaste los tres ingredientes de la fórmula de tamaño de muestra —MDE (lección 2), alpha (ya conocido del módulo 6) y power— y construiste sampleSize(), ejecutada sobre checkoutConversionRate de Mercado: 12,997 usuarios por variante para un MDE de 20%, 49,718 para 10%, y 194,307 para 5%. Viste, con números reales, por qué esa relación no es lineal sino cuadrática —el denominador (p2-p1)^2 de la fórmula—, y verificaste el orden de magnitud de la implementación contra un segundo caso de referencia (baseline=5%).

Antes de avanzar deberías poder: explicar la diferencia entre alpha y power (los dos tipos de error que un experimento puede cometer); calcular sampleSize() a mano dado baseline, MDE, y los valores críticos estándar; y explicar por qué reducir el MDE a la mitad, aproximadamente, cuadruplica la muestra necesaria.

Con esto termina la primera mitad del módulo — la parte de "cuánta muestra necesito". La segunda mitad, lecciones 4 a 7, cambia de pregunta: aunque tengas exactamente la muestra correcta, ¿qué puede arruinar tu resultado de todas formas? La lección 4 abre ese catálogo con la primera trampa, y probablemente la más común: el peeking — el riesgo de mirar el experimento antes de que termine, y parar apenas ves algo prometedor.

Recursos

• Evan Miller, Sample Size Calculator (Evan's Awesome A/B Tools) — evanmiller.org/ab-testing/sample-size.html. Una calculadora interactiva de la misma fórmula implementada hoy — útil para explorar rápidamente cómo cambia n al mover baseline, MDE, alpha o power de forma independiente. En inglés.
• Optimizely, "Sample size calculations for A/B tests and experiments" — optimizely.com/insights/blog/sample-size-calculations-for-experiments. La misma fórmula estándar de proporciones, explicada desde la perspectiva de una plataforma de experimentación usada en producción por miles de equipos. En inglés.
• Wikipedia, "Power (statistics)" — en.wikipedia.org/wiki/Power_(statistics). Referencia formal de power, beta, y su relación con el tamaño de muestra y el tamaño del efecto — la base teórica completa detrás de sampleSize(). En inglés.