Kako se retentioneering implementira u App in the Air

Kako se retentioneering implementira u App in the Air

Zadržati korisnika u mobilnoj aplikaciji je cijela znanost. Autor tečaja opisao je njegove osnove u našem članku na VC.ru Growth Hacking: analitika mobilnih aplikacija Maxim Godzi, voditelj strojnog učenja u App in the Air. Maxim govori o alatima razvijenim u tvrtki na primjeru rada na analizi i optimizaciji mobilne aplikacije. Ovaj sustavni pristup poboljšanju proizvoda, razvijen u App in the Air, zove se Retentioneering. Možete koristiti ove alate u svom proizvodu: neki od njih su u besplatan pristup na GitHubu.

App in the Air je aplikacija s više od 3 milijuna aktivnih korisnika diljem svijeta, pomoću koje možete pratiti letove, dobiti informacije o promjenama vremena polaska/slijetanja, prijave i karakteristike zračne luke.

Od lijevka do putanje

Svi razvojni timovi grade lijevak uključivanja (proces usmjeren na prihvaćanje proizvoda od strane korisnika). Ovo je prvi korak koji vam pomaže da sagledate cijeli sustav odozgo i pronađete probleme u aplikaciji. Ali kako se proizvod bude razvijao, osjetit ćete ograničenja ovog pristupa. Korištenjem jednostavnog lijevka ne možete vidjeti neočite točke rasta za proizvod. Svrha toka je dati opći pogled na faze korisnika u aplikaciji, pokazati vam metriku norme. Ali lijevak će razborito sakriti odstupanja od norme prema očitim problemima ili, naprotiv, posebnim aktivnostima korisnika.

Kako se retentioneering implementira u App in the Air

U App in the Airu izgradili smo vlastiti lijevak, no zbog specifičnosti proizvoda završili smo s pješčanim satom. Tada smo odlučili proširiti pristup i iskoristiti bogatstvo informacija koje nam sama aplikacija daje.

Kada gradite tok, gubite putanje korisnika. Trajektorije se sastoje od slijeda radnji korisnika i same aplikacije (na primjer, slanje push obavijesti).

Kako se retentioneering implementira u App in the Air

Pomoću vremenskih oznaka možete vrlo jednostavno rekonstruirati putanju korisnika i od toga napraviti grafikon za svakog od njih. Naravno, ima puno grafikona. Stoga morate grupirati slične korisnike. Na primjer, možete poredati sve korisnike po recima tablice i navesti koliko često koriste određenu funkciju.

Kako se retentioneering implementira u App in the Air

Na temelju takve tablice napravili smo matricu i grupirali korisnike po učestalosti korištenja funkcija, odnosno po čvorovima u grafu. To je obično prvi korak prema uvidu: na primjer, već u ovoj fazi vidjet ćete da neki korisnici uopće ne koriste neke od funkcija. Kada smo radili analizu učestalosti, počeli smo proučavati koji su čvorovi na grafu “najveći”, odnosno koje stranice korisnici najčešće posjećuju. Odmah se ističu kategorije koje se bitno razlikuju po nekom vama važnom kriteriju. Evo, na primjer, dva klastera korisnika koje smo podijelili na temelju odluke o pretplati (ukupno je bilo 16 klastera).

Kako se retentioneering implementira u App in the Air

Kako ga koristiti

Promatrajući svoje korisnike na ovaj način, možete vidjeti koje značajke koristite da biste ih zadržali ili, na primjer, naveli da se prijave. Naravno, matrica će pokazati i očite stvari. Na primjer, da su oni koji su kupili pretplatu posjetili zaslon za pretplatu. Ali osim toga, također možete pronaći uzorke za koje inače nikad ne biste znali.

Tako smo potpuno slučajno pronašli skupinu korisnika koji dodaju let, aktivno ga prate tijekom dana i onda nestanu na duže vrijeme dok ponovno nekamo ne odlete. Kad bismo analizirali njihovo ponašanje pomoću konvencionalnih alata, pomislili bismo da jednostavno nisu bili zadovoljni funkcionalnošću aplikacije: kako drugačije objasniti da su je koristili jedan dan i više se nisu vratili. Ali uz pomoć grafikona vidjeli smo da su vrlo aktivni, samo im sva aktivnost stane u jedan dan.

Sada je naš glavni zadatak potaknuti takvog korisnika da se poveže s programom vjernosti svojeg zrakoplovnog prijevoznika dok koristi našu statistiku. U ovom ćemo slučaju uvesti sve letove koje kupi i pokušati ga natjerati da se prijavi čim kupi novu kartu. Kako bismo riješili ovaj problem, također smo počeli surađivati ​​s Aviasales, Svyaznoy.Travel i drugim aplikacijama. Kada korisnik kupi kartu, aplikacija ga traži da doda let u App in the Air, a mi to odmah vidimo.

