Kako je Retentioneering implementiran v App in the Air

Kako je Retentioneering implementiran v App in the Air

Zadržati uporabnika v mobilni aplikaciji je cela znanost. Avtor tečaja je njegove osnove opisal v našem članku na VC.ru Growth Hacking: analitika mobilnih aplikacij Maxim Godzi, vodja strojnega učenja pri App in the Air. Maxim govori o orodjih, razvitih v podjetju, na primeru dela na analizi in optimizaciji mobilne aplikacije. Ta sistematičen pristop k izboljšanju izdelkov, razvit v App in the Air, se imenuje Retentioneering. Ta orodja lahko uporabite v svojem izdelku: nekatera od njih so v brezplačen dostop na GitHubu.

App in the Air je aplikacija z več kot 3 milijoni aktivnih uporabnikov po vsem svetu, s katero lahko spremljate lete, dobite informacije o spremembah ur odhoda/pristanka, prijave in značilnosti letališča.

Od lijaka do trajektorije

Vse razvojne ekipe gradijo vstopni lijak (proces, katerega cilj je uporabnik sprejeti izdelek). To je prvi korak, ki vam pomaga pogledati celoten sistem od zgoraj in najti težave z aplikacijo. Ko pa se izdelek razvija, boste občutili omejitve tega pristopa. Z uporabo preprostega lijaka ne morete videti neočitnih točk rasti za izdelek. Namen lijaka je dati splošen vpogled v stopnje uporabnikov v aplikaciji, da vam pokaže meritve norme. Toda tok bo preudarno skril odstopanja od norme v smeri očitnih težav ali, nasprotno, posebne dejavnosti uporabnikov.

Kako je Retentioneering implementiran v App in the Air

Pri App in the Air smo zgradili svoj lijak, vendar smo zaradi specifike produkta na koncu dobili peščeno uro. Nato smo se odločili razširiti pristop in uporabiti bogate informacije, ki nam jih ponuja sama aplikacija.

Ko zgradite tok, izgubite poti vkrcanja uporabnikov. Trajektorije so sestavljene iz zaporedja dejanj uporabnika in same aplikacije (na primer pošiljanje potisnega obvestila).

Kako je Retentioneering implementiran v App in the Air

Z uporabo časovnih žigov lahko zelo preprosto rekonstruirate pot uporabnika in iz tega naredite graf za vsakega od njih. Grafov je seveda veliko. Zato morate podobne uporabnike združiti v skupine. Na primer, vse uporabnike lahko razporedite po vrsticah tabele in navedete, kako pogosto uporabljajo določeno funkcijo.

Kako je Retentioneering implementiran v App in the Air

Na podlagi takšne tabele smo naredili matriko in uporabnike razvrstili po pogostosti uporabe funkcij, torej po vozliščih v grafu. To je običajno prvi korak k vpogledu: na primer, že na tej stopnji boste videli, da nekateri uporabniki nekaterih funkcij sploh ne uporabljajo. Ko smo naredili frekvenčno analizo, smo začeli proučevati, katera vozlišča v grafu so »največja«, torej katere strani uporabniki najpogosteje obiskujejo. Takoj so izpostavljene kategorije, ki se bistveno razlikujejo po nekem za vas pomembnem kriteriju. Tukaj sta na primer dva grozda uporabnikov, ki smo ju razdelili na podlagi odločitve o naročnini (skupaj je bilo 16 grozdov).

Kako je Retentioneering implementiran v App in the Air

Kako ga uporabljati

Če na ta način pogledate svoje uporabnike, lahko vidite, katere funkcije uporabljate, da jih obdržite ali jih na primer prepričate, da se prijavijo. Seveda bo matrika pokazala tudi očitne stvari. Na primer, da so tisti, ki so kupili naročnino, obiskali zaslon za naročnino. Toda poleg tega lahko najdete tudi vzorce, ki jih sicer ne bi nikoli poznali.

Tako smo povsem po naključju našli skupino uporabnikov, ki dodajo let, ga aktivno spremljajo ves dan in nato izginejo za dolgo časa, dokler spet nekam ne odletijo. Če bi njihovo vedenje analizirali z običajnimi orodji, bi pomislili, da preprosto niso bili zadovoljni s funkcionalnostjo aplikacije: kako drugače naj si razložimo, da so jo uporabljali en dan in se nikoli več niso vrnili. A s pomočjo grafov smo videli, da so zelo aktivni, le da se vsa njihova aktivnost zbere v enem dnevu.

Zdaj je naša glavna naloga spodbuditi takšnega uporabnika, da se poveže s programom zvestobe svojega letalskega prevoznika, medtem ko uporablja naše statistike. V tem primeru bomo uvozili vse lete, ki jih kupi, in ga poskušali prisiliti, da se prijavi takoj, ko kupi novo vozovnico. Za rešitev te težave smo začeli sodelovati tudi z Aviasales, Svyaznoy.Travel in drugimi aplikacijami. Ko njihov uporabnik kupi vozovnico, ga aplikacija pozove, naj doda let v aplikacijo App in the Air, mi pa to takoj vidimo.

Zahvaljujoč grafu smo videli, da 5 % ljudi, ki obiščejo zaslon za naročnino, to prekliče. Začeli smo analizirati takšne primere in videli, da obstaja uporabnik, ki gre na prvo stran, sproži povezavo svojega Google računa in jo takoj prekliče, spet pride na prvo stran in tako naprej štirikrat. Sprva smo mislili: "S tem uporabnikom je očitno nekaj narobe." In potem smo ugotovili, da je najverjetneje prišlo do napake v aplikaciji. V lijaku bi si to razlagali takole: uporabniku ni bil všeč niz dovoljenj, ki jih zahteva aplikacija, in je zapustil.

Pri drugi skupini se je 5 % uporabnikov izgubilo na zaslonu, kjer jih je aplikacija pozvala, naj izberejo eno izmed vseh koledarskih aplikacij na svojem pametnem telefonu. Uporabniki bi vedno znova izbrali različne koledarje in nato preprosto zapustili aplikacijo. Izkazalo se je, da je prišlo do težave z UX: ko je oseba izbrala koledar, je morala klikniti Končano v zgornjem desnem kotu. Samo tega niso videli vsi uporabniki.

Kako je Retentioneering implementiran v App in the Air
Prvi zaslon App in the Air

Na našem grafu smo videli, da približno 30 % uporabnikov ne gre dlje od prvega zaslona: to je posledica dejstva, da smo precej agresivni pri spodbujanju uporabnika, da se naroči. Na prvem zaslonu vas aplikacija pozove, da se registrirate z Googlom ali Tripltom, in ni informacij o preskoku registracije. Od tistih, ki zapustijo prvi zaslon, 16 % uporabnikov klikne »Več« in se znova vrne. Ugotovili smo, da iščejo način za interno registracijo v aplikaciji in to bomo objavili v naslednji posodobitvi. Poleg tega 2/3 tistih, ki takoj odidejo, sploh ne kliknejo ničesar. Da bi ugotovili, kaj se z njimi dogaja, smo izdelali toplotni zemljevid. Izkazalo se je, da stranke klikajo na seznam funkcij aplikacije, ki niso povezave, ki jih je mogoče klikniti.

Ujemite mikrotrenutek

Pogosto lahko vidite ljudi, ki teptajo poti ob asfaltni cesti. Retentioneering je poskus najti te poti in, če je mogoče, spremeniti ceste.

Seveda je slabo, da se učimo od resničnih uporabnikov, a smo vsaj začeli samodejno slediti vzorcem, ki nakazujejo uporabniško težavo v aplikaciji. Zdaj produktni vodja prejme e-poštna obvestila, če pride do velikega števila "zank" – ko se uporabnik vedno znova vrača na isti zaslon.

Poglejmo, katere vzorce v poteh uporabnikov je na splošno zanimivo iskati za analizo težav in področij rasti aplikacije:

  • Zanke in cikli. Zgoraj omenjene zanke so, ko se en dogodek ponavlja na uporabnikovi poti, na primer koledar-koledar-koledar-koledar. Zanka z veliko ponavljanjem je jasen pokazatelj težave z vmesnikom ali nezadostnega označevanja dogodkov. Tudi cikel je zaprta trajektorija, vendar za razliko od zanke vključuje več kot en dogodek, na primer: ogled zgodovine letov - dodajanje leta - ogled zgodovine letov.
  • Flowstoppers - ko uporabnik zaradi neke ovire ne more nadaljevati želenega gibanja skozi aplikacijo, na primer zaslon z vmesnikom, ki odjemalcu ni očiten. Takšni dogodki upočasnijo in premaknejo pot uporabnikov.
  • Bifurkacijske točke so pomembni dogodki, po katerih se ločijo trajektorije strank različnih vrst. Predvsem so to zasloni, ki ne vsebujejo neposrednega prehoda ali poziva k dejanju na ciljno dejanje, kar nekatere uporabnike dejansko potiska k njemu. Na primer, nek zaslon, ki ni neposredno povezan z nakupom vsebine v aplikaciji, a na katerem so kupci nagnjeni k nakupu ali nekupovanju vsebine, se bo obnašal drugače. Bifurkacijske točke so lahko točke vpliva na dejanja vaših uporabnikov s predznakom plus - lahko vplivajo na odločitev o nakupu ali kliku ali znakom minus - lahko določijo, da bo po nekaj korakih uporabnik zapustil aplikacijo.
  • Prekinjene točke pretvorbe so možne bifurkacijske točke. Lahko si jih predstavljate kot zaslone, ki bi lahko spodbudili ciljno dejanje, vendar tega ne storite. To je lahko tudi trenutek, ko ima uporabnik potrebo, a je ne zadovoljimo, ker zanjo preprosto ne vemo. Analiza trajektorij bi morala omogočiti ugotovitev te potrebe.
  • Točka odvračanja pozornosti – zasloni/pojavna okna, ki uporabniku ne dajejo vrednosti, ne vplivajo na pretvorbo in lahko »zameglijo« trajektorije, kar uporabnika odvrne od ciljnih dejanj.
  • Slepe pege so skrite točke aplikacije, zaslonov in funkcij, ki jih uporabnik zelo težko doseže.
  • Odtoki – točke, kjer pušča promet

Na splošno nam je matematični pristop omogočil razumeti, da odjemalec uporablja aplikacijo na popolnoma drugačen način, kot si produktni vodje običajno mislijo, ko poskušajo načrtovati nek standardni scenarij uporabe za uporabnika. Ko sedite v pisarni in se udeležujete najbolj kul produktnih konferenc, si je še vedno zelo težko predstavljati vso raznolikost resničnih terenskih pogojev, v katerih bo uporabnik z uporabo aplikacije reševal svoje težave.

To me spominja na odlično šalo. Tester stopi v lokal in naroči: kozarec piva, 2 kozarca piva, 0 kozarcev piva, 999999999 kozarcev piva, kuščar v kozarcu, -1 kozarec piva, qwertyuip kozarcev piva. Prva prava stranka vstopi v lokal in vpraša, kje je stranišče. Bar zagori in vsi umrejo.

Produktni analitiki, globoko potopljeni v ta problem, so začeli uvajati koncept mikromomenta. Sodobni uporabnik potrebuje takojšnjo rešitev svojega problema. Google je o tem začel govoriti že pred nekaj leti: v podjetju so takšna uporabniška dejanja poimenovali mikrotrenutki. Uporabnik se zamoti, pomotoma zapre aplikacijo, ne razume, kaj se od njega zahteva, dan pozneje se znova prijavi, spet pozabi in nato sledi povezavi, ki mu jo je poslal prijatelj v messengerju. In vse te seje lahko trajajo največ 20 sekund.

Tako smo začeli poskušati vzpostaviti delo podporne službe tako, da bi lahko zaposleni skoraj v realnem času razumeli, v čem je težava. Do trenutka, ko oseba pride na stran za podporo in začne pisati svoje vprašanje, lahko ugotovimo bistvo problema, saj poznamo njegovo pot - zadnjih 100 dogodkov. Prej smo avtomatizirali distribucijo vseh zahtevkov za podporo v kategorije z uporabo ML analize besedil zahtevkov za podporo. Kljub uspehu kategorizacije, ko je 87% vseh zahtevkov pravilno razporejenih v eno od 13 kategorij, je delo s trajektorijami tisto, ki lahko samodejno najde najprimernejšo rešitev za situacijo uporabnika.

Posodobitev ne moremo izdati hitro, lahko pa opazimo težavo in mu, če uporabnik sledi scenariju, ki smo ga že videli, pošljemo potisno obvestilo.

Vidimo, da naloga optimizacije aplikacije zahteva bogata orodja za preučevanje poti uporabnikov. Nadalje, s poznavanjem vseh poti, ki jih ubirajo uporabniki, lahko utrete potrebne poti in s pomočjo prilagojene vsebine, potisnih obvestil in prilagodljivih elementov uporabniškega vmesnika »z roko« vodite uporabnika do ciljanih dejanj, ki najbolj ustrezajo njegovim potrebam in prinašajo denar , podatke in drugo vrednost za vaše podjetje.

Kaj je treba upoštevati

  • Preučevanje konverzij uporabnika samo na primeru tokov pomeni izgubo bogatih informacij, ki nam jih ponuja sama aplikacija.

  • Analiza zadrževanja uporabnikov na grafih vam pomaga videti, katere funkcije uporabljate, da obdržite uporabnike ali jih na primer spodbudite, da se naročijo.
  • Orodja za ohranjanje podatkov pomagajo samodejno, v realnem času, slediti vzorcem, ki kažejo na težave uporabnika v aplikaciji, najti in zapreti napake, kjer jih je bilo težko opaziti.

  • Pomagajo najti neočitne vzorce vedenja uporabnikov.

  • Orodja za zadrževanje omogočajo izdelavo avtomatiziranih orodij ML za napovedovanje ključnih uporabniških dogodkov in meritev: izguba uporabnikov, LTV in številne druge meritve, ki jih je enostavno določiti na grafu.

Okoli Retentioneeringa gradimo skupnost za brezplačno izmenjavo idej. Orodja, ki jih razvijamo, si lahko predstavljate kot jezik, v katerem lahko analitiki in izdelki iz različnih mobilnih in spletnih aplikacij izmenjujejo vpoglede, najboljše tehnike in metode. Na tečaju se lahko naučite uporabljati ta orodja Growth Hacking: analitika mobilnih aplikacij Binarno okrožje.

Vir: www.habr.com

Dodaj komentar