Pruebas más rápidas, el mismo tráfico: lo que la IA cambia en las pruebas A/B y lo que no.

El problema que resuelve crear pruebas rápido

Un programa que corre un experimento al mes tiene un problema predecible. Cada prueba se vuelve valiosa. Los equipos buscan en el backlog la idea que seguro va a funcionar y, mientras tanto, el banner nuevo y la oferta nueva salen al aire por fuera del programa, sin medirse. En los distintos mercados en los que he trabajado, las pruebas han sido esenciales para entender al público. Cuando lanzar una prueba es difícil, los cambios más importantes se la saltan.

La IA ataca ese problema de frente. Las plataformas de pruebas ya permiten que un asistente de IA cree, lance y lea experimentos a través de servidores MCP. El servidor MCP de Convert permite leer resultados, hacer auditorías y crear pruebas en lenguaje natural. El MCP de Intelligems, de un competidor enfocado en Shopify, puede crear y actualizar pruebas de precios, ofertas, contenido y ventas adicionales después de la compra. Una auditoría de 14 herramientas de pruebas A/B publicada por Convert, que también vende pruebas A/B, encontró que crear experimentos por chat es la función de IA más común, y que el 58% de las 59 funciones de IA que clasificó eran interfaces de chat sobre acciones que las herramientas ya tenían (página actualizada el 3 de noviembre de 2026). En otras palabras, la mayor parte de la IA hasta ahora acelera la construcción.

La velocidad ayuda más cuando viene con hábitos que no tienen nada que ver con la IA:

• Una hipótesis documentada y refutable para cada idea, en un lugar donde todo el negocio pueda verla.
• Ideas pensadas para todo el sitio, no solo para la página de la que salieron, cada una con un plan de despliegue si gana.
• Un formulario de solicitudes abierto a todos, para que probar sea el camino más rápido hacia un cambio y no el más lento.

Construir nunca fue el único cuello de botella

Cuando una etapa de un proceso se acelera, el cuello de botella pasa a la siguiente. Lo escribí para la entrega de software en Encontrar cuellos de botella en la entrega: la IA hizo más rápido escribir código, así que el trabajo se acumuló en la revisión. Los experimentos se comportan igual. Cuando crear una prueba toma minutos, las partes lentas pasan a ser:

• El tráfico. Cada prueba necesita suficientes visitantes y pedidos para distinguir un efecto real del ruido, y las pruebas compiten por los mismos visitantes.
• La definición. Una hipótesis, un alcance y una métrica claros, decididos antes del lanzamiento.
• El análisis. Alguien que lea el resultado con honestidad, lo contraste con los datos reales y decida.

En otras empresas he visto lo que pasa cuando un equipo adopta una herramienta de pruebas y solo se acelera la primera parte: muchas pruebas, ningún alcance definido, una prueba detenida a los dos días y nadie responsable de analizar los datos. Eso produce actividad, no aprendizaje.

El tráfico decide cuántas pruebas puedes correr

Antes de lanzar una prueba puedes calcular cuántos visitantes necesita. Los datos de entrada son tu tasa de conversión actual, la mejora más pequeña que vale la pena detectar y qué tan seguro quieres estar. Este es un ejemplo con una tasa de conversión del 2%, 95% de confianza (bilateral) y 80% de potencia, usando la fórmula estándar para comparar dos tasas de conversión. La cifra de tráfico es ilustrativa: una página que recibe 5,000 visitantes al día, repartidos entre el control y la variante.

De aquí salen tres conclusiones:

1. Las mejoras pequeñas necesitan mucho tráfico. Reducir a la mitad la mejora que quieres detectar multiplica por cuatro, más o menos, los visitantes que necesitas. El ingreso por visitante, una métrica muy usada en los titulares, suele necesitar todavía más, porque el valor de los pedidos varía mucho más que una conversión de sí o no.
2. Corre las pruebas por semanas completas. Quienes compran el fin de semana se comportan distinto a quienes compran entre semana. Redondea siempre la duración a semanas completas, aunque el cálculo diga ocho días.
3. Las pruebas en paralelo comparten un presupuesto fijo. Dos pruebas sobre los mismos visitantes o se los reparten, y cada una tarda el doble, o se superponen, y pueden afectarse entre sí. Las pruebas creadas en una mañana igual tienen que caber en el tráfico que tienes.

