Cuando desarrolla un producto, cada nueva iteración es un riesgo de perder métricas y perder usuarios. Sin embargo, a veces, especialmente en las etapas iniciales, las compañías, sin saberlo, corren este riesgo: cambian el producto, confiando solo en sus instintos e hipótesis.En Badoo no confiamos en los sentimientos, pero creemos en los números. En total, nuestros servicios tienen más de 500 millones de usuarios, y escribimos nuestro marco de prueba durante mucho tiempo. En seis años, 2962 pruebas pasaron por él, y las pruebas A / B demostraron su importancia, confiabilidad y efectividad.
Pero en este artículo no hablaré sobre cómo funciona nuestro sistema. Un artículo no es suficiente para esto. Además, muchas cosas son específicas de nuestra empresa y no se adaptarán a otras. Hoy hablaré sobre la evolución de nuestras ideas sobre las pruebas A / B: qué tipo de rastrillo pisamos en el proceso y cómo verificamos la corrección de las pruebas. Este artículo es para aquellos que aún no han comenzado las pruebas, pero piensen en ello, así como para aquellos que no están seguros de su sistema de prueba.¿Qué es una prueba A / B?
Imagine una situación: se lanzará una nueva función y nuestro gerente de producto no está listo para arriesgar un ingreso pequeño pero estable para el producto. Después de algunas deliberaciones, sugiere lanzar la función a través de la prueba A / B y ver si despegará y los usuarios no acudirán a la competencia. No realizamos pruebas A / B antes, así que lo primero que aprendemos es cuáles son. Wikipedia dice: "La prueba A / B es un método de investigación de mercado , cuya esencia es que el grupo de elementos de control se compara con un conjunto de grupos de prueba en los que se cambiaron uno o más indicadores para averiguar cuál de ellos Cambiar Mejorar objetivo". Resulta que necesitamos realizar un estudio en el que debería haber un grupo de control, al menos un grupo de prueba y un indicador objetivo.Para el grupo de prueba, mostraremos una versión alternativa de la página de pago. En él, queremos cambiar el texto, resaltar el descuento, reemplazar la imagen, y todo esto para los usuarios de Eurasia, para que compren más. Y para los usuarios de Estados Unidos, no queremos cambiar nada. Tendremos objetivos. Tomemos los básicos:- ARPU (ingreso promedio por usuario): el beneficio que recibiremos en promedio del usuario;
- cantidad de clics en elementos de CTA (llamada a la acción): botones y enlaces en la página de pago.
Tarea técnica
Se planea cambiar tres elementos en la página al mismo tiempo: texto, botón e imagen con información de descuento.
Será bastante difícil entender cuál de estos cambios influyó en el resultado si se prueba simultáneamente. Quizás el nuevo texto repelerá a los usuarios y conducirá a una disminución en el número de compras, pero al resaltar el descuento lo aumentará: como resultado, obtenemos cero. Se desperdiciarán recursos de desarrollo y se rechazará la hipótesis de trabajo. Por lo tanto, no haremos esto. Dejaremos solo un cambio para la prueba: asignación de descuentos. 
Primer examen
El plan es este: dividimos a los usuarios en dos grupos iguales y esperamos el resultado. Cuando lo recibamos, compararemos los indicadores en los grupos de control y prueba. Todo parece bastante simple: dividimos a los usuarios en pares e impares y luego miramos las estadísticas. Escribimos el código:if (userId % 2 == 1) {
showNewAwesomeFeature();
}
Esperamos un par de semanas: ¡los resultados son increíbles! ¡ARPU aumentado en un 100%! La gente hace clic, paga, el gerente de producto le pide que implemente rápidamente el cambio. 
Lo encendemos, pasan un par de semanas más, pero no hay resultados. El beneficio total no ha aumentado. ¿Qué estamos haciendo mal?Seleccionamos un grupo de prueba
Simplemente dividimos a los usuarios en dos grupos iguales y realizamos la prueba, pero no puede hacerlo. Después de todo, algo ha cambiado solo para los usuarios de Eurasia. Y tenemos mucho menos de ellos que los usuarios de Estados Unidos. Por lo tanto, resultó que un aumento repentino en la actividad de los usuarios de Estados Unidos influyó en los resultados de nuestra prueba, aunque en realidad no fueron los mejores.Conclusión: siempre seleccione en el grupo de prueba solo aquellos usuarios para quienes se implementan los cambios.Arreglemos nuestro código:if (user.continent === ‘eurasia’ && userId % 2 == 1) {
showNewAwesomeFeature();
}
¡Ahora todo debería funcionar como debería! Ejecute la prueba Estamos esperando un par de semanas.
Sucedió! ¡ARPU ha subido un 80%! Implemente el cambio para todos los usuarios. Y ... después del mismo período de tiempo, los gráficos nuevamente no se ven como planeamos.Calcular significancia estadística
La prueba no se puede detener simplemente "después de un par de semanas": los resultados obtenidos pueden ser inexactos. Cuanto menos haya cambiado la métrica que estamos siguiendo y menos personas participen en la prueba, más probabilidades hay de que sea aleatoria. Esta probabilidad se puede calcular. El valor que lo denota se llama valor p. Te diré cómo funciona.Al realizar cualquier prueba, existe la posibilidad de obtener resultados aleatorios. Por ejemplo, los usuarios que visitaron el sitio pueden estar distribuidos de manera desigual, y toda la audiencia que paga caerá en uno de los grupos. En las pruebas reales, la diferencia en las métricas generalmente no es tan grande: es difícil o incluso imposible notar un problema en los gráficos, y no se puede prescindir de las pruebas estadísticas. En particular, necesitamos arreglar la probabilidaderrores del primer y segundo tipo : en otras palabras, la probabilidad de encontrar cambios donde no existen y, por el contrario, no encontrarlos si existen. Según el valor de la métrica y las probabilidades establecidas, necesitaremos un número diferente de usuarios.Puede calcularlo usando la calculadora en línea : especifique los valores actuales y objetivo de las métricas monitoreadas; obtendrá el número requerido de usuarios para la prueba, y viceversa.
Cálculo para la conversión al 10% y cambios al 0.2% en relación con el valor actual.Ahora hemos recibido todos los datos necesarios y entendemos cuándo detener la prueba. No hay más obstáculos.Ejecutemos nuestra prueba A / B y veamos los resultados.
Esta vez, los resultados se parecen más a la verdad, pero siguen siendo excelentes: el crecimiento de ARPU en un 55%. Paramos la prueba, aplicamos el grupo de prueba en absoluto. Y ... las métricas están cayendo nuevamente. ¿Por qué? Verifica el número de usuarios
Averigüemos cuántos usuarios visitaron realmente nuestro sitio mientras se realizaban las pruebas. A juzgar por los registros, solo el 10% de nuestros grupos de prueba, pero no tomamos esto en cuenta. Si su DAU (la cantidad de usuarios únicos por día) es de 1000 personas, esto no significa que en diez días tendrá 10,000 usuarios en la prueba. Siempre registre aciertos reales en la prueba (aciertos de prueba) y cuente solo ellos.Implementamos lógica simple. Para cada usuario que visita el sitio, enviamos una solicitud al servidor con los nombres del grupo de prueba y control A / B. Gracias a esto, sabremos exactamente cuántos usuarios nos han visitado, y ya no nos equivocaremos.Lanzamos la prueba A / B.Los resultados son excelentes. ¡Ganamos más dinero nuevamente! Activamos nuestra prueba para todos, y algo vuelve a salir mal: después de un par de semanas, las métricas vuelven a ser más bajas de lo previsto. ¿Recuerdas que comenzamos a enviar visitas a todos los usuarios que visitaron el sitio? Nunca hagas eso. Las visitas solo deben enviarse a aquellos usuarios que interactuaron con la parte probada del recurso. Y cuanto más exactamente los defina, mejor. Afortunadamente, esto es fácil de verificar. Para hacer esto, puede realizar una prueba A / A / B. Parece una prueba A / B, pero en este caso tiene dos grupos de control y un grupo de prueba. ¿Por qué se necesita esto? Si el momento para enviar un hit se eligió incorrectamente, los usuarios que no interactuaron con la parte probada del sitio caerán en la prueba. En este caso, habrá grandes diferencias en las métricas en los grupos A y A, y puede comprender de inmediato que algo está mal. Lanzamos la prueba A / A / B. En el grupo B, deje el 50% de los usuarios y divida el 50% restante por igual entre los grupos A y A (los llamamos control y control_check). Sí, los resultados tendrán que esperar más, pero si los resultados de los grupos A y A convergen, comprenderá si el hit se envía correctamente.
Los resultados son modestos (crecimiento de solo el 20%), pero realistas. Hagamos el cambio en absoluto. ¡Todo funciona a la perfección! Pero después de un mes, las métricas cayeron nuevamente.Probar lo que podemos controlar
Resulta que nuestra facturación de terceros también realizó su prueba A / B, que afectó directamente nuestros resultados. Por lo tanto, siempre siga los resultados en la producción e intente probar lo que controla por completo.Total
Las pruebas A / B pueden ayudar al crecimiento del producto. Pero para confiar en las pruebas, es importante realizarlas correctamente y verificar siempre los resultados. Este enfoque le permitirá probar cualitativamente su producto y probar hipótesis antes de que eliminen todas las métricas.- Siempre verifique el grupo objetivo.
- Enviar visitas.
- Envía los golpes correctos.
- Prueba lo que controlas por completo.
- /-!