Significancia estadística

Sample size push: cuándo n=2.000 por arm no alcanza

Tabla de sample size mínimo para detectar lift en push por baseline CTR, lift esperado y poder estadístico. Por qué n=2.000 por arm raramente alcanza.

Soy Diego. He corrido 4.322 tests A/B/n en push notification ads. La pregunta que más recibí en consultoría desde que dejé iAdvize en marzo 2024 fue siempre la misma: “Estoy corriendo un test con n=2.000 por arm. ¿Es suficiente?”

La respuesta correcta es: depende del baseline y del lift que querés detectar. La mayoría de las veces, no alcanza.

La fórmula que importa

Para detectar diferencia de proporciones (CTR es proporción de clics sobre impresiones), el sample size por arm para poder 80% y α=0.05 se aproxima por:

n ≈ 16 · p · (1-p) / d²

donde p es el CTR baseline (en proporción, no porcentaje) y d es la diferencia mínima detectable absoluta (también en proporción).

Esta aproximación funciona bien para CTR entre 0,5% y 8%, que es donde vive el 95% del push real. Para CTR fuera de ese rango usá la fórmula exacta con z-scores.

La tabla para push

Tomo los baselines de CTR que aparecen con más frecuencia en mi base:

Baseline CTR 0,6% (Chrome mobile LATAM utility típico):

  • Para detectar lift relativo +25% (CTR sube a 0,75%, diferencia absoluta 0,15 pp): n≥10.640 por arm.
  • Para detectar lift relativo +50% (CTR sube a 0,9%, diferencia absoluta 0,3 pp): n≥2.660 por arm.
  • Para detectar lift relativo +100% (CTR sube a 1,2%, diferencia absoluta 0,6 pp): n≥670 por arm.

Baseline CTR 2,0% (Chrome desktop ES iGaming típico):

  • Para detectar lift relativo +10% (CTR sube a 2,2%, diferencia absoluta 0,2 pp): n≥7.840 por arm.
  • Para detectar lift relativo +20% (CTR sube a 2,4%, diferencia absoluta 0,4 pp): n≥1.960 por arm.
  • Para detectar lift relativo +30% (CTR sube a 2,6%, diferencia absoluta 0,6 pp): n≥870 por arm.

Baseline CTR 4,0% (Edge desktop tier-1 finanzas típico):

  • Para detectar lift relativo +10% (CTR sube a 4,4%, diferencia absoluta 0,4 pp): n≥3.840 por arm.
  • Para detectar lift relativo +15% (CTR sube a 4,6%, diferencia absoluta 0,6 pp): n≥1.710 por arm.
  • Para detectar lift relativo +25% (CTR sube a 5,0%, diferencia absoluta 1,0 pp): n≥615 por arm.

Qué dice la tabla sobre n=2.000

Si tu baseline es 2,0% y querés detectar un +10% (un lift que en push se considera comercialmente significativo), n=2.000 por arm tiene poder estadístico muy por debajo del 80% — alrededor del 30%. Eso significa que aunque exista una diferencia real del +10%, tu test la va a detectar 3 de cada 10 veces. Las otras 7 veces vas a concluir “no hay diferencia” cuando sí la hay.

Si tu baseline es 0,6% (push mobile LATAM) y querés detectar +25%, n=2.000 por arm tiene poder ~22%. Estás corriendo un test con 78% de probabilidad de declarar “no hay ganador” aun cuando hay ganador.

n=2.000 por arm es suficiente cuando: el lift mínimo que te interesa detectar es ≥30% relativo sobre baseline ≥2%. Fuera de esa ventana, casi nunca alcanza.

El error que veo en agencias hispanohablantes con más frecuencia

Caso típico: agencia corre test de 5 creativos (5 arms), 800 impresiones por arm por día durante 3 días, total n=2.400 por arm. Declara ganador al creativo con CTR 2,31% sobre baseline 1,98% (lift +16,7%). Calcula p=0.04. Concluye que el “ganador” es estadísticamente significativo.

Tres problemas con esa lectura:

  1. Múltiples comparaciones. Con 5 arms hay 10 comparaciones pareadas (4+3+2+1) si comparás todos contra todos, o 4 si comparás cada variante contra el control. Sin corrección Bonferroni, tu α efectivo no es 0.05 — es ~0.20 si comparás todos vs todos. El p=0.04 declarado como “significativo” probablemente no sobrevive a la corrección.

  2. Stopping rule mal definida. Si el test se cortó a día 3 porque “ya hay un ganador claro”, eso es peeking. La probabilidad de falso positivo bajo peeking diario es ~3-4x el α declarado.

  3. n=2,400 por arm con baseline 2% tiene poder ~40% para detectar +16.7% real. El p=0.04 puede ser un verdadero positivo, pero también puede ser un falso positivo con tasa real ~0.15 dado el peeking y las múltiples comparaciones.

Lo que hago cuando me consultan