Cada proveedor lo plantea de forma distinta, y esa es una razón para hacer las cuentas tú mismo. En su episodio de podcast sobre tráfico (15 de junio de 2026), Intelligems sugiere que unos 500 a 700 pedidos al mes probablemente bastan para hacer pruebas útiles en Shopify, y que el número que importa son los pedidos, no los visitantes. El mismo episodio deja una idea que vale la pena guardar: el valor promedio del pedido importa. Su ejemplo es una marca de muebles que vende sofás de 4,000 a 5,000 dólares y que quizá procesa solo 80 a 100 pedidos al mes, muy pocos para llegar a significancia en un tiempo útil, y su consejo para tiendas con poco tráfico es apostar por cambios más grandes. Frente a la tabla, ese umbral solo funciona para cambios grandes. La página de ejemplo ya produce unos 3,000 pedidos al mes. Con 600 pedidos al mes, detectar una mejora del 10% necesita unos 3,400 pedidos, es decir, cinco a seis meses; una mejora del 20% necesita unos 930 pedidos, o seis a siete semanas. Así que 500 a 700 pedidos al mes bastan si buscas mejoras de un 20% o más, y por eso mismo las tiendas con menos volumen deberían probar cambios más grandes.

Es un cálculo que un asistente de IA hace en segundos. Inclúyelo en cada brief, para que el equipo sepa antes del lanzamiento si una prueba puede responder su propia pregunta.

La tasa de éxito es la métrica equivocada

Un caso de estudio de Convert muestra el patrón. La agencia anterior de un cliente de ocio y turismo corría más o menos una prueba al mes: 12 pruebas en un año con una tasa de éxito del 33%, que Convert calcula en unas cuatro ganadoras. En sus primeros tres meses, la agencia Another Web Is Possible corrió 16 pruebas, creadas con sus propias herramientas conectadas al servidor MCP de Convert, y encontró cuatro ganadoras, una tasa de éxito del 25%. La mejor aumentó el ingreso por visitante en un 12%.

Leído de una forma, el programa nuevo gana menos seguido. Leído bien, encontró el mismo número de ganadoras en la cuarta parte del tiempo. El aprendizaje por mes es la métrica correcta, y en eso el programa más rápido sale adelante. Pero las ganadoras son solo una medida aproximada del aprendizaje: como muestra el siguiente punto, un programa que corre más pruebas también acumula más ganadoras falsas, así que el mismo número de ganadoras no es exactamente el mismo aprendizaje. Las pruebas no concluyentes y las perdedoras también enseñan algo, si se registran, y el caso de estudio dice lo mismo sobre sus pruebas perdedoras.

Correr 16 pruebas en tres meses requiere mucho tráfico, pruebas repartidas en distintas partes del sitio, pruebas dimensionadas para mejoras grandes, o una mezcla de las tres. El caso de estudio no da el tráfico ni la duración de las pruebas, así que no puedo decir cuál. En una tienda, las pruebas en la página de inicio, las colecciones, las páginas de producto y el carrito pueden usar cada una la mayor parte del tráfico, pero los compradores se mueven entre esas páginas, así que las pruebas igual se superponen y pueden afectarse entre sí, un riesgo que hay que aceptar a conciencia. Crear pruebas más rápido hace prácticas las pruebas en paralelo; no crea el tráfico para ellas.

Correr más pruebas trae, eso sí, dos advertencias:

