Cómo se implementa la retención en App in the Air

Cómo se implementa la retención en App in the Air

Mantener a un usuario en una aplicación móvil es toda una ciencia. El autor del curso describió sus conceptos básicos en nuestro artículo en VC.ru. Growth Hacking: análisis de aplicaciones móviles Maxim Godzi, director de aprendizaje automático de App in the Air. Maxim habla de las herramientas desarrolladas en la empresa utilizando el ejemplo del trabajo de análisis y optimización de una aplicación móvil. Este enfoque sistemático para la mejora de productos, desarrollado en App in the Air, se llama Retentioneering. Puede utilizar estas herramientas en su producto: algunas de ellas están en acceso libre en GitHub.

App in the Air es una aplicación con más de 3 millones de usuarios activos en todo el mundo, con la que puedes rastrear vuelos, obtener información sobre cambios en horarios de salida/aterrizaje, check-in y características del aeropuerto.

Del embudo a la trayectoria

Todos los equipos de desarrollo crean un embudo de incorporación (un proceso destinado a la aceptación del producto por parte del usuario). Este es el primer paso que le ayuda a observar todo el sistema desde arriba y encontrar problemas con las aplicaciones. Pero a medida que el producto se desarrolle, sentirá las limitaciones de este enfoque. Al utilizar un embudo simple, no se pueden ver puntos de crecimiento no obvios para un producto. El propósito del embudo es brindar una visión general de las etapas de los usuarios en la aplicación, para mostrarle las métricas de la norma. Pero el embudo ocultará prudentemente las desviaciones de la norma hacia problemas obvios o, por el contrario, actividades especiales del usuario.

Cómo se implementa la retención en App in the Air

En App in the Air, construimos nuestro propio embudo, pero debido a las características específicas del producto, terminamos con un reloj de arena. Luego decidimos ampliar el enfoque y utilizar la rica información que nos brinda la propia aplicación.

Cuando construyes un embudo, pierdes las trayectorias de incorporación del usuario. Las trayectorias consisten en una secuencia de acciones del usuario y de la propia aplicación (por ejemplo, enviar una notificación push).

Cómo se implementa la retención en App in the Air

Usando marcas de tiempo, puedes reconstruir muy fácilmente la trayectoria del usuario y hacer un gráfico para cada uno de ellos. Por supuesto, hay muchos gráficos. Por lo tanto, es necesario agrupar usuarios similares. Por ejemplo, puede organizar a todos los usuarios por filas de la tabla y enumerar con qué frecuencia utilizan una determinada función.

Cómo se implementa la retención en App in the Air

Basándonos en dicha tabla, creamos una matriz y agrupamos a los usuarios por frecuencia de uso de funciones, es decir, por nodos en el gráfico. Este suele ser el primer paso hacia la información: por ejemplo, ya en esta etapa verás que algunos usuarios no utilizan algunas de las funciones en absoluto. Cuando hicimos el análisis de frecuencia, comenzamos a estudiar qué nodos del gráfico son los “más grandes”, es decir, qué páginas visitan los usuarios con más frecuencia. Las categorías que son fundamentalmente diferentes según algún criterio que sea importante para usted se resaltan inmediatamente. Aquí, por ejemplo, hay dos grupos de usuarios que dividimos según la decisión de suscripción (había 16 grupos en total).

Cómo se implementa la retención en App in the Air

Cómo usarlo

Al observar a sus usuarios de esta manera, puede ver qué funciones utiliza para retenerlos o, por ejemplo, lograr que se registren. Naturalmente, la matriz también mostrará cosas obvias. Por ejemplo, que quienes compraron una suscripción visitaran la pantalla de suscripción. Pero además de esto, también puedes encontrar patrones que de otro modo nunca habrías conocido.

Entonces, por casualidad encontramos un grupo de usuarios que agregan un vuelo, lo rastrean activamente durante el día y luego desaparecen durante mucho tiempo hasta que vuelven a volar a algún lugar. Si analizáramos su comportamiento utilizando herramientas convencionales, pensaríamos que simplemente no estaban satisfechos con la funcionalidad de la aplicación: ¿de qué otra manera podemos explicar que la usaron por un día y nunca regresaron? Pero con la ayuda de gráficos vimos que son muy activos, solo que toda su actividad cabe en un día.

Ahora nuestra tarea principal es animar a dicho usuario a conectarse al programa de fidelización de su aerolínea mientras utiliza nuestras estadísticas. En este caso, importaremos todos los vuelos que compre e intentaremos presionarlo para que se registre tan pronto como compre un boleto nuevo. Para solucionar este problema, también comenzamos a cooperar con Aviasales, Svyaznoy.Travel y otras aplicaciones. Cuando su usuario compra un boleto, la aplicación le solicita que agregue el vuelo a App in the Air y lo vemos de inmediato.

