por Rostyslav Mykhajliw Fundador de TrueSocialMetrics.com ~ 5 min
La clásica prueba A/B es una distribución entre diferentes estados. Comencemos con una muestra general que todos usan. Tenemos un sitio con un botón de registro, actualmente es azul, pero queremos probar un nuevo color rojo.
Luego asignamos algo de tráfico y esperamos algo. Hay calculadoras simples para statistical significance.
Opción A: 50k visitas - 500 registro Opciones B: 50k visitantes - 570 registros - ganador
B es un ganador, es claro. Más registros, significancia estadística.
¡Espera un poco! Lo que estamos lanzando algo nuevo. Por ejemplo, estamos agregando un botón de "demostración" para ver una guía paso a paso del producto.
Si seguimos una lógica simple de pruebas A/B, ¡no funciona! Porque no podemos comparar manzanas con naranjas. ¡No podemos comparar nada con algo! Es totalmente incorrecto. Si no hay un botón de demostración, los usuarios pueden obtener una peor experiencia que aquellos que tienen esta opción. Pero esta opción solo puede ayudar a los usuarios que ya están interesados en el producto o que ya se han declarado usuarios del producto recientemente. Incluso si tiene millones de tráfico, no puede decir cómo funciona en unas pocas horas/días porque los resultados pueden posponerse en el tiempo.
Para una nueva funcionalidad se debe liberar linealmente como proceso de liberación enteral. Solo entonces, después de un tiempo, podemos analizarlo y determinar si tuvo algún impacto en la experiencia del cliente o no, pero rastreando las métricas comerciales. Las pruebas A/B NO son aplicables para una nueva funcionalidad.
Regrese a la primera muestra con el botón de registro. Si nuestra suposición es correcta, podemos agregar más opciones A y más opciones B y nada cambiará, porque B aún puede ganar la batalla.
Luego mira los resultados:
A1: 50k visitas - 500 registro A2: 50k visitantes - 580 registros - ganador B1: 50k visitantes - 570 registros - ganador B2: 50k visitantes - 500 registros
¡QUÉ! ¡QUÉ! ¡QUÉ! Puede decir que es imposible, pero esta situación muestra una diferencia si la asignación de visitantes tiene efecto en los resultados de las pruebas. Y estos resultados muestran una significación estadística estable del 95% pero confianza baja.
Si volvemos al comienzo del artículo, notaremos un gran tráfico de 50k visitantes y 500 transiciones requeridas para recibir resultados significativos. Sin embargo, no todas las páginas tienen estas posibilidades. No todas las empresas emergentes son lo suficientemente buenas para generar tal tráfico, o pueden ser páginas de poco tráfico como configuración/facturación, etc. más o menos. El siguiente inconveniente del enfoque general es que al menos 50 000 visitantes (de 100 000 asignados a la prueba) empeoraron la experiencia del cliente. Así que estamos esperando mucho tiempo y perdiendo clientes debido a la asignación a una prueba de "pérdida". Tiene algún sentido ? En la sanidad los médicos cruzaban los temas del caso, pero en una tabla estaba la vida de las personas. Si hacemos una prueba durante la cual el 50% de los pacientes están muriendo debido a "atención aún no probada". Y es una locura. Aquí hay un tipo, Marvin Zelen, a quien se le ocurrió la idea de las pruebas adaptativas, que ahora se llama Zelen’s design.
Imaginemos que tenemos 2 posibilidades: bolas rojas y azules, por lo que estadísticamente es un 50% de probabilidad.
Por ejemplo, asignamos aleatoriamente al visitante a "azul" y "azul" es una mejor experiencia porque obtuvimos la compra. En este caso, "azul" está ganando, es por eso que agregamos una bola "azul" adicional a la piscina.
Como resultado, la probabilidad cambió "rojo" - 33% y "azul" - 67%
¡Suena bien! Pero el próximo visitante con "azul" no hace nada. Así que "azul" está perdiendo, es por eso que tenemos que quitar una bola "azul" de la piscina y obtuvimos nuestro estado anterior.
Ventajas: + funciona para una pequeña cantidad de tráfico + proporciona una mejor atención a los usuarios de forma adaptativa Contras: - requiere que los desarrolladores trabajen para descubrir pruebas ganadoras/perdedoras en el proceso de prueba