• Más pruebas, más ganadoras falsas. Con una prueba bilateral al 95% de confianza, cada prueba de un cambio que no hace nada tiene cerca de un 2.5% de probabilidad de parecer ganadora. Si ninguno de 16 cambios tuviera un efecto real, la probabilidad de que al menos uno apareciera igual como ganador es de más o menos una en tres. Si cuentas también las perdedoras significativas, sube a más de una en dos. Eso no hace falsa a ninguna de las ganadoras del caso de estudio. Significa que un programa más grande necesita más verificación: vuelve a probar las ganadoras importantes, o mantén un grupo pequeño de visitantes con la versión anterior después del despliegue.
• El mejor resultado suele estar sobreestimado. Cuando eliges la mayor mejora entre muchas pruebas, el azar casi siempre la ayudó. Esto se conoce como la maldición del ganador. Planea el despliegue con una mejora menor de la que mostró la prueba, y vuelve a medir después de publicarla.

Así que, para cada prueba, registra cuánto duró, cómo compartió el tráfico con otras pruebas y si la ganadora se sostuvo después del despliegue. Los casos de estudio rara vez incluyen esos datos, y este no los incluye, pero tu propio programa debería. Sin ellos, de una lista de ganadoras se aprende poco, por rápido que se haya producido.

Lo que una prueba hecha rápido no alcanza en Shopify

Nuestras tiendas funcionan en Shopify, y los impuestos, las aplicaciones y otros servicios de terceros se conectan a través de él. La IA que escribe el código de las variantes es excelente en la capa de front-end: diseño, textos, imágenes, banners, cambios en la página de producto. Los cambios que suelen importar más para los ingresos están más abajo:

• El checkout. El checkout ya no es un lugar para pegar scripts. Shopify ya no admite checkout.liquid en los pasos de información, envío y pago, y los script tags en las páginas de agradecimiento y de estado del pedido dejaron de funcionar para las tiendas que no son Plus el 26 de agosto de 2026. Para cambiar el checkout, las aplicaciones ahora usan extensiones, incluidas las extensiones de píxel web para el seguimiento. Convert, por ejemplo, indica que, por estos cambios, las pruebas directas en el checkout no están disponibles por ahora en su aplicación para Shopify.
• Precios, descuentos y umbrales de envío. Cambian lo que paga el cliente, el monto sobre el que se calculan los impuestos y lo que ve cada aplicación que lee el carrito. Si vendes en más de un país o moneda, la misma prueba se comporta distinto en cada mercado.
• Las aplicaciones. Las de reseñas, suscripciones, paquetes, ventas adicionales e impuestos agregan su propio código a la página o leen el carrito. Una variante que mueve un elemento del que depende una aplicación puede romperla solo en esa variante. La prueba entonces reporta una pérdida que en realidad es un error, o no detecta el problema.
• La velocidad. La mayoría de las herramientas de pruebas del lado del cliente ocultan la página hasta aplicar la variante, o los visitantes ven un destello de la versión original. De cualquier forma, la herramienta tiene un costo, que medí en tiendas reales en Verifica antes de creer.

Las pruebas más profundas son posibles, pero son trabajo de integración, no algo que se crea en una mañana. Intelligems, que se especializa en pruebas de precios en Shopify, dice en su guía de integración que está pasando sus pruebas de precios de los Checkout Scripts, que Shopify está retirando, a las Cart Transform Functions de Shopify. La guía enumera cuatro pasos: agregar su script, etiquetar los precios de los productos en el tema, actualizar el carrito y, por último, hacer QA y publicar. También advierte que solo una Cart Transform Function puede correr sobre una misma línea del carrito, y pide a las tiendas que ya usan una para otra cosa que contacten primero a su soporte. Ese es justo el tipo de dependencia que una revisión de ingeniería debería detectar antes de que empiece una prueba de precios.

Shopify también tiene ahora una opción nativa. Su función Rollouts puede programar cambios en el tema, las páginas de checkout y de cuentas, los descuentos y los catálogos, y su tipo Experiment compara un tratamiento con un control. La página de requisitos de Shopify enumera límites que conviene conocer:

