Test A/B vs. bandit de IA: 30 días de datos de conversión

Dejé de preparar el siguiente test A/B para mi landing page con más tráfico y, en su lugar, puse a trabajar un bandit multibrazo de IA. Treinta días después, los registros habían aumentado y el bandit había reducido automáticamente el tráfico de la variante perdedora. Sin embargo, yo no podía presentar una cifra de atribución estadísticamente significativa, porque eso no es lo que produce un bandit. Ese intercambio resume toda la historia.

La cifra y su contrapartida

Se trata de una página de oferta extensa que convierte tanto el tráfico frío de pago como las visitas orgánicas templadas en registros de prueba. La tasa de conversión de registros durante los 30 días anteriores a la activación del bandit fue de 3.41%. En la misma página, con la misma oferta y la misma mezcla de tráfico, los 30 días posteriores a dejar la asignación en manos del bandit cerraron en 4.62%. Eso equivale a una mejora relativa del 35.5% en el evento de conversión principal.

Antes de que alguien haga una captura de esa cifra, conviene aclarar la contrapartida: es una mejora del resultado acumulado, no una mejora identificada de forma causal. Un bandit multibrazo redirige el tráfico hacia la variante que va ganando en ese momento. No mantiene una división limpia 50/50 durante el tiempo necesario para calcular un intervalo de confianza de una variante concreta. No hay valor p. Tampoco se puede afirmar que «la variante B superó a la variante A con un 95% de confianza». Lo único que puede decirse es que «convirtió una mayor proporción del conjunto total de visitantes que durante el periodo de control anterior». Son afirmaciones distintas, y un consejo directivo que entienda la diferencia preguntará cuál de las dos se está haciendo.

En cuanto al costo, durante esos 30 días pasaron ~84,000 vistas de página por el bandit. Las herramientas costaron $299 por un mes de Webflow Optimize en el nivel de 100K vistas, más un piloto de Coframe (precio disponible al contactar con ventas; más detalles a continuación). En total, el costo de las plataformas quedó por debajo de $500 y generó una mejora real en una página que aporta un volumen significativo de registros de prueba. Los números funcionan. La salvedad sobre la atribución no desaparece.

Por qué descarté el test A/B

La página recibe dos corrientes de tráfico en la parte inferior del embudo: Meta Ads, con la rotación entre AdCreative.ai, Pencil Pro y un control humano que analicé anteriormente, y el tráfico orgánico y de referencia procedente de motores de IA que generó la guía práctica de GEO en 14 días. En total, son aproximadamente 2,800 sesiones al día, con un reparto 30/70 entre tráfico de pago y orgánico que varía de una semana a otra.

Ese perfil de tráfico tiene justo la forma equivocada para una prueba A/B limpia. Para detectar una mejora relativa del 10% con una potencia del 80% sobre una tasa de conversión base del 3.4%, necesitaba alrededor de 50,000 visitantes por brazo: unos 35 días para una prueba de dos brazos si mantenía el reparto 50/50. Eso suponía cinco semanas enviando el 50% del tráfico de pago a una variante que ya sabía que perdía mientras esperaba significancia. Con un CPL de $24 en el canal de pago, cada punto porcentual de peor rendimiento de esa variante era dinero que el propio diseño de la prueba obligaba a desperdiciar.

Ese es el problema del arrepentimiento acumulado, o regret. Una prueba A/B es exploración pura: se mantiene fija la asignación porque se busca potencia estadística, aunque el costo sea mostrar una mala experiencia a la mitad de las visitas durante todo el experimento. Un bandit renuncia a esa inferencia limpia a cambio de mejores resultados acumulados: aprovecha la variante líder sin dejar de explorar las demás. Las comparaciones empíricas muestran que, en problemas estacionarios, reduce el arrepentimiento acumulado entre un 30–60% frente a una prueba A/B con reparto uniforme.

Esta fue mi regla de decisión antes de empezar:

• Bandit cuando el tráfico es escaso en relación con el efecto que se quiere detectar, mostrar la variante perdedora sale caro, la página funciona de forma continua y sin una ventana fija de campaña, y las conversiones acumuladas del trimestre importan más que una cifra causal defendible.
• A/B cuando hay que justificar la mejora ante quien controla el P&L, cuando el cambio es grande y poco frecuente (precio, hero o posicionamiento), o cuando las variantes son demasiado distintas para aprender de ellas en conjunto.

