CRO para sitios de bajo tráfico: cómo seguir testeando
Cómo hacer CRO en un sitio de bajo tráfico: amplía tu MDE, testea más arriba en el funnel y sabe cuándo el test A/B no es la herramienta correcta.
📚 Este artículo es parte de la guía Optimización de Conversión (CRO): La Guía Completa 2026.
El bajo tráfico no significa que no puedas testear, significa que no puedes testear de la misma forma que un sitio de alto tráfico. La estadística no ofrece un descuento por tener menos visitantes: detectar un efecto pequeño de forma confiable sigue necesitando un tamaño de muestra real, y pretender lo contrario solo cambia un test lento por uno rápido y equivocado. Esta guía cubre las palancas reales que tiene un sitio de bajo tráfico: ampliar el tamaño del efecto que estás buscando, mover los tests más arriba en el funnel, extender el plazo con honestidad y saber cuándo el test A/B genuinamente no es la herramienta correcta para la pregunta que estás haciendo.
Por qué el bajo tráfico rompe el manual estándar
El manual estándar de CRO asume que puedes detectar un aumento modesto (10% a 20% relativo) en unas pocas semanas. Esa suposición depende por completo del volumen de tráfico, y se rompe en silencio en cuanto el volumen baja.
Un ejemplo trabajado. Supongamos que una página convierte al 3%, y quieres detectar un aumento relativo del 20% (aproximadamente de 3% a 3,6%), con la confianza estándar del 95% y un poder del 80%. Con 1.000 visitantes por semana llegando a esa página, divididos entre dos variantes, el dimensionamiento da:
- Tamaño de muestra necesario: 13.914 visitantes por variante
- Duración estimada del test: 195 días, más de seis meses
Seis meses es más de lo que la mayoría de los equipos está dispuesto a esperar por una sola respuesta, y para cuando termine, la página, la oferta o el mercado ya pueden haber cambiado por debajo del test. Este es el problema real que crea el bajo tráfico: no que el testeo sea imposible, sino que el plazo honesto para detectar un efecto pequeño suele ser más largo de lo que un negocio puede tolerar.
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Ingresa tu propia tasa base y tu tráfico semanal arriba antes de asumir que cualquier palanca específica de abajo va a resolver tu situación, ya que la palanca correcta depende de qué tan lejos están tus números de un plazo manejable.
Palanca 1: amplía tu efecto mínimo detectable (MDE)
La palanca más grande en un sitio de bajo tráfico es aceptar que solo puedes detectar de forma confiable un efecto más grande, y diseñar tests alrededor de cambios mayores en vez de ajustes pequeños.
El mismo ejemplo trabajado, con un MDE más amplio. La misma página, convirtiendo al 3%, los mismos 1.000 visitantes por semana, pero ahora testeando un aumento relativo del 50% (aproximadamente de 3% a 4,5%) en lugar del 20%:
- Tamaño de muestra necesario: 2.518 visitantes por variante
- Duración estimada del test: 36 días, cerca de cinco semanas
| MDE buscado | Muestra por variante | Duración con 1.000 visitantes/semana |
|---|---|---|
| Aumento relativo del 20% | 13.914 | 195 días |
| Aumento relativo del 50% | 2.518 | 36 días |
Recortar a más de la mitad el tamaño del efecto que estás persiguiendo convirtió un test de seis meses en uno de cinco semanas. El costo es real: no vas a detectar una mejora genuina pero pequeña del 10% con este diseño, va a aparecer como inconcluso desde el punto de vista estadístico aunque exista de verdad. En un sitio de bajo tráfico, ese costo suele valer la pena, ya que un test que nunca termina no enseña absolutamente nada.
Palanca 2: mueve el testeo más arriba en el funnel
Un checkout, un paso de prueba-a-pago u otra etapa profunda del funnel casi siempre ve una fracción del tráfico que ve una landing page, una homepage o una página de precios. Testear en ese punto de mayor volumen, y luego seguir el efecto río abajo mediante analítica en vez de un segundo test A/B completo, suele ser el camino realista cuando la etapa más profunda de tu funnel simplemente no puede sostener por sí sola un tamaño de muestra adecuado.
Este es un costo real, no algo gratuito: un test del titular de la homepage te dice algo sobre el comportamiento en la homepage, y de todos modos tienes que confiar en que una mejora ahí se traslada a la métrica más profunda que realmente te importa. Sigue la tasa de conversión río abajo a lo largo del tiempo después de lanzar una variante ganadora de la homepage, en vez de asumir que el aumento observado arriba equivale automáticamente al mismo aumento en el checkout.
Palanca 3: testea cambios grandes, no microajustes
Ampliar tu MDE (Palanca 1) solo vale la pena si el cambio que estás testeando es realmente capaz de producir un efecto grande. Es poco probable que un cambio de color de botón mueva la conversión un 50%, por muy desesperado que esté tu tráfico. En un sitio de bajo tráfico, prioriza cambios estructurales (una propuesta de valor reescrita, una página de precios rediseñada, un flujo de onboarding fundamentalmente distinto) por sobre los cosméticos, ya que solo un cambio estructural tiene una chance realista de lograr el tamaño de efecto grande que tu tráfico realmente puede detectar en un plazo razonable.
Palanca 4: extiende la duración con honestidad
A veces la respuesta correcta es simplemente aceptar un test más largo, siempre que el negocio pueda tolerar la espera y que la página u oferta subyacente sea lo bastante estable como para no cambiar de forma significativa durante esa ventana. El error que hay que evitar es el opuesto: acortar la espera declarando un ganador antes de alcanzar el tamaño de muestra y la duración calculados, lo cual reintroduce el problema del peeking sin importar cuán poco tráfico tengas. Un test lento y correctamente dimensionado vale más que uno rápido y subdimensionado que por azar parece significativo.
Palanca 5: tests unilaterales, usados con cuidado
Un test bilateral verifica si una variante es mejor o peor que el control. Un test unilateral solo verifica si es mejor, lo que necesita una muestra algo menor para la misma confianza y poder.
El mismo ejemplo trabajado, unilateral. La misma página (base del 3%), el mismo MDE relativo del 20%, los mismos 1.000 visitantes por semana, pero testeando de forma unilateral en vez de bilateral:
- Tamaño de muestra necesario: 10.960 visitantes por variante (frente a 13.914 bilateral)
- Duración estimada del test: 154 días (frente a 195 bilateral)
El ahorro es real pero modesto, y viene con un costo real: un test unilateral, por diseño, no está construido para señalar de forma confiable una variante que rinde notablemente peor que el control. Úsalo solo cuando genuinamente no actuarías distinto ante un resultado “peor” que ante un resultado de “sin diferencia”, lo cual es un caso más acotado de lo que suena. Como palanca por defecto para el bajo tráfico, ampliar el MDE (Palanca 1) o subir en el funnel (Palanca 2) suele ayudar más.
Cuándo el test A/B genuinamente no es la herramienta correcta
Algunas situaciones de bajo tráfico se resuelven mejor con un método completamente distinto, no con un atajo dentro del test A/B.
| Situación | Herramienta mejor | Por qué |
|---|---|---|
| Necesitas entender por qué los usuarios abandonan | Investigación cualitativa: entrevistas a usuarios, session replay, pruebas de usabilidad | Estas responden el “por qué”, algo que ningún test A/B, sin importar el tamaño de muestra, está diseñado para responder |
| El tráfico es demasiado bajo para que cualquier test termine en un plazo tolerable | Revisión heurística / experta contra principios de usabilidad conocidos | No requiere tráfico en absoluto, y puede detectar fricción obvia que un test A/B tardaría meses en confirmar |
| Tienes que lanzar un cambio sin poder dividir el tráfico (un rediseño completo, un requisito de cumplimiento) | Una comparación antes/después cuidadosamente advertida | Se confunde con el tiempo, pero a veces es la única opción; etiquétala claramente como evidencia más débil que un test controlado |
Una tabla de decisión: qué palanca activar primero
| Si esta es tu restricción | Activa primero esta palanca |
|---|---|
| Tu duración calculada es realista pero un poco larga | Palanca 4: extiende la duración con honestidad |
| Tu duración calculada es inviable (muchos meses) | Palanca 1: amplía el MDE, y combínala con la Palanca 3 (testea cambios más grandes) |
| La etapa que te importa tiene muy poco tráfico, pero una página anterior tiene de sobra | Palanca 2: mueve el test más arriba en el funnel |
| Solo te importa detectar una mejora, nunca un perjuicio | Palanca 5: considera un test unilateral, con cautela |
| El tráfico es tan bajo que ningún MDE realista cierra la brecha | Salta el test A/B para esta pregunta; usa investigación cualitativa o revisión heurística en su lugar |
Una nota sobre testeo secuencial y bandits
Dos métodos más avanzados aparecen a menudo en las discusiones sobre bajo tráfico, y ambos merecen una advertencia honesta en vez de una recomendación general. El testeo secuencial (a veces llamado inferencia siempre válida) está diseñado para dejarte espiar los resultados a medida que se acumulan sin inflar tu tasa de falsos positivos como sí lo hace el peeking ingenuo, lo cual suena como la solución perfecta para un test lento de bajo tráfico. Ayuda de verdad con el problema del peeking específicamente, pero no reduce el tamaño de muestra subyacente necesario para detectar un efecto dado, así que un test de bajo tráfico que use métodos secuenciales igual puede tardar lo mismo en llegar a una respuesta confiable, solo te deja dejar de mirar por encima del hombro mientras esperas.
Los bandits multibrazo cambian el objetivo de “aprender con certeza” a “ganar mientras aprendes”, desplazando gradualmente el tráfico hacia la variante que se ve mejor a medida que avanza el test. Pueden tener sentido para un sitio de bajo tráfico que tiene muchas variantes para probar (un test de línea de asunto de email con diez candidatas, por ejemplo) y que le importa más el rendimiento general durante el período del test que una respuesta limpia y estadísticamente certera al final. Encajan mal cuando el objetivo real es una decisión confiable de sí o no sobre un cambio específico, ya que un bandit optimiza para el rendimiento acumulado durante el test, no para el tipo de significancia clara que un test A/B tradicional está construido para producir.
Errores comunes en sitios de bajo tráfico
El mismo puñado de errores aparece repetidamente en sitios de bajo tráfico en particular. Segmentar los resultados después del hecho para encontrar un subgrupo donde el test “funcionó” es una forma de p-hacking que se vuelve más tentadora, no menos, cuando la muestra general se ve decepcionante. Correr un test indefinidamente sin nunca comprometerse con una decisión desperdicia el único recurso que un sitio de bajo tráfico no puede permitirse perder: el tiempo. Y tratar un cambio pequeño y cosmético como si pudiera producir el tamaño de efecto grande que el bajo tráfico te exige buscar condena al test a fallar antes de empezar.
Haz esto automático en Donnu
Dimensionar un test correctamente importa aún más en un sitio de bajo tráfico, donde cada semana extra cuenta y cada atajo se acumula. Donnu resuelve la matemática del dimensionamiento de la misma forma que acaba de hacerlo la calculadora de arriba, contra tu tráfico real y tu tasa base real, recolecta datos mediante un snippet que nunca bloquea la carga de la página, y lee el resultado con estadística bayesiana honesta en vez de declarar un ganador antes de que la muestra realmente esté completa.
Empieza una prueba gratis de 14 días y dimensiona tu próximo test con honestidad, sea cual sea tu tráfico. Para la mecánica subyacente sobre la que se construye esta guía, consulta la guía completa de test A/B y la guía de significancia estadística.
Lee también
Continúa con la guía completa de CRO para el proceso completo de investigación a test, o revisa los errores comunes en test A/B y las amenazas a la validez para los modos de falla que empeoran bajo presión de tiempo.
Referencias
- Kohavi, R., Tang, D. & Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoyo en experimentguide.com.
- Nielsen Norman Group. Usability testing and qualitative research methods as alternatives to low-powered quantitative tests. nngroup.com
- CXL. Conversion research on testing strategy under limited traffic. cxl.com
- Georgiev, G. Statistical Methods in Online A/B Testing, sobre el diseño de tests unilaterales versus bilaterales. analytics-toolkit.com
Preguntas frecuentes
- ¿Se puede hacer un test A/B en un sitio de bajo tráfico?
- Sí, pero no de la misma manera que un sitio de alto tráfico. La estadística no da descuentos por tener poco tráfico: igual necesitas una muestra correctamente dimensionada para confiar en un resultado. Lo que cambia es tu estrategia: ampliar el efecto mínimo detectable que estás buscando, mover los tests a etapas del funnel con más volumen y extender el plazo que estás dispuesto a aceptar, en lugar de pretender que una muestra pequeña da una respuesta confiable.
- ¿Cuánto tráfico necesito para correr un test A/B?
- No hay un número universal fijo, depende de tu tasa de conversión base y del tamaño del efecto que quieres detectar. Como ilustración aproximada, una página que convierte al 3% necesita alrededor de 13.900 visitantes por variación para detectar de forma confiable un aumento relativo del 20% con la confianza y el poder estándar, pero esa misma página solo necesita cerca de 2.500 visitantes por variación para detectar un aumento relativo del 50%. El bajo tráfico no descarta el testeo, descarta detectar efectos pequeños con rapidez.
- ¿Qué debería testear en cambio si mi etapa de conversión tiene muy poco tráfico?
- Mueve el test a una etapa más temprana del funnel, con más volumen. Un checkout o un paso de prueba-a-pago suele ver una fracción del tráfico que ve una landing page o una página de precios, así que testear más arriba y luego seguir el efecto funnel abajo con tu analítica suele ser el camino más realista en un sitio de bajo tráfico.
- ¿Está bien testear sin alcanzar significancia estadística?
- No, si vas a declarar un ganador a partir de eso. Un test subdimensionado igual puede ser informativo como señal cualitativa (¿algo se veía claramente roto?, ¿los usuarios expresaron reacciones fuertes?) pero no debería usarse para tomar una decisión permanente de la forma en que sí puede hacerlo un test correctamente dimensionado y significativo. Ser honesto con un "inconcluso por tráfico insuficiente" es un resultado legítimo, y mejor que fabricar una falsa confianza a partir de una muestra demasiado pequeña.
- ¿Cuál es la diferencia entre un test unilateral y uno bilateral, y ayuda con el bajo tráfico?
- Un test bilateral verifica si una variante es mejor o peor que el control; un test unilateral solo verifica si es mejor, lo que requiere una muestra algo menor para la misma confianza y poder. Solo tiene sentido cuando genuinamente no te importa detectar un resultado peor, lo cual rara vez es toda la verdad en CRO, así que debe usarse con cuidado y declararse con claridad, no como un truco por defecto para reducir el tamaño de muestra.
- ¿Un sitio de bajo tráfico debería simplemente saltarse el test A/B y usar comparaciones antes/después?
- Las comparaciones antes/después son tentadoras con bajo tráfico porque no necesitan división de tráfico, pero confunden tu cambio con todo lo demás que cambió con el tiempo (estacionalidad, mezcla de tráfico, actualizaciones del sitio no relacionadas), algo que un test A/B controla al correr ambas versiones simultáneamente. El antes/después puede ser un último recurso razonable cuando el volumen realmente no puede sostener ningún test A/B, pero debe etiquetarse como una forma de evidencia más débil, no tratarse como equivalente a un experimento controlado.