Como se implementa a retención na aplicación no aire

Como se implementa a retención na aplicación no aire

Manter un usuario nunha aplicación móbil é toda unha ciencia. O autor do curso describiu os seus conceptos básicos no noso artigo sobre VC.ru Growth Hacking: análise de aplicacións móbiles Maxim Godzi, xefe de Machine Learning en App in the Air. Maxim fala das ferramentas desenvolvidas na empresa co exemplo do traballo de análise e optimización dunha aplicación móbil. Este enfoque sistemático para a mellora do produto, desenvolvido en App in the Air, chámase Retentioneering. Podes usar estas ferramentas no teu produto: algunhas delas están en acceso libre en GitHub.

App in the Air é unha aplicación con máis de 3 millóns de usuarios activos en todo o mundo, coa que podes seguir os voos, obter información sobre os cambios nos horarios de saída/aterraxe, facturación e características do aeroporto.

Do funil á traxectoria

Todos os equipos de desenvolvemento constrúen un funil de incorporación (un proceso dirixido á aceptación do produto por parte dos usuarios). Este é o primeiro paso que che axuda a mirar todo o sistema desde arriba e atopar problemas de aplicación. Pero a medida que se desenvolve o produto, sentirás as limitacións deste enfoque. Usando un funil simple, non podes ver puntos de crecemento non obvios dun produto. O propósito do funil é dar unha visión xeral das etapas dos usuarios na aplicación, para mostrarche as métricas da norma. Pero o funil ocultará prudentemente as desviacións da norma cara a problemas obvios ou, pola contra, a actividade especial do usuario.

Como se implementa a retención na aplicación no aire

En App in the Air, construímos o noso propio funil, pero debido ás características específicas do produto, acabamos cun reloxo de area. Entón decidimos ampliar o enfoque e utilizar a rica información que nos proporciona a propia aplicación.

Cando creas un funil, perdes as traxectorias de incorporación do usuario. As traxectorias consisten nunha secuencia de accións do usuario e da propia aplicación (por exemplo, o envío dunha notificación push).

Como se implementa a retención na aplicación no aire

Usando marcas de tempo, podes reconstruír moi facilmente a traxectoria do usuario e facer un gráfico para cada un deles. Por suposto, hai moitos gráficos. Polo tanto, cómpre agrupar usuarios similares. Por exemplo, pode organizar todos os usuarios por filas da táboa e enumerar a frecuencia con que usan unha determinada función.

Como se implementa a retención na aplicación no aire

A partir desta táboa, elaboramos unha matriz e agrupamos os usuarios por frecuencia de uso das funcións, é dicir, por nodos do gráfico. Este adoita ser o primeiro paso cara a insights: por exemplo, xa nesta fase verás que algúns usuarios non usan ningunha das funcións. Cando fixemos a análise de frecuencia, comezamos a estudar que nodos do gráfico son os "máis grandes", é dicir, que páxinas visitan máis a miúdo os usuarios. As categorías que son fundamentalmente diferentes segundo algún criterio que sexa importante para vostede son inmediatamente destacadas. Aquí, por exemplo, tes dous grupos de usuarios que dividimos en función da decisión de subscrición (había 16 grupos en total).

Como se implementa a retención na aplicación no aire

Como usalo

Ao mirar aos teus usuarios deste xeito, podes ver que funcións utilizas para conservalos ou, por exemplo, conseguir que se rexistren. Por suposto, a matriz tamén mostrará cousas obvias. Por exemplo, que os que compraron unha subscrición visitaron a pantalla de subscrición. Pero ademais disto, tamén podes atopar patróns que doutro xeito nunca terías coñecido.

Polo tanto, atopamos de forma completamente accidental un grupo de usuarios que engaden un voo, seguen activamente durante todo o día e despois desaparecen durante moito tempo ata que volven a voar a algún lugar. Se analizasemos o seu comportamento mediante ferramentas convencionais, pensaríamos que simplemente non estaban satisfeitos coa funcionalidade da aplicación: de que outra maneira podemos explicar que a usaron durante un día e nunca volveron. Pero coa axuda de gráficos vimos que son moi activos, é que toda a súa actividade encaixa nun día.

Agora a nosa tarefa principal é animar a un usuario deste tipo a que se conecte ao programa de fidelización da súa compañía aérea mentres utiliza as nosas estatísticas. Neste caso, importaremos todos os voos que compre e tentaremos empurralo para que se rexistre en canto compre un novo billete. Para resolver este problema, tamén comezamos a cooperar con Aviasales, Svyaznoy.Travel e outras aplicacións. Cando o seu usuario compra un billete, a aplicación pídelle que engada o voo a App in the Air e vémolo inmediatamente.

