Test A/B no concluyente: qué hacer sin ganador

La mayoría de los tests A/B no tienen ganador, y no es un fallo del método. De hecho, solo una fracción de los experimentos mejora la métrica objetivo. Esa fracción va de aproximadamente un tercio a cifras cercanas al 10%, según la empresa y la madurez del producto.

Si eso es lo normal, la pregunta relevante no es cómo evitar los tests planos, sino qué hacer con ellos. Un resultado sin ganador puede significar que no hay efecto. Pero también puede significar que hay dos efectos opuestos que se anulan.

Cuando dos efectos se cancelan entre sí

Hace unas semanas testeamos un selector de destinos por pestañas en la home de una cadena de hoteles de lujo, con tres versiones: el listado actual y dos variantes del selector. El test se cerró sin ganador. La mejor variante marcaba +2,09% con un 79,7% de probabilidad, lejos del umbral de fiabilidad para Boost.

Al desglosar por dispositivo apareció el patrón: el selector funcionaba en mobile y restaba en desktop. En mobile el usuario ya viene haciendo scroll sobre contenido apilado, y el selector ordena la navegación. En desktop el listado ya se escaneaba bien, y el bloque añadía un paso. En el agregado, un efecto compensaba al otro.

La segunda ronda

Con esa lectura lanzamos una segunda versión solo para mobile, manteniendo las tres versiones. Estos fueron los resultados:

<table> <thead> <tr> <th>Métrica</th> <th>Control</th> <th>Variante B</th> <th>Cambio</th> <th>Probabilidad</th> </tr> </thead> <tbody> <tr> <td>Clic al CTA de disponibilidad (principal)</td> <td>8,65%</td> <td>9,84%</td> <td>+13,65%</td> <td>98,5%</td> </tr> <tr> <td>Clic de abandono (diagnóstico, menos es mejor)</td> <td>17,68%</td> <td>15,92%</td> <td>−9,95%</td> <td>99,4%</td> </tr> <tr> <td>Entrada al motor de reservas (guardrail)</td> <td>20,31%</td> <td>21,65%</td> <td>+6,60%</td> <td>96,1%</td> </tr> </tbody> </table>

La variante B logró la significancia con margen y con una pérdida esperada del 2,11%. Las tres métricas apuntaban en la misma dirección, y el efecto se mantenía en usuarios nuevos (+14,89%) y recurrentes (+13,43%). Lo que en la primera ronda parecía una idea sin impacto terminó implementado en mobile.

Potencia y efecto mínimo detectable: el origen de muchos tests planos

Una parte importante de los tests sin ganador no fracasan por la idea, sino por el diseño. Un test tiene una capacidad limitada de detectar cambios, que depende de tres cosas: la tasa de conversión de partida, el tamaño del efecto que quieres detectar y el tráfico disponible.

Un ejemplo con números redondos lo muestra bien. Imagina una página con una conversión del 5%. Para detectar una mejora relativa del 20%, es decir, pasar al 6%, con una confianza del 95% y una potencia del 80%, necesitas aproximadamente 7.600 usuarios por versión. Si quieres detectar una mejora del 10%, pasar al 5,5%, la cifra sube a unos 30.000 por versión. Reducir a la mitad el efecto que buscas multiplica por cuatro la muestra necesaria.

Eso tiene una consecuencia directa. Si tu página recibe 20.000 visitas al mes y lanzas un test con tres versiones, cualquier cambio que mueva menos de un 15% o un 20% probablemente saldrá plano, aunque el efecto exista. El test no dice que la idea no funciona. Dice que no ha podido verlo.

Por eso calculamos el efecto mínimo detectable antes de lanzar, y no después. Si el efecto esperado es menor de lo que el test puede ver, hay tres opciones: reducir el número de versiones, usar una métrica con más volumen o más cercana al cambio, o asumir que ese test no merece la pena en esa página.

Probabilidad bayesiana y pérdida esperada

En la mayoría de nuestros proyectos trabajamos con un enfoque bayesiano. En lugar de un valor, el resultado se expresa como la probabilidad de que la variante sea mejor que el control, acompañada de la pérdida esperada: cuánto perderías, en promedio, si eliges la variante y resulta ser peor.

Las dos cifras se leen juntas. Un 98,5% de probabilidad con una pérdida esperada del 2,11%, como en el caso anterior, es una decisión clara. Un 80% de probabilidad con una pérdida esperada alta indica que la variante podría ser mejor, pero que el riesgo de equivocarse todavía es relevante.

En algunas cuentas usamos un 90% de probabilidad como umbral de decisión en lugar del 95% habitual, combinado con un límite de pérdida esperada. Es una decisión que se toma por cliente, según su volumen de tráfico y su tolerancia al riesgo, y queda documentada desde el inicio. Un umbral más bajo permite decidir antes, a cambio de asumir algo más de riesgo. Lo que no conviene es moverlo a mitad de test para que un resultado "llegue".

Cinco preguntas antes de cerrar un test sin ganador

• La primera es si el test tenía potencia suficiente. Si el efecto mínimo detectable era del 15% y tu cambio podía mover un 3%, el test nunca iba a dar una respuesta clara. Con conversiones bajas, como las reservas finales o las compras de alto ticket, esto es muy frecuente.
• La segunda es si los segmentos definidos de antemano divergen. Dispositivo y tipo de usuario, nuevo o recurrente, son los candidatos habituales. Si van en direcciones opuestas, tienes una hipótesis para una nueva ronda, no una conclusión.
• La tercera es si las métricas diagnósticas cuentan la misma historia. Una métrica principal plana con el abandono bajando y la entrada al embudo subiendo no es lo mismo que tres métricas planas.
• La cuarta es si la métrica principal está cerca de la decisión real de negocio. Un test puede ser plano en clics y relevante en ventas, o al revés.
• La quinta es si el objetivo era ganar o no perder. Hay cambios obligatorios, de marca o de cumplimiento normativo, donde un resultado plano es exactamente el éxito buscado.

Lo que se pierde al archivar sin interpretar antes

Un programa de experimentación que descarta todos los tests planos sin analizarlos pierde dos cosas.

• Pierde ideas que funcionaban en un segmento y se diluyeron en el agregado, como el selector de Finest Resorts.
• Y pierde el aprendizaje acumulado: saber que en una web concreta añadir contenido en desktop resta es tan útil como saber qué suma, porque evita repetir hipótesis que ya han fallado.

Si tu equipo tiene un histórico de tests "sin ganador" archivados, puede que haya aprendizajes esperando en ellos. Revisarlos con método es parte de lo que hacemos en nuestro servicio de CRO.