Pruebas A / B en Android de la A a la Z

La mayoría de los artículos sobre pruebas A / B están dedicados al desarrollo web y, a pesar de la relevancia de esta herramienta para otras plataformas, el desarrollo móvil sigue siendo injusto. Intentaremos eliminar esta injusticia describiendo los pasos principales y revelando las características de la implementación y realización de pruebas A / B en plataformas móviles.

Concepto de prueba A / B

Se necesita una prueba A / B para probar hipótesis destinadas a mejorar las métricas clave de la aplicación. En el caso más simple, los usuarios se dividen en 2 grupos de control (A) y experimental (B). Una característica que implementa la hipótesis se implementa solo para el grupo experimental. Además, con base en un análisis comparativo de indicadores métricos para cada uno de los grupos, se llega a una conclusión sobre la relevancia de la característica.

Implementación

1. Divida a los usuarios en grupos.

Primero, debemos comprender cómo dividiremos a los usuarios en grupos en el porcentaje correcto con la capacidad de cambiarlo dinámicamente. Tal oportunidad será especialmente útil si de repente resulta que una nueva característica aumenta la conversión en un 146%, y se implementa, por ejemplo, ¡solo en un 5% de los usuarios! Seguramente querremos implementarlo para todos los usuarios y en este momento, sin actualizar las aplicaciones en la tienda y los costos de tiempo asociados.

Por supuesto, puede organizar un desglose en el servidor y cada vez que necesite cambiar algo, tire de los desarrolladores de back-end. Pero en la vida real, el respaldo a menudo se desarrolla del lado del cliente o de una tercera empresa, y los desarrolladores de servidores tienen suficientes cosas que hacer, por lo que no siempre es posible ajustar rápidamente el desglose, trabajar con terceros, o más bien, casi nunca, por lo que esta opción no nos conviene. ¡Y luego Firebase Remote Config viene al rescate!

En Firebase Console, en el grupo Grow hay una pestaña Remote Config donde puedes crear tu propia configuración que Firebase entregará a los usuarios de tu aplicación.


La configuración es un mapa <clave de parámetro, valor de parámetro> con la capacidad de asignar un valor de parámetro de acuerdo con la condición. Por ejemplo, para usuarios con una versión específica de la aplicación, el valor es X, para todos los demás: Y. Para obtener más información sobre la configuración, consulte la sección correspondiente de la documentación .



También en el grupo Grow hay una pestaña Prueba A / B. Aquí podemos ejecutar las pruebas con todos los bollos anteriores. Las claves de nuestra configuración remota se utilizan como parámetros. En teoría, puede crear nuevos parámetros directamente en la prueba A / B, pero esto solo agregará confusión innecesaria, por lo que no debe hacer esto, es más fácil agregar el parámetro correspondiente a la configuración. El valor que contiene es tradicionalmente el valor predeterminado y corresponde al grupo de control, y el valor experimental del parámetro, que no sea el predeterminado, es experimental.



Nota El grupo de control generalmente se llama grupo A, el grupo experimental se llama B. Como puede ver en la captura de pantalla, en Firebase el grupo experimental predeterminado se llama "Variante A", lo que introduce cierta confusión. Pero nada impide cambiar su nombre.

Luego, ejecute la prueba A / B, Firebase divide a los usuarios en grupos que corresponden a diferentes valores del parámetro, después de recibir la configuración en el cliente, extraemos el parámetro necesario y aplicamos una nueva función basada en el valor. Tradicionalmente, el parámetro tiene un nombre correspondiente al nombre de la función y 2 valores: Verdadero: la función se aplica, Falso: no se aplica. Lea más sobre la configuración de las pruebas A / B en la sección correspondiente de la documentación .

2. Código

No nos detendremos directamente en la integración con Firebase Remote Config, se describe en detalle aquí .

Veamos cómo organizar el código para las pruebas A / B. Si solo cambiamos el color del botón, entonces hablar de la organización no tiene sentido, porque no hay nada especial que organizar. Consideraremos una variante en la que, dependiendo del parámetro de Remote Config, se muestra la pantalla actual (para el grupo de control) o nueva (para el experimental).

Debe comprender que después de que la prueba A / B expire, una de las opciones de pantalla deberá eliminarse, en este sentido, el código debe organizarse de tal manera que minimice los cambios en la implementación actual. Todos los archivos asociados con la nueva pantalla deben llamarse con el prefijo AB y colocarse en carpetas con el mismo prefijo.

Si hablamos de MVP en la capa Presentación, se verá más o menos así:



La jerarquía de clases más flexible y transparente parece ser:



BaseOrderStatusFragment contendrá toda la funcionalidad de la implementación actual, excepto los métodos que no se pueden colocar en una clase abstracta debido a limitaciones de la arquitectura. Se ubicarán en OrderStatusFragment.

AbOrderStatusFragment anulará los métodos que difieren en la implementación y tienen los necesarios adicionales. Por lo tanto, en la implementación actual, solo el desglose de una clase en dos cambiará y algunos métodos en la clase base quedarán protegidos abiertos en lugar de privados.

Nota: si la arquitectura y el caso específico lo permiten, puede hacerlo sin crear una clase base y heredar directamente AbOrderStatusFragment de OrderStatusFragment.

Dentro del marco de una organización de este tipo, es muy probable que sea necesario desviarse del CodeStyle aceptado, lo cual está permitido en este caso, porque el código correspondiente se eliminará o refactorizará al completar la prueba A / B (pero, por supuesto, en los lugares donde se viola CodeStyle, vale la pena dejar un comentario)

