Hvernig varðveisla er útfærð í App in the Air

Hvernig varðveisla er útfærð í App in the Air

Að halda notanda í farsímaforriti er heil vísindi. Höfundur námskeiðsins lýsti grunnatriðum þess í grein okkar á VC.ru Growth Hacking: greiningar á farsímaforritum Maxim Godzi, yfirmaður vélanáms hjá App in the Air. Maxim talar um verkfærin sem þróuð eru í fyrirtækinu með því að nota dæmi um vinnu við greiningu og hagræðingu á farsímaforriti. Þessi kerfisbundna nálgun að endurbótum á vörum, þróuð í App in the Air, er kölluð Retentioneering. Þú getur notað þessi verkfæri í vörunni þinni: sum þeirra eru í ókeypis aðgangur á GitHub.

App in the Air er forrit með meira en 3 milljón virkum notendum um allan heim, með því er hægt að fylgjast með flugi, fá upplýsingar um breytingar á brottfarar-/lendingartíma, innritun og flugvallareiginleika.

Frá trekt til brautar

Öll þróunarteymi búa til inngöngutrekt (ferli sem miðar að því að notendur samþykkja vöruna). Þetta er fyrsta skrefið sem hjálpar þér að skoða allt kerfið ofan frá og finna forritunarvandamál. En þegar varan þróast muntu finna fyrir takmörkunum á þessari nálgun. Með því að nota einfalda trekt geturðu ekki séð óljósa vaxtarpunkta fyrir vöru. Tilgangur trektarinnar er að gefa almenna yfirsýn yfir stig notenda í forritinu, til að sýna þér mæligildi normsins. En trektin mun skynsamlega fela frávik frá norminu í átt að augljósum vandamálum eða þvert á móti sérstakri notendavirkni.

Hvernig varðveisla er útfærð í App in the Air

Við hjá App in the Air smíðuðum okkar eigin trekt en vegna sérstakra vörunnar enduðum við með stundaglas. Þá ákváðum við að útvíkka nálgunina og nota þær ríkulegu upplýsingar sem forritið sjálft gefur okkur.

Þegar þú býrð til trekt missir þú feril notandans um borð. Ferlar samanstanda af röð aðgerða af notandanum og forritinu sjálfu (til dæmis að senda ýtt tilkynningu).

Hvernig varðveisla er útfærð í App in the Air

Með því að nota tímastimpla geturðu á mjög auðveldan hátt endurbyggt feril notandans og búið til línurit úr honum fyrir hvern þeirra. Auðvitað eru til fullt af línuritum. Þess vegna þarftu að flokka svipaða notendur. Til dæmis er hægt að raða öllum notendum eftir töflulínum og skrá hversu oft þeir nota ákveðna aðgerð.

Hvernig varðveisla er útfærð í App in the Air

Út frá slíkri töflu gerðum við fylki og flokkuðum notendur eftir notkunartíðni aðgerða, það er að segja eftir hnútum á línuritinu. Þetta er venjulega fyrsta skrefið í átt að innsýn: til dæmis, þegar á þessu stigi muntu sjá að sumir notendur nota sumar aðgerðirnar alls ekki. Þegar við gerðum tíðnigreininguna fórum við að rannsaka hvaða hnútar á grafinu eru „stærstir“, það er að segja hvaða síður notendur heimsækja oftast. Flokkar sem eru í grundvallaratriðum ólíkir í samræmi við einhverja viðmiðun sem er mikilvæg fyrir þig eru strax auðkenndir. Hér eru til dæmis tveir notendaklasar sem við skiptum með hliðsjón af áskriftarákvörðuninni (það voru alls 16 klasar).

Hvernig varðveisla er útfærð í App in the Air

Hvernig á að nota það

Með því að skoða notendur þína með þessum hætti geturðu séð hvaða eiginleika þú notar til að halda þeim eða til dæmis fá þá til að skrá sig. Auðvitað mun fylkið líka sýna augljósa hluti. Til dæmis að þeir sem keyptu áskrift heimsóttu áskriftarskjáinn. En fyrir utan þetta geturðu líka fundið mynstur sem þú hefðir aldrei vitað um annars.

Þannig að við fundum algjörlega óvart hóp af notendum sem bæta við flugi, fylgjast með því virkan allan daginn og hverfa svo í langan tíma þar til þeir fljúga eitthvert aftur. Ef við greindum hegðun þeirra með hefðbundnum verkfærum, myndum við halda að þeir væru einfaldlega ekki ánægðir með virkni forritsins: hvernig getum við annars útskýrt að þeir hafi notað það í einn dag og aldrei komið aftur. En með hjálp línurita sáum við að þeir eru mjög virkir, það er bara að öll virkni þeirra passar inn á einn dag.

Nú er aðalverkefni okkar að hvetja slíkan notanda til að tengjast vildarkerfi flugfélags síns á meðan hann notar tölfræði okkar. Í þessu tilviki munum við flytja inn allt flug sem hann kaupir og reyna að ýta á hann til að skrá sig um leið og hann kaupir nýjan miða. Til að leysa þetta vandamál byrjuðum við einnig að vinna með Aviasales, Svyaznoy.Travel og öðrum forritum. Þegar notandi þeirra kaupir miða biður appið þá um að bæta fluginu við App in the Air og við sjáum það strax.

