Cum este implementat Retentioneering în App in the Air

Cum este implementat Retentioneering în App in the Air

Menținerea unui utilizator într-o aplicație mobilă este o întreagă știință. Autorul cursului a descris elementele de bază în articolul nostru de pe VC.ru Growth Hacking: analiza aplicațiilor mobile Maxim Godzi, șeful Machine Learning la App in the Air. Maxim vorbește despre instrumentele dezvoltate în companie folosind exemplul de lucru privind analiza și optimizarea unei aplicații mobile. Această abordare sistematică a îmbunătățirii produselor, dezvoltată în App in the Air, se numește Retentioneering. Puteți utiliza aceste instrumente în produsul dvs.: unele dintre ele sunt în acces liber pe GitHub.

App in the Air este o aplicație cu peste 3 milioane de utilizatori activi din întreaga lume, cu ajutorul căreia puteți urmări zborurile, obțineți informații despre modificările orelor de plecare/aterizare, check-in și caracteristicile aeroportului.

De la pâlnie la traiectorie

Toate echipele de dezvoltare construiesc o pâlnie de onboarding (un proces care vizează acceptarea de către utilizator a produsului). Acesta este primul pas care vă ajută să priviți întregul sistem de sus și să găsiți problemele aplicației. Dar pe măsură ce produsul se dezvoltă, veți simți limitările acestei abordări. Folosind o pâlnie simplă, nu puteți vedea puncte de creștere neevidente pentru un produs. Scopul pâlniei este de a oferi o privire generală asupra etapelor utilizatorilor din aplicație, pentru a vă arăta metrica normei. Dar pâlnia va ascunde cu prudență abaterile de la normă către probleme evidente sau, dimpotrivă, activitate specială a utilizatorului.

Cum este implementat Retentioneering în App in the Air

La App in the Air ne-am construit propria pâlnie, dar din cauza specificului produsului, am ajuns să avem o clepsidră. Apoi am decis să extindem abordarea și să folosim informațiile bogate pe care ni le oferă aplicația în sine.

Când construiți o pâlnie, pierzi traiectorii de integrare a utilizatorului. Traiectorii constau într-o secvență de acțiuni ale utilizatorului și aplicației în sine (de exemplu, trimiterea unei notificări push).

Cum este implementat Retentioneering în App in the Air

Folosind marcaje temporale, puteți reconstrui foarte ușor traiectoria utilizatorului și puteți face un grafic din ea pentru fiecare dintre ele. Desigur, există o mulțime de grafice. Prin urmare, trebuie să grupați utilizatori similari. De exemplu, puteți aranja toți utilizatorii după rânduri de tabel și puteți enumera cât de des folosesc o anumită funcție.

Cum este implementat Retentioneering în App in the Air

Pe baza unui astfel de tabel, am realizat o matrice și am grupat utilizatorii după frecvența de utilizare a funcțiilor, adică pe nodurile din grafic. Acesta este de obicei primul pas către perspective: de exemplu, deja în această etapă veți vedea că unii utilizatori nu folosesc deloc unele dintre funcții. Când am făcut analiza frecvenței, am început să studiem care noduri din grafic sunt cele „mai mari”, adică ce pagini vizitează cel mai des utilizatorii. Categoriile care sunt fundamental diferite în funcție de un criteriu care este important pentru dvs. sunt imediat evidențiate. Iată, de exemplu, două grupuri de utilizatori pe care le-am împărțit în funcție de decizia de abonare (au fost 16 clustere în total).

Cum este implementat Retentioneering în App in the Air

Cum să-l folosească

Privind astfel utilizatorii dvs., puteți vedea ce funcții folosiți pentru a-i păstra sau, de exemplu, pentru a-i determina să se înscrie. Desigur, matricea va arăta și lucruri evidente. De exemplu, cei care au achiziționat un abonament au vizitat ecranul de abonament. Dar, pe lângă asta, poți găsi și modele despre care altfel nu ai fi știut niciodată.

Așa că am găsit complet accidental un grup de utilizatori care adaugă un zbor, îl urmăresc în mod activ pe tot parcursul zilei și apoi dispar mult timp până zboară din nou undeva. Dacă le-am analiza comportamentul folosind instrumente convenționale, am crede că pur și simplu nu au fost mulțumiți de funcționalitatea aplicației: cum altfel le putem explica că au folosit-o o zi și nu s-au mai întors. Dar cu ajutorul graficelor am văzut că sunt foarte activi, doar că toată activitatea lor se încadrează într-o singură zi.

Acum sarcina noastră principală este să încurajăm un astfel de utilizator să se conecteze la programul de fidelitate al companiei sale aeriene în timp ce folosește statisticile noastre. În acest caz, vom importa toate zborurile pe care le cumpără și vom încerca să-l împingem să se înscrie de îndată ce își cumpără un nou bilet. Pentru a rezolva această problemă, am început să cooperăm și cu Aviasales, Svyaznoy.Travel și alte aplicații. Când utilizatorul lor achiziționează un bilet, aplicația îi solicită să adauge zborul la App in the Air și îl vedem imediat.

