La idea detrás de las pruebas A/B es comparar y contrastar variantes similares de usuarios, pero proporcionando diferentes optimizaciones en cada variante para determinar qué cambios hacer en el futuro. Idealmente, las pruebas A/B se utilizan para comparar dos o más versiones de un experimento para ver cuál funciona mejor.

Cuando se comparan las dos variantes, suelen denominarse variante A y variante B. Los usuarios son asignados aleatoriamente a cada variante para evitar cualquier tipo de sesgo que pudiera sesgar los datos.

Esto puede incluir sesgos previos a la prueba basados en variables que pueden afectar a los resultados de la prueba, como una campaña en las redes sociales que premie a los usuarios con dinero para probar el juego justo antes de empezar el experimento. Esta cohorte de usuarios puede afectar a su prueba y proporcionar resultados sesgados.

Las pruebas A/B permiten tomar decisiones basadas en datos y no en corazonadas. Poder aportar pruebas con datos es esencial para realizar con confianza los cambios necesarios para optimizar mejor tu aplicación.

Dependiendo del tamaño de su prueba, podrá probar más de una variante A y B. Las pruebas pueden ajustarse para incluir más variantes. Sin embargo, dividir el público en más variantes obliga a ampliar la duración de la prueba para alcanzar la significación estadística o, de lo contrario, se corre el riesgo de que los datos se diluyan por falta de muestras.

Las causas más comunes para utilizar las pruebas A/B son:

• Maximizar el comportamiento específico de los jugadores (hábitos de gasto, hábitos de juego, retención, etc.)
• Probar funciones nuevas y existentes para optimizar el rendimiento y las tasas de adopción por parte de los usuarios.
• Mejora de flujos de usuario específicos (FTUE, flujo de usuario de la tienda, progresión de niveles, ritmo de recompensas, etc.)

Definir los objetivos de cada prueba A/B es importante para utilizar los datos y el tiempo correctamente. Asegúrese de que el objetivo empresarial de cada experimento está claro para poder medir los KPI que proporcionan datos valiosos para impulsar iniciativas que optimicen su aplicación.

Un ejemplo de prueba A/B en una aplicación sería comprobar el saldo inicial de divisas de un nuevo jugador. Tu experimento podría ser algo parecido a:

Audiencia: Nuevos usuarios Variante A (activada): 100 oro Variante B (control): 0 oro KPIs a medir: Tasa de retención (D1, D3, D7, D30), ARPDAU y tasa de conversión

Una variante de control es un subconjunto de usuarios que coinciden con los criterios de audiencia de la prueba, pero que no se ven afectados por el tratamiento. La importancia de este grupo es garantizar que su equipo pueda ver claramente cualquier subida o bajada medida utilizando las variantes A y B. Los KPI fijados antes de la prueba ayudarán a determinar estos cambios.

Es importante tener en cuenta que, al comparar el cambio de un grupo de prueba en el tiempo con la métrica de la variante de control, podemos aislar los impactos en los KPI causados por factores externos que pueden afectar a sus resultados.

Unity Gaming Services tiene la capacidad de crear campañas de pruebas A/B utilizando nuestro sistema Game Overrides. Puede consultar nuestra guía paso a paso aquí. No deje de consultar esta página, ya que iremos añadiendo más consejos en los próximos meses.

Después de ejecutar esta prueba podemos analizar los datos para ver cómo cada uno de los comportamientos de estas variantes se ven afectados por el equilibrio inicial variable y su impacto en los KPI que deseamos medir.

Basándonos en nuestro ejemplo anterior, queremos ver si la variante A tuvo un impacto positivo (o negativo) en nuestros KPI. Algunas preguntas que puede hacerse al revisar los resultados son:

• ¿Proporciona la variante A una mayor tasa de retención frente a la de control debido a que los usuarios disponen de más moneda para gastar y progresar en el juego?
• ¿Proporcionar a los usuarios un saldo inicial más alto incentiva a gastar más dinero?
• ¿Los usuarios se convierten en gastadores en mayor medida cuando tienen un saldo inicial más alto?

Hacerse estas preguntas y comprender el impacto que el tratamiento tiene en los usuarios es esencial para entender el comportamiento de estos jugadores y cómo se puede optimizar la experiencia de estos usuarios.