Dicha organización nos permitirá eliminar rápida e indoloramente una nueva característica si resulta ser irrelevante, ya que todos los archivos asociados con ella son fáciles de encontrar por prefijo y su implementación no afecta la funcionalidad actual. Si la función mejoró la métrica clave y se decidió abandonarla, todavía tenemos que trabajar para recortar la funcionalidad actual, lo que afectará el código de la nueva función.

Para obtener la configuración, vale la pena crear un repositorio separado e inyectarlo a nivel de la aplicación para que sea accesible en todas partes, ya que no sabemos qué partes de la aplicación afectarán futuras pruebas A / B. Por las mismas razones, vale la pena solicitarlo lo antes posible, por ejemplo, junto con la información básica necesaria para que la aplicación funcione (por lo general, tales solicitudes se producen durante la presentación, aunque este es un tema holístico, pero es importante que existan en algún lugar).

Bueno, y, por supuesto, es importante no olvidar tirar el valor del parámetro de la configuración a los parámetros del evento de análisis, para que pueda comparar métricas

Análisis de resultados

Hay muchos artículos que detallan cómo analizar los resultados de las pruebas A / B, por ejemplo . Para no repetirnos, simplemente indicamos la esencia. Debe comprender que la diferencia en las métricas en los grupos de control y experimentales es una variable aleatoria, y no podemos concluir que la característica sea relevante solo sobre la base de que la métrica en el grupo experimental es mejor. Es necesario construir un intervalo de confianza (la elección del nivel de confiabilidad debe confiarse a los analistas) para la variable aleatoria descrita anteriormente y realizar el experimento hasta que el intervalo esté completamente en el semiplano positivo o negativo; luego se puede llegar a una conclusión estadísticamente válida.

Trampas

1. Error al obtener la configuración remota

Se realiza un análisis comparativo de los nuevos usuarios, ya que los usuarios con la misma experiencia de usuario y solo aquellos que han visto la única opción de implementación deben participar en los experimentos. Recuerde que recibir la configuración es una solicitud de red y puede fallar, en cuyo caso se aplicará el valor predeterminado, tradicionalmente igual al valor para el grupo de control.

Considere el siguiente caso: tenemos un usuario a quien Firebase asignó al grupo experimental. El usuario inicia la aplicación por primera vez y la solicitud de configuración remota devuelve un error: el usuario ve la pantalla anterior. En el siguiente inicio, la solicitud de configuración remota se procesa correctamente y el usuario ve una nueva pantalla. Es importante comprender que dicho usuario no es relevante para el experimento, por lo que debe descubrir cómo filtrar a dicho usuario en el lado del sistema de análisis o demostrar que el número de usuarios es insignificante.

De hecho, tales errores ocurren con poca frecuencia, y lo más probable es que la última opción le convenga, pero esencialmente hay un problema similar, pero mucho más urgente: el momento de obtener la configuración. Como se mencionó anteriormente, es mejor pegar la solicitud de configuración remota al comienzo de la sesión, pero si la solicitud demora demasiado, el usuario se cansará de esperar y saldrá de la aplicación. Por lo tanto, debe resolver una tarea no trivial: elegir un tiempo de espera mediante el cual se restablezca la solicitud de configuración remota. Si es demasiado pequeño, entonces un gran porcentaje de usuarios puede estar en la lista de irrelevantes para la prueba, si es demasiado grande, corremos el riesgo de enojar a los usuarios. Hemos recopilado estadísticas sobre el momento de recibir la configuración:



Nota Datos de los últimos 30 días. Número total de solicitudes 673 529 . La primera columna, además de las solicitudes de red, contiene la recepción de la configuración de la memoria caché, por lo tanto, se elimina del formulario de distribución general.


2. Configuración remota de actualización de moleteado

Debe comprender que Firebase almacena en caché una solicitud de configuración remota. La duración predeterminada de la memoria caché es de 12 horas. El tiempo se puede ajustar, pero Firebase tiene un límite en la frecuencia de las solicitudes, y si se excede, Firebase nos prohibirá y devolverá un error en la solicitud de configuración (Nota para la prueba, puede establecer la configuración setDeveloperModeEnabled, en cuyo caso el límite no se aplicará, pero hágalo posible para un número limitado de dispositivos).

Por lo tanto, por ejemplo, si queremos completar la prueba A / B y desplegar una nueva función en un 100%, debemos entender que la transición solo tendrá lugar dentro de las 12 horas, pero este no es el problema principal. Considere el siguiente caso: realizamos una prueba A / B, la completamos y preparamos una nueva versión, en la que hay otra prueba A / B con la configuración correspondiente. Hemos lanzado una nueva versión de la aplicación, pero nuestros usuarios ya tienen una configuración almacenada en caché de la prueba A / B anterior, y si el caché aún no ha expirado, la solicitud de configuración no extraerá nuevos parámetros, y nuevamente obtendremos usuarios asignados al grupo experimental, que en la primera solicitud recibirá los valores predeterminados de la configuración y en el futuro estropeará los datos del nuevo experimento.

La solución a este problema es muy simple: debe forzar la solicitud de configuración al actualizar la versión de la aplicación restableciendo la vida útil de la memoria caché:

val cacheExpiration = if (isAppNewVersion) 0L else TWELVE_HOURS_IN_SECONDS FirebaseRemoteConfig.getInstance().fetch(cacheExpiration) 

Como las actualizaciones no se emiten con tanta frecuencia, no superaremos los límites
Lea más sobre estos temas aquí .

Conclusiones

Firebase proporciona una herramienta de prueba A / B muy conveniente y simple que debe usarse, prestando especial atención a los cuellos de botella descritos anteriormente. La organización propuesta del código minimizará la cantidad de errores al realizar cambios asociados con el ciclo de pruebas A / B.

Buena suerte a todos, pruebas A / B exitosas y un aumento del 100.5% en las conversiones.