Þökk sé línuritinu sáum við að 5% þeirra sem fara á áskriftarskjáinn hætta því. Við byrjuðum að greina slík tilvik og sáum að það er notandi sem fer á fyrstu síðu, kemur af stað tengingu á Google reikningi sínum og hættir því strax, kemst á fyrstu síðu aftur og svo framvegis fjórum sinnum. Í fyrstu hugsuðum við: "Það er greinilega eitthvað að þessum notanda." Og þá komumst við að því að líklega var villa í forritinu. Í trektinni yrði þetta túlkað sem hér segir: notandanum líkaði ekki heimildasamstæðan sem forritið biður um og hann fór.

Annar hópur lét 5% notenda týnast á skjánum þar sem appið biður þá um að velja einn úr öllum dagatalsforritum snjallsímans. Notendur myndu velja mismunandi dagatöl aftur og aftur og hætta svo einfaldlega í appinu. Það kemur í ljós að það var UX vandamál: eftir að einstaklingur valdi dagatal þurfti hann að smella á Lokið efst í hægra horninu. Það er bara að ekki allir notendur sáu það.

Hvernig varðveisla er útfærð í App in the Air
Fyrsti skjárinn af App in the Air

Í línuritinu okkar sáum við að um 30% notenda fara ekki út fyrir fyrsta skjáinn: þetta er vegna þess að við erum frekar árásargjarn í að ýta notandanum til að gerast áskrifandi. Á fyrsta skjánum biður appið þig um að skrá þig með Google eða Triplt og engar upplýsingar eru um að sleppa skráningu. Af þeim sem yfirgefa fyrsta skjáinn smella 16% notenda á „Meira“ og snúa aftur. Við höfum komist að því að þeir eru að leita að leið til að skrá sig innbyrðis í forritinu og við munum gefa það út í næstu uppfærslu. Auk þess klikka 2/3 þeirra sem fara strax ekki neitt. Til að komast að því hvað er að gerast hjá þeim smíðuðum við hitakort. Það kemur í ljós að viðskiptavinir eru að smella á lista yfir appeiginleika sem eru ekki smellanlegir tenglar.

Fangaðu ör augnablik

Oft má sjá fólk troða stíga við malbikaðan veg. Varðveisla er tilraun til að finna þessar leiðir og, ef hægt er, breyta vegum.

Auðvitað er slæmt að við lærum af raunverulegum notendum, en við byrjuðum að minnsta kosti að rekja sjálfkrafa mynstur sem gefa til kynna notendavandamál í forritinu. Nú fær vörustjórinn tilkynningar í tölvupósti ef mikill fjöldi „lykkja“ á sér stað—þegar notandinn snýr aftur og aftur á sama skjáinn.

Við skulum skoða hvaða mynstur í notendaferlum er almennt áhugavert að leita að til að greina vandamál og vaxtarsvið forrits:

  • Lykkjur og hringrásir. Lykkjurnar sem nefndar eru hér að ofan eru þegar einn atburður endurtekur sig á ferli notandans, td dagatal-dagatal-dagatal-dagatal. Lykka með miklum endurtekningum er skýr vísbending um viðmótsvandamál eða ófullnægjandi atburðamerkingu. Hringrás er líka lokuð braut, en ólíkt lykkju inniheldur hún fleiri en einn atburð, til dæmis: að skoða flugsögu - bæta við flugi - skoða flugsögu.
  • Flæðistopparar - þegar notandinn, vegna einhverrar hindrunar, getur ekki haldið áfram æskilegri hreyfingu sinni í gegnum forritið, til dæmis skjá með viðmóti sem er ekki augljóst fyrir viðskiptavininn. Slíkir atburðir hægja á og breyta feril notenda.
  • Tvískiptingarpunktar eru mikilvægir atburðir þar sem ferill viðskiptavina af mismunandi gerðum er aðskilinn. Einkum eru þetta skjáir sem innihalda ekki bein umskipti eða ákall til aðgerða til markaðgerðarinnar, sem ýtir í raun sumum notendum í átt að henni. Til dæmis mun einhver skjár sem tengist ekki efniskaupum í forriti beint en þar sem viðskiptavinir hafa tilhneigingu til að kaupa eða ekki kaupa efni hegða sér öðruvísi. Tvískiptapunktar geta verið áhrifapunktar á aðgerðir notenda þinna með plúsmerki - þeir geta haft áhrif á ákvörðun um að kaupa eða smella, eða mínusmerki - þeir geta ákveðið að eftir nokkur skref mun notandinn yfirgefa forritið.
  • Hættir umbreytingarpunktar eru hugsanlegir klofningspunktar. Þú getur hugsað um þá sem skjái sem gætu hvatt til markaðgerðar, en ekki. Þetta gæti líka verið tími þar sem notandinn hefur þörf, en við fullnægjum henni ekki vegna þess að við vitum einfaldlega ekki um það. Ferilgreining ætti að gera kleift að greina þessa þörf.
  • Truflunarpunktur - skjáir/sprettigluggar sem veita notandanum ekki gildi, hafa ekki áhrif á viðskipti og geta „óskýrt“ feril og truflað notandann frá markaðgerðum.
  • Blindir blettir eru faldir punktar forritsins, skjáir og eiginleikar sem er mjög erfitt fyrir notandann að ná í.
  • Niðurföll – staðir þar sem umferð lekur