Zahvaljujući grafikonu, vidjeli smo da 5% ljudi koji odu na ekran za pretplatu je otkažu. Počeli smo analizirati takve slučajeve i vidjeli da postoji korisnik koji ode na prvu stranicu, pokrene povezivanje svog Google računa i odmah ga poništi, ponovno dođe na prvu stranicu i tako četiri puta. Prvo smo pomislili: "Nešto očito nije u redu s ovim korisnikom." A onda smo shvatili da, najvjerojatnije, postoji greška u aplikaciji. U lijevku bi se to protumačilo na sljedeći način: korisniku se nije svidio skup dozvola koje aplikacija traži i on je otišao.

Kod druge skupine 5% korisnika se izgubilo na zaslonu gdje ih je aplikacija pozvala da odaberu jednu od svih aplikacija kalendara na svom pametnom telefonu. Korisnici bi uvijek iznova birali različite kalendare, a zatim bi jednostavno izašli iz aplikacije. Ispostavilo se da postoji problem s UX-om: nakon što je osoba odabrala kalendar, morala je kliknuti Gotovo u gornjem desnom kutu. Samo što to nisu svi korisnici vidjeli.

Kako se retentioneering implementira u App in the Air
Prvi zaslon aplikacije u zraku

Na našem grafikonu vidjeli smo da oko 30% korisnika ne ide dalje od prvog zaslona: to je zbog činjenice da smo prilično agresivni u tjeranju korisnika da se pretplate. Na prvom ekranu aplikacija traži da se registrirate putem Googlea ili Triplta, a nema informacija o preskakanju registracije. Od onih koji napuste prvi zaslon, 16% korisnika klikne "Više" i ponovno se vrati. Saznali smo da traže način za internu registraciju u aplikaciji i objavit ćemo ga u sljedećem ažuriranju. Osim toga, 2/3 onih koji odmah odu ne kliknu baš ništa. Kako bismo saznali što im se događa, napravili smo toplinsku kartu. Ispostavilo se da korisnici klikaju na popis značajki aplikacije koje nisu veze na koje se može kliknuti.

Uhvatite mikrotrenutak

Često se pored asfaltne ceste mogu vidjeti ljudi koji gaze staze. Retencioniranje je pokušaj pronalaženja tih staza i, ako je moguće, promjena cesta.

Naravno, loše je što učimo od stvarnih korisnika, ali barem smo počeli automatski pratiti obrasce koji ukazuju na problem korisnika u aplikaciji. Sada voditelj proizvoda prima obavijesti e-poštom ako se dogodi veliki broj "petlji"—kada se korisnik uvijek iznova vraća na isti zaslon.

Pogledajmo koje je uzorke u korisničkim putanjama općenito zanimljivo tražiti za analizu problema i područja rasta aplikacije:

  • Petlje i ciklusi. Gore spomenute petlje su kada se jedan događaj ponavlja u korisnikovoj putanji, na primjer, kalendar-kalendar-kalendar-kalendar. Petlja s puno ponavljanja jasan je pokazatelj problema sa sučeljem ili nedovoljnog označavanja događaja. Ciklus je također zatvorena putanja, ali za razliku od petlje uključuje više od jednog događaja, na primjer: pregled povijesti leta - dodavanje leta - pregled povijesti leta.
  • Flowstoppers - kada korisnik zbog neke prepreke ne može nastaviti željeno kretanje kroz aplikaciju, npr. zaslon sa sučeljem koje nije vidljivo klijentu. Takvi događaji usporavaju i pomiču putanju korisnika.
  • Bifurkacijske točke su značajni događaji nakon kojih se razdvajaju putanje klijenata različitih tipova. Konkretno, to su zasloni koji ne sadrže izravan prijelaz ili poziv na radnju na ciljanu radnju, učinkovito gurajući neke korisnike prema njoj. Na primjer, neki zaslon koji nije izravno vezan uz kupnju sadržaja u aplikaciji, ali na kojem su kupci skloni kupnji ili nekupnji sadržaja, ponašat će se drugačije. Bifurkacijske točke mogu biti točke utjecaja na radnje vaših korisnika s predznakom plus - mogu utjecati na odluku o kupnji ili kliku ili predznakom minus - mogu odrediti da će nakon nekoliko koraka korisnik napustiti aplikaciju.
  • Prekinute točke konverzije potencijalne su točke bifurkacije. Možete ih zamisliti kao zaslone koji bi mogli potaknuti ciljanu akciju, ali nemojte. To također može biti trenutak u vremenu kada korisnik ima potrebu, ali je mi ne zadovoljavamo jer jednostavno ne znamo za nju. Analiza putanje trebala bi omogućiti utvrđivanje ove potrebe.
  • Točka odvlačenja pažnje - zasloni/skočni prozori koji ne pružaju vrijednost korisniku, ne utječu na pretvorbu i mogu "zamutiti" putanje, odvraćajući korisnika od ciljnih radnji.
  • Slijepe točke su skrivene točke aplikacije, zaslona i značajki do kojih je korisniku vrlo teško doći.
  • Odvodi – mjesta gdje curi promet

