Características de las pruebas de hipótesis para aplicaciones móviles.

¿Cuánto tiempo lleva una prueba de hipótesis para una aplicación móvil? Vamos a contar

1. Desarrollo de una aplicación que funciona en diferentes modos para diferentes grupos de usuarios.
2. Probar el resultado.
3. Poner la aplicación en las tiendas de aplicaciones y esperar su aprobación.
4. Esperando a que los usuarios actualicen la aplicación. En 2019, la mayoría tiene la actualización automática activada, pero no todos la tienen.
5. Recopilación y análisis de estadísticas.
6. Llevando la aplicación al estado de la hipótesis ganadora, en paralelo con el desarrollo de lo siguiente ...

Si sus desarrolladores trabajan en Scrum con iteraciones de dos semanas, esto generalmente significa que probar una hipótesis lleva un mes completo. Con otras metodologías, este período puede acortarse, pero no significativamente.

Este estado de cosas hace que sea imposible alcanzar el ritmo de "5 hipótesis por semana", que muchos equipos de productos se esfuerzan por alcanzar.

A continuación, le diré cómo puede acelerar y mejorar este proceso e indicarle una serie de soluciones preparadas que puede usar.

Vamos

Encender y apagar

Antes de sumergirse en los detalles, debe ingresar un término adicional: el patrón de indicador de función (alternar función) .

Para los lectores sin antecedentes técnicos, puede ser necesaria una aclaración:

Al desarrollar alguna función nueva, el programador introduce un "interruptor" en el código de la aplicación que activa esta función. Por lo general, esta solución se usa para mantener las características inacabadas en el código general del programa, pero, por supuesto, también se puede usar para probar hipótesis.

Para usar el patrón de indicador de Característica al probar el experimento, necesitará:

1. Funcionalidad completamente desarrollada para experimentar.
2. El interruptor está en el estado predeterminado de "Apagado".
3. Control remoto del interruptor desde el servidor.

La pregunta es, ¿cuál es el tiempo ahorrado si aún es necesario desarrollar la funcionalidad antes de realizar pruebas A / B? Intentemos analizar las etapas del experimento:

¿Qué vemos aquí?

En primer lugar, utilizando el indicador de función, podemos cargar la aplicación en las tiendas de aplicaciones antes de probar completamente los errores. Solo debemos asegurarnos de que cuando la nueva funcionalidad esté desactivada, la aplicación se comporte como antes, y esto se puede hacer con pruebas automáticas escritas previamente. El resto se puede probar mientras la aplicación se distribuye entre los usuarios.

En segundo lugar, una vez completado el experimento, puede usar el indicador de función para habilitar / deshabilitar la funcionalidad para todos los usuarios hasta que la próxima versión esté lista, donde el indicador ya no se utilizará.

Es por este principio que el servicio Apptimize funciona , proporcionando un sistema listo para pruebas A / B.

Analizar

Para realizar un experimento, debe hacer varias cosas:

1. Seleccione un segmento de usuario si el experimento no es para todos.
2. Elige el tamaño de la audiencia.
3. Recopile datos, y no solo aquellos que se verifican por experimento. El resto de las métricas comerciales serán necesarias para garantizar que el experimento no rompa nada en otras métricas.
4. Recoge y analiza el resultado.

Si no utiliza la solución preparada de Apptimize, el enfoque más simple es una combinación de Google Analytics para Firebase para análisis y Firebase Remote Config para establecer configuraciones individuales (segmentos y pruebas). Estas herramientas están diseñadas para trabajar juntas.

En consecuencia, necesitas:

1. Use Google Analytics para Firebase para rastrear las métricas comerciales.
2. Usa Firebase Remote Config para administrar las banderas de funciones.
3. Usa Firebase Remote Config para especificar segmentos y parámetros de experimento.
4. Analice los datos de Google Analytics usando las claves de Firebase Remote Config en el análisis. Esta característica es proporcionada por estas herramientas "fuera de la caja".

Vamos a optimizar aún más

Analizamos cómo acortar el ciclo de prueba de hipótesis para aplicaciones móviles, reduciendo el tiempo de prueba y diseminando los resultados del experimento. Pero este enfoque no permite deshacerse del tiempo para la aprobación y distribución de la aplicación. El objetivo de "5 hipótesis por semana" con este enfoque todavía no es muy realista.

Para acelerar los experimentos, debe poder desarrollar y enviar nuevas funcionalidades sin tener que actualizar la aplicación. Esto se puede lograr, debe usar una interfaz de usuario dinámica. Sin embargo, este enfoque tiene problemas:

Por un lado, existen limitaciones técnicas en la construcción de la interfaz de acuerdo con la configuración recibida desde el exterior. La mayoría de los marcos de desarrollo móvil utilizan un enfoque declarativo donde es imposible o muy difícil.

Por otro lado, la política de la tienda de aplicaciones prohíbe la descarga y ejecución de código arbitrario, ya que puede usarse para funciones que violan las reglas de las tiendas de aplicaciones.

Otra limitación es la cantidad de datos transferidos desde Firebase Remote Config. No se puede usar para transferir toda la interfaz. Es óptimo almacenar solo la "clave" de una versión específica de la interfaz y, al cambiar este código, cargar la interfaz desde un servicio de terceros. Por sí solo, no limita la elección del marco de desarrollo móvil, pero requiere esfuerzos de implementación adicionales.

La solución óptima es un enfoque en el que solo la interfaz de usuario se construye dinámicamente y la lógica empresarial permanece fija. Dado que la gran mayoría de los experimentos de productos se relacionan específicamente con la interfaz, puede mantener un alto ritmo de trabajo. Al mismo tiempo, los experimentos que requieren un refinamiento de la lógica de negocios se pueden realizar en paralelo, de acuerdo con el proceso descrito anteriormente con banderas.

Técnicamente, este enfoque se implementa más fácilmente en un marco que tiene las siguientes características:

1. Una interfaz de usuario reactiva y de alto rendimiento que no utiliza un enfoque declarativo de forma predeterminada.
2. Soporte para Google Analytics para Firebase y Firebase Remote Config.
3. Una solución multiplataforma es deseable para acelerar el desarrollo en general.

Óptimamente, el marco Flutter cumple con estos criterios. Como prueba de concepto de este enfoque, para él hay una biblioteca que le permite crear una interfaz dinámica .

Usando la interfaz dinámica creada en Flutter, Google Analytics para Firebase y Firebase Remote Config, puede desarrollar aplicaciones que se pueden comparar con sitios web con facilidad de prueba de hipótesis.