Le pido al cliente tres números antes de mirar el test: baseline CTR del segmento (no del agregado), lift mínimo de interés comercial, y volumen disponible por día por arm. Con esos tres, calculo n necesario y días requeridos. Si los días requeridos son más que el budget para el test, el test no se corre — porque correrlo subdimensionado es peor que no correrlo: te da una conclusión engañosa con apariencia de rigor.

Si no me podés decir el sample size que necesitás antes de empezar, no me podés decir que ganaste después de terminar.

Una nota sobre la corrección Bonferroni

Para tests con K arms (K>2) corregí dividiendo α entre K-1 comparaciones contra control. Es conservador pero defendible. Para tests A/B/n con 5 arms, el α corregido es 0,0125 — y eso sube los requisitos de n entre 30 y 40%. Lo que para α=0.05 requería n=1.960 ahora requiere n≈2.720. Si el cliente quiere comparar todos contra todos, no me molesto: le digo que rediseñe el test como múltiples A/B secuenciales o que use Holm-Bonferroni. El A/B/n masivo sin corrección es la forma más común de p-hacking en push, y casi nadie la reconoce como tal.

Preguntas frecuentes

¿Cuál es la fórmula correcta para calcular el sample size en un test push?

Uso la aproximación n ≈ 16 · p · (1-p) / d², donde p es el baseline CTR en proporción decimal y d es la diferencia mínima detectable absoluta. Esta fórmula aplica para poder 80% y α=0,05. Funciona bien para CTR entre 0,5% y 8%, que cubre el 95% del push real. Para CTR fuera de ese rango hay que usar la fórmula exacta con z-scores. Si no podés decirme el n que necesitás antes de empezar, no podés decirme que ganaste después de terminar.

¿Cuándo sí alcanza n=2.000 por arm en push?

n=2.000 por arm es suficiente únicamente cuando el lift mínimo de interés es al menos +30% relativo sobre un baseline de al menos 2%. Concretamente: baseline 2%, lift +30% relativo, A/B simple sin múltiples comparaciones, poder 80% — el n mínimo es 870 por arm. Fuera de esa ventana específica, n=2.000 casi nunca alcanza. Con baseline 2% y lift +10%, el n necesario es 7.840 — cuatro veces más.

¿Por qué un p=0,04 en un test push de 5 arms puede no significar nada?

Con 5 arms y comparaciones de todos contra todos hay 10 pares posibles. Sin corrección Bonferroni, el α efectivo no es 0,05 sino ~0,20. Encima, si el test se cortó al día 3 porque “ya hay un ganador” (peeking), la probabilidad de falso positivo se multiplica ~3-4x. Y si el baseline es 2% con n=2.400 por arm, el poder estadístico para detectar un lift real de +16,7% es solo ~40%. El p=0,04 en ese contexto puede perfectamente ser ruido.

¿Qué es la corrección Bonferroni y por qué importa en tests A/B/n de push?

Cuando comparás K arms contra un control, la corrección Bonferroni divide α entre K-1 comparaciones. Para 5 arms es α=0,0125 en lugar de 0,05. Eso sube el n requerido por arm entre un 30% y un 40%. Si en vez de comparar contra control comparás todos contra todos — K(K-1)/2 pares — la corrección es aún más severa. El test A/B/n masivo sin corrección es la forma más común de p-hacking en push y casi nadie la reconoce como tal.

¿Qué hago si el volumen disponible no alcanza el n mínimo para el test?

No corro el test. Correrlo subdimensionado es peor que no correrlo porque produce una conclusión engañosa con apariencia de rigor. Si el n necesario requiere más días de los que el presupuesto permite, re-diseño el test: reduzco el número de arms, elevo el lift mínimo de interés (lo que reduce n), o acumulo volumen de múltiples GEOs/browsers antes de comparar. Nunca declaro ganador sobre un test que no tenía poder estadístico suficiente para ganar.

¿Qué baseline CTR de push suele requerir más sample size — mobile utility LATAM o desktop iGaming ES?

Mobile utility LATAM tiene baseline ~0,6% contra ~2,0% de Chrome desktop iGaming ES. Para detectar el mismo +25% de lift relativo, el test utility LATAM necesita n≥10.640 por arm mientras que iGaming ES necesita solo n≥1.960 para un +20%. La relación es no lineal: cada caída de un punto porcentual en baseline multiplica el n requerido por 1,5–2x. Push utility mobile LATAM es el tipo de tráfico donde más frecuentemente veo tests declarados con muestras 20 o 30 veces insuficientes.

Privacidad

Tus opciones de privacidad

Usamos cookies para que el sitio funcione y, con tu consentimiento, para medir el uso y personalizar el contenido. Puedes cambiar tus opciones cuando quieras.

Accesibilidad

Ajustes de accesibilidad

Personaliza el aspecto y el movimiento del sitio. Se guarda solo en este navegador.