Cuando empezamos un proceso de investigación y experimentación en cualquier contexto, el primer paso que debemos tomar es obtener datos mediante una gran variedad de fuentes. Con estos datos es posible desarrollar hipótesis, testearlas y, en base a los resultados de nuestros tests, decidir si nuestra hipótesis formulada puede ser cierta o falsa.
Siempre existe una hipótesis nula: la afirmación de que no hay una relación entre dos fenómenos medidos. En otras palabras, estamos suponiendo que cualquier resultado que obtenemos es debido al azar y no a nuestro accionar.
Sin embargo, como todas las pruebas se basan en estadísticas y probabilidad, nunca podemos asegurar con un 100% de certeza la verdad o falsedad de la hipótesis. Por eso hablamos de errores de tipo I y tipo II.
En un error de tipo I, la hipótesis nula se rechaza, sin embargo era verdadera. Supusimos que nuestros cambios efectuados generaron una mejora en nuestras métricas objetivo, sin embargo no es así, sino que cualquier mejora detectada fue debido al azar. Estamos en presencia de un falso positivo.
Exigir un mayor nivel de significación estadística nos ayuda a disminuir el riesgo de cometer un error de tipo I; por otro lado, la desventaja de aplicar esta modificación es que perdemos un poco de probabilidad de detectar una diferencia real, si esta existiera. Otra consecuencia de aumentar la significación es que se aumentará el efecto mínimo detectable (MDE).
En un error de tipo II, la hipótesis nula se acepta, sin embargo era falsa. En este caso, pensamos que los resultados eran debidos al azar, pero en realidad el cambio observado fue consecuencia de nuestras modificaciones. Cuando esto ocurre, se habla de un falso negativo.
Para reducir el riesgo de cometer un error de tipo II, es necesario aumentar la potencia del test, aumentando el tamaño de la muestra. De este modo se puede detectar la diferencia real, cuando ésta exista. A veces, al aumentar el tamaño de la muestra, se estiran los plazos en los tests si no alcanza con la cantidad de usuarios que ya hay.
Más de una vez, luego de hacer un test A/B de rutina, es posible que nos encontremos con excelentes resultados que prometen aumentos en las métricas objetivo, sin embargo al implementar el cambio, no parece que tengamos una mejora en las mismas.
¿Qué está pasando? Es posible que no veamos una mejora en la performance, porque en realidad nunca hubo una mejora real. Sin saberlo, nuestro test generó un error de tipo I. Después de todo, un test con una significación estadística de un 95% quiere decir que hay una posibilidad en 20 de obtener un falso positivo.
De hecho, muchas veces los tests A/B no producen resultados significativos, y puede que se deba a problemas con la herramienta de testing.
Si sospechamos que nuestros tests A/B pueden estar dando resultados incorrectos (es decir, dando un ganador cuando al implementar el cambio no se ve una mejora), es necesario analizar por qué está ocurriendo esto. Hay algunas causas de errores muy comunes que podemos descartar:
- Es posible que tengamos poco tamaño de muestra para testear cambios menores, y el efecto en la métrica objetivo no sea detectable.
- Muchas veces se decide terminar el test antes de tiempo, ya sea porque se llegó al tamaño de muestra esperado, o porque creemos que la variación que se testea está perdiendo contra el control. Esta es una práctica nada recomendable, ya que el comportamiento de los usuarios varía dependiendo del momento del día, de la semana e incluso del mes.
Si luego de descartar estas opciones, seguimos buscando una causa que explique la discrepancia entre el test y la implementación, puede ser útil pensar en correr un test A/A: esto es, testear dos versiones idénticas de la página entre sí. En teoría, deberíamos ver comportamientos similares y conversiones similares en ambas versiones.
- Permite asegurarnos que nuestra herramienta de testing funcione correctamente: en un test A/A, no deberíamos tener diferencias significativas entre nuestras dos variaciones de la situación (por ejemplo, dos sitios web exactamente iguales), ya que son idénticas. Por lo tanto, si al terminar el test se declara un ganador, esto significa que hay algo a resolver. Puede ser que la herramienta de testing no esté bien configurada, o directamente no sea efectiva. O también puede ocurrir que el test no se haya configurado correctamente. Correr un test A/A nos proporciona la oportunidad de ver que todo esté bien antes de lanzarnos a testear.
- Podemos conocer las métricas esperadas de nuestro control: al testear una situación contra sí misma, si todo está configurado correctamente, no solamente obtenemos una sola métrica, sino un rango de métricas posibles para nuestro control. Por lo tanto, cuando más tarde corramos un test A/B, si nuestras métricas caen dentro de este rango, podemos considerar que el resultado no es significativo estadísticamente.
- Es una manera de decidir un tamaño de muestra adecuado: cuando el tamaño de muestra es demasiado pequeño, puede que no haya la suficiente cantidad de usuarios en algunos segmentos, y esto impactará en el resultado de nuestro test. Al ir aumentando el tamaño de muestra, disminuimos este efecto, hasta encontrar el tamaño adecuado para configurar el test A/B.
- Se pierden recursos y tiempo de testeo: pasar semanas haciendo un test A/A son semanas que se podrían haber usado para correr un test A/B. Y considerando que un tiempo adecuado para un test son por lo menos dos ciclos de compra (idealmente 4, es decir, 28 días), esto puede generar retrasos importantes en un proceso de experimentación.
- Puede distraernos de correr tests A/B válidos, que a la larga serán los que nos generen un aumento en los ingresos.
- Requieren un tamaño de muestra mucho mayor que un test A/B convencional, ya que estamos intentando ver una diferencia que no existe debido a que estamos comparando cosas iguales.
- Es posible que caigamos en una situación donde se declara un ganador, y sin embargo se deba al azar. En ese caso, si bien tanto herramienta como test están bien configurados, creemos falsamente que hay algún problema. Por más que hagamos un test de tipo A/A, no estamos exentos de caer en errores de tipo I o II, ya que éstos son inherentes a los test de hipótesis.
Si nunca corrimos un test A/B, empezar con un test A/A es ideal para familiarizarnos con la herramienta elegida, ya que tiene muy poco riesgo, y nos muestra la forma correcta de proceder al empezar a hacer tests A/B.
Cualquier herramienta con la capacidad de correr un test A/B permite correr un test A/A: la muestra se divide en iguales partes entre ambas versiones, pero en ambos casos la experiencia del usuario es idéntica.
Al estar comparando una situación con sí misma, la aleatoriedad debería dictar que no haya una diferencia significativa entre ellas. Pero podría ocurrir que una de las dos iteraciones muestre un aumento en la performance que no esperábamos.
Si “la variación” gana, es algo atribuible al azar, y es algo que puede corregirse con un aumento del tamaño de muestra. Pero si vemos que se declara a “la versión original” como ganadora, y es algo que ocurre con regularidad, podría ser importante prestar atención a la herramienta de testing que usamos; es muy posible que la variación esté mostrando una menor performance (por ejemplo, un sitio web o un menú telefónico que se comportan de forma mucho más lenta respecto al original).
Si ya tenemos la experiencia en tests A/B, puede que nos interesen los beneficios de un test A/A, pero al mismo tiempo no queremos gastar tiempo de testeo y recursos.
En ese caso, una opción es hacer un test A/A/B, es decir: dos variaciones de la misma página control, y una variación con un cambio.
La mayor desventaja de este tipo de test es que al tener tres versiones y no dos, se necesita una mayor cantidad de usuarios para llegar al tamaño de muestra que precisamos, pero por otro lado, tendremos información tanto de la herramienta y del test en sí (al comparar A/A) y la comparación entre control y cambio efectuado. De este modo, podemos “ganar tiempo” haciendo un test A/B al mismo tiempo que nuestro test A/A. La desventaja de esto es que si al comparar A/A encontramos diferencias significativas (lo que implica que hay algún problema con el test o la herramienta), los resultados del test A/B no pueden considerarse confiables.
Otra variación de este tipo de tests son los A/A/B/B: se divide la muestra en 4, de este modo se compara el control con el cambio, entre ellos y también con sí mismos. La mayor desventaja de este tipo de test es que se requiere un tamaño de muestra mucho mayor debido a la mayor división de los usuarios (se requiere el doble de personas que en un test A/B tradicional), por lo que en la mayoría de los casos no es una opción recomendable.
Los tests A/A pueden ser una herramienta para entrar en el mundo de los tests A/B de manera responsable y aplicando buenas prácticas, y un buen primer paso para conocer las herramientas con las que contamos. Sin embargo, cuando no se cuenta con suficiente tamaño de muestra, podemos llegar a conclusiones equivocadas. En muchos casos, si la cantidad de usuarios es suficiente para poder ser dividido en más de dos caminos, puede ser más productivo hacer tests de tipo A/A/B en vez de correr un test A/A.