Esta página cumplía todas las condiciones para usar un bandit. Así que cancelé la prueba A/B pendiente y lancé el bandit.

Herramientas y costos, sin omitir nada

Evalué cuatro herramientas que ofrecen optimización continua con IA en lugar de los flujos clásicos de pruebas A/B. Implementé dos en producción; las otras dos se estudiaron en serio, pero quedaron fuera de esta prueba. Esta es la evaluación sin adornos.

Coframe. Es un optimizador basado en un bandit multibrazo modificado que genera variantes de textos, elementos visuales e incluso código de componentes, y después distribuye el tráfico con su bandit. Se instala mediante una etiqueta de script. La empresa ha recaudado cerca de $9M. Para conocer el precio hay que contactar con ventas; no existe una página pública de tarifas. Eso ya da una señal útil para planificar: presupuesto impredecible, un ciclo comercial antes de poder ejecutar nada y un enfoque empresarial poco cómodo para quien trabaja en solitario. Probé un piloto. La calidad de sus variantes generativas fue la mejor de las cuatro. La fricción de compra, la peor.

Webflow Optimize. Se basa en el motor de Intellimize que adquirió Webflow. El plan Standard cuesta $299 al mes por 100K vistas de página; hay niveles de 25K, 50K, 100K, 250K y 500K. Permite hasta 5 pruebas simultáneas. Solo funciona en páginas alojadas en Webflow, algo que en mi caso no suponía un problema, pero que lo descarta por completo si el sitio utiliza otra plataforma. Fue la herramienta que usé durante los 30 días de producción porque la página ya estaba en Webflow y el cálculo del plan de Webflow ya estaba cubierto.

Optimizely Opal. Añade experimentación gestionada por agentes a la plataforma actual de Optimizely. Según las cifras publicadas por la propia empresa, quienes usan Opal ejecutan un 78.7% más de experimentos y un 24.1% más de campañas de personalización, además de lograr una mejora del 9.3% en la tasa de éxito. Son datos del proveedor y responden a su propia metodología; los incluyo para que puedan ponderarse como corresponde. El precio es empresarial. Tenía sentido para un equipo con un contrato vigente de Optimizely, pero no para una sola landing page.

VWO Copilot. Combina las soluciones Testing, Insights y Personalize con una capa de IA. Es la plataforma más consolidada y sus funciones de IA descansan sobre la concepción más clásica de las pruebas A/B. La elegiría si buscara un flujo A/B limpio asistido por IA, en vez de un flujo centrado primero en bandits y con A/B como opción.

Para esta prueba, Webflow Optimize estuvo en producción durante los 30 días completos, mientras Coframe se ejecutó como piloto paralelo en una página secundaria para comparar la calidad de las variantes.

Guía práctica de 30 días, paso a paso

Días 0–3: instrumentar y congelar. Definí un solo evento de conversión: el registro de prueba, confirmado por el servidor, no el clic en un botón. Cualquier evento medido del lado del cliente inflará por igual los resultados de todas las variantes y hará parecer que hay una mejora cuando, en realidad, solo se está maquillando el ruido. Congelé el control: la página existente quedó intacta como variante A y mantuvo un piso garantizado del 20% durante toda la prueba, de modo que al final hubiera una cohorte de reserva con la que comparar. Sin ese piso, el bandit habría dejado al control sin tráfico en cuanto surgiera un líder y no habría quedado ningún punto de comparación.

Días 4–10: generar y dejar que aprenda. Introduje cuatro variantes que modificaban el titular del hero, el texto del CTA principal y el orden del bloque de prueba social. La primera semana corresponde a la fase de exploración del bandit. La asignación parecía casi uniforme: 22%, 19%, 21%, 18% y 20% entre el control y las cuatro variantes en el día 7. Es justo el momento en que muchos responsables se inquietan e intentan «ayudar». No hay que hacerlo. Retocar las variantes a mitad del aprendizaje reinicia los priors y desperdicia la semana.