Grazas ao gráfico, vimos que o 5% das persoas que van á pantalla de subscrición cancela. Comezamos a analizar este tipo de casos, e vimos que hai un usuario que vai á primeira páxina, inicia a conexión da súa conta de Google e inmediatamente a cancela, chega de novo á primeira páxina, e así catro veces. Ao principio pensamos: "Claramente hai algo mal con este usuario". E entón decatámonos de que, moi probablemente, houbese un erro na aplicación. No embudo, isto interpretaríase do seguinte xeito: ao usuario non lle gustou o conxunto de permisos que solicita a aplicación e abandonou.

Outro grupo tiña un 5% dos usuarios perdidos na pantalla onde a aplicación lles pediu que seleccionen unha de todas as aplicacións de calendario do seu teléfono intelixente. Os usuarios seleccionarían diferentes calendarios unha e outra vez e despois simplemente saían da aplicación. Resulta que houbo un problema de UX: despois de que unha persoa seleccionase un calendario, tivo que facer clic en Feito na esquina superior dereita. É que non todos os usuarios o viron.

Como se implementa a retención na aplicación no aire
Primeira pantalla da aplicación no aire

No noso gráfico, vimos que preto do 30% dos usuarios non van máis alá da primeira pantalla: isto débese a que somos bastante agresivos ao impulsar ao usuario a subscribirse. Na primeira pantalla, a aplicación pídelle que se rexistre mediante Google ou Triplt, e non hai información sobre que se salte o rexistro. Dos que saen da primeira pantalla, o 16% dos usuarios fai clic en "Máis" e volve de novo. Descubrimos que están a buscar unha forma de rexistrarse internamente na aplicación e lanzarémolo na próxima actualización. Ademais, 2/3 dos que marchan inmediatamente non fan clic en nada. Para saber que lles está pasando, elaboramos un mapa de calor. Resulta que os clientes están facendo clic nunha lista de funcións da aplicación que non son ligazóns nas que se pode facer clic.

Captura un micro-momento

Moitas veces podes ver xente pisando camiños xunto á estrada asfaltada. A retención é un intento de atopar estes camiños e, se é posible, cambiar as estradas.

Por suposto, é malo que aprendamos de usuarios reais, pero polo menos comezamos a rastrexar automaticamente patróns que indican un problema do usuario na aplicación. Agora o xestor de produto recibe notificacións por correo electrónico se se producen un gran número de "bucles", cando o usuario volve á mesma pantalla unha e outra vez.

Vexamos que patróns nas traxectorias dos usuarios son xeralmente interesantes de buscar para analizar problemas e áreas de crecemento dunha aplicación:

  • Ciclos e ciclos. Os bucles mencionados anteriormente son cando un evento se repite na traxectoria do usuario, por exemplo, calendario-calendario-calendario-calendario. Un bucle con moita repetición é un claro indicador dun problema de interface ou de marcado de eventos insuficiente. Un ciclo tamén é unha traxectoria pechada, pero a diferenza dun bucle inclúe máis dun evento, por exemplo: ver o historial de voos - engadir un voo - ver o historial de voos.
  • Flowstoppers - cando o usuario, debido a algún obstáculo, non pode continuar o seu movemento desexado a través da aplicación, por exemplo, unha pantalla cunha interface que non é obvia para o cliente. Este tipo de eventos ralentizan e cambian a traxectoria dos usuarios.
  • Os puntos de bifurcación son eventos significativos tras os cales se separan as traxectorias de clientes de diferentes tipos. En particular, trátase de pantallas que non conteñen unha transición directa ou chamada á acción á acción de destino, polo que empurran a algúns usuarios cara a ela. Por exemplo, algunha pantalla que non está directamente relacionada coa compra de contido nunha aplicación, pero na que os clientes están inclinados a mercar ou non, comportarase de forma diferente. Os puntos de bifurcación poden ser puntos de influencia nas accións dos teus usuarios cun signo máis -poden influír na decisión de facer unha compra ou facer clic, ou un signo menos- poden determinar que despois duns pasos o usuario abandonará a aplicación.
  • Os puntos de conversión abortados son puntos de bifurcación potenciais. Podes pensar nelas como pantallas que poden provocar unha acción de destino, pero non o fan. Este tamén pode ser un momento no que o usuario teña unha necesidade, pero non a satisfacemos porque simplemente non a coñecemos. A análise da traxectoria debería permitir identificar esta necesidade.
  • Punto de distracción: pantallas e ventás emerxentes que non proporcionan valor ao usuario, non afectan á conversión e poden "desenfocar" as traxectorias, distraendo ao usuario das accións de destino.
  • Os puntos cegos son puntos ocultos da aplicación, pantallas e funcións que son moi difíciles de alcanzar para o usuario.
  • Drenaxes: puntos onde o tráfico ten fugas