Datorită graficului, am văzut că 5% dintre persoanele care merg la ecranul de abonament îl anulează. Am început să analizăm astfel de cazuri și am văzut că există un utilizator care merge la prima pagină, inițiază conectarea contului său Google și îl anulează imediat, ajunge din nou la prima pagină și așa mai departe de patru ori. La început ne-am gândit: „Ceva este clar în neregulă cu acest utilizator”. Și apoi ne-am dat seama că, cel mai probabil, a existat un bug în aplicație. În pâlnie, acest lucru ar fi interpretat astfel: utilizatorului nu i-a plăcut setul de permisiuni pe care le solicită aplicația și a plecat.

Un alt grup a avut 5% dintre utilizatori s-au pierdut pe ecran, unde aplicația le cere să selecteze una dintre toate aplicațiile de calendar de pe smartphone-ul lor. Utilizatorii ar selecta diferite calendare din nou și din nou și apoi pur și simplu ar ieși din aplicație. Se pare că a existat o problemă UX: după ce o persoană a selectat un calendar, a trebuit să facă clic pe Terminat în colțul din dreapta sus. Doar că nu toți utilizatorii l-au văzut.

Cum este implementat Retentioneering în App in the Air
Primul ecran al aplicației în aer

În graficul nostru, am văzut că aproximativ 30% dintre utilizatori nu trec dincolo de primul ecran: acest lucru se datorează faptului că suntem destul de agresivi în a împinge utilizatorul să se aboneze. Pe primul ecran, aplicația vă solicită să vă înregistrați folosind Google sau Triplt și nu există informații despre omiterea înregistrării. Dintre cei care părăsesc primul ecran, 16% dintre utilizatori fac clic pe „Mai mult” și revin din nou. Am aflat că ei caută o modalitate de a se înregistra intern în aplicație și o vom lansa în următoarea actualizare. În plus, 2/3 dintre cei care pleacă imediat nu dau clic pe nimic. Pentru a afla ce se întâmplă cu ei, am construit o hartă termică. Se pare că clienții fac clic pe o listă de funcții ale aplicației care nu sunt linkuri pe care se poate face clic.

Surprindeți un micro-moment

Poți vedea adesea oameni călcând în picioare poteci lângă drumul asfaltat. Retentioneeringul este o încercare de a găsi aceste căi și, dacă este posibil, de a schimba drumurile.

Desigur, este rău că învățăm de la utilizatori reali, dar cel puțin am început să urmărim automat modele care indică o problemă a utilizatorului în aplicație. Acum, managerul de produs primește notificări prin e-mail dacă apare un număr mare de „bucle” - când utilizatorul revine la același ecran din nou și din nou.

Să ne uităm la ce tipare în traiectorii utilizatorilor sunt în general interesante de căutat pentru a analiza problemele și zonele de creștere ale unei aplicații:

  • Bucle și cicluri. Buclele menționate mai sus sunt atunci când un eveniment se repetă în traiectoria utilizatorului, de exemplu, calendar-calendar-calendar-calendar. O buclă cu multă repetare este un indicator clar al unei probleme de interfață sau al unui eveniment insuficient. Un ciclu este, de asemenea, o traiectorie închisă, dar spre deosebire de o buclă include mai mult de un eveniment, de exemplu: vizualizarea istoricului zborului - adăugarea unui zbor - vizualizarea istoricului zborului.
  • Flowstoppers - atunci când utilizatorul, din cauza unui obstacol, nu își poate continua mișcarea dorită prin aplicație, de exemplu, un ecran cu o interfață care nu este evidentă pentru client. Astfel de evenimente încetinesc și schimbă traiectoria utilizatorilor.
  • Punctele de bifurcație sunt evenimente semnificative în urma cărora traiectoriile clienților de diferite tipuri sunt separate. În special, acestea sunt ecrane care nu conțin o tranziție directă sau îndemn la acțiunea țintă, împingând efectiv unii utilizatori către aceasta. De exemplu, un ecran care nu are legătură directă cu achiziționarea de conținut într-o aplicație, dar pe care clienții sunt înclinați să cumpere sau să nu cumpere conținut, se vor comporta diferit. Punctele de bifurcație pot fi puncte de influență asupra acțiunilor utilizatorilor tăi cu un semn plus - pot influența decizia de a face o achiziție sau un clic, sau un semn minus - pot determina că după câțiva pași utilizatorul va părăsi aplicația.
  • Punctele de conversie întrerupte sunt puncte potențiale de bifurcare. Puteți să vă gândiți la ele ca pe niște ecrane care ar putea determina o acțiune țintă, dar nu o fac. Acesta ar putea fi, de asemenea, un moment în care utilizatorul are o nevoie, dar noi nu o satisfacem pentru că pur și simplu nu știm despre asta. Analiza traiectoriei ar trebui să permită identificarea acestei necesități.
  • Punct de distragere a atenției - ecrane/fer-uri pop-up care nu oferă valoare utilizatorului, nu afectează conversia și pot „ estompa” traiectorii, distragerea atenției utilizatorului de la acțiunile țintă.
  • Punctele moarte sunt puncte ascunse ale aplicației, ecrane și funcții la care utilizatorul le poate ajunge foarte greu.
  • Drenuri – puncte în care traficul se scurge