La significación estadística es el nivel de confianza en que una prueba A/B proporciona datos precisos y no está influida por factores externos. El primer paso para calcular la significación estadística es formular las hipótesis nula y alternativa.

• Hipótesis nula (H0): Afirmación de que el cambio no ha tenido ningún efecto en el grupo de muestra y se asume como cierto.
• Hipótesis alternativa (Ha): Predicción que su tratamiento tendrá sobre la muestra dada.

Una vez elegidas las hipótesis, puede elegir el nivel de significación (α ), que es la probabilidad de rechazar la hipótesis nula. El nivel de significación estándar al que debe aspirarse es 0,05, lo que significa que los resultados tienen una probabilidad inferior al 5% de que la hipótesis nula sea cierta.

El siguiente paso sería hallar su valor de probabilidad (valor p), que determina la probabilidad de que sus datos se encuentren dentro de la hipótesis nula. Cuanto menor sea el valor p, más estadísticamente significativos serán sus resultados.

Si el valor p es superior al nivel de significación, la probabilidad es demasiado alta para rechazar la hipótesis nula y, por tanto, los resultados no son estadísticamente significativos.

Si el nivel p es inferior al nivel de significación, hay pruebas suficientes para rechazar la hipótesis nula y aceptar la hipótesis alternativa, lo que significa que los resultados son estadísticamente significativos.

Una prueba A/B con significación estadística indica que nuestro experimento ha tenido éxito y que podemos hacer cambios con confianza basándonos en nuestra prueba para optimizar nuestra aplicación.

Un experimento de pruebas A/B muy común en las primeras fases de los juegos es probar diferentes experiencias de usuario por primera vez (FTUE) con el fin de aumentar la retención temprana entre los jugadores (D1, D3, D7). La FTUE de un juego es importante para atraer a los usuarios y hacer que se interesen por tu aplicación.

Audiencia: Nuevos usuarios Variante A (variante): FTUE normal (10 pasos) Variante B (control): FTUE corto (5 pasos) KPIs a medir: Tasa de retención (D1, D3, D7)

Muchos juegos y aplicaciones de servicios en directo tienen compras dentro de la aplicación (IAP) a disposición de los usuarios para ayudar a distribuir contenidos e ingresos para el desarrollador. Un ejemplo común es probar diferentes precios para un paquete IAP, como un paquete de artículos (paquete de 5 $ frente a paquete de 20 $). También puede tener el mismo precio pero diferentes contenidos dentro del paquete.

Audiencia: Variante A (activada): Paquete de 5 $ Variante B (control): Paquete de 20 $ KPIs a medir: ARPDAU (ingresos medios por usuario medio diario), LTV (valor a largo plazo)

DO:

Realice siempre una prueba A/B. Siempre debes tener al menos una prueba A/B en ejecución para no perder tiempo y encontrar nuevas formas de optimizar tu aplicación.

Realización de pruebas sobre diversas métricas. Cuando experimente, asegúrese siempre de probar diferentes variables que pueda optimizar utilizando pruebas A/B independientes para cada una de ellas. Esto puede variar desde la dificultad, las recompensas de los anuncios, la sincronización de las notificaciones push y otros.

Asegúrese de que los grupos de variables tienen tamaños de muestra similares. Si el tamaño de las muestras difiere demasiado de un grupo a otro, los resultados serán imprecisos. Los tratamientos que se apliquen a esas muestras pueden no ser adecuados.

NO LO HAGAS:

Probar demasiadas variables al mismo tiempo. Realizar demasiadas pruebas A/B al mismo tiempo enturbiará los resultados, ya que las distintas pruebas pueden influirse directamente entre sí.

Realice las pruebas demasiado cortas. Un error común es detener una prueba demasiado pronto cuando los datos no son suficientes y pueden verse afectados por una gran variedad de factores. Un evento del juego que se produzca en mitad de tu experimento puede influir enormemente en tus resultados, provocando una baja significación estadística y teniendo datos menos fiables.

No tema profundizar en sus experimentos. Reducir el público objetivo a un nivel más refinado puede ser muy eficaz siempre que se tenga una hipótesis bien planteada y se disponga de una muestra lo suficientemente grande como para proporcionar resultados precisos.