In brûker hâlde yn in mobile applikaasje is in hiele wittenskip. De skriuwer fan 'e kursus beskreau syn basis yn ús artikel op VC.ru Maxim Godzi, haad fan Machine Learning by App in the Air. Maxim fertelt oer de ark ûntwikkele yn it bedriuw mei help fan it foarbyld fan wurk oan analyze en optimalisaasje fan in mobile applikaasje. Dizze systematyske oanpak foar produktferbettering, ûntwikkele yn App in the Air, wurdt Retentioneering neamd. Jo kinne dizze ark brûke yn jo produkt: guon fan harren binne yn op GitHub.
App in the Air is in applikaasje mei mear as 3 miljoen aktive brûkers oer de hiele wrâld, wêrmei jo flechten kinne folgje, ynformaasje krije oer feroarings yn fertrek-/lâningstiden, check-in en fleanfjildkenmerken.
Fan trechter nei trajekt
Alle ûntwikkelingsteams bouwe in onboarding-trechter (in proses dat rjochte is op akseptaasje fan it produkt troch brûkers). Dit is de earste stap dy't jo helpt om it heule systeem fan boppen te besjen en applikaasjeproblemen te finen. Mar as it produkt ûntwikkelet, sille jo de beheiningen fan dizze oanpak fiele. Mei in ienfâldige trechter kinne jo net-foar de hân lizzende groeipunten foar in produkt sjen. It doel fan 'e trechter is om in algemiene blik te jaan op' e stadia fan brûkers yn 'e applikaasje, om jo de metriken fan' e noarm te sjen. Mar de trechter sil foarsichtich ferbergje ôfwikingen fan 'e noarm nei foar de hân lizzende problemen of, krekt oarsom, spesjale brûkersaktiviteit.
By App in the Air hawwe wy ús eigen trechter boud, mar troch de spesifikaasjes fan it produkt kamen wy útein mei in oereglas. Doe besleaten wy de oanpak út te wreidzjen en de rike ynformaasje te brûken dy't de applikaasje sels ús jout.
As jo in trechter bouwe, ferlieze jo de trajekten fan 'e brûker oan board. Trajekten besteane út in folchoarder fan aksjes troch de brûker en de applikaasje sels (bygelyks it ferstjoeren fan in push-notifikaasje).
Mei help fan tiidstempels kinne jo it trajekt fan 'e brûker heul maklik rekonstruearje en dêr in grafyk fan meitsje foar elk fan har. Fansels binne d'r in protte grafiken. Dêrom moatte jo ferlykbere brûkers groepearje. Jo kinne bygelyks alle brûkers op tabel rigen regelje en listje hoe faak se in bepaalde funksje brûke.
Op grûn fan sa'n tabel makken wy in matrix en groepearre brûkers troch frekwinsje fan gebrûk fan funksjes, dat is, troch knopen yn 'e grafyk. Dit is meastal de earste stap nei ynsjoch: jo sille bygelyks al op dit stadium sjen dat guon brûkers guon fan 'e funksjes hielendal net brûke. Doe't wy de frekwinsje-analyze diene, begûnen wy te ûndersykjen hokker knopen yn 'e grafyk de "grutste" binne, dat is, hokker siden brûkers it meast besykje. Kategoryen dy't fûneminteel ferskille neffens ien of oare kritearium dat foar jo wichtich is, wurde fuortendaliks markearre. Hjir binne bygelyks twa klusters fan brûkers dy't wy ferdield hawwe op basis fan it abonnemintsbeslút (d'r wiene yn totaal 16 klusters).
Hoe te brûken
Troch op dizze manier nei jo brûkers te sjen, kinne jo sjen hokker funksjes jo brûke om se te behâlden of, bygelyks, har oan te melden krije. Fansels sil de matrix ek dúdlike dingen sjen litte. Bygelyks dat dejingen dy't in abonnemint kocht hawwe it abonnemintskerm besocht. Mar njonken dit kinne jo ek patroanen fine dy't jo oars noait wisten.
Sa fûnen wy per ongeluk in groep brûkers dy't in flecht tafoegje, de hiele dei aktyf folgje en dan foar in lange tiid ferdwine oant se wer earne fleane. As wy har gedrach analysearje mei konvinsjonele ark, soene wy tinke dat se gewoan net tefreden wiene mei de funksjonaliteit fan 'e applikaasje: hoe kinne wy oars ferklearje dat se it ien dei brûkten en nea weromkamen. Mar mei help fan grafiken seagen wy dat se tige aktyf binne, it is gewoan dat al har aktiviteit yn ien dei past.
No is ús haadtaak om sa'n brûker oan te moedigjen om te ferbinen mei it loyaliteitsprogramma fan syn loftfeartmaatskippij wylst hy ús statistiken brûkt. Yn dit gefal sille wy alle flechten dy't hy keapet ymportearje en besykje him te triuwe om oan te melden sa gau as hy in nij kaartsje keapet. Om dit probleem op te lossen, begûnen wy ek gear te wurkjen mei Aviasales, Svyaznoy.Travel en oare applikaasjes. As har brûker in kaartsje keapet, freget de app har om de flecht ta te foegjen oan App in the Air, en wy sjogge it direkt.
Mei tank oan de grafyk seagen wy dat 5% fan minsken dy't nei it abonnemintsskerm geane it annulearje. Wy begûnen sokke gefallen te analysearjen, en seagen dat d'r in brûker is dy't nei de earste side giet, de ferbining fan syn Google-akkount inisjearret en it fuortdaliks annulearret, wer nei de earste side komt, ensafuorthinne. Earst tochten wy, "Der is dúdlik mis mei dizze brûker." En doe realisearre wy dat, nei alle gedachten, d'r wie in brek yn 'e applikaasje. Yn 'e trechter soe dit as folget ynterpretearre wurde: de brûker fûn de set fan tagongsrjochten net leuk dy't de applikaasje freget, en hy gie fuort.
In oare groep hie 5% fan brûkers ferlern gien op it skerm wêr't de app har freget ien te selektearjen fan alle kalinderapps op har smartphone. Brûkers soene ferskate kalinders hieltyd wer selektearje en dan gewoan de app ferlitte. It docht bliken dat d'r in UX-probleem wie: nei't in persoan in kalinder selektearde, moasten se klikke op dien yn 'e rjochter boppeste hoeke. It is gewoan dat net alle brûkers it seagen.
Earste skerm fan App in the Air
Yn ús grafyk seagen wy dat sawat 30% fan 'e brûkers net fierder gean as it earste skerm: dit komt troch it feit dat wy frij agressyf binne om de brûker te triuwen om te abonnearjen. Op it earste skerm freget de app jo om te registrearjen mei Google of Triplt, en d'r is gjin ynformaasje oer it oerslaan fan registraasje. Fan dejingen dy't it earste skerm ferlitte, klikke 16% fan brûkers op "Mear" en gean wer werom. Wy hawwe fûn dat se op syk binne nei in manier om yntern te registrearjen yn 'e applikaasje en wy sille it frijlitte yn' e folgjende update. Boppedat klikt 2/3 fan dejingen dy't fuort fuortgean hielendal neat. Om út te finen wat der mei har bart, hawwe wy in heatmap boud. It docht bliken dat klanten klikke op in list mei app-funksjes dy't gjin klikbere keppelings binne.
Fange in mikromomint
Jo kinne faak sjen dat minsken paden fertrape neist de asfaltdyk. Retentioneering is in besykjen om dizze paden te finen en, as it kin, de diken te feroarjen.
Fansels is it slim dat wy leare fan echte brûkers, mar teminsten begon wy automatysk patroanen te folgjen dy't in brûkersprobleem yn 'e applikaasje oanjaan. No ûntfangt de produktbehearder e-postnotifikaasjes as in grut oantal "loops" foarkomme - as de brûker hieltyd wer nei itselde skerm weromkomt.
Litte wy sjen nei hokker patroanen yn brûkerstrajekten oer it algemien ynteressant binne om te sykjen om problemen en groeigebieten fan in applikaasje te analysearjen:
- Loops en cycles. De hjirboppe neamde loops binne as ien evenemint werhellet yn it trajekt fan 'e brûker, bygelyks kalinder-kalinder-kalinder-kalinder. In loop mei in protte werhelling is in dúdlike yndikator fan in ynterface probleem of net genôch evenemint markearring. In syklus is ek in sletten trajekt, mar yn tsjinstelling ta in lus befettet it mear as ien evenemint, bygelyks: flechtskiednis besjen - in flecht tafoegje - flechtskiednis besjen.
- Flowstoppers - as de brûker, fanwege wat obstakel, syn winske beweging net trochgean kin troch de applikaasje, bygelyks in skerm mei in ynterface dy't net foar de klant dúdlik is. Sokke eveneminten fertrage en ferskowe it trajekt fan brûkers.
- Bifurkaasjepunten binne wichtige eveneminten wêrnei't de trajekten fan kliïnten fan ferskate soarten wurde skieden. Benammen dit binne skermen dy't gjin direkte oergong of oprop ta aksje nei de doelaksje befetsje, wat guon brûkers der effektyf nei triuwe. Bygelyks, guon skermen dat net direkt relatearre is oan it keapjen fan ynhâld yn in applikaasje, mar wêrop klanten oanstriid binne om ynhâld te keapjen of net te keapjen, sille har oars gedrage. Bifurkaasjepunten kinne punten fan ynfloed wêze op 'e aksjes fan jo brûkers mei in plusteken - se kinne ynfloed hawwe op it beslút om in oankeap te meitsjen of te klikken, as in minteken - se kinne bepale dat nei in pear stappen de brûker de applikaasje sil ferlitte.
- Abortearre konverzjepunten binne potinsjele bifurkaasjepunten. Jo kinne se tinke as skermen dy't in doelaksje kinne oanfreegje, mar net dwaan. Dit kin ek in momint wêze dat de brûker in need hat, mar wy befredigje it net om't wy der gewoan net fan witte. Trajectory analyze soe tastean dizze need te identifisearjen.
- Distraasjepunt - skermen / pop-ups dy't de brûker gjin wearde leverje, gjin konverzje beynfloedzje en trajekten "wazigje" kinne, de brûker ôfliede fan doelaksjes.
- Bline flekken binne ferburgen punten fan 'e applikaasje, skermen en funksjes dy't heul lestich binne foar de brûker te berikken.
- Drains - punten dêr't ferkear lekken
Yn 't algemien liet de wiskundige oanpak ús begripe dat de klant de applikaasje op in folslein oare manier brûkt as produktbehearders gewoanlik tinke as se besykje wat standert gebrûkssenario foar de brûker te plannen. Sittend op it kantoar en it bywenjen fan de coolste produktkonferinsjes, is it noch heul lestich om alle ferskaat oan echte fjildbetingsten foar te stellen wêryn de brûker syn problemen sil oplosse mei de applikaasje.
Dit docht my tinken oan in geweldige grap. In tester rint in bar yn en bestelt: in gleske bier, 2 glêzen bier, 0 glêzen bier, 999999999 glêzen bier, in ljip yn in gleske, -1 gleske bier, qwertyuip glêzen bier. De earste echte klant rint de bar yn en freget wêr't it toilet is. De bar baart yn flammen en elkenien stjert.
Produktanalisten, djip ûnderdompele yn dit probleem, begûnen it konsept fan in mikromomint yn te fieren. De moderne brûker hat in direkte oplossing nedich foar har probleem. Google begon hjir in pear jier lyn oer te praten: it bedriuw neamde sokke brûkersaksjes mikromominten. De brûker wurdt ôfleid, slút de applikaasje by ûngelok, begrypt net wat fan him fereaske is, logt in dei letter opnij oan, ferjit it wer, en folget dan de keppeling dy't in freon him yn 'e boadskipper stjoerde. En al dizze sesjes kinne net mear as 20 sekonden duorje.
Sa begûnen wy te besykjen om it wurk fan 'e stipetsjinst op te setten sadat meiwurkers begrepen wat it probleem hast yn echt wie. Tsjin 'e tiid dat in persoan nei de stipeside komt en syn fraach begjint te skriuwen, kinne wy de essinsje fan it probleem bepale, wittende syn trajekt - de lêste 100 eveneminten. Earder automatisearren wy de ferdieling fan alle stipe-oanfragen yn kategoryen mei ML-analyse fan 'e teksten fan stipe-oanfragen. Nettsjinsteande it súkses fan kategorisearring, as 87% fan alle oanfragen goed ferdield binne yn ien fan 'e 13 kategoryen, is it wurk mei trajekten dy't automatysk de meast geskikte oplossing fine kinne foar de situaasje fan 'e brûker.
Wy kinne gjin updates fluch frijjaan, mar wy kinne it probleem opmerke en, as de brûker it senario folget dat wy al sjoen hawwe, stjoer him in push-notifikaasje.
Wy sjogge dat de taak fan it optimalisearjen fan in applikaasje rike ark fereasket foar it bestudearjen fan brûkerstrajekten. Fierder kinne jo alle paden witte dy't brûkers nimme, en mei help fan oanpaste ynhâld kinne push-notifikaasjes en adaptive UI-eleminten "troch de hân" de brûker liede ta doelrjochte aksjes dy't it bêste passe by syn behoeften en jild bringe , gegevens en oare wearde foar jo bedriuw.
Wat te nimmen notysje
- It studearjen fan brûkerskonverzje allinich mei help fan trechters as foarbyld betsjuttet de rike ynformaasje te ferliezen dy't de applikaasje sels ús jout.
- Retentioneering-analyze fan brûkerstrajekten op grafiken helpt jo te sjen hokker funksjes jo brûke om brûkers te behâlden of, bygelyks, oan te moedigjen om te abonnearjen.
- Retentioneering-ark helpe automatysk, yn echte tiid, patroanen te folgjen dy't brûkersproblemen yn 'e applikaasje oanjaan, bugs te finen en te sluten wêr't se lestich op te merken wiene.
- Se helpe om net-foar de hân lizzende patroanen fan brûkersgedrach te finen.
- Retentioneering-ark meitsje it mooglik om automatisearre ML-ark te bouwen foar it foarsizzen fan wichtige brûkerseveneminten en metriken: brûkersferlies, LTV en in protte oare metriken dy't maklik wurde bepaald op 'e grafyk.
Wy bouwe in mienskip om Retentioneering hinne foar de frije útwikseling fan ideeën. Jo kinne tinke oan de ark dy't wy ûntwikkelje as in taal wêryn analisten en produkten fan ferskate mobile en webapplikaasjes ynsjoch, bêste techniken en metoaden kinne útwikselje. Jo kinne leare hoe't jo dizze ark brûke yn 'e kursus Binary District.
Boarne: www.habr.com