En xeral, o enfoque matemático permitiunos entender que o cliente usa a aplicación dun xeito completamente diferente do que adoitan pensar os xestores de produtos cando intentan planificar algún escenario de uso estándar para o usuario. Sentado na oficina e asistindo ás conferencias de produtos máis chulas, aínda é moi difícil imaxinar toda a variedade de condicións reais de campo nas que o usuario resolverá os seus problemas utilizando a aplicación.

Isto lémbrame a unha gran broma. Un probador entra nun bar e pide: un vaso de cervexa, 2 vasos de cervexa, 0 vasos de cervexa, 999999999 vasos de cervexa, un lagarto nun vaso, -1 vaso de cervexa, qwertyuip vasos de cervexa. O primeiro cliente real entra no bar e pregunta onde está o baño. O bar arde en chamas e todos morren.

Os analistas de produtos, profundamente inmersos neste problema, comezaron a introducir o concepto de micromomento. O usuario moderno necesita unha solución instantánea ao seu problema. Google comezou a falar diso hai uns anos: a compañía chamou micro-momentos a esas accións dos usuarios. O usuario distrae, pecha accidentalmente a aplicación, non entende o que se lle esixe, volve iniciar sesión un día despois, esquécese de novo e despois segue a ligazón que lle enviou un amigo no messenger. E todas estas sesións non poden durar máis de 20 segundos.

Así que comezamos a tentar configurar o traballo do servizo de apoio para que os empregados puidesen comprender cal era o problema case en tempo real. Cando unha persoa chega á páxina de soporte e comeza a escribir a súa pregunta, podemos determinar a esencia do problema, coñecendo a súa traxectoria: os últimos 100 eventos. Anteriormente, automatizamos a distribución de todas as solicitudes de soporte en categorías mediante a análise de ML dos textos das solicitudes de soporte. A pesar do éxito da categorización, cando o 87% de todas as solicitudes están correctamente distribuídas nunha das 13 categorías, trátase dun traballo con traxectorias que poden atopar automaticamente a solución máis adecuada para a situación do usuario.

Non podemos lanzar actualizacións rapidamente, pero podemos notar o problema e, se o usuario segue o escenario que xa vimos, enviarlle unha notificación push.

Vemos que a tarefa de optimizar unha aplicación require de ricas ferramentas para estudar as traxectorias dos usuarios. Ademais, coñecendo todos os camiños que percorren os usuarios, pode abrir os camiños necesarios e, coa axuda de contido personalizado, notificacións push e elementos de IU adaptativos "da man" levan ao usuario a accións dirixidas que mellor se adapten ás súas necesidades e traen diñeiro. , datos e outro valor para a súa empresa.

Que tomar nota

  • Estudar a conversión de usuarios só usando funnels como exemplo significa perder a rica información que nos proporciona a propia aplicación.

  • A análise de retención das traxectorias dos usuarios nos gráficos axúdache a ver que funcións utilizas para reter aos usuarios ou, por exemplo, animalos a que se subscriban.
  • As ferramentas de retención axudan automaticamente, en tempo real, a rastrexar patróns que indican problemas do usuario na aplicación, a atopar e pechar erros nos que fosen difíciles de detectar.

  • Axudan a atopar patróns non obvios de comportamento do usuario.

  • As ferramentas de retención permiten construír ferramentas automatizadas de ML para predicir eventos e métricas clave do usuario: perda de usuarios, LTV e moitas outras métricas que se determinan facilmente no gráfico.

Estamos a construír unha comunidade arredor do Retentioneering para o libre intercambio de ideas. Podes pensar nas ferramentas que estamos a desenvolver como unha linguaxe na que analistas e produtos de diferentes aplicacións web e móbiles poden intercambiar coñecementos, mellores técnicas e métodos. Podes aprender a utilizar estas ferramentas no curso Growth Hacking: análise de aplicacións móbiles Distrito Binario.

Fonte: www.habr.com

Engadir un comentario