CRO

¿Cuántos Tests A/B Deberías Hacer por Mes?

Cuántos tests A/B por mes banca tu sitio: la cuenta de capacidad a partir del tráfico, con calculadora y ejemplo trabajado.

Ilustración abstracta de una grilla de calendario en verde oscuro y teal, representando la cantidad de experimentos que caben en un mes

La respuesta honesta a “cuántos tests A/B hacer por mes” no es un número de benchmark: es la capacidad que banca tu tráfico, y sale de una cuenta de dos líneas. La duración de cada test es el mayor valor entre la muestra necesaria dividida por el tráfico diario y un piso de dos semanas; la capacidad mensual es la cantidad de días del mes dividida por esa duración. Este artículo muestra la cuenta, explica por qué los números de Booking y Microsoft no sirven de meta para casi nadie, revela el punto en el que más tráfico deja de comprar más tests y pasa a comprar más sensibilidad, y trae calculadoras en vivo con un ejemplo trabajado de punta a punta. Forma parte de la guía de cómo construir una cultura de experimentación.

Por qué el benchmark del mercado no sirve como meta

Todo artículo sobre velocidad de experimentación cita a los mismos gigantes. Microsoft documentó públicamente el programa de experimentación de Bing, con miles de experimentos corriendo a escala (Bing Search Quality Insights, Large Scale Experimentation at Bing). Casos de empresas como Booking.com, que según relatos públicos llegó a mantener cientos de tests simultáneos, circulan como referencia de excelencia.

Esos números describen una condición que casi nadie tiene: decenas de millones de sesiones por mes, plataforma interna dedicada y equipos enteros de infraestructura de experimentación. Copiar la meta sin copiar el tráfico produce el peor resultado posible: una cadencia artificialmente alta, tests cerrados antes de tiempo para “caber en el mes” y una secuencia de decisiones tomadas sobre ruido.

La pregunta útil no es “cuántos tests hace Booking”, es “cuántos tests banca mi tráfico con rigor estadístico”. Esa segunda pregunta tiene respuesta numérica exacta.

La cuenta de la capacidad

Son tres entradas y dos operaciones:

  1. Muestra por variación. Depende de la tasa base de conversión, del efecto mínimo detectable (MDE) y del rigor (estándar de mercado: 95% de confianza y 80% de poder). Es el mismo cálculo de la guía de cómo hacer un test A/B paso a paso.
  2. Muestra total del test. Muestra por variación multiplicada por el número de variaciones (2 en un A/B clásico).
  3. Tráfico diario en el flujo testeado. No el tráfico del sitio entero: solo quien entra en el flujo donde corre el test.

Con eso: días por test = el mayor valor entre (muestra total dividida por el tráfico diario) y el piso de duración, y tests por mes = 30 dividido por días por test.

El piso de duración merece explicación. Aunque el tráfico cierre la muestra en tres días, cerrar un test en tres días mide solo el comportamiento de martes a jueves, y el público de fin de semana suele convertir de forma distinta. Dos semanas es el piso más común de mercado porque captura dos ciclos semanales completos. Es ese piso el que transforma la cuenta en dos fases distintas, y la segunda sorprende a mucha gente.

Los dos cuellos de botella de la capacidad de testsCon poco tráfico, la duración de cada test está definida por el tiempo necesario para acumular muestra, y la capacidad mensual crece conforme aumenta el tráfico. A partir del punto en que la muestra cierra en menos de dos semanas, el piso de duración pasa a mandar y la capacidad se estanca en cerca de dos tests por mes.Tests por mes (misma tasa base y mismo MDE)la muestra pasa a cerrar en menos de 14 díaslimitado por el tráficomás visitantes = más testslimitado por el calendariomás visitantes = tests más sensibles,no más tests por mesTráfico mensual en el flujo testeadoEl excedente de tráfico después del codo de la curva debe volverse MDE menor, no test más corto.
La capacidad crece con el tráfico hasta el punto en que la muestra cierra antes del piso de duración. De ahí en adelante, el tráfico extra compra sensibilidad estadística, no cadencia.

Cuántos tests A/B por mes banca tu tráfico

La tabla de abajo aplica la cuenta a un escenario común: conversión base del 2,5%, dos variaciones, piso de 14 días, y la ambición de detectar un efecto relativo del 20% (lo que exige 16.792 visitantes por variación, 33.584 en total).

Visitantes por mes en el flujo Días limitados por el tráfico Duración real por test Tests por mes Cuello de botella
20.000 51 51 días 0,6 Tráfico
60.000 17 17 días 1,8 Tráfico
200.000 6 14 días 2,1 Calendario
600.000 2 14 días 2,1 Calendario

Muestra por aproximación normal de dos proporciones (95% de confianza, 80% de poder, bilateral), 2 variaciones, piso de 14 días, mes de 30 días.

