Las pruebas A / B frecuentemente se facturan como una forma científica de validar las decisiones de diseño. Ocasionalmente denominado prueba dividida, la prueba A / B es un proceso simple que en la superficie parece prometer resultados concretos:
Cree dos variaciones en un elemento de diseño, al azar intercambielas en su sitio y registre cómo reaccionan sus usuarios, compare los resultados e implemente la variación que mejor funcione. Que tiene sentido.
El ejemplo clásico es: ¿un botón rojo vs. un botón verde, que se tocará más? Sin embargo, la pregunta más interesante es: ¿un botón verde vs. el mismo botón verde, que se tocará más?
¿Qué sucede cuando nosotros A / B probamos dos variaciones idénticas? Una prueba A / A, si lo desea.
Para probar la validez de cualquier prueba A / B, necesitamos una prueba que tenga una respuesta "correcta". Necesitamos una respuesta correcta porque queremos saber, en igualdad de condiciones, qué tan probable es que la prueba A / B produzca el resultado que debería, y para eso necesitamos saber qué resultado esperar.
Si A / B probamos dos botones idénticos, el resultado debería ser un calor muerto
Entonces, supongamos que estamos probando un botón verde con el mismo botón verde, y que el botón es tan tentador que el 100% de los usuarios lo tocará.
(El porcentaje en realidad no importa, podría ser 14.872%. Lo que importa es que debido a que los botones son idénticos, la tasa de toque también debería ser idéntica).
Si A / B probamos dos botones idénticos, el resultado debería ser un punto muerto.
Tirar una moneda. ¿Qué lado saldrá, cara o cruz? Sabemos que hay dos lados, ambos idénticos, así que es una posibilidad de 50-50.
Si arrojamos nuestra moneda dos veces, sabemos que hay tres resultados posibles: 2 cabezas, 2 colas o 1 cabeza y 1 cola. Y así…
Digamos que el lanzamiento de la moneda es nuestra prueba A / A; las probabilidades de que salga el lado de las cabezas son idénticas a las probabilidades de que salga el lado de las colas, al igual que las probabilidades de que cualquiera de nuestros botones verdes sean golpeados son iguales.
Así que vamos a escribir una secuencia de comandos rápida en el navegador (porque la mayoría de las pruebas A / B se realizan en el navegador) para simular usuarios tocando un botón u otro, dependiendo de cuál se les presente.
Recuerde: estamos probando dos variaciones idénticas de un botón, y la forma en que sabemos que son idénticas es que estamos tratando la probabilidad de que se exploten como idénticas. Todo lo que estamos buscando es un resultado consistente (y por lo tanto correcto).
En primer lugar, necesitamos una tabla HTML para registrar nuestros resultados, la tabla se verá así:
# Heads Tails Difference Margin of Error
En la primera columna registraremos el número de la prueba (todas las buenas pruebas A / B se repiten para verificar los resultados, por lo que repetiremos la prueba varias veces). A continuación, registraremos el número de resultados de Jefes , luego el número de resultados de Tails . La columna después de eso será la diferencia entre los dos resultados (que debe ser cero). Luego registraremos el margen de error (que una vez más debería ser 0%). Debajo de la tabla, imprimiremos un resumen, el promedio de todos los resultados y el peor de los casos.
Aquí está el guión:
var bestOf = 12, // the number of times we want to run the testtestRepeat = 12, // the number of times we’d like to repeat the testtestCount = 0, // the number of the current testtestInterval = setInterval(performCoinToss, 100), // call the coin toss functiontotalDifference = 0, // used for calculating the average differenceworstDifference = 0; // the worst casefunction performCoinToss(){testCount++; // increment the current testvar testCounter = bestOf, // the current iteration of the testheadsCounter = 0, // the total number of times the script came up with "heads"tailsCounter = 0; // the total number of times the script came up with "tails"while(testCounter--) // loop 'testCounter' times{Math.round(Math.random()) ? headsCounter++ : tailsCounter++; // finds 0 or 1 randomly, if 1 increments headsCounter, otherwise increments tailsCounter}var difference = Math.abs(headsCounter - tailsCounter), // the difference between the twoerror = (difference / bestOf) * 100; // the error percentagedocument.getElementById("results").innerHTML += "" + testCount + " " + headsCounter + " " + tailsCounter + " " + difference + " " + error + "% Average difference: " + averageDifference + "
Average margin of error: " + averageError + "%
Worst Case: " + worstDifference + "
"; // write summary to pageclearInterval(testInterval); // if the test has been repeated enough times, clear the interval}}El código está comentado, así que aquí están solo los aspectos más destacados:
En primer lugar, configuramos algunas variables, incluidas la cantidad de veces que deseamos arrojar la moneda (bestOf) y el número de veces que queremos repetir la prueba (testRepeat).
Alerta de spoiler: vamos a entrar en algunos bucles bastante altos, por lo que para evitar romper el navegador de cualquier persona estamos realizando la prueba en un intervalo cada 100 ms.
Dentro de la función performCoinToss hacemos un círculo en el número requerido de veces, cada iteración del ciclo usamos la función aleatoria de JavaScript para generar un 1 o un 0, que a su vez incrementa el contador de cabezas o el contador de cruces .
A continuación, escribimos el resultado de esa prueba en la tabla.
Por último, si la prueba se ha repetido la cantidad de veces que nos gustaría, encontramos los promedios y, en el peor de los casos, los escribimos en el resumen y borramos el intervalo.
Aquí está el resultado . Como puede ver, la diferencia promedio es, bueno, será diferente para usted, pero mientras escribo esto, la diferencia promedio es 2.8333333333333335, el error promedio es por lo tanto 23.611111111111114%.
Más del 23% de error no inspira confianza, especialmente porque sabemos que la diferencia debe ser 0%. Lo que es peor es que el resultado de mi peor caso es 8, eso es 10-2 a favor de las cabezas.
De acuerdo, entonces esa prueba no fue justa. Una prueba A / B real nunca reclamaría para encontrar un resultado concluyente de solo 12 usuarios.
Las pruebas A / B usan algo llamado "significación estadística", lo que significa que la prueba debe ejecutarse en suficientes ocasiones para lograr un resultado procesable.
Entonces, dupliquemos la variable bestOf y veamos cuánto tenemos que avanzar para alcanzar un margen de error de menos del 1%, el equivalente al 99% de confianza.
En el mejor de los 24 (en el momento de redactar este informe), la diferencia promedio es 3.1666666666666665, que es 13.194444444444445%. ¡Un paso en la dirección correcta! Pruébalo por ti mismo (sus resultados variarán).
Vamos a duplicarlo de nuevo. Esta vez, mi diferencia promedio fue 6.666666666666667, con un margen de error de 13.88888888888889%. Peor aún, el peor caso es 16, ¡eso es un error de 33.33333333333333%! Usted puede intenta eso para ti también.
En realidad, no hay premios para adivinar que podemos seguir: Lo mejor de 96 , lo mejor de 192 , Lo mejor de 384 , Lo mejor de 768 , Lo mejor de 1536 , Lo mejor de 3072 , Lo mejor de 6144 , Lo mejor de 12288 , Lo mejor de 24576 , Lo mejor de 49152 , Lo mejor de 98304 .
Finalmente, en el mejor de 98304, el peor de los escenarios cae por debajo del 1%. En otras palabras, podemos estar 99% seguros de que la prueba es precisa.
Entonces, en una prueba A / A, cuyo resultado conocíamos de antemano, tomó un tamaño de muestra de 98,304 para alcanzar un margen de error aceptable.
Cada vez que se habla de las pruebas A / B, alguien recuerda a un amigo de un amigo, que A / B probó un solo botón en su sitio, e inmediatamente obtuvo algunas ganancias improbables (el valor real en dólares del botón aumenta cada vez que oigo el historia).
En esos cuentos, los botones generalmente se prueban para microcopias, "Descargar mi libro electrónico" vs. "Descargar mi libro electrónico gratis". No debería ser una sorpresa que este último gane. Es una mejora que cualquier buen redactor haría. Una prueba A / B más apropiada sería "Descargar mi libro electrónico" frente a "Descargar el libro electrónico" (mi dinero está en este último).
Si te encuentras con un resultado muy cargado hacia una de las opciones, sugiere que algo está muy mal con una de tus variaciones. Más a menudo, un buen resultado será una mejora de menos del 5%, lo que presenta un problema si está probando con alrededor de 1000 usuarios (el margen de error es de alrededor del 5%).
Cuanto más útil sea una prueba, más ajustado será el margen de victoria para una variación u otra. Sin embargo, cuanto más ajustado sea el margen de victoria, mayor será el tamaño de muestra necesario para obtener un margen de error aceptablemente pequeño.
Mark Twain, posiblemente citando a Disraeli, una vez usó la frase: mentiras, malditas mentiras y estadísticas. Con lo cual quiso decir que algo demostrado por las estadísticas, no es necesariamente cierto. Las estadísticas se pueden usar para demostrar cualquier cosa que desee.
Las pruebas A / B le proporcionarán un resultado, pero es un resultado que dirá más sobre usted y sobre lo que esperaba encontrar, que sobre sus clientes
Lo más peligroso de las pruebas A / B es que puede probar todo lo que quieras; puede producir falsos positivos y nos permite discernir patrones que no están adecuadamente respaldados.
Además, una prueba A / B puede indicar que un botón verde supera a un botón rojo, pero ¿qué pasa con un botón azul? Incluso las pruebas A / B exitosas solo nos permiten validar nuestras decisiones de diseño dentro del contexto de la prueba en sí.
Para que una prueba A / B funcione de la manera prevista, necesitamos que se cumplan dos condiciones opuestas:
Desafortunadamente, la mayoría de los sitios no tienen un tamaño de muestra lo suficientemente grande como para alcanzar un margen de error suficientemente pequeño. Y como no podemos aumentar nuestro tamaño de muestra (lo haríamos si pudiéramos), nuestra única opción es aumentar la variación de las opciones para producir un resultado claro, sesgando la prueba según nuestras preferencias.
Las pruebas A / B le proporcionarán un resultado, pero es un resultado que dirá más sobre usted y sobre lo que esperaba encontrar, que sobre sus clientes. Cuando se trata de tomar decisiones de diseño en cualquier sitio que no sean aquellos con volúmenes muy altos de tráfico, también podríamos lanzar una moneda, como prueba A / B.
Foto principal, imagen de lanzamiento de moneda a través de Shutterstock.