• Los Experiments requieren el plan Grow o superior.
• Los cambios de tema, checkout y cuentas solo aplican a la tienda online. Los checkouts headless y de storefronts personalizados no se pueden probar, y la analítica excluye a los visitantes headless y de POS.
• Rollouts no funciona con temas vintage y no puede cambiar plantillas Liquid.
• En un Experiment de descuentos, el grupo de control no recibe el descuento del rollout, y la configuración de combinaciones puede hacer que cada grupo pueda usar descuentos distintos.
• Cuando un cambio de catálogo está en un Experiment, o un rollout llega a menos del 100% de los visitantes, los precios y productos pueden diferir entre la tienda online y Google, otros canales, anuncios, feeds y aplicaciones de terceros.

La función es nueva y sigue cambiando, así que revisa el centro de ayuda de Shopify para ver los detalles actuales.

Nada de esto hace menos útiles las pruebas de front-end. Significa que cada prueba necesita un alcance técnico: ¿es solo de front-end, o toca el checkout, los precios, los impuestos, las aplicaciones o los mercados? El segundo tipo necesita revisión de ingeniería, QA en cada mercado y un plan de reversión, por rápido que se haya creado la variante.

El ingreso por visitante necesita una sola fuente de verdad

Una herramienta de pruebas suele registrar el ingreso en el momento de la compra. Tus pedidos de Shopify tienen el número real: después de descuentos, sin impuestos ni envío, y descontando los reembolsos y cancelaciones que llegan semanas después. Si los dos no coinciden, los pedidos tienen la razón. Es la misma razón por la que impulsé una sola fuente de verdad cuando construimos nuestra plataforma de datos.

• Define la métrica en términos de Shopify antes del lanzamiento. Por ejemplo: ventas netas sin impuestos ni envío, después de los reembolsos de los primeros 30 días, divididas entre los visitantes.
• Conecta cada pedido con su variante. Por ejemplo, escribe el experimento y la variante en el carrito como un atributo del carrito, para que llegue al pedido y puedas conciliar los números de la herramienta con los tuyos. Pregunta a tu proveedor de pruebas cómo lo registra, porque cada herramienta lo hace distinto.
• Revisa el reparto antes de leer el resultado. Si configuraste 50/50 y obtuviste un reparto claramente desigual sobre miles de visitantes, algo está roto: bots, redirecciones, caché, consentimiento o una variante que no carga. Arregla eso primero. Hasta que lo hagas, no se puede confiar en el resultado.
• Decide de antemano la regla para valores atípicos. Unos pocos pedidos muy grandes pueden mover el ingreso por visitante. Pon un tope al valor de los pedidos en un percentil fijo, o excluye los pedidos mayoristas, y decídelo antes de que empiece la prueba, nunca después de ver en qué variante cayó el pedido grande.

La herramienta de pruebas no ve tu calendario

En distintos mercados aprendí a mirar mucho más allá de la página que se está probando, porque el resultado depende de todo lo demás que pasa al mismo tiempo. Una herramienta de pruebas ve visitantes y clics. No ve:

• Las campañas y la estrategia. Un envío masivo de correos, una campaña pagada o una promoción cambian quién llega y por qué. Mira el panorama completo de lo que marketing tiene activo antes y durante la prueba.
• El tráfico esperado en ese periodo. Una prueba dimensionada con el tráfico del mes pasado puede quedarse corta en un mes flojo, o desbordarse con una venta especial.
• El país, la moneda y la temporada. Los tipos de cambio, los feriados locales y la época del año cambian la forma en que la gente compra.
• El clima. En productos de temporada, un fin de semana caluroso puede mover las ventas más que cualquier variante.
• Otros cambios en el sitio. Si alguien edita la página que se está probando o lanza un banner nuevo a mitad de la prueba, la prueba ya no mide una sola cosa. Congela el área que se prueba o, al menos, registra cada cambio.

Las simulaciones tampoco resuelven esto. SimGym, de Shopify, hace pasar compradores de IA por un tema antes de publicarlo, y puede ser un filtro barato para descartar ideas débiles. Pero la propia Shopify advierte que los resultados pueden diferir de cómo se comportan los clientes reales, y los compradores simulados no tienen temporada, presupuesto ni campaña detrás de su visita. Usa la simulación para decidir qué probar, y el tráfico real para decidir qué funcionó.