Días 11–21: observar la curva de reasignación. Cerca del día 12, la inclinación del bandit empezó a ser visible. Para el día 18, la variante líder recibía el 41% del tráfico, el control conservaba su piso del 20%, dos variantes intermedias se situaban en ~15% cada una y la peor había quedado limitada a menos del 10%. Así es como el bandit cumple su función: cada visitante enviado a la opción perdedora aumenta el arrepentimiento acumulado, y el algoritmo lo minimiza en tiempo real.

Días 22–30: fijar el patrón y decidir. Fijé la dirección ganadora, no la variante literal, sino el patrón: un hero más corto, un CTA centrado en el beneficio y la prueba social visible antes de desplazarse por la página. Exporté las variantes. La pregunta del día 30 era esta: ¿debía pasar la variante ganadora a una prueba A/B limpia contra el control para obtener una cifra causal que pudiera presentar al consejo, o convenía mantener el bandit activo con la siguiente ronda de variantes?

Estas fueron las salvaguardas vigentes durante todo el periodo: un piso mínimo del 20% del tráfico para el control; un interruptor de emergencia si el límite inferior del intervalo de confianza de una variante mostraba una caída relativa del 50% frente al control durante más de 48 horas; y una revisión semanal de los cambios en la mezcla de tráfico. Si el reparto entre pago y orgánico variaba más de 10 puntos de una semana a otra, congelaría el bandit hasta que se estabilizara. El tráfico no estacionario es el enemigo silencioso.

El problema de atribución, sin rodeos

Esta es la sección que las listas superficiales nunca incluyen y la única razón por la que existe este artículo.

Por definición, un bandit multibrazo no puede ofrecer significancia estadística para una sola variante. El aparato estadístico de las pruebas A/B —valores p, intervalos de confianza y cálculos de potencia— parte de una regla fija de asignación. Toda la propuesta de valor del bandit consiste precisamente en que esa regla no sea fija: se adapta a lo que indican los primeros datos. En cuanto la asignación depende de los resultados, la inferencia clásica deja de ser válida. Las muestras quedan sesgadas en todos los brazos. Todavía es posible medir las conversiones acumuladas de toda la población, pero no establecer una relación causal limpia entre la variante B y la variante A.

No es un error, sino una decisión de diseño. El bandit optimiza otro objetivo: minimizar el arrepentimiento acumulado y maximizar las conversiones acumuladas. Las comparaciones empíricas muestran de forma consistente que los bandits reducen el arrepentimiento un 30–60% frente a las pruebas A/B con reparto uniforme en problemas estacionarios. La métrica es «menos arrepentimiento acumulado», no «mejora causal demostrada de la variante B».

Esta diferencia obliga a expresarse con precisión:

• Defendible: «Tras implementar el bandit, la página convirtió al 4.62% entre 84,000 visitantes durante 30 días, frente al 3.41% de la misma página en los 30 días anteriores».
• Indefendible: «La variante B causó una mejora del 35% en la tasa de conversión».

La primera frase describe un resultado acumulado. La segunda afirma causalidad, algo que un bandit no permite demostrar.

La solución parcial fue reservar el 20% para el control. Como la página original mantuvo una asignación garantizada del 20% durante los 30 días, dispongo de una cohorte de comparación pequeña pero limpia. La cohorte de control convirtió al 3.38% durante la prueba, prácticamente igual que la tasa base de los 30 días anteriores. La cohorte que excluía el control convirtió al 4.93%. Eso aporta una señal direccional: la mejora es real, no un efecto estacional. Aun así, no constituye un resultado A/B limpio, porque el grupo sin control es una mezcla cambiante de variantes. Basta, sin embargo, para decirle a un consejo directivo que «la prueba superó a su propio grupo de reserva interno; esta es la diferencia, esto es lo que afirmamos y esto es lo que no».

Si se necesita una cifra causal defendible, el bandit puede utilizarse para encontrar la dirección candidata y, después, la variante líder puede pasar a una prueba A/B 50/50 contra el control. Ese flujo respeta tanto el presupuesto de arrepentimiento acumulado de quien opera la página como el estándar probatorio de quien analiza los resultados.