Gracias al gráfico vimos que el 5% de las personas que acceden a la pantalla de suscripción la cancelan. Comenzamos a analizar estos casos y vimos que hay un usuario que va a la primera página, inicia la conexión de su cuenta de Google, e inmediatamente la cancela, vuelve a la primera página y así cuatro veces. Al principio pensamos: "Evidentemente, algo anda mal con este usuario". Y luego nos dimos cuenta de que lo más probable era que hubiera un error en la aplicación. En el funnel esto se interpretaría de la siguiente manera: al usuario no le gustó el conjunto de permisos que solicita la aplicación y se fue.

En otro grupo, el 5% de los usuarios se perdió en la pantalla donde la aplicación les pide que seleccionen una de todas las aplicaciones de calendario en su teléfono inteligente. Los usuarios seleccionarían diferentes calendarios una y otra vez y luego simplemente saldrían de la aplicación. Resulta que había un problema de UX: después de que una persona seleccionara un calendario, tenía que hacer clic en Listo en la esquina superior derecha. Es solo que no todos los usuarios lo vieron.

Cómo se implementa la retención en App in the Air
Primera pantalla de App in the Air

En nuestro gráfico, vimos que alrededor del 30% de los usuarios no pasan de la primera pantalla: esto se debe al hecho de que somos bastante agresivos al presionar al usuario para que se suscriba. En la primera pantalla, la aplicación le solicita que se registre usando Google o Triplt y no hay información sobre cómo omitir el registro. De los que abandonan la primera pantalla, el 16% de los usuarios hacen clic en “Más” y regresan nuevamente. Hemos descubierto que están buscando una manera de registrarse internamente en la aplicación y la lanzaremos en la próxima actualización. Además, 2/3 de los que se van inmediatamente no hacen clic en nada. Para saber qué les está sucediendo, creamos un mapa de calor. Resulta que los clientes están haciendo clic en una lista de funciones de la aplicación que no son enlaces en los que se puede hacer clic.

Captura un micromomento

A menudo se puede ver gente pisoteando los caminos junto a la carretera asfaltada. La retención es un intento de encontrar estos caminos y, si es posible, cambiar los caminos.

Por supuesto, es malo que aprendamos de usuarios reales, pero al menos comenzamos a rastrear automáticamente patrones que indican un problema del usuario en la aplicación. Ahora el gerente de producto recibe notificaciones por correo electrónico si se produce una gran cantidad de "bucles", cuando el usuario regresa a la misma pantalla una y otra vez.

Veamos qué patrones en las trayectorias de los usuarios son generalmente interesantes de buscar para analizar los problemas y las áreas de crecimiento de una aplicación:

  • Bucles y ciclos. Los bucles mencionados anteriormente ocurren cuando un evento se repite en la trayectoria del usuario, por ejemplo, calendario-calendario-calendario-calendario. Un bucle con mucha repetición es un indicador claro de un problema de interfaz o de un marcado de eventos insuficiente. Un ciclo también es una trayectoria cerrada, pero a diferencia de un bucle, incluye más de un evento, por ejemplo: ver el historial de vuelos, agregar un vuelo, ver el historial de vuelos.
  • Flowstoppers: cuando el usuario, debido a algún obstáculo, no puede continuar el movimiento deseado a través de la aplicación, por ejemplo, una pantalla con una interfaz que no es obvia para el cliente. Estos eventos ralentizan y cambian la trayectoria de los usuarios.
  • Los puntos de bifurcación son eventos significativos tras los cuales se separan las trayectorias de clientes de diferentes tipos. En particular, se trata de pantallas que no contienen una transición directa o un llamado a la acción hacia la acción objetivo, lo que empuja efectivamente a algunos usuarios hacia ella. Por ejemplo, algunas pantallas que no están directamente relacionadas con la compra de contenido en una aplicación, pero en las que los clientes se inclinan a comprar o no contenido, se comportarán de manera diferente. Los puntos de bifurcación pueden ser puntos de influencia en las acciones de sus usuarios con un signo más (pueden influir en la decisión de realizar una compra o hacer clic, o un signo menos) pueden determinar que después de unos pocos pasos el usuario abandonará la aplicación.
  • Los puntos de conversión abortados son posibles puntos de bifurcación. Puedes pensar en ellas como pantallas que podrían provocar una acción objetivo, pero no lo hagas. Este también podría ser un momento en el que el usuario tiene una necesidad, pero no la satisfacemos porque simplemente no la conocemos. El análisis de la trayectoria debería permitir identificar esta necesidad.
  • Punto de distracción: pantallas/ventanas emergentes que no aportan valor al usuario, no afectan la conversión y pueden "difuminar" las trayectorias, distrayendo al usuario de las acciones objetivo.
  • Los puntos ciegos son puntos ocultos de la aplicación, pantallas y funciones que son muy difíciles de alcanzar para el usuario.
  • Drenajes: puntos por donde se escapa el tráfico