Así que lleva un calendario compartido con cada prueba al lado de las campañas y promociones. Y guarda el historial: cada prueba con su hipótesis, fechas, resultado y lo que pasaba al mismo tiempo. Meses después, con más datos, puedes volver, contrastar el resultado con datos externos y analizarlo de nuevo.

Antes del lanzamiento: un brief de una página

1. Hipótesis. Qué cambiamos, para quién, qué esperamos que pase y la evidencia que lo respalda.
2. Métrica y métricas de protección. Una métrica principal definida en términos de Shopify, más algunas que no deben empeorar, como el valor promedio del pedido, los reembolsos y la velocidad de la página.
3. Tamaño y duración. La mejora más pequeña que vale la pena detectar, los visitantes y pedidos necesarios y la fecha de cierre en semanas completas.
4. Regla para detenerla. La prueba termina en su fecha de cierre. Revisarla a diario y detenerla en cuanto parece significativa hace mucho más probables las ganadoras falsas, salvo que la herramienta use un método secuencial diseñado para eso. Detenla antes solo por un problema real, como una variante rota.
5. Alcance técnico. ¿Solo front-end, o toca el checkout, los precios, los impuestos, las aplicaciones o los mercados? Si va más allá, ingeniería la revisa y hay un plan de reversión listo.
6. QA. Cada mercado, moneda y dispositivo, con todas las aplicaciones de la página funcionando en ambas versiones.
7. Revisión del calendario. Campañas, promociones, feriados y temporada durante el periodo de la prueba.
8. Responsable. La persona que analizará el resultado y la fecha en que lo presentará.
9. Después del resultado. El plan de despliegue si gana, cómo vas a confirmar la mejora después de publicarla y el registro en la bitácora de pruebas.

Dónde encaja la IA en el programa

La respuesta no es menos IA. Es IA también en las partes lentas, con las personas a cargo de las decisiones. Algunas herramientas ya empiezan a ir en esa dirección. El Experiment Review Agent de Optimizely puede revisar la configuración de un experimento antes del lanzamiento y recomendar cambios para mejorar sus probabilidades de llegar a significancia estadística. Intelligems dice que las skills de su MCP crean lo que recomiendan como borrador para que lo revises, y el servidor MCP local de Convert usa por defecto un perfil de solo lectura para reportes. Revisa cómo funcionan las aprobaciones en la herramienta que uses antes de dejar que un asistente toque una tienda en producción.

El mismo tipo de conexión MCP que permite a la IA crear una prueba puede permitirle leer pedidos, así que puede hacer la conciliación además de la construcción. Expliqué cómo hacer útiles esas conexiones en Servidores MCP que de verdad ayudan a usuarios no técnicos.

La IA sacó la construcción de la ruta crítica, y eso vale la pena celebrarlo. Pero una herramienta de pruebas con IA mejora la velocidad solo hasta cierto punto. Lo que convierte la velocidad en aprendizaje es ser estratégico y analítico: una definición clara, un alcance que la plataforma pueda soportar, suficiente tráfico, un análisis honesto y datos que hayas verificado. La velocidad sin definición solo produce conclusiones equivocadas más rápido.

Fuentes

Todas las fuentes están en inglés.

• Convert – AI in A/B Testing Tools: A Capability Audit (actualizado el 3 de noviembre de 2026)
• Convert – How Another Web is Possible took a leisure and tourism business from 12 tests a year to 16 in just three months
• Convert – Experiences MCP Server
• Convert – Integrate with Shopify through our Shopify Convert App
• Intelligems – MCP
• Intelligems – Price testing integration guide using Shopify Functions
• Intelligems – IntelliJAMS EP 061: How Much Traffic Do You Actually Need To A/B Test? (15 de junio de 2026)
• Optimizely – Run A/B tests in Feature Experimentation
• Shopify – Rollouts
• Shopify – Rollouts requirements and considerations
• Shopify – Apps in checkout
• Shopify – SimGym

Los tamaños de muestra y las probabilidades de falsos positivos se calcularon con la fórmula estándar para dos proporciones (95% de confianza bilateral, 80% de potencia).