Dos lecturas importantes salen de ahí. La primera: entre 200 mil y 600 mil visitantes mensuales, la capacidad no cambia. Triplicar el tráfico no dio ningún test más, porque el piso de dos semanas ya era el límite. La segunda: el sitio de 20 mil visitantes no está condenado a 0,6 tests por mes para siempre, solo que no logra detectar un efecto del 20% en ese plazo. Buscando un efecto mayor, la misma operación vuelve a caber en el calendario.

Calcula tu capacidad real, con tu tasa base, tu MDE y tu tráfico:

Calculadora de velocidad de tests A/B
-Tests por mes
-Tests por año
-Días por test

Muestra por variación al 95% de confianza y 80% de poder (bilateral), según tu tasa y MDE. Ajusta los campos y mira la capacidad en vivo.

Qué hacer con el tráfico excedente

Cuando el cuello de botella pasa a ser el calendario, el tráfico que sobra tiene un uso mejor que “cerrar el test en 6 días”: comprar sensibilidad. Con más muestra dentro de la misma ventana de 14 días, el mismo test pasa a detectar efectos menores, y los efectos menores son la mayor parte de los efectos reales.

En el escenario de la tabla, el sitio de 200 mil visitantes mensuales que baja la ambición de +20% a +10% relativo pasa a necesitar 64.199 visitantes por variación. Eso estira la duración a 20 días y derriba la capacidad de 2,1 a 1,5 tests por mes. Es un canje deliberado y casi siempre bueno: menos tests por mes, pero cada uno capaz de ver mejoras que antes pasarían como empate.

Ambición del test Muestra por variación Duración a 200 mil por mes Tests por mes
Detectar +20% relativo 16.792 14 días (piso) 2,1
Detectar +10% relativo 64.199 20 días 1,5

O sea: la pregunta “cuántos tests por mes” y la pregunta “qué tamaño de efecto logro ver” son la misma pregunta, vista desde dos lados. Fijar una define la otra.

Ejemplo trabajado: un SaaS de 60 mil visitantes por mes

Un SaaS recibe 60.000 visitantes por mes en la landing page de registro, con conversión del 2,5% en inicio de trial. El equipo quiere detectar una ganancia relativa del 20% (de 2,5% a 3,0%).

Verifica el primer paso de esa cuenta con tu propia tasa base:

Calculadora de tamaño de muestra
-Visitantes por variación
-Total (2 variaciones)
-Duración estimada

Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.

Ahora la parte que cambia decisiones. Ese equipo tiene 21 tests por año de capacidad. Si aplica la proporción que Ronny Kohavi documentó para experimentos en Microsoft, aproximadamente un tercio de las ideas mejora la métrica objetivo, un tercio queda neutro y un tercio empeora (Kohavi, Online Controlled Experiments: Lessons from Running A/B/n Tests for 12 Years, KDD 2015), entonces la expectativa realista es de cerca de 7 victorias por año, de las cuales varias serán pequeñas.

Ese número suele asustar, y es exactamente por eso que necesita estar en la planificación. Un roadmap que promete “vamos a aumentar la conversión un 40% este año con tests A/B” y tiene capacidad de 21 tests está prometiendo algo que la matemática no sostiene. Un roadmap que planifica 21 tests, espera 7 victorias y trata cada una como una ganancia compuesta está siendo honesto con su propia capacidad. La plantilla de roadmap de experimentación tiene la columna de duración justamente para forzar esa conversación antes del compromiso.

Qué suelen producir 21 tests por añoCon aproximadamente un tercio de las ideas mejorando la métrica objetivo, un tercio neutro y un tercio negativo, un programa de 21 tests por año tiende a producir cerca de 7 victorias, 7 empates y 7 resultados negativos que se evitaron justamente por haber sido testeados.Capacidad de 21 tests por año7mejoran la métricalas ganancias que componen en el año7quedan neutroscosto pagado en aprendizaje7empeoran la métricaperjuicio evitado por haber testeadoProporción aproximada documentada por Kohavi para experimentos en Microsoft.El tercer bloque suele olvidarse en el cálculo de retorno, y es donde vive buena parte del valor del programa.
El valor de un programa de tests no está solo en las victorias. El tercio de cambios malos que nunca llegó al 100% del tráfico es retorno real, aunque sea invisible en el reporte de crecimiento.

Paralelizar sin contaminar la lectura

La salida obvia para duplicar la cadencia es hacer dos tests al mismo tiempo, y funciona con una condición: los tests no pueden disputar el mismo público en la misma decisión. Dos experimentos en flujos independientes (uno en la página de precios, otro en el flujo de recuperación de contraseña) conviven sin problema, porque la mayor parte de los visitantes de uno nunca ve el otro.

El caso peligroso es el opuesto: dos tests en el mismo recorrido, o dos tests que mueven la misma métrica primaria. Ahí surgen tres problemas al mismo tiempo. La muestra se divide entre cuatro combinaciones en lugar de dos, lo que alarga los dos tests en vez de acelerar el programa. La interacción entre los cambios queda incorporada al resultado, y ninguno de los dos reportes logra separar el efecto propio del efecto del vecino. Y si los dos “ganan”, subir los dos cambios juntos puede entregar menos que la suma prometida, porque parte de la ganancia era la misma ganancia contada dos veces.