En general, el enfoque matemático nos permitió entender que el cliente usa la aplicación de una manera completamente diferente a lo que los gerentes de producto suelen pensar cuando intentan planificar algún escenario de uso estándar para el usuario. Sentado en la oficina y asistiendo a las mejores conferencias de productos, todavía es muy difícil imaginar toda la variedad de condiciones reales de campo en las que el usuario resolverá sus problemas utilizando la aplicación.

Esto me recuerda un gran chiste. Un evaluador entra a un bar y pide: un vaso de cerveza, 2 vasos de cerveza, 0 vasos de cerveza, 999999999 vasos de cerveza, un lagarto en un vaso, -1 vaso de cerveza, qwertyuip vasos de cerveza. El primer cliente real entra al bar y pregunta dónde está el baño. El bar estalla en llamas y todos mueren.

Los analistas de producto, profundamente inmersos en este problema, comenzaron a introducir el concepto de micromomento. El usuario moderno necesita una solución instantánea a su problema. Google empezó a hablar de esto hace unos años: la empresa llamó micromomentos a estas acciones de los usuarios. El usuario se distrae, cierra accidentalmente la aplicación, no comprende lo que se le pide, vuelve a iniciar sesión un día después, se olvida nuevamente y luego sigue el enlace que un amigo le envió en el messenger. Y todas estas sesiones no pueden durar más de 20 segundos.

Entonces comenzamos a intentar configurar el trabajo del servicio de soporte para que los empleados pudieran entender cuál era el problema casi en tiempo real. Cuando una persona llega a la página de soporte y comienza a escribir su pregunta, podemos determinar la esencia del problema, conociendo su trayectoria: los últimos 100 eventos. Anteriormente, automatizamos la distribución de todas las solicitudes de soporte en categorías utilizando el análisis ML de los textos de las solicitudes de soporte. A pesar del éxito de la categorización, cuando el 87% de todas las solicitudes se distribuyen correctamente en una de las 13 categorías, es el trabajo con trayectorias el que puede encontrar automáticamente la solución más adecuada a la situación del usuario.

No podemos publicar actualizaciones rápidamente, pero podemos detectar el problema y, si el usuario sigue el escenario que ya hemos visto, enviarle una notificación automática.

Vemos que la tarea de optimizar una aplicación requiere herramientas ricas para estudiar las trayectorias de los usuarios. Además, al conocer todos los caminos que toman los usuarios, puede allanar los caminos necesarios y, con la ayuda de contenido personalizado, notificaciones automáticas y elementos de interfaz de usuario adaptables, "de la mano" llevan al usuario a acciones específicas que mejor se adapten a sus necesidades y le generen dinero. , datos y otros valores para su negocio.

Que tomar nota

  • Estudiar la conversión de usuarios únicamente tomando como ejemplo los funnels supone perder la rica información que nos aporta la propia aplicación.

  • El análisis de retención de las trayectorias de los usuarios en gráficos le ayuda a ver qué funciones utiliza para retener a los usuarios o, por ejemplo, animarlos a suscribirse.
  • Las herramientas de retención ayudan automáticamente, en tiempo real, a rastrear patrones que indican problemas del usuario en la aplicación, a encontrar y cerrar errores donde eran difíciles de notar.

  • Ayudan a encontrar patrones de comportamiento de usuario no obvios.

  • Las herramientas de retención permiten crear herramientas de aprendizaje automático automatizadas para predecir métricas y eventos clave de los usuarios: pérdida de usuarios, LTV y muchas otras métricas que se determinan fácilmente en el gráfico.

Estamos construyendo una comunidad en torno a Retentioneering para el libre intercambio de ideas. Puede pensar en las herramientas que estamos desarrollando como un lenguaje en el que analistas y productos de diferentes aplicaciones móviles y web pueden intercambiar conocimientos, mejores técnicas y métodos. Puedes aprender a utilizar estas herramientas en el curso. Growth Hacking: análisis de aplicaciones móviles Distrito binario.

Fuente: habr.com

Añadir un comentario