Dónde no funcionó

Apliqué la misma metodología en dos páginas donde el bandit rindió peor que una prueba A/B convencional. La primera era una página de precios con poco tráfico: menos de 400 sesiones al día. El bandit tardaba demasiado en salir de la fase de exploración y las señales direccionales eran ruidosas. Una prueba A/B sencilla con reparto 50/50 durante seis semanas ofreció una respuesta más clara y exigió menos trabajo operativo. La segunda era un flujo de pago cuyo evento de conversión se producía entre 3–5 días después de la exposición a la variante. Los bandits presuponen una respuesta razonablemente rápida; cuando transcurre mucho tiempo entre la exposición y el resultado, el algoritmo reasigna el tráfico con datos obsoletos y persigue espejismos.

Descarté cerca del 40% de las variantes generativas de Coframe y una proporción menor de las creadas por Webflow Optimize. Las señales eran las habituales: rayas largas donde no correspondían, verbos grandilocuentes de catálogo y listas paralelas con ese ritmo de un modelo que intenta sonar como un especialista en marketing. Todo lo que caía en el valle inquietante de la voz de marca se eliminaba antes de recibir tráfico. Esa tasa de rechazo es el costo que nadie incluye en las páginas de precios.

La trampa del tráfico no estacionario estuvo a punto de afectarme en la tercera semana. La proporción de tráfico de pago pasó del 30% al 47% en cuatro días mientras escalaba una campaña de Meta. La variante líder del bandit había ganado con una mezcla de tráfico distinta de la que empezaba a llegar, y su conversión comenzó a debilitarse. Congelé el bandit durante 48 horas, esperé a que la mezcla se estabilizara y reinicié la exploración desde cero. Si lo hubiera dejado activo, habría aprendido una lección equivocada de una audiencia temporalmente distinta.

La regla que puede repetirse

Esta es la regla de decisión general, ya separada de las particularidades de mi página:

Conviene usar un bandit cuando el tráfico sea escaso en relación con la mejora que se necesita detectar, cuando resulte significativo el costo de mostrar una variante perdedora a la mitad de las visitas, cuando la página opere continuamente y sin una ventana de campaña, y cuando las conversiones acumuladas del trimestre importen más que una cifra causal defendible de una sola variante. Conviene usar una prueba A/B cuando haya que justificar la mejora ante quien controla el P&L, cuando el cambio sea lo bastante grande e infrecuente como para exigir una lectura limpia antes de adoptarlo, o cuando se pretenda extender la variante ganadora a otras superficies y sea necesario saber si funcionó de verdad.

La mayoría de los equipos terminará usando ambos métodos. El bandit encaja en las superficies de conversión siempre activas: la página de inicio, la página principal de oferta y el flujo de registro. El A/B corresponde a las apuestas de dirección: precios, posicionamiento y una nueva versión del hero. El error es tratarlos como metodologías rivales. Cada una optimiza un objetivo distinto. Las listas superficiales también se equivocan al presentar el bandit como una mejora gratuita, sin contrapartida estadística. No lo es. El precio es el valor p, y se paga de forma consciente o no se paga.

El costo de mantenerlo activo a la escala descrita es de $299 al mes por Webflow Optimize en el nivel de 100K vistas de página, con niveles superiores a medida que crece el tráfico. Hay que presupuestar además medio día semanal de trabajo operativo para revisar las asignaciones, eliminar variantes deficientes y vigilar las desviaciones no estacionarias. Esa es la cifra real. Si este flujo se está integrando en una agencia o en un equipo interno de crecimiento y hace falta conectar la atribución de conversiones con el CRM y el almacén de datos de forma limpia, esa es otra conversación. La implementación del bandit en sí requiere una persona, una tarde y una etiqueta de script.

Un solo CTA, porque el artículo es largo y el siguiente paso debe ser claro: la lista de verificación para auditar flujos de negocio con IA es la que utilizo para determinar qué superficies admiten un bandit y cuáles necesitan una prueba A/B limpia. Hay que aplicarla al embudo antes de elegir una herramienta. Cuando un equipo de crecimiento elige primero la herramienta, termina pagando por funciones que no tiene tráfico suficiente para aprovechar.