Usabilidad de pruebas A / B con recuento de usuarios estático
Soy nuevo en las pruebas A / B y tengo algunas preguntas.
La situación
sería probar un sistema de información sin nuevos usuarios, por lo que el recuento de usuarios es más o menos constante. En el sistema hay un gran formulario que los usuarios están llenando. No mediré las tasas de conversión ni nada por el estilo. El objetivo es medir los tiempos de finalización de este formulario y el objetivo es mejorar el formulario, por lo que a los usuarios les lleva menos tiempo completarlo.
Algunos usuarios pueden completar este formulario una vez al mes, mientras que otros pueden llenarlo varias veces al día.
Las preguntas
- ¿Divido a los usuarios por la mitad según el recuento de formularios (por lo que hay aproximadamente el mismo recuento de formularios rellenados) o según el recuento de usuarios (por lo que hay aproximadamente el mismo recuento de usuarios en cada grupo)?
- ¿Puedo considerar la finalización de cada formulario como una "instancia" (en lugar de usuarios) a pesar de que un usuario puede completar varios formularios?
- ¿Cómo calculo cuánto tiempo debo ejecutar la prueba para obtener resultados estadísticamente significativos?
Por ejemplo, encontré la calculadora de tamaño de muestra (https://www.surveysystem.com/sscalc.htm), e ingreso dichos datos:
-Nivel de confianza: 95%
-Intervalo de confianza: 5
y como resultado obtengo 384. ¿Es 384 el recuento de formularios completados para cada variante?
Digamos que, en promedio, se completan 70 formularios al día. ¿Eso significa que tengo que realizar la prueba durante 11 días? (El cálculo es:384/70 * 2(multiplicado por 2 ya que hay variantes A y B)) ¿O debería redondearlo a semanas completas (es decir, 14 días en este caso)?
Pido disculpas si mis preguntas son muy simples. He estado leyendo bastante sobre las pruebas A / B, pero generalmente hay tasas de conversión y parece que no puedo aplicarlas a mi situación.
Respuestas
Está en el camino correcto, pero hay algunas cosas que planificar.
Intente tomar medidas de control antes de comenzar. Estos serán invaluables para segmentar a sus usuarios, clasificar sus tiempos de finalización y son una buena copia de seguridad si las pruebas A / B no son posibles o tienen un impacto negativo. Esto le permitirá saber cuánta variación en el tiempo de finalización ya tiene y puede indicar tendencias o correlaciones que necesita conocer. (La regla 80/20 dice que el 80% de sus finalizaciones probablemente provienen del 20% de sus usuarios. ¿Son los tiempos más rápidos o los más lentos? ¿Ocurren todos en un solo día de la semana? ¿Son los horarios de los lunes diferentes a los del viernes? Etc.)
Pensar en completar el formulario como las unidades que está midiendo, en lugar de los usuarios, es una buena idea, pero querrá asegurarse de que cada usuario solo obtenga una versión del formulario, ya que cambiar varias veces introducirá más sesgo. Si le preocupa impactar a demasiados usuarios, las dos audiencias no tienen por qué ser iguales. Una muestra del 10% de sus usuarios (con suerte, haciendo el 10% de sus finalizaciones) puede darle resultados. Tardará más, pero afectará a menos usuarios.
Los cálculos del tamaño de la muestra son para juzgar qué tan cerca una muestra aleatoria coincidirá con la población completa. Si desea seleccionar una muestra aleatoria de sus usuarios para el grupo B, una calculadora de tamaño de muestra le dirá cuántos necesita para estar seguro de que representan el todo. (Si tiene 1000 usuarios, solo necesita 278 para estar en el grupo B para estar 95% seguro de que sus datos estarán dentro del 5% de todo el grupo. Solo necesita 88 si pueden estar dentro del 10%. Eso podría estar bien para tiempos de finalización.)
Para medir el éxito de la prueba en sí, necesita una calculadora de significación estadística como esta: https://www.surveymonkey.com/mp/ab-testing-significance-calculator/
Sin embargo, la significación estadística solo mide eventos discretos (es decir, conversiones), no tiempos. Ahí es donde entran los datos de control. Si la mediana anterior (o el promedio si los datos están sesgados) fue de 60 segundos, puede definir una conversión exitosa como 59 segundos o menos. Luego, puede poner esos números en el cálculo y ver si necesita más pruebas. Las tasas de conversión muy diferentes entre sí podrán alcanzar una importancia significativa rápidamente, pero cuanto más cerca estén, más tiempo tendrá que dejarlas correr antes de declarar un ganador. Si su cambio hace que un formulario sea dos veces más rápido, lo verá rápidamente, pero tendrá que medir durante mucho tiempo para detectar una disminución del 5%.
Tenga en cuenta que las pruebas A / B solo le dirán qué versión es más rápida, no cuál les gusta más a los usuarios o su tasa de error u otras cosas. Puede optimizarse en un formulario que sea mucho más rápido pero que resulte en la recopilación de muchos más datos incorrectos debido a errores tipográficos u otros errores.
Seré sincero: nunca he realizado una prueba A / B, por lo que agregaré mis sugerencias aquí para que se voten a favor o en contra según la comunidad lo considere apropiado, sin embargo, creo que entiendo conceptualmente cómo se usa.
Creo que estás en el camino correcto sobre cómo aplicar esto . Lo ideal sería dividir su base de usuarios para que algunos usuarios vean constantemente la versión A y algunos vean constantemente la versión B. No querría que un usuario determinado a veces vea una versión durante una instancia, luego una versión diferente para la siguiente instancia .
Como mencionaste, tu objetivo, en este caso, no es medir las tasas de conversión (es decir, cuántos usuarios eligen realizar una determinada acción), sino la eficiencia con la que realizan la acción. Entonces, en su caso, tiene razón en que medir el tiempo de finalización del formulario es probablemente uno de los mejores indicadores de esto. Si de alguna manera puede verificar que los formularios se estén completando correctamente (por ejemplo, los usuarios no regresan para corregir o enmendar sus envíos, o hacer un seguimiento de las solicitudes de soporte), entonces ese podría ser otro punto de datos significativo para intentar recopilar.
Ha identificado diferencias significativas en la forma en que sus usuarios interactúan con el formulario: algunos lo usan varias veces al día (llamémoslos "usuarios frecuentes"), mientras que otros lo usan mucho menos ("usuarios ocasionales").
Como ya ha insinuado, creo que es aconsejable que divida a sus usuarios de manera que tenga una combinación de usuarios frecuentes y usuarios ocasionales que vean cada versión del formulario, de modo que pueda notar diferencias en cómo una versión afecta a cada tipo de usuario.
Sus cálculos estadísticos también suenan razonables: dos semanas parece una cantidad de tiempo suficiente para comenzar a basarse en sus hallazgos. Esto también permite que los usuarios que ven cada versión se familiaricen con sus versiones y se "acomoden" al tiempo que tardan ahora en completar su versión del formulario.
Al final de las dos semanas, puede ejecutar sus análisis para intentar encontrar si uno tuvo un tiempo promedio de finalización más bajo que el otro, y desglosar esos resultados por diferentes dimensiones: tipo de usuario (para ver si el formulario funciona mejor para usuarios que son mucho más competentes, o quizás más simples para los usuarios que solo lo usan ocasionalmente), tiempo desde que se les presentó el formulario (para ver si las personas mejoraron después de acostumbrarse a las nuevas versiones), o tasa de error de finalización (si corresponde, para vea si una versión previno errores mejor que la otra).