Test A/B

Un test A/B es un experimento que muestra dos versiones de una página o un anuncio a partes iguales del público para comprobar cuál produce mejores resultados. Se decide con datos y no con opiniones, y solo cambia un elemento entre ambas versiones.

Cómo se hace bien

La mecánica es sencilla y las condiciones para que el resultado valga algo lo son menos.

Primero se formula una hipótesis, no una ocurrencia. Una hipótesis dice qué se cambia, qué se espera que ocurra y por qué. Cambiar el color de un botón porque sí no enseña nada; cambiarlo porque el mapa de calor muestra que pasa desapercibido, sí.

Después se define la métrica de éxito antes de empezar. Si se decide al final mirando qué salió bien, siempre saldrá algo bien por azar.

Después se calcula cuánto tráfico hace falta. Aquí es donde fracasan la mayoría de las pruebas en pymes. Para detectar una mejora de un 20 por ciento sobre una conversión del 2 por ciento hacen falta varios miles de visitas por versión. Con 300 visitas al mes, un test A/B no es la herramienta adecuada.

Y después se deja correr el tiempo necesario, mínimo una o dos semanas completas para cubrir todos los días de la semana, sin parar en cuanto una versión va ganando. Los primeros días engañan casi siempre.

Un cuidado adicional: cambiar una sola cosa. Si se modifican el titular, la foto y el botón a la vez, se sabrá que una versión gana pero no por qué, y eso impide aprender para la siguiente.

Qué probar cuando hay poco tráfico

Con volúmenes pequeños, tres alternativas dan más que un test mal hecho.

Probar cambios grandes en lugar de detalles. Una diferencia del 40 por ciento se detecta con mucho menos tráfico que una del 5. Rediseñar la página entera y compararla con la anterior es más práctico que discutir el texto de un botón.

Medir en secuencia en lugar de en paralelo. Comparar el mes de la versión antigua con el mes de la nueva no es tan riguroso, porque cambian la estacionalidad y el tráfico, pero orienta.

Y usar métodos cualitativos: grabaciones de sesión, encuestas de una pregunta al salir y pruebas de usuario con cinco personas. Detectan problemas evidentes que ninguna prueba estadística va a descubrir.

Conviene saber que Google no penaliza estas pruebas siempre que se hagan con las herramientas habituales, se muestre el mismo contenido esencial y no se prolonguen indefinidamente.

Ejemplo: una empresa de seguros de decesos en Jaén

Una correduría recibía 12.000 visitas mensuales en su página de solicitud de presupuesto, con una conversión del 3,1 por ciento.

Su hipótesis parte de las grabaciones de sesión: la gente se detenía y abandonaba en el campo de fecha de nacimiento, que exigía un formato concreto y daba error con frecuencia.

Prueban dos versiones durante tres semanas. La A mantiene el formulario de nueve campos con el selector de fecha original. La B reduce a cuatro campos, sustituye el selector por tres desplegables y traslada las preguntas restantes a la llamada posterior.

La versión B convierte al 7,4 por ciento, más del doble. Con 12.000 visitas mensuales, eso supone 516 solicitudes en lugar de 372.

El experimento siguiente prueba añadir el precio orientativo antes del formulario, y esa vez la versión nueva pierde. Lo descartan y siguen con la anterior, que es exactamente para lo que sirve el método.