În general, abordarea matematică ne-a permis să înțelegem că clientul folosește aplicația într-un mod complet diferit decât cred de obicei managerii de produs atunci când încearcă să planifice un scenariu standard de utilizare pentru utilizator. Stând la birou și asistând la cele mai tari conferințe de produse, este încă foarte greu de imaginat toată varietatea condițiilor reale de teren în care utilizatorul își va rezolva problemele folosind aplicația.

Asta îmi amintește de o glumă grozavă. Un tester intră într-un bar și comandă: un pahar de bere, 2 pahare de bere, 0 pahare de bere, 999999999 pahare de bere, o șopârlă într-un pahar, -1 pahar de bere, pahare qwertyuip de bere. Primul client real intră în bar și întreabă unde este toaleta. Barul izbucnește în flăcări și toată lumea moare.

Analistii de produs, profund cufundati in aceasta problema, au inceput sa introduca conceptul de micromoment. Utilizatorul modern are nevoie de o soluție instantanee la problema lor. Google a început să vorbească despre asta acum câțiva ani: compania a numit astfel de acțiuni ale utilizatorilor micro-momente. Utilizatorul este distras, închide accidental aplicația, nu înțelege ce i se cere, se conectează din nou o zi mai târziu, uită din nou și apoi urmează linkul pe care i l-a trimis un prieten în messenger. Și toate aceste sesiuni nu pot dura mai mult de 20 de secunde.

Așa că am început să încercăm să punem la punct activitatea serviciului de asistență, astfel încât angajații să poată înțelege care este problema aproape în timp real. În momentul în care o persoană ajunge pe pagina de asistență și începe să-și scrie întrebarea, putem determina esența problemei, cunoscându-i traiectoria - ultimele 100 de evenimente. Anterior, am automatizat distribuirea tuturor solicitărilor de asistență pe categorii folosind analiza ML a textelor cererilor de asistență. În ciuda succesului categorizării, atunci când 87% din toate solicitările sunt corect distribuite într-una din cele 13 categorii, se lucrează cu traiectorii care pot găsi automat soluția cea mai potrivită pentru situația utilizatorului.

Nu putem lansa rapid actualizări, dar putem observa problema și, dacă utilizatorul urmează scenariul pe care l-am văzut deja, îi trimitem o notificare push.

Vedem că sarcina de optimizare a unei aplicații necesită instrumente bogate pentru studierea traiectoriilor utilizatorilor. În plus, cunoscând toate căile pe care le parcurg utilizatorii, puteți deschide căile necesare și, cu ajutorul conținutului personalizat, notificări push și elemente de UI adaptive „de mână” conduc utilizatorul la acțiuni direcționate care se potrivesc cel mai bine nevoilor sale și aduc bani. , date și alte valori pentru afacerea dvs.

Ce să ții cont

  • Studierea conversiei utilizatorilor folosind doar pâlnii ca exemplu înseamnă pierderea informațiilor bogate pe care ni le oferă aplicația în sine.

  • Analiza retentioneering a traiectoriilor utilizatorilor pe grafice vă ajută să vedeți ce caracteristici folosiți pentru a păstra utilizatorii sau, de exemplu, pentru a-i încuraja să se aboneze.
  • Instrumentele de reținere ajută automat, în timp real, să urmărească tiparele care indică problemele utilizatorilor în aplicație, să găsească și să închidă erori acolo unde au fost greu de observat.

  • Ele ajută la găsirea unor modele neevidente de comportament al utilizatorului.

  • Instrumentele de retentioneering fac posibilă construirea de instrumente automate de ML pentru prezicerea evenimentelor și valorilor cheie ale utilizatorilor: pierderea utilizatorilor, LTV și multe alte valori care sunt ușor de determinat pe grafic.

Construim o comunitate în jurul Retentioneering pentru schimbul liber de idei. Vă puteți gândi la instrumentele pe care le dezvoltăm ca la un limbaj în care analiștii și produsele din diferite aplicații mobile și web pot face schimb de informații, cele mai bune tehnici și metode. Puteți învăța cum să utilizați aceste instrumente în cadrul cursului Growth Hacking: analiza aplicațiilor mobile Districtul Binar.

Sursa: www.habr.com

Adauga un comentariu