Dos formas de organizar esto sin renunciar a la paralelización: exclusión mutua, en la que cada visitante entra en como máximo un experimento y los grupos quedan completamente separados, o capas ortogonales, en las que la asignación de un test se sortea de forma independiente de la del otro, garantizando que las combinaciones queden equilibradas. La primera es más simple y más conservadora, la segunda aprovecha mejor el tráfico. En cualquiera de las dos, vale la regla práctica: un test por flujo, y la decisión de paralelizar tomada en la planificación, no en medio de la ejecución.

Si tu capacidad es baja

Un resultado de 0,6 tests por mes no significa “no testees”. Significa que la estrategia necesita cambiar de forma:

Errores comunes a la hora de definir la cadencia

Error Señal de alerta Corrección
Copiar el benchmark de un gigante “Booking hace miles, nosotros vamos a hacer 20 por mes” Calcula la capacidad a partir de tu tráfico, no de la meta de los demás
Cerrar temprano para caber en el mes Test detenido el día 8 porque “ya dio significancia” Fija la duración antes de correr y respeta el piso de dos semanas
Contar el tráfico del sitio entero Usó 500 mil sesiones cuando el flujo testeado recibe 40 mil Usa solo el tráfico que entra en el flujo del test
Ignorar el piso de duración Test de 4 días porque el tráfico cierra la muestra Corre al menos uno o dos ciclos semanales completos
Hacer dos tests en el mismo flujo Dos experimentos simultáneos en el checkout Un test por flujo; usa flujos distintos para paralelizar
Medir velocidad en lugar de aprendizaje Panel con “tests hechos en el mes” como KPI principal Mide también cuántos tests tenían hipótesis defendible y qué enseñó cada uno

Hazlo automático en Donnu

Descubrir cuántos tests caben en tu mes implica calcular muestra, dividir por tráfico real, respetar el piso de duración y reordenar el roadmap cuando la cuenta cambia. Donnu hace esa parte por ti: al configurar un test, lo dimensiona contra tu tráfico real, muestra la duración estimada antes de que empieces, y acompaña la recolección sin dejar que una mirada al panel se convierta en una decisión prematura. Planificas la cadencia con números en lugar de esperanza.

Empieza una prueba gratis de 14 días y descubre la capacidad real de tu tráfico antes de prometer resultados. Para organizar la cola que esa capacidad soporta, mira la plantilla de roadmap de experimentación.

Referencias

Lee también:

Preguntas frecuentes

¿Cuántos tests A/B por mes debería hacer una empresa?
No existe un número universal: la respuesta correcta es la capacidad que banca tu tráfico. Sale de una división simple: días del mes divididos por la duración de cada test, y la duración es el mayor valor entre la muestra necesaria dividida por el tráfico diario y un piso de dos semanas para capturar el ciclo semanal completo. Un sitio con 60 mil visitantes por mes, conversión del 2,5% y ambición de detectar +20% relativo logra cerca de 1,8 tests por mes. Uno con 200 mil llega a 2,1, limitado por el calendario y ya no por el tráfico.
¿Hacer más tests A/B por mes significa crecer más rápido?
Solo hasta cierto punto, y nunca por sí solo. La velocidad multiplica la calidad de las hipótesis: si la mayoría de tus tests no tiene hipótesis defendible, aumentar la cadencia solo produce más empates más rápido. Según datos publicados por Ronny Kohavi sobre experimentos en Microsoft, aproximadamente un tercio de las ideas testeadas mejora la métrica objetivo, un tercio no cambia nada y un tercio empeora. La velocidad sin calidad de hipótesis solo acelera esos dos últimos tercios.
Mi sitio tiene poco tráfico. ¿Debo renunciar a testear?
No, pero necesitas cambiar qué testeas. Con poco tráfico, solo los efectos grandes son detectables, así que los tests de cambio radical (nuevo layout, nueva propuesta de valor, nueva estructura de oferta) tienen más sentido que los ajustes de color de botón. También vale mover la métrica primaria a un evento más frecuente y más arriba en el embudo, como inicio de registro en lugar de compra concluida.
¿Por qué más tráfico, a partir de cierto punto, no aumenta la cantidad de tests?
Porque la duración mínima pasa a ser un límite de calendario, no de muestra. Todo test debería correr al menos una o dos semanas completas para capturar la variación entre días hábiles y fin de semana. Cuando el tráfico ya cierra la muestra en tres días, el piso de dos semanas manda, y el excedente de tráfico pasa a comprar sensibilidad (detectar efectos menores) en lugar de cantidad de tests.
¿Puedo hacer dos tests A/B al mismo tiempo para duplicar la cadencia?
Puedes, siempre que no disputen el mismo flujo ni la misma métrica primaria. Dos tests en páginas distintas de recorridos distintos conviven bien. Dos tests en la misma página comparten visitantes, y la interacción entre los cambios contamina la lectura de ambos, además de dividir la muestra y alargar los dos.