Seguimos esta serie de métricas con las estadísticas de uso o Usage KPIs. En este post trataremos de descifrar el comportamiento de los usuarios dentro de nuestra aplicación móvil, que sin duda, nos ayudará a tomar decisiones a la hora de mejorar la retención y engagement de nuestra app.
Post previos de esta serie:
Con este post intentaremos conocer desde dónde entra nuestro usuario, saber por qué pantallas navega, en qué botones hace click y, sobre todo, en qué momento decide abandonar nuestra app. Si detectamos que hay una pantalla intermedia, sin mucha importancia, en la que todos los usuarios nos abandonan, debemos reaccionar rápido y entender que tenemos un problema grave en esa pantalla, ya que nos está espantando a los usuarios.
En este post trataremos de identificar las formas de entender el comportamiento del usuario, después, como siempre, el poner la inteligencia para corregir ese comportamiento, ya dependerá de vosotros. E insistimos una vez más, HAY QUE PONERSE EN LA PIEL DEL USUARIO. De nada vale el decir que “está clarísimo que tenían que hacer click ahí” si después revisas las estadísticas de uso y el 80% de tus usuarios no hizo click en ese botón.
Y para demostraros que no es ningún delito el estar equivocado, y que los mejores del mundo en diseño se equivocan “9 de cada 10 veces”, os dejamos esta joya de vídeo de Stuart Frisby, director del departamento de diseño de Booking.com
Una vez que tengamos claro el concepto de que el usuario quiere lo que quiere y no lo que nosotros creemos/queremos (bonito trabalenguas), es cuando debemos comenzar a mirar las estadísticas de uso y sacar nuestras propias conclusiones.
Para conocer en detalle el uso que le dan nuestros usuarios a nuestra app nos valdremos de Google Analytics. Vamos a analizar las principales métricas a tener en cuenta,
Screen Views – Pantallas Vistas:
Es una métrica muy básica pero de la que podemos empezar a extraer conclusiones. es importante saber cuáles son las pantallas más y menos vistas e intentar detectar un patrón de comportamiento de nuestros usuarios.
Esta es una estadística de pantallas vistas muy correcta, en la que podemos apreciar como la “home” es la segunda pantalla más vista, y en primera posición se encuentra la pantalla de detalle de, en este caso, un restaurante. Las siguientes pantallas son las de la pantalla de selección de fecha para la reserva, el detalle de una lista de restaurantes, y algún otro tipo de lista.
Importante sin duda la última columna, que pone “% Exit” y que nos indica qué porcentaje de usuarios abandonaron la app estando en esa pantalla. Obviamente interesa que ese número sea lo más bajo posible y que esté concentrada en donde a nosotros nos interesa, por ejemplo en la pantalla de “su reserva ha sido un éxito” en el caso de esta app de reserva de restaurantes. Los números que podemos apreciar entran dentro de la normalidad más absoluta, pero si vemos que un 30% (o más) de nuestros usuarios se van de la app en una determinada pantalla, deben saltarnos las alarmas y debemos analizar qué está pasando en esa pantalla en concreto que hace que buena parte de nuestros usuarios se marchen al llegar a ese punto. Pero no adelantemos acontecimientos, sigamos con las métricas.
Flujo de navegación
En esta pantalla podremos ver de forma gráfica de qué forma navegan nuestros usuarios dentro de nuestra app. Desde dónde acceden, y a dónde se dirigen después de pasar por una determinada pantalla. Es un esquema que bien merecería ser imprimido y ponerlo de poster en la oficina
Funnel
La mejor forma de analizar gráficamente el flujo de usuarios en nuestra app. En este embudo de conversiones se nos muestra
Eventos
Configurar eventos es una buena forma de proceder si tenemos unas metas muy claras en nuestra app. Los eventos los configuras tú mismo en Google Analytics y los puedes personalizar totalmente. Pueden ser desde un simple registro de un usuario hasta completar una reserva, realizar una compra o compartir contenido en redes sociales.
Aquí podemos ver algunos eventos, en la captura de arriba podemos ver que es del tipo “Event Action” mientras que la segunda es del tipo “Event Label”. Así que podemos tener tipos distintos de eventos y para una misma acción, podemos ver el detalle con cada una de las “labels” asignadas.
Vamos a adentrarnos en el ejemplo: en el buscador de esta app se podía introducir una keyword (Action). En la captura de abajo vemos que los usuarios en ese campo de búsqueda de keywords introducían Barcelona o Madrid como principales keywords. De ahí podemos inferir que el campo ciudad tiene la importancia suficiente como para tratarlo de otra forma. Y aunque la app geolocaliza al usuario, éste sigue buscando localizaciones en el buscador, así que hay que buscar una fórmula para minimizar este problema. Veamos algunas posibles soluciones:
– Destacar en pantalla la localización del usuario: especificarle claramente al usuario en qué lugar se están centrando las búsquedas. Puede ser un campo destacado justo encima del buscador, o en el texto del buscador: “busca en la ciudad X”
– Preguntar antes de cada búsqueda en qué ciudad quiere que se realice esa búsqueda. Obviamente, a nivel de UX, el usuario sólo debería indicar la primera vez dónde quiere hacer esa búsqueda y después se le quedaría marcada por defecto.
– No hacer nada, dejar que los usuarios sigan introduciendo la ciudad en el lugar de las keywords a pesar de que el usuario ya está siendo geolocalizado.
Llegados a este punto, tendríamos 2 opciones: tomar la que creemos que es la mejor solución (mala idea), o, hacer un test A/B con las opciones y ver cuál funciona mejor, si hay alguna que aumente las conversiones, si las sesiones duran más con alguna de las opciones, etc. De este modo, nos estaremos dejando guiar por datos y no por apreciaciones subjetivas nuestras, y como bien nos demuestran desde Booking, si nos fiamos por nuestras propias apreciaciones, estaremos equivocados en 9 de cada 10 ocasiones. Y esos fallos, ¡los podemos evitar!