Saltar al contenido

Tests A/B con poco tráfico

Con el tráfico de una startup, la mayoría de los tests A/B carecen de potencia estadística: no puedes detectar con fiabilidad efectos pequeños, así que lo honesto es probar solo cambios grandes, usar métodos que necesitan menos muestras o no hacer el test. Esta guía explica cómo saber en qué situación estás y qué hacer en su lugar.

Actualizado el 8 min de lecturaPor fromHello

Lo esencial

  1. La potencia estadística es la probabilidad de que un test detecte un efecto real. Poco tráfico significa poca potencia, así que solo se detectan diferencias grandes.

  2. El efecto mínimo detectable (MDE) sube a medida que se reduce la muestra: a escala de startup eso suele significar cambios del 20 % o más, no del 2 %.

  3. Los métodos secuenciales y bayesianos reducen el problema del tamaño de muestra. No lo eliminan.

  4. A menudo lo correcto es no hacer un test A/B: lanza el cambio con una métrica de salvaguarda, haz una apuesta mayor o recurre a lo cualitativo.

Por qué el poco tráfico rompe la mayoría de los tests A/B

Un test A/B compara dos versiones y se pregunta si la diferencia es real o ruido. Para responder, necesita observaciones suficientes para separar la señal del azar, y las startups rara vez las tienen. Con unos cientos de conversiones al mes, las matemáticas dicen que solo puedes detectar diferencias grandes, así que el consejo popular de testearlo todo te lleva a lanzar tests que nunca iban a llegar a una conclusión. Elegir los pocos tests que vale la pena lanzar es justo el objetivo de una hoja de ruta de experimentación.

Potencia estadística y MDE, en palabras simples

La potencia estadística es la probabilidad de que un test detecte un efecto real cuando existe; el objetivo habitual es el 80 %. El efecto mínimo detectable (MDE) es la mejora más pequeña que un test puede captar con esa potencia, dada tu tasa base y tu tamaño de muestra. Ambos van juntos: menos visitas hacen subir el MDE. A escala de startup, el MDE suele ser un cambio relativo del 20 % al 50 %, no el 2 % que podría dar el color de un botón. Si tu cambio es menor que tu MDE, el test no puede verlo en ningún plazo realista.

Con el tráfico de una startup, solo los efectos grandes son detectables: el cuadrante resaltado es donde los tests A/B con poco tráfico funcionan de verdad. Los efectos pequeños necesitan una escala que todavía no tienes.

Por qué solo se detectan los efectos grandes

El tamaño de muestra necesario crece aproximadamente con el inverso del cuadrado del efecto que quieres detectar, así que reducir el MDE a la mitad multiplica más o menos por cuatro las visitas que necesitas. El propio ejemplo de Optimizely le pone cifras: con una tasa base del 10 %, detectar una mejora del 3 % requiere unas quince veces las visitas que necesita una mejora del 10 %. Los efectos que un equipo pequeño puede medir con honestidad son, por tanto, los gruesos: una nueva página de precios, un flujo de onboarding rehecho, una oferta principal distinta, no los microtextos. Un CRO Specialist dedica la mayor parte de su tiempo a decidir qué cambios son lo bastante grandes para merecer un test.

Los tests secuenciales y bayesianos ayudan, un poco

Los métodos secuenciales te permiten parar antes cuando un resultado es concluyente, con unas matemáticas pensadas para resistir revisiones repetidas. El diseño secuencial de Evan Miller puede reducir las observaciones entre un 25 % y un 50 % cuando el efecto real es grande, y existe precisamente para que no tengas que mirar antes de tiempo un test de muestra fija. Los enfoques bayesianos indican la probabilidad de que una variante supere a otra en lugar de un p-valor, lo que es más fácil de interpretar a mitad de camino. Ambos reducen el problema del tamaño de muestra. Ninguno lo elimina: si el efecto real es diminuto, cualquier método sigue necesitando más datos de los que tienes.

Prueba cambios más grandes y evita mirar antes de tiempo

Dos reglas mantienen honestos los tests con poco tráfico. Primero, prueba cambios más grandes: elige cambios lo bastante amplios para superar tu MDE y lanza un único test A/B limpio en lugar de una cuadrícula multivariante que divida aún más tu tráfico. Segundo, fija el tamaño de muestra y la regla de parada antes de empezar, y no declares un ganador el primer día en que parezca significativo: mirar antes de tiempo un test de muestra fija es la forma en que el ruido se lanza como si fuera una victoria. Si ejecutas divisiones automáticas dentro de un journey, se aplica la misma disciplina: registra de antemano la métrica y el horizonte. Un grupo de control (holdout) —una parte que mantienes a propósito en la experiencia anterior— es una forma sencilla de comprobar que un efecto es real. Los equipos pequeños hacen pocos tests, así que elige los que vale la pena lanzar y hazlos bien.

FAQ

Preguntas frecuentes

  • ¿Cuánto tráfico necesito para hacer un test A/B?

    Depende de tu tasa de conversión base y del efecto que quieres detectar, no de un número fijo de visitas. Como referencia aproximada, la guía de VWO cita umbrales orientativos de menos de ~1.000 visitas o 5–10 conversiones por semana. Por debajo de eso, prevé probar solo cambios grandes o renunciar a los tests formales.

  • ¿Los tests secuenciales o bayesianos resuelven el problema del poco tráfico?

    Ayudan, pero no lo resuelven. Ambos pueden terminar un test antes cuando el efecto es grande, pero si la diferencia real es pequeña, cualquier método sigue necesitando datos que no tienes. Reducen el problema del tamaño de muestra en lugar de eliminarlo.

  • ¿Debería una startup hacer tests A/B?

    A veces. Reserva los tests para cambios lo bastante grandes como para superar tu efecto mínimo detectable. Para todo lo demás, lanza con una métrica de salvaguarda, agrupa los cambios pequeños o usa investigación cualitativa. Lanzar tests sin potencia hace perder semanas y genera una falsa seguridad.

  • ¿Qué es mirar antes de tiempo (peeking) y por qué es un problema?

    Peeking es revisar una y otra vez un test de muestra fija y pararlo en cuanto parece significativo. Infla los falsos positivos, porque el ruido cruza el umbral por azar si miras con suficiente frecuencia. Fija de antemano el tamaño de muestra y la regla de parada, o usa un método pensado para revisiones secuenciales.

fromHello es software de automatización de marketing de código abierto: mensajes activados por lo que hace la gente.

fromHello Cloud está en acceso anticipado a través de la lista de espera.

Acceso anticipado

fromHello Cloud

Nadie emprende para quedarse pequeño.

El acceso anticipado a fromHello Cloud se abre por etapas. El onboarding es personalizado: te ayudamos a configurarlo y a traer tus contactos.

Te escribiremos cuando se abra tu plaza. Sin spam.

¿Aún no quieres unirte? Ver en GitHub