Općenito, matematički pristup nam je omogućio da shvatimo da klijent koristi aplikaciju na potpuno drugačiji način nego što voditelji proizvoda obično misle kada pokušavaju planirati neki standardni scenarij korištenja za korisnika. Sjedeći u uredu i prisustvujući najcool konferencijama o proizvodima, još uvijek je vrlo teško zamisliti svu raznolikost stvarnih terenskih uvjeta u kojima će korisnik rješavati svoje probleme pomoću aplikacije.

Ovo me podsjeća na sjajan vic. Ispitivač ulazi u bar i naručuje: čašu piva, 2 čaše piva, 0 čaša piva, 999999999 čaša piva, guštera u čaši, -1 čašu piva, qwertyuip čaša piva. Prva prava mušterija ulazi u bar i pita gdje je toalet. Bar bukne u plamenu i svi poginu.

Analitičari proizvoda, duboko uronjeni u ovaj problem, počeli su uvoditi koncept mikromomenta. Moderni korisnik treba trenutno rješenje za svoj problem. Google je o tome počeo govoriti prije nekoliko godina: tvrtka je takve radnje korisnika nazvala mikrotrenucima. Korisnik se omesti, slučajno zatvori aplikaciju, ne razumije što se od njega traži, ponovno se ulogira dan kasnije, opet zaboravi, a zatim slijedi link koji mu je prijatelj poslao u messengeru. I sve te sesije ne mogu trajati duže od 20 sekundi.

Tako smo počeli pokušavati postaviti rad službe podrške tako da zaposlenici mogu razumjeti u čemu je problem gotovo u stvarnom vremenu. U trenutku kada osoba dođe na stranicu podrške i počne pisati svoje pitanje, možemo odrediti bit problema, znajući njegovu putanju - zadnjih 100 događaja. Prethodno smo automatizirali distribuciju svih zahtjeva za podršku u kategorije koristeći ML analizu tekstova zahtjeva za podršku. Unatoč uspjehu kategorizacije, kada je 87% svih zahtjeva ispravno raspoređeno u jednu od 13 kategorija, upravo rad s putanjama može automatski pronaći najprikladnije rješenje za situaciju korisnika.

Ne možemo brzo objaviti ažuriranja, ali možemo uočiti problem i, ako korisnik slijedi scenarij koji smo već vidjeli, poslati mu push obavijest.

Vidimo da zadatak optimizacije aplikacije zahtijeva bogate alate za proučavanje putanja korisnika. Nadalje, poznavajući sve putove kojima korisnici idu, možete utrti potrebne putove, a uz pomoć prilagođenog sadržaja, push obavijesti i prilagodljivih UI elemenata „za ruku“ dovesti korisnika do ciljanih akcija koje najbolje odgovaraju njegovim potrebama i donose novac podataka i druge vrijednosti za vaše poslovanje.

Što uzeti na znanje

  • Proučavanje pretvorbe korisnika samo na primjeru tokova znači gubitak bogatih informacija koje nam daje sama aplikacija.

  • Analiza zadržavanja korisničkih putanja na grafikonima pomaže vam da vidite koje značajke koristite da zadržite korisnike ili ih, na primjer, potaknete da se pretplate.
  • Alati za zadržavanje pomažu automatski, u stvarnom vremenu, pratiti obrasce koji ukazuju na probleme korisnika u aplikaciji, pronaći i zatvoriti greške tamo gdje ih je bilo teško primijetiti.

  • Pomažu u pronalaženju neočitih obrazaca ponašanja korisnika.

  • Alati za zadržavanje omogućuju izradu automatiziranih ML alata za predviđanje ključnih korisničkih događaja i metrika: gubitak korisnika, LTV i mnoge druge metrike koje je lako odrediti na grafikonu.

Gradimo zajednicu oko Retentioneeringa za slobodnu razmjenu ideja. Možete zamisliti alate koje razvijamo kao jezik u kojem analitičari i proizvodi iz različitih mobilnih i web aplikacija mogu razmjenjivati ​​uvide, najbolje tehnike i metode. Na tečaju možete naučiti kako koristiti te alate Growth Hacking: analitika mobilnih aplikacija Binarni okrug.

Izvor: www.habr.com

Dodajte komentar