Almennt séð gerði stærðfræðiaðferðin okkur kleift að skilja að viðskiptavinurinn notar forritið á allt annan hátt en vörustjórar halda venjulega þegar þeir reyna að skipuleggja staðlaða notkunaratburðarás fyrir notandann. Þegar þú situr á skrifstofunni og sækir flottustu vöruráðstefnurnar er samt mjög erfitt að ímynda sér allar hinar ýmsu raunverulegu aðstæður þar sem notandinn mun leysa vandamál sín með því að nota forritið.

Þetta minnir mig á frábæran brandara. Prófari gengur inn á bar og pantar: bjórglas, 2 bjórglös, 0 bjórglös, 999999999 bjórglös, eðla í glasi, -1 bjórglas, qwertyuip bjórglös. Fyrsti alvöru viðskiptavinurinn gengur inn á barinn og spyr hvar salernið sé. Barinn logar og allir deyja.

Vörusérfræðingar, djúpt á kafi í þessu vandamáli, byrjuðu að kynna hugmyndina um örstund. Nútíma notandi þarf tafarlausa lausn á vandamáli sínu. Google byrjaði að tala um þetta fyrir nokkrum árum: Fyrirtækið kallaði slíkar notendaaðgerðir örstundir. Notandinn verður annars hugar, lokar forritinu óvart, skilur ekki hvað er krafist af honum, skráir sig inn aftur degi síðar, gleymir aftur og fylgir svo hlekknum sem vinur sendi honum í boðberanum. Og allar þessar lotur geta ekki varað lengur en 20 sekúndur.

Við fórum því að reyna að stilla starfi stoðþjónustunnar upp þannig að starfsmenn gætu áttað sig á vandamálinu nánast í rauntíma. Þegar einstaklingur kemur á stuðningssíðuna og byrjar að skrifa spurningu sína, getum við ákvarðað kjarna vandamálsins, þekkjum feril hans - síðustu 100 atburðina. Áður gerðum við sjálfvirka dreifingu allra stuðningsbeiðna í flokka með því að nota ML greiningu á texta stuðningsbeiðna. Þrátt fyrir árangur af flokkun, þegar 87% allra beiðna er rétt dreift í einn af 13 flokkunum, er það vinna með feril sem getur sjálfkrafa fundið hentugustu lausnina fyrir aðstæður notandans.

Við getum ekki gefið út uppfærslur fljótt, en við getum tekið eftir vandamálinu og, ef notandinn fylgir atburðarásinni sem við höfum þegar séð, sendu honum ýtt tilkynningu.

Við sjáum að það verkefni að fínstilla forrit krefst ríkra verkfæra til að rannsaka feril notenda. Ennfremur, með því að þekkja allar leiðirnar sem notendur fara, geturðu ryðjað nauðsynlegar slóðir og með hjálp sérsniðins efnis, ýtt tilkynningar og aðlögunarviðmótsþættir „við höndina“ leiða notandann til markvissra aðgerða sem henta best þörfum hans og skila peningum. , gögn og önnur verðmæti fyrir fyrirtækið þitt.

Hvað ber að taka eftir

  • Að rannsaka notendaviðskipti eingöngu með því að nota trekt sem dæmi þýðir að tapa ríkulegum upplýsingum sem forritið sjálft gefur okkur.

  • Varðveislugreining á ferlum notenda á línuritum hjálpar þér að sjá hvaða eiginleika þú notar til að halda notendum eða, til dæmis, hvetja þá til að gerast áskrifendur.
  • Varðveisluverkfæri hjálpa sjálfkrafa, í rauntíma, að rekja mynstur sem gefa til kynna vandamál notenda í forritinu, finna og loka villum þar sem erfitt var að taka eftir þeim.

  • Þeir hjálpa til við að finna óljós hegðunarmynstur notenda.

  • Retentioneering verkfæri gera það mögulegt að smíða sjálfvirk ML verkfæri til að spá fyrir um lykilatburði og mælikvarða notenda: tap notenda, LTV og margar aðrar mælikvarðar sem auðvelt er að ákvarða á línuritinu.

Við erum að byggja upp samfélag í kringum Retentioneering fyrir frjáls hugmyndaskipti. Þú getur hugsað þér verkfærin sem við erum að þróa sem tungumál þar sem sérfræðingar og vörur frá mismunandi farsíma- og vefforritum geta skipt á innsýn, bestu tækni og aðferðum. Þú getur lært hvernig á að nota þessi verkfæri á námskeiðinu Growth Hacking: greiningar á farsímaforritum Tvöfaldur hverfi.

Heimild: www.habr.com

Bæta við athugasemd