Hay un momento incómodo en muchos proyectos digitales. Abres tu panel de analítica, decides que toca "optimizar la conversión", y vas a buscar cómo se hace. Lo que encuentras está escrito para empresas que no tienen tu problema: casos de Booking, de Amazon, de productos que mueven millones de sesiones al mes. Y ahí está el primer malentendido. A ese volumen, una mejora del 0,5% en un botón da para una reunión y una diapositiva, porque la matemática acompaña. Tú miras tus números y ves unos cientos de sesiones al mes, búsqueda orgánica en un dígito, y quizás un evento de conversión que ni siquiera has configurado.

El instinto entonces es copiar el manual de los grandes: forma una hipótesis, lanza el test, espera al 95% de confianza. Y el manual, sin avisar, deja de aplicar. Porque el test que necesitarías correr tardaría más que el propio proyecto.

Este post va de qué hacer en ese escenario. No es una versión descafeinada del CRO de verdad. Es otra disciplina para otra restricción: cuando los números no pueden cargar el peso, el diseño, la UX y el criterio tienen que mantener el proyecto en movimiento.

La matemática que nadie te cuenta antes de decir "lanza un test"

Empecemos por entender por qué el manual estándar se rompe. Calcular el tamaño de muestra de un test necesita cuatro datos: tu tasa de conversión actual, el efecto mínimo que quieres detectar (el MDE), tu nivel de significancia y tu poder estadístico. Cualquier calculadora seria pide los mismos cuatro, y la relación entre ellos no perdona.

Pon números reales. Un sitio con un 3% de conversión que quiere detectar una mejora relativa del 15% necesita unos 23.000 visitantes por variante con 95% de significancia. Con dos variantes, son unas 46.000 sesiones para cerrar un solo test. Y si quieres detectar un efecto más fino, del 5%, el requisito se dispara a unos 104.000 por variante, cerca de cinco meses de tráfico para muchos sitios.

Ahora pon eso al lado de un sitio que hace mil sesiones a la semana. El test no dura un sprint, dura casi un año, y eso suponiendo que el embudo y la estacionalidad colaboren, que no lo harán. Hay una regla práctica de la comunidad CRO que lo resume bien: si el cálculo de muestra te da una duración de más de ocho semanas, párate y revisa los supuestos — sube el MDE, busca una página con más tráfico, o pregúntate si el test vale la pena siquiera.

Esa es la tesis. Por debajo de cierto volumen, la optimización deja de ser un experimento de laboratorio y se vuelve un taller de diseño con un bucle de feedback. El objetivo se desplaza: ya no se trata de demostrar un cambio, sino de aprender de él rápido.

Deja de testear lo cosmético. Empieza a testear decisiones.

Aquí cae casi todo el mundo con poco tráfico: copia el manual de los grandes y testea cosas pequeñas. El color del botón. Una palabra del titular. Un ajuste de microcopy. A escala eso funciona porque el volumen detecta medio punto de diferencia. Con poco tráfico, medio punto es invisible — queda enterrado bajo el ruido natural de tu tráfico semana a semana, y no hay paciencia que lo saque a la superficie.

Así que cambia lo que pones sobre la mesa. Si vas a gastar semanas de tráfico en una comparación, las dos versiones tienen que ser lo bastante distintas como para que la diferencia pueda asomar por encima del ruido. Eso significa cambios estructurales, no cosméticos: reorganizar el layout entero en lugar del color de un elemento, cambiar la jerarquía de la información (qué destaca la página y qué entierra), o eliminar pasos completos del embudo en vez de pulir los que ya tienes.

Las propias calculadoras lo dicen con otras palabras: los sitios de bajo tráfico todavía pueden correr tests válidos, pero tienen que aceptar concesiones — subir el MDE para detectar solo efectos grandes, reducir el número de variantes, o correr más tiempo. Las dos primeras están en tu mano hoy. La regla, entonces, queda así: cambios más grandes, menos variantes.

Y con las variantes, sé estricto. Control contra una sola variante. Nada más. Cada variante extra parte tu tráfico ya escaso en charcos más pequeños y diluye la poca señal que existe. Un test de cuatro caminos en un sitio de bajo tráfico no es un experimento, son cuatro formas de no aprender nada.

Acerca la métrica al cambio: las microconversiones

La conversión final — la compra, el registro, la reserva — suele ser lo peor que puedes medir cuando el tráfico es escaso, justamente porque es rara. Si solo una fracción pequeña de visitantes llega hasta ahí, estás esperando un número diminuto montado sobre otro número ya pequeño. La señal llega, si llega, demasiado tarde para actuar.

La solución es acercar la medición al cambio que hiciste. En lugar de esperar la conversión del fondo del embudo, vigila las señales que ocurren mucho más seguido: clics en el CTA principal, el paso de un campo del formulario al siguiente, la interacción con un módulo concreto que rediseñaste.

Estas microconversiones se disparan a una frecuencia mucho más alta que tu objetivo final, así que acumulas suficientes para leer un patrón en días en vez de meses. No te dirán que el cambio te hizo ganar dinero — eso solo lo dice el embudo completo. Pero sí te dicen si el usuario notó y reaccionó a lo que cambiaste, que es exactamente el feedback rápido que un proyecto de bajo tráfico necesita para seguir iterando.

Esta es también la razón práctica para poner orden en tu medición antes que nada. Un rediseño que no puedes medir a nivel micro es un rediseño que corres a ciegas. Si todavía no tienes los eventos de conversión configurados, esa es la tarea cero. Todo lo demás de este enfoque depende de ella.

Cuando el dashboard no se mueve, mira en vez de contar

Los métodos cuantitativos necesitan volumen. Los cualitativos no. Cuando tus números son demasiado pequeños para calcular nada fiable, cambias de herramienta — y dejas de contar para empezar a mirar. Cinco usuarios en una sala (o en una llamada) sacan a la luz fricciones que ningún paquete estadístico vería a tu escala.

Y esto no es un premio de consolación. Está apoyado en algunos de los hallazgos más replicados de la investigación UX. En usabilidad, el análisis del Nielsen Norman Group sobre decenas de sus propios proyectos de consultoría encontró que probar con más usuarios apenas aumentaba el número de hallazgos. La versión más citada de la regla dice que cinco participantes destapan alrededor del 85% de los problemas de usabilidad de un producto, y la recomendación del propio NN/G es directa: prueba con cinco usuarios y corre tantos tests pequeños como puedas permitirte. Cinco personas es un número al que cualquier proyecto de bajo tráfico llega esta misma semana.

Con las grabaciones de sesión pasa algo parecido. Deja de mirar el promedio de tiempo en página y ponte a ver sesiones individuales. ¿Dónde duda el cursor? ¿Qué campo del formulario hace que alguien se detenga, suba de nuevo y vuelva a leer? Una sola grabación de un usuario confundido suele valer más que un dashboard plano de un mes entero, porque te dice el porqué, y el porqué era justo lo que los números nunca te iban a dar. Los mapas de calor cumplen otra función: encontrar qué se ignora de forma sistemática. Si una sección entera no recibe atención, no es razón para hacerla más llamativa, suele ser razón para cortarla y reducir el ruido visual que compite con lo que de verdad importa.

El giro de fondo es ese. Con mucho tráfico, optimizar es un problema de estadística. Con poco tráfico, es un problema de observación — y la observación no tiene un tamaño de muestra mínimo que tarde un año en alcanzarse.

A veces lo riguroso es NO testear

Hay una versión de la disciplina profesional que se convierte en ceremonia: insistir en un test para un cambio que es obvio que hay que hacer. Cuando tu tráfico es escaso, gastarlo en "demostrar" algo que todo el mundo ya ve es lo contrario de riguroso. Es desperdicio disfrazado de método.

Puedes actuar sin test cuando hay una fricción obvia o un bug de UX que sufren todos los usuarios — si el formulario rechaza datos válidos o el CTA está tres scrolls por debajo del pliegue, no necesitas 23.000 sesiones para confirmar que está mal, lo arreglas. También cuando las señales cualitativas son unánimes: si los tickets de soporte, las grabaciones y los cinco usuarios que observaste apuntan al mismo problema, esa convergencia es tu evidencia, y correr un test para reconfirmarla solo retrasa el arreglo. Y cuando los benchmarks de la competencia muestran que tu flujo está anclado en patrones obsoletos: si todos los productos comparables ya superaron un patrón que tú sigues usando, el test que toca correr es "publica la versión moderna", no "gasta dos meses confirmando que la obsoleta rinde peor".

La habilidad no está en testear todo. Está en saber qué decisiones necesitan un test y cuáles solo necesitan que las tomes.

Velocidad de aprendizaje por encima de significancia

El objetivo real nunca fue ganar un test al 95% de confianza. Eso es un medio, y con mucho tráfico es un medio eficiente. El objetivo de verdad es aprender qué funciona y aplicarlo antes de que la oportunidad pase.

Un equipo que itera sobre evidencia cualitativa y lógica de negocio se mueve más rápido que uno que espera meses por un número que quizás nunca se estabilice. El primero publica, observa, ajusta y vuelve a publicar, acumulando una comprensión real de cómo se comportan sus usuarios. El segundo espera un intervalo de confianza que su tráfico nunca va a llenar con holgura, y a esa espera la llama "rigor".

La significancia estadística es una herramienta para una condición concreta: tener tráfico suficiente para pagarla. Fuera de esa condición, aferrarse a ella no es disciplina, es usar el instrumento equivocado para el trabajo. Si los números no pueden cargar con el peso, el diseño, la UX y el sentido común mantienen el proyecto en movimiento. No como un descenso desde el CRO "de verdad", sino como la versión que de hecho encaja con la restricción en la que trabajas.

Si estás revisando tu propia analítica y no sabes por dónde empezar, algunas lecturas relacionadas: cómo la investigación de usuarios moldea un producto que la gente realmente necesita, por qué una interfaz es un sistema de signos y, si aún estás eligiendo plataforma para construir, cómo pienso sobre los principales constructores de sitios web.