Internetis on sadu artikleid klientide käitumise analüüsimise eeliste kohta. Enamasti puudutab see jaemüügisektorit. Alates toidukorvi analüüsist, ABC ja XYZ analüüsist kuni säilitamisturunduse ja personaalsete pakkumisteni. Erinevaid tehnikaid on kasutatud aastakümneid, algoritmid on läbi mõeldud, kood kirjutatud ja silutud - võta ja kasuta. Meie puhul tekkis üks põhimõtteline probleem – me ISPsystemis tegeleme tarkvaraarendusega, mitte jaemüügiga.
Minu nimi on Denis ja vastutan praegu ISPsystemi analüütiliste süsteemide taustaprogrammi eest. Ja see on lugu sellest, kuidas mina ja mu kolleeg — andmete visualiseerimise eest vastutajad — püüdsid vaadelda meie tarkvaratooteid läbi nende teadmiste prisma. Alustame, nagu tavaliselt, ajaloost.
Alguses oli sõna ja sõna oli "Kas proovime?"
Sel hetkel töötasin arendajana R&D osakonnas. Kõik sai alguse sellest, et Danil luges siin Habrest — tööriist kasutajate üleminekute analüüsimiseks rakendustes. Olin selle siin kasutamise idee suhtes mõnevõrra skeptiline. Näidetena tõid raamatukogu arendajad rakenduste analüüsi, kus oli selgelt määratletud sihttegevus – tellimuse esitamine või mõni muu variatsioon, kuidas omanikfirmale tasuda. Meie tooteid tarnitakse kohapeal. See tähendab, et kasutaja ostab esmalt litsentsi ja alles seejärel alustab oma teekonda rakenduses. Jah, meil on demoversioonid. Seal saad toodet proovida, et põrsast kotis ei oleks.
Kuid enamik meie tooteid on suunatud hostimisturule. Tegemist on suurklientidega ja äriarenduse osakond nõustab neid tootevõimaluste osas. Sellest järeldub ka see, et meie kliendid teavad juba ostuhetkel, milliseid probleeme meie tarkvara neil lahendada aitab. Nende marsruudid rakenduses peavad kattuma tootesse manustatud CJM-iga ja UX-lahendused aitavad neil õigel teel püsida. Spoiler: seda ei juhtu alati. Raamatukogu tutvustus lükkus edasi... aga mitte kauaks.
Kõik muutus meie käivitusettevõtte vabastamisega - — platvormid veebipoe loomiseks Instagrami kontolt. Selles rakenduses anti kasutajale kahenädalane periood kõigi funktsioonide tasuta kasutamiseks. Seejärel tuli otsustada, kas tellida. Ja see sobib suurepäraselt „marsruudi sihtmärgi tegevuse” kontseptsiooniga. Otsustati: proovime!
Esimesed tulemused ehk kust ideid ammutada
Ühendasime arendusmeeskonnaga toote ürituste kogumissüsteemiga sõna otseses mõttes päevaga. Ütlen kohe, et ISPsystem kasutab lehekülastuste kohta sündmuste kogumiseks oma süsteemi, kuid miski ei takista teil samadel eesmärkidel kasutamast Yandex.Metricat, mis võimaldab algandmeid tasuta üles laadida. Uuriti näiteid raamatukogu kasutamisest ja pärast nädalast andmete kogumist saime üleminekugraafiku.
Üleminekugraafik. Põhifunktsioonid, selguse huvides eemaldatud muud üleminekud
Tuli välja nagu näites: tasapinnaline, selge, ilus. Sellelt graafikult suutsime tuvastada kõige sagedasemad marsruudid ja ülekäigukohad, kus inimesed veedavad kõige kauem aega. See võimaldas meil mõista järgmist:
- Suure CJM-i asemel, mis hõlmab tosinat üksust, kasutatakse aktiivselt vaid kahte. UX lahendusi kasutades on vaja täiendavalt suunata kasutajaid meile vajalikesse kohtadesse.
- Mõned lehed, mille UX-i disainerid on kujundanud täielikuks, kulutavad inimesed neile ebamõistlikult palju aega. Peate välja mõtlema, millised peatuselemendid on konkreetsel lehel, ja neid kohandama.
- Pärast 10 üleminekut hakkas 20% inimestest väsima ja lõpetas rakenduse seansi. Ja see võtab arvesse asjaolu, et meil oli rakenduses koguni 5 liitumislehte! Peate tuvastama lehed, kus kasutajad regulaarselt seanssidest loobuvad, ja lühendama teed nendeni. Veelgi parem: tuvastage kõik tavalised marsruudid ja võimaldage kiiret üleminekut lähtelehelt sihtlehele. Midagi ühist ABC analüüsi ja mahajäetud käru analüüsiga, kas sa ei arva?
Ja siin vaatasime uuesti läbi oma suhtumise selle tööriista rakendatavuse kohta kohapealsete toodete puhul. Otsustati analüüsida aktiivselt müüdud ja kasutatud toodet - . See on palju keerulisem, üksusi on suurusjärgu võrra rohkem. Ootasime põnevusega, milliseks üleminekugraafik kujuneb.
Pettumustest ja inspiratsioonist
Pettumus nr 1
Oli korraga nii tööpäeva lõpp, kuu lõpp kui ka aasta lõpp - 27. detsember. Andmeid on kogunenud, päringuid kirjutatud. Alles oli jäänud sekundeid enne, kui kõik oli töödeldud ja saime vaadata oma töö tulemust, et teada saada, kust järgmine tööaasta algab. Uurimis- ja arendusosakond, tootejuht, kasutajakogemuse disainerid, meeskonna juht, arendajad kogunesid monitori ette, et näha, millised kasutajateed nende tootes välja näevad, kuid... nägime seda:
Retentioneeringu raamatukogu loodud üleminekugraafik
Inspiratsioon nr 1
Tugevalt seotud, kümned üksused, ebaselged stsenaariumid. Oli vaid selge, et uus tööaasta ei alga mitte analüüsiga, vaid sellise graafikuga töö lihtsustamise viisi leiutamisega. Kuid ma ei saanud lahti tundest, et kõik oli palju lihtsam, kui tundus. Ja pärast viisteist minutit Retentioneeringu lähtekoodi uurimist saime koostatud graafiku eksportida punktivormingusse. See võimaldas graafiku üles laadida teise tööriista - Gephisse. Ja graafikute analüüsimiseks on juba ruumi: paigutused, filtrid, statistika - piisab, kui seadistada liideses vajalikud parameetrid. Selle mõttega lahkusime aastavahetuse nädalavahetusele.
Pettumus nr 2
Pärast tööle naasmist selgus, et sel ajal, kui kõik puhkasid, uurisid meie kliendid toodet. Jah, nii kõvasti, et hoidlasse ilmusid sündmused, mida varem polnud. See tähendas, et päringuid oli vaja värskendada.
Natuke tausta, et mõista selle tõsiasja kurbust. Edastame nii meie poolt märgitud sündmused (näiteks mõnel nupul klõpsamised) kui ka nende lehtede URL-e, mida kasutaja külastas. Cartbee puhul töötas mudel “üks tegevus – üks leht”. Kuid VMmanageriga oli olukord täiesti erinev: ühel lehel võis avaneda mitu modaalset akent. Nendes sai kasutaja lahendada erinevaid probleeme. Näiteks URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
tähendab, et lehele "IP-aadressid" lisas kasutaja IP-aadressi. Ja siin on korraga näha kaks probleemi:
- URL sisaldab mingit teeparameetrit – virtuaalmasina ID-d. See tuleb välistada.
- URL sisaldab modaalse akna ID-d. Peate sellised URL-id kuidagi lahti pakkima.
Teine probleem oli see, et just nendel sündmustel, mille me tähistasime, olid parameetrid. Näiteks loendist virtuaalmasina kohta teabega lehele pääsemiseks oli viis erinevat võimalust. Vastavalt saadeti üks sündmus, kuid parameetriga, mis näitas, millisel meetodil kasutaja ülemineku tegi. Selliseid üritusi oli palju ja kõik parameetrid olid erinevad. Ja meil on kogu Clickhouse'i SQL-i dialekti andmete otsimise loogika. 150–200 rea pikkused päringud hakkasid tunduma üsna tavalised. Probleemid ümbritsesid meid.
Inspiratsioon nr 2
Ühel varahommikul soovitas Danil teist minutit nukralt päringut sirvida: "Kirjutame andmetöötluse torujuhtmeid?" Mõtlesime selle üle ja otsustasime, et kui me seda tegema hakkame, siis oleks see midagi ETL-i sarnast. Nii et see filtreerib kohe ja tõmbab vajalikud andmed teistest allikatest üles. Nii sündis meie esimene täisväärtusliku taustaprogrammiga analüüsiteenus. See rakendab andmetöötluse viit peamist etappi:
- Sündmuste laadimine algandmete salvestuselt ja ettevalmistamine töötlemiseks.
- Selgitamine on just nende modaalakende identifikaatorite, sündmuse parameetrite ja muude sündmust selgitavate üksikasjade "lahtipakkimine".
- Rikastamine (sõnast "rikkaks saamiseks") on sündmuste lisamine kolmandate osapoolte allikatest pärit andmetega. Sel ajal hõlmas see ainult meie arveldussüsteemi BILLmanager.
- Filtreerimine on analüüsi tulemusi moonutavate sündmuste (sündmused sisemistest stendidelt, kõrvalekalded jne) välja filtreerimine.
- Vastuvõetud sündmuste üleslaadimine salvestusruumi, mida nimetasime puhasteks andmeteks.
Nüüd oli võimalik asjakohasust säilitada, lisades reegleid sündmuse või isegi sarnaste sündmuste rühmade töötlemiseks. Näiteks pole me sellest ajast saati kordagi URL-i lahtipakkimist värskendanud. Kuigi selle aja jooksul on lisatud mitu uut URL-i variatsiooni. Need vastavad teenuses juba kehtestatud reeglitele ja neid töödeldakse korrektselt.
Pettumus nr 3
Kui hakkasime analüüsima, mõistsime, miks graafik oli nii sidus. Fakt on see, et peaaegu iga N-gramm sisaldas üleminekuid, mida ei saanud liidese kaudu läbi viia.
Algas väike juurdlus. Mind ajas segadusse, et ühe üksuse sees polnud võimatuid üleminekuid. See tähendab, et tegemist ei ole sündmuste kogumissüsteemi ega meie ETL-teenuse veaga. Tekkis tunne, et kasutaja töötas korraga mitmes olemis, liikumata ühelt teisele. Kuidas seda saavutada? Erinevate vahekaartide kasutamine brauseris.
Cartbeed analüüsides päästis meid selle spetsiifilisus. Rakendust kasutati mobiilseadmetest, kus mitmelt vahekaardilt töötamine on lihtsalt ebamugav. Siin on meil töölaud ja kui ühes olemis ülesannet täidetakse, on mõistlik kulutada see aeg mõnes teises olemis seadistamisele või oleku jälgimisele. Ja selleks, et edusamme mitte kaotada, avage lihtsalt teine vahekaart.
Inspiratsioon nr 3
Kolleegid esiotsa arendusest õpetasid sündmuste kogumise süsteemi vahekaarte eristama. Analüüs võis alata. Ja me alustasime. Ootuspäraselt ei vastanud CJM tegelikele teedele: kasutajad veetsid palju aega kataloogilehtedel, mahajäetud seanssidel ja vahekaartidel kõige ootamatumates kohtades. Üleminekuanalüüsi kasutades leidsime mõnes Mozilla järgus probleeme. Neis kadusid juurutusfunktsioonide tõttu navigeerimiselemendid või kuvati pooltühjad lehed, millele peaks ligi pääsema ainult administraator. Leht avanes, kuid taustaprogrammist sisu ei tulnud. Üleminekute loendamine võimaldas hinnata, milliseid funktsioone tegelikult kasutati. Ketid võimaldasid aru saada, kuidas kasutaja selle või teise vea sai. Kasutaja käitumise põhjal testimiseks lubatud andmed. See oli edukas, idee polnud asjata.
Analüüsi automatiseerimine
Ühes tulemuste demonstratsioonis näitasime, kuidas Gephit graafikute analüüsiks kasutatakse. Selles tööriistas saab konversiooniandmeid kuvada tabelis. Ja UX-i osakonna juhataja ütles ühe väga olulise mõtte, mis mõjutas ettevõttes kogu käitumisanalüütika suuna arengut: "Teeme sama, aga Tableaus ja filtritega - see on mugavam."
Siis mõtlesin: miks mitte, Retentioneering salvestab kõik andmed pandas.DataFrame struktuuri. Ja see on üldiselt laud. Nii ilmus teine teenus: Andmepakkuja. Ta mitte ainult ei koostanud graafikust tabelit, vaid arvutas ka välja, kui populaarne on leht ja sellega seotud funktsionaalsus, kuidas see mõjutab kasutajate hoidmist, kui kaua kasutajad sellel püsivad ja millistelt lehtedelt kasutajad kõige sagedamini lahkuvad. Ja visualiseerimise kasutamine Tableaus vähendas graafiku uurimise kulusid nii palju, et toote käitumisanalüüsi iteratsiooniaeg vähenes peaaegu poole võrra.
Danil räägib, kuidas seda visualiseerimist kasutatakse ja milliseid järeldusi see teha võimaldab.
Rohkem laudu lauajumalale!
Lihtsustatud kujul sõnastati ülesanne järgmiselt: kuvada üleminekugraafik Tableau's, pakkuda filtreerimisvõimalust ning muuta see võimalikult selgeks ja mugavaks.
Ma ei tahtnud Tableau's suunatud graafikut joonistada. Ja isegi kui see õnnestus, ei tundunud kasu Gephiga võrreldes ilmne. Vajasime midagi palju lihtsamat ja kättesaadavamat. Laud! Graafi saab ju hõlpsasti esitada tabeliridadena, kus iga rida on “allika-sihtkoha” tüüpi serv. Lisaks oleme sellise tabeli juba hoolikalt koostanud, kasutades Retentioneering ja Data Provider tööriistu. Ei jäänud muud üle, kui tabel Tableaus välja panna ja aruandes tuhnida.
Rääkides sellest, kuidas kõik lauad armastavad.
Siin seisame aga silmitsi teise probleemiga. Mida teha andmeallikaga? Panda.DataFrame'i ühendamine oli võimatu; Tableau'l sellist pistikut pole. Graafiku talletamiseks eraldi aluse tõstmine tundus liiga radikaalne ja ebamääraste väljavaadetega lahendus. Ja kohalikud mahalaadimisvõimalused ei sobinud pidevate käsitsitoimingute vajaduse tõttu. Vaatasime läbi saadaolevate pistikute loendi ja meie pilk langes esemele , kes küürus igavalt päris põhjas.
Tableaul on rikkalik valik pistikuid. Leidsime ühe, mis lahendas meie probleemi
Milline loom? Mõned uued avatud vahelehed brauseris – ja sai selgeks, et see konnektor võimaldab teil URL-ile juurde pääsedes andmeid vastu võtta. Andmete arvutamise taustaprogramm ise oli peaaegu valmis, jäi vaid see WDC-ga sõbraks teha. Denis uuris mitu päeva dokumentatsiooni ja võitles Tableau mehhanismidega ning saatis siis mulle lingi, mille kleepisin ühenduse aknasse.
Ühendusvorm meie WDC-ga. Denis tegi oma esiosa ja hoolitses ohutuse eest
Pärast paariminutilist ootamist (andmed arvutatakse nõudmisel dünaamiliselt) ilmus tabel:
Nii näeb toorandmete massiiv Tableau liideses välja
Nagu lubatud, kujutas sellise tabeli iga rida graafiku serva, st kasutaja suunatud üleminekut. See sisaldas ka mitmeid lisaomadusi. Näiteks unikaalsete kasutajate arv, üleminekute koguarv ja muud.
Seda tabelit oleks võimalik aruandes kuvada nii, nagu see on, filtreid heldelt puistata ja tööriista teele saata. Kõlab loogiliselt. Mida saate lauaga teha? Kuid see pole meie tee, sest me ei tee lihtsalt tabelit, vaid analüüsi ja tooteotsuste langetamise tööriista.
Tavaliselt soovib inimene andmeid analüüsides saada küsimustele vastuseid. Suurepärane. Alustame nendega.
- Millised on kõige sagedasemad üleminekud?
- Kuhu need konkreetsetelt lehtedelt lähevad?
- Kui kaua kulutate keskmiselt sellel lehel enne lahkumist?
- Kui sageli teete üleminekut punktist A punkti B?
- Millistel lehtedel seanss lõpeb?
Iga aruanne või nende kombinatsioon peaks võimaldama kasutajal neile küsimustele iseseisvalt vastuseid leida. Peamine strateegia on anda teile tööriistad, et seda ise teha. See on kasulik nii analüütikaosakonna koormuse vähendamiseks kui ka otsuste langetamiseks kuluva aja vähendamiseks – pole ju enam vaja Youtracki minna ja analüütikule ülesannet luua, vaid aruanne tuleb avada.
Mida me saime?
Kus inimesed armatuurlaualt kõige sagedamini kõrvale kalduvad?
Fragment meie aruandest. Pärast armatuurlauda läksid kõik kas VM-ide loendisse või sõlmede loendisse
Võtame üldise tabeli üleminekutega ja filtreerime lähtelehe järgi. Enamasti lähevad need armatuurlaualt virtuaalmasinate loendisse. Veelgi enam, veerg Regulaarsus viitab sellele, et tegemist on korduva toiminguga.
Kust nad tulevad klastrite nimekirja?
Aruannete filtrid töötavad mõlemas suunas: saate teada, kust lahkusite või kuhu läksite
Näidetest on selge, et isegi kahe lihtsa filtri olemasolu ja väärtuste järjestamine võimaldab teil kiiresti teavet hankida.
Küsime midagi raskemat.
Kus kasutajad oma seansi kõige sagedamini katkestavad?
VMmanageri kasutajad töötavad sageli eraldi vahekaartidel
Selleks vajame aruannet, mille andmed on koondatud viiteallikate kaupa. Ja ülesandena võeti nn murdepunkte – sündmusi, mis olid üleminekute ahela lõpuks.
Siinkohal on oluline märkida, et see võib olla kas seansi lõpp või uue vahelehe avamine. Näide näitab, et kett lõpeb enamasti tabeliga, kus on virtuaalmasinate loend. Sel juhul on iseloomulik käitumine teisele vahekaardile lülitumine, mis on kooskõlas eeldatava mustriga.
Eelkõige testisime nende aruannete kasulikkust enda peal, kui tegime analüüsi sarnasel viisil , veel üks meie toode. Tabelite ja filtrite tulekuga kontrolliti hüpoteese kiiremini ja silmad väsisid vähem.
Aruannete väljatöötamisel ei unustanud me visuaalset kujundust. Sellise suurusega tabelitega töötamisel on see oluline tegur. Näiteks kasutasime rahulikku värvivalikut, kergesti tajutav numbrite puhul joonte värviline esiletõstmine vastavalt tunnuste arvväärtustele. Sellised detailid parandavad kasutajakogemust ja suurendavad tõenäosust, et tööriist ettevõttes edukalt lendu läheb.
Tabel osutus üsna mahukaks, kuid loodame, et see pole lakanud olemast loetav
Eraldi tasub mainida meie siseklientide koolitust: tootespetsialistid ja UX disainerid. Nende jaoks koostati spetsiaalselt juhendid analüüsinäidete ja filtritega töötamise näpunäidetega. Lisasime lingid juhenditele otse aruannete lehtedele.
Tegime juhendi lihtsalt Google Docsi esitlusena. Tabelitööriistad võimaldavad teil kuvada veebilehti otse aruande töövihikus.
asemel epiloog
Mis on alumisel real? Suhteliselt kiiresti ja soodsalt saime töövahendi igaks päevaks. Jah, see ei asenda kindlasti graafikut ennast, klikkide soojuskaarti ega veebivaaturit. Kuid sellised aruanded täiendavad märkimisväärselt loetletud tööriistu ja pakuvad mõtlemisainet ning uusi toote ja liidese hüpoteese.
See lugu oli ainult ISP-süsteemi analüütika arendamise algus. Viimase poole aasta jooksul on ilmunud veel seitse uut teenust, sealhulgas tootes olevad kasutaja digitaalsed portreed ja teenus Look-alike-sihtimise andmebaaside loomiseks, kuid neist räägime järgmistes osades.
Allikas: www.habr.com