Teni uzanton en poŝtelefona aplikaĵo estas tuta scienco. La aŭtoro de la kurso priskribis ĝiajn bazojn en nia artikolo pri VC.ru Maxim Godzi, Estro de Maŝina Lernado ĉe App in the Air. Maxim parolas pri la iloj disvolvitaj en la kompanio uzante la ekzemplon de laboro pri analizo kaj optimumigo de movebla aplikaĵo. Ĉi tiu sistema aliro al produktoplibonigo, evoluigita en App in the Air, nomiĝas Retentioneering. Vi povas uzi ĉi tiujn ilojn en via produkto: kelkaj el ili estas en sur GitHub.
App in the Air estas aplikaĵo kun pli ol 3 milionoj da aktivaj uzantoj tra la mondo, per kiu vi povas spuri flugojn, ricevi informojn pri ŝanĝoj en la tempoj de foriro/alteriĝo, enregistriĝo kaj flughavenaj trajtoj.
De funelo al trajektorio
Ĉiuj evoluigaj teamoj konstruas enŝipigan funelon (procezo celita al uzantakcepto de la produkto). Ĉi tiu estas la unua paŝo, kiu helpas vin rigardi la tutan sistemon de supre kaj trovi aplikajn problemojn. Sed dum la produkto disvolviĝas, vi sentos la limojn de ĉi tiu aliro. Uzante simplan funelon, vi ne povas vidi ne-evidentajn kreskopunktojn por produkto. La celo de la funelo estas doni ĝeneralan rigardon al la stadioj de uzantoj en la aplikaĵo, por montri al vi la metrikojn de la normo. Sed la funelo prudente kaŝos deviojn de la normo al evidentaj problemoj aŭ, male, speciala uzant-agado.
Ĉe App in the Air, ni konstruis nian propran funelon, sed pro la specifaĵoj de la produkto, ni finis kun sablohorloĝo. Tiam ni decidis pligrandigi la aliron kaj uzi la riĉajn informojn, kiujn la aplikaĵo mem donas al ni.
Kiam vi konstruas funelon, vi perdas la uzantajn surbordajn trajektoriojn. Trajektorioj konsistas el sekvenco de agoj de la uzanto kaj la aplikaĵo mem (ekzemple, sendante puŝan sciigon).
Uzante tempomarkojn, vi povas tre facile rekonstrui la trajektorion de la uzanto kaj fari el ĝi grafikon por ĉiu el ili. Kompreneble, estas multaj grafikaĵoj. Tial vi devas grupigi similajn uzantojn. Ekzemple, vi povas aranĝi ĉiujn uzantojn per tabelvicoj kaj listigi kiom ofte ili uzas certan funkcion.
Surbaze de tia tabelo, ni faris matricon kaj grupigis uzantojn laŭ ofteco de uzo de funkcioj, tio estas, laŭ nodoj en la grafeo. Ĉi tio kutime estas la unua paŝo al komprenoj: ekzemple, jam en ĉi tiu etapo vi vidos, ke iuj uzantoj tute ne uzas iujn el la funkcioj. Kiam ni faris la frekvencan analizon, ni komencis studi, kiuj nodoj en la grafikaĵo estas la "plej grandaj", tio estas, kiujn paĝojn uzantoj vizitas plej ofte. Kategorioj fundamente malsamaj laŭ iu kriterio grava por vi estas tuj reliefigitaj. Jen, ekzemple, du aroj de uzantoj, kiujn ni dividis laŭ la abondecido (estis 16 aroj entute).
Kiel uzi ĝin
Rigardante viajn uzantojn tiamaniere, vi povas vidi kiajn funkciojn vi uzas por reteni ilin aŭ, ekzemple, igi ilin registriĝi. Nature, la matrico ankaŭ montros evidentajn aferojn. Ekzemple, ke tiuj kiuj aĉetis abonon vizitis la abonan ekranon. Sed krom ĉi tio, vi ankaŭ povas trovi ŝablonojn, pri kiuj vi neniam scius alie.
Do ni tute hazarde trovis grupon da uzantoj, kiuj aldonas flugon, aktive spuras ĝin dum la tuta tago kaj poste malaperas dum longa tempo ĝis ili denove flugas ien. Se ni analizus ilian konduton per konvenciaj iloj, ni pensus, ke ili simple ne kontentiĝis pri la funkcieco de la aplikaĵo: kiel alie ni povas klarigi, ke ili uzis ĝin dum unu tago kaj neniam revenis. Sed helpe de grafikaĵoj ni vidis, ke ili estas tre aktivaj, estas nur, ke ilia tuta agado konvenas en unu tagon.
Nun nia ĉefa tasko estas instigi tian uzanton konekti al la lojalecprogramo de sia flugkompanio dum li uzas niajn statistikojn. En ĉi tiu kazo, ni importos ĉiujn flugojn kiujn li aĉetas kaj provos puŝi lin registriĝi tuj kiam li aĉetos novan bileton. Por solvi ĉi tiun problemon, ni ankaŭ komencis kunlabori kun Aviasales, Svyaznoy.Travel kaj aliaj aplikoj. Kiam ilia uzanto aĉetas bileton, la aplikaĵo instigas ilin aldoni la flugon al App in the Air, kaj ni tuj vidas ĝin.
Danke al la grafikaĵo, ni vidis, ke 5% de homoj, kiuj iras al la ekrano de abono, nuligas ĝin. Ni komencis analizi tiajn kazojn, kaj vidis, ke estas uzanto, kiu iras al la unua paĝo, komencas la konekton de sia Guglo-konto, kaj tuj nuligas ĝin, denove venas al la unua paĝo, kaj tiel plu kvarfoje. Komence ni pensis, "Io klare misas kun ĉi tiu uzanto." Kaj tiam ni rimarkis, ke, plej verŝajne, estis cimo en la aplikaĵo. En la funelo, ĉi tio estus interpretita jene: la uzanto ne ŝatis la aron de permesoj, kiujn la aplikaĵo petas, kaj li foriris.
Alia grupo havis 5% de uzantoj perdiĝas sur la ekrano kie la programo instigas ilin elekti unu el ĉiuj kalendaraj apoj sur sia inteligenta telefono. Uzantoj elektus malsamajn kalendarojn denove kaj denove kaj poste simple elirus la apon. Montriĝas, ke estis problemo pri UX: post kiam persono elektis kalendaron, ili devis klaki Farita en la supra dekstra angulo. Nur ne ĉiuj uzantoj vidis ĝin.
Unua ekrano de App en la Aero
En nia grafiko, ni vidis, ke ĉirkaŭ 30% de uzantoj ne iras preter la unua ekrano: tio estas pro la fakto, ke ni estas sufiĉe agresemaj puŝante la uzanton por aboni. Sur la unua ekrano, la programo petas vin registri per Google aŭ Triplt, kaj ne ekzistas informoj pri transsalti registradon. El tiuj, kiuj forlasas la unuan ekranon, 16% de uzantoj alklakas "Pli" kaj revenas denove. Ni eksciis, ke ili serĉas manieron registri interne en la aplikaĵo kaj ni liberigos ĝin en la venonta ĝisdatigo. Krome, 2/3 el tiuj, kiuj tuj foriras, tute nenion klakas. Por ekscii, kio okazas al ili, ni konstruis varmmapon. Montriĝas, ke klientoj alklakas liston de aplikaj funkcioj, kiuj ne estas alklakeblaj ligiloj.
Kaptu mikro-momenton
Ofte oni povas vidi homojn tretantajn vojojn apud la asfalta vojo. Retenado estas provo trovi ĉi tiujn vojojn kaj, se eble, ŝanĝi la vojojn.
Kompreneble, estas malbone, ke ni lernas de realaj uzantoj, sed almenaŭ ni komencis aŭtomate spuri ŝablonojn, kiuj indikas uzantan problemon en la aplikaĵo. Nun la produktmanaĝero ricevas retpoŝtajn sciigojn se granda nombro da "bukloj" okazas—kiam la uzanto revenas al la sama ekrano denove kaj denove.
Ni rigardu kiajn ŝablonojn en uzanttrajektorioj estas ĝenerale interesaj serĉi por analizi problemojn kaj kreskareojn de aplikaĵo:
- Bukloj kaj cikloj. La cikloj menciitaj supre estas kiam unu evento ripetas en la trajektorio de la uzanto, ekzemple kalendaro-kalendaro-kalendaro-kalendaro. Buklo kun multe da ripetado estas klara indikilo de interfaca problemo aŭ nesufiĉa evento-markado. Ciklo ankaŭ estas fermita trajektorio, sed male al buklo ĝi inkluzivas pli ol unu eventon, ekzemple: vidi flughistorion - aldono de flugo - rigardante flughistorion.
- Flowstoppers - kiam la uzanto, pro iu malhelpo, ne povas daŭrigi sian deziratan movadon tra la aplikaĵo, ekzemple ekrano kun interfaco, kiu ne estas evidenta por la kliento. Tiaj eventoj malrapidiĝas kaj ŝanĝas la trajektorion de uzantoj.
- Forkiĝopunktoj estas signifaj okazaĵoj post kiuj la trajektorioj de klientoj de malsamaj tipoj estas apartigitaj. Aparte, ĉi tiuj estas ekranoj, kiuj ne enhavas rektan transiron aŭ alvokon al la cela ago, efike puŝante kelkajn uzantojn al ĝi. Ekzemple, iu ekrano, kiu ne rekte rilatas al aĉetado de enhavo en aplikaĵo, sed sur kiu klientoj emas aĉeti aŭ ne aĉeti enhavon, kondutos alimaniere. Forkpunktoj povas esti punktoj de influo sur la agoj de viaj uzantoj kun plus-signo - ili povas influi la decidon fari aĉeton aŭ klaki, aŭ minus-signon - ili povas determini, ke post kelkaj paŝoj la uzanto forlasos la aplikaĵon.
- Ĉesigitaj konvertaj punktoj estas eblaj forkpunktoj. Vi povas pensi pri ili kiel ekranoj, kiuj povus instigi celan agon, sed ne faras. Ĉi tio ankaŭ povus esti momento en kiu la uzanto havas bezonon, sed ni ne kontentigas ĝin ĉar ni simple ne scias pri ĝi. Trajektoria analizo devus permesi tiun bezonon esti identigita.
- Distra punkto - ekranoj/pop-ups, kiuj ne donas valoron al la uzanto, ne influas konvertiĝon kaj povas "malklarigi" trajektoriojn, distrante la uzanton de celaj agoj.
- Blindpunktoj estas kaŝitaj punktoj de la aplikaĵo, ekranoj kaj funkcioj, kiujn la uzanto estas tre malfacile atingeblaj.
- Dreniloj - punktoj kie trafiko likas
Ĝenerale, la matematika aliro permesis al ni kompreni, ke la kliento uzas la aplikaĵon en tute malsama maniero ol produktmanaĝeroj kutime pensas kiam ili provas plani iun norman uzscenaron por la uzanto. Sidante en la oficejo kaj partoprenante la plej bonegajn produktajn konferencojn, estas ankoraŭ tre malfacile imagi ĉiujn diversajn realajn kampajn kondiĉojn, en kiuj la uzanto solvos siajn problemojn uzante la aplikaĵon.
Ĉi tio memorigas min pri bonega ŝerco. Testisto eniras drinkejon kaj ordigas: glason da biero, 2 glasojn da biero, 0 glasojn da biero, 999999999 glasojn da biero, lacerto en glaso, -1 glason da biero, qwertyuip glasojn da biero. La unua vera kliento eniras la drinkejon kaj demandas kie estas la necesejo. La drinkejo eksplodas en flamojn kaj ĉiuj mortas.
Produktanalizistoj, profunde mergitaj en ĉi tiu problemo, komencis enkonduki la koncepton de mikromomento. La moderna uzanto bezonas tujan solvon al sia problemo. Guglo komencis paroli pri tio antaŭ kelkaj jaroj: la kompanio nomis tiajn uzantajn agojn mikro-momentoj. La uzanto distriĝas, hazarde fermas la aplikaĵon, ne komprenas, kio estas postulata de li, denove ensalutas tagon poste, denove forgesas, kaj poste sekvas la ligilon, kiun sendis al li amiko en la mesaĝisto. Kaj ĉiuj ĉi tiuj kunsidoj povas daŭri ne pli ol 20 sekundojn.
Do ni komencis provi agordi la laboron de la helpservo por ke dungitoj povu kompreni, kio estas la problemo preskaŭ en reala tempo. Kiam homo venas al la subtena paĝo kaj komencas skribi sian demandon, ni povas determini la esencon de la problemo, sciante sian trajektorion - la lastajn 100 eventojn. Antaŭe, ni aŭtomatigis la distribuadon de ĉiuj subtenaj petoj en kategoriojn uzante ML-analizon de la tekstoj de subtenaj petoj. Malgraŭ la sukceso de kategoriigo, kiam 87% de ĉiuj petoj estas ĝuste distribuitaj en unu el la 13 kategorioj, ĝi estas laboro kun trajektorioj, kiuj aŭtomate povas trovi la plej taŭgan solvon por la situacio de la uzanto.
Ni ne povas liberigi ĝisdatigojn rapide, sed ni povas rimarki la problemon kaj, se la uzanto sekvas la scenaron, kiun ni jam vidis, sendu al li puŝan sciigon.
Ni vidas, ke la tasko optimumigi aplikaĵon postulas riĉajn ilojn por studi uzantajn trajektoriojn. Plue, konante ĉiujn vojojn, kiujn uzantoj prenas, vi povas pavimi la necesajn vojojn, kaj kun la helpo de personigita enhavo, puŝaj sciigoj kaj adaptaj UI-elementoj "permane" kondukas la uzanton al celitaj agoj, kiuj plej taŭgas al liaj bezonoj kaj alportas monon. , datumoj kaj alia valoro por via komerco.
Kion noti
- Studi uzantan konvertiĝon nur uzante funelojn kiel ekzemplon signifas perdi la riĉan informon, kiun la aplikaĵo mem donas al ni.
- Konserva analizo de uzanttrajektorioj sur grafikaĵoj helpas vin vidi kiujn funkciojn vi uzas por reteni uzantojn aŭ, ekzemple, instigi ilin aboni.
- Retenaj iloj helpas aŭtomate, en reala tempo, spuri ŝablonojn, kiuj indikas uzantproblemojn en la aplikaĵo, trovi kaj fermi cimojn kie ili estis malfacile rimarkeblaj.
- Ili helpas trovi ne-evidentajn ŝablonojn de uzantkonduto.
- Retenaj iloj ebligas konstrui aŭtomatigitajn ML-ilojn por antaŭdiri ŝlosilajn uzantajn eventojn kaj metrikojn: uzantperdo, LTV kaj multaj aliaj metrikoj, kiuj estas facile determinitaj sur la grafikaĵo.
Ni konstruas komunumon ĉirkaŭ Retentioneering por la libera interŝanĝo de ideoj. Vi povas pensi pri la iloj, kiujn ni disvolvas, kiel lingvo, en kiu analizistoj kaj produktoj de malsamaj poŝtelefonaj kaj retaj aplikaĵoj povas interŝanĝi komprenojn, plej bonajn teknikojn kaj metodojn. Vi povas lerni kiel uzi ĉi tiujn ilojn en la kurso Binara Distrikto.
fonto: www.habr.com