Internete yra šimtai straipsnių apie klientų elgesio analizės naudą. Dažniausiai tai liečia mažmeninės prekybos sektorių. Nuo maisto krepšelio analizės, ABC ir XYZ analizės iki išlaikymo rinkodaros ir asmeninių pasiūlymų. Dešimtmečius naudojamos įvairios technikos, apgalvoti algoritmai, parašytas kodas ir derinamas – imk ir naudokis. Mūsų atveju iškilo viena esminė problema – mes ISPsystem užsiimame programinės įrangos kūrimu, o ne mažmenine prekyba.
Mano vardas Denisas ir šiuo metu esu atsakingas už ISPsystem analitinių sistemų užpakalinę dalį. Ir tai yra istorija apie tai, kaip aš ir mano kolega — tie, kurie atsakingi už duomenų vizualizavimą — bandė pažvelgti į mūsų programinės įrangos produktus per šių žinių prizmę. Pradėkime, kaip įprasta, nuo istorijos.
Pradžioje buvo žodis, o žodis buvo "Pabandysime?"
Tuo metu dirbau kūrėju MTEP skyriuje. Viskas prasidėjo, kai Danilas skaitė čia apie Habré — įrankis, skirtas naudotojų perėjimams programose analizuoti. Aš kiek skeptiškai žiūrėjau į idėją jį panaudoti čia. Kaip pavyzdžius bibliotekos kūrėjai nurodė programų analizę, kur buvo aiškiai apibrėžtas tikslinis veiksmas – užsakymo pateikimas ar koks kitas variantas, kaip atsiskaityti įmonės savininkei. Mūsų gaminiai tiekiami vietoje. Tai yra, vartotojas pirmiausia nusiperka licenciją ir tik tada pradeda savo kelionę programoje. Taip, mes turime demonstracines versijas. Galite išbandyti produktą ten, kad neliktų kiaulės kišenėje.
Tačiau dauguma mūsų produktų yra skirti prieglobos rinkai. Tai stambūs klientai, verslo plėtros skyrius konsultuoja juos dėl produkto galimybių. Tai taip pat reiškia, kad pirkimo metu mūsų klientai jau žino, kokias problemas jiems padės išspręsti mūsų programinė įranga. Jų maršrutai programoje turi sutapti su CJM, įterptu į gaminį, o UX sprendimai padės jiems neatsilikti. Spoileris: taip nutinka ne visada. Įžanga į biblioteką buvo nukelta... bet neilgam.
Viskas pasikeitė išleidus mūsų startuolį - — platformos, skirtos sukurti internetinę parduotuvę iš Instagram paskyros. Šioje programoje vartotojui buvo suteiktas dviejų savaičių laikotarpis nemokamai naudotis visomis funkcijomis. Tada reikėjo nuspręsti, ar užsiprenumeruoti. Ir tai puikiai tinka „maršruto-taikinio veiksmo“ koncepcijai. Buvo nuspręsta: pabandykime!
Pirmieji rezultatai arba iš kur semtis idėjų
Kūrimo komanda ir aš prijungėme produktą prie renginių surinkimo sistemos tiesiogine prasme per dieną. Iš karto pasakysiu, kad ISPsistema naudoja savo sistemą įvykiams apie apsilankymus puslapyje rinkti, tačiau niekas netrukdo tiems patiems tikslams naudoti „Yandex.Metrica“, kuri leidžia nemokamai atsisiųsti neapdorotus duomenis. Buvo ištirti bibliotekos naudojimo pavyzdžiai ir po savaitės duomenų rinkimo gavome pereinamąjį grafiką.
Perėjimo grafikas. Pagrindinės funkcijos, kiti perėjimai pašalinti aiškumo dėlei
Išėjo kaip ir pavyzdyje: plokštu, aišku, gražu. Iš šio grafiko galėjome nustatyti dažniausiai pasitaikančius maršrutus ir perėjas, kuriose žmonės praleidžia ilgiausiai. Tai leido mums suprasti šiuos dalykus:
- Vietoj didelio CJM, apimančio keliolika subjektų, aktyviai naudojami tik du. Būtina papildomai nukreipti vartotojus į mums reikalingas vietas naudojant UX sprendimus.
- Kai kuriuose puslapiuose, kuriuos UX dizaineriai sukūrė taip, kad jie būtų išsamūs, žmonės juose praleidžia nepagrįstai daug laiko. Turite išsiaiškinti, kokie stabdymo elementai yra konkrečiame puslapyje, ir juos pakoreguoti.
- Po 10 perėjimų 20% žmonių pradėjo pavargti ir išėjo iš programos seanso. Ir tai atsižvelgiama į tai, kad programoje turėjome net 5 prisijungimo puslapius! Turite nustatyti puslapius, kuriuose naudotojai reguliariai atsisako seansų, ir sutrumpinti kelią iki jų. Dar geriau: nustatykite įprastus maršrutus ir leiskite greitai pereiti iš šaltinio puslapio į paskirties puslapį. Kažkas bendro su ABC analize ir apleista krepšelio analize, ar nemanote?
Ir čia mes pergalvojome savo požiūrį į šio įrankio pritaikymą vietiniams gaminiams. Buvo nuspręsta išanalizuoti aktyviai parduodamą ir naudojamą prekę - . Tai daug sudėtingesnė, yra daug daugiau subjektų. Su nekantrumu laukėme, koks bus perėjimo grafikas.
Apie nusivylimus ir įkvėpimus
Nusivylimas #1
Buvo darbo dienos pabaiga, mėnesio pabaiga ir metų pabaiga vienu metu – gruodžio 27 d. Sukaupti duomenys, parašytos užklausos. Liko kelios sekundės, kol viskas buvo apdorota, ir mes galėjome pažvelgti į savo darbo rezultatus, kad sužinotume, kur prasidės kiti darbo metai. Mokslinių tyrimų ir plėtros skyrius, produkto vadovas, UX dizaineriai, komandos vadovas, kūrėjai susirinko priešais monitorių, norėdami pamatyti, kaip atrodo jų produkto naudotojo keliai, bet... mes pamatėme tai:
Perėjimo grafikas, sukurtas Retentioneering bibliotekos
Įkvėpimas #1
Tvirtai susiję, dešimtys subjektų, neakivaizdūs scenarijai. Buvo tik aišku, kad naujieji darbymetiai prasidės ne analize, o būdo supaprastinimo tokiu grafiku išradimu. Tačiau negalėjau atsikratyti jausmo, kad viskas daug paprasčiau, nei atrodė. Ir po penkiolikos minučių išstudijavę Retentioneering šaltinio kodą, galėjome eksportuoti sukurtą grafiką į taško formatą. Tai leido įkelti grafiką į kitą įrankį – Gephi. Ir jau yra erdvės analizuoti grafikus: maketus, filtrus, statistiką – tereikia sąsajoje sukonfigūruoti reikiamus parametrus. Su tokia mintimi išvažiavome į Naujųjų metų savaitgalį.
Nusivylimas #2
Grįžus į darbą paaiškėjo, kad kol visi ilsėjosi, mūsų klientai studijavo produktą. Taip, taip sunkiai, kad saugykloje atsirado įvykių, kurių anksčiau nebuvo. Tai reiškė, kad užklausas reikėjo atnaujinti.
Šiek tiek informacijos, kad suprastumėte šio fakto liūdesį. Perduodame ir mūsų pažymėtus įvykius (pavyzdžiui, kai kurių mygtukų paspaudimus), ir puslapių, kuriuose vartotojas lankėsi, URL adresus. „Cartbee“ atveju veikė modelis „vienas veiksmas – vienas puslapis“. Tačiau su VMmanager situacija buvo visiškai kitokia: viename puslapyje galėjo atsidaryti keli modaliniai langai. Juose vartotojas galėjo išspręsti įvairias problemas. Pavyzdžiui, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
reiškia, kad puslapyje „IP adresai“ vartotojas pridėjo IP adresą. Ir čia iškart matomos dvi problemos:
- URL yra tam tikras kelio parametras - virtualios mašinos ID. Jį reikia atmesti.
- URL yra modalinio lango ID. Reikia kažkaip „išpakuoti“ tokius URL.
Kita problema buvo ta, kad patys įvykiai, kuriuos pažymėjome, turėjo parametrus. Pavyzdžiui, buvo penki skirtingi būdai patekti į puslapį su informacija apie virtualią mašiną iš sąrašo. Atitinkamai buvo išsiųstas vienas įvykis, bet su parametru, nurodnčiu, kokiu būdu vartotojas atliko perėjimą. Tokių renginių buvo daug, ir visi parametrai buvo skirtingi. Ir mes turime visą „Clickhouse“ duomenų gavimo logiką SQL dialektu. 150–200 eilučių užklausos pradėjo atrodyti įprastos. Mus supo problemos.
Įkvėpimas #2
Vieną ankstyvą rytą Danilas, antrą minutę liūdnai slinkdamas per užklausą, man pasiūlė: „Parašykime duomenų apdorojimo konvejerius? Pagalvojome ir nusprendėme, kad jei tai darysime, tai bus kažkas panašaus į ETL. Kad jis būtų nedelsiant filtruojamas ir iš kitų šaltinių paima reikiamus duomenis. Taip gimė mūsų pirmoji analitinė paslauga su visaverte backend. Ji įgyvendina penkis pagrindinius duomenų apdorojimo etapus:
- Įvykių iškrovimas iš neapdorotų duomenų saugyklos ir paruošimas apdorojimui.
- Paaiškinimas yra tų pačių modalinių langų identifikatorių, įvykių parametrų ir kitų detalių, kurios paaiškina įvykį, „išpakavimas“.
- Praturtinimas (iš žodžio „tapimas turtingu“) yra įvykių papildymas duomenimis iš trečiųjų šalių šaltinių. Tuo metu tai apėmė tik mūsų atsiskaitymo sistemą BILLmanager.
- Filtravimas – tai įvykių, iškreipiančių analizės rezultatus (įvykiai iš vidinių stendų, iškrypėlių ir kt.), filtravimo procesas.
- Gautų įvykių įkėlimas į saugyklą, kurį pavadinome švariais duomenimis.
Dabar buvo galima išlaikyti aktualumą pridedant įvykio ar net panašių įvykių grupių apdorojimo taisykles. Pavyzdžiui, nuo tada mes niekada neatnaujinome URL išpakavimo. Tačiau per tą laiką buvo pridėta keletas naujų URL variantų. Jie atitinka jau tarnyboje nustatytas taisykles ir yra tinkamai apdorojami.
Nusivylimas #3
Pradėję analizuoti supratome, kodėl grafikas toks nuoseklus. Faktas yra tas, kad beveik kiekviename N grame buvo perėjimų, kurių nebuvo galima atlikti per sąsają.
Prasidėjo nedidelis tyrimas. Buvau sutrikęs, kad viename subjekte nebuvo neįmanomų perėjimų. Tai reiškia, kad tai nėra įvykių rinkimo sistemos ar mūsų ETL paslaugos klaida. Buvo jausmas, kad vartotojas vienu metu dirba keliuose subjektuose, nejudėdamas iš vieno į kitą. Kaip tai pasiekti? Skirtingų skirtukų naudojimas naršyklėje.
Analizuojant „Cartbee“, mus išgelbėjo jos specifiškumas. Programa buvo naudojama iš mobiliųjų įrenginių, kur dirbti iš kelių skirtukų tiesiog nepatogu. Čia mes turime darbalaukį ir kol užduotis atliekama viename objekte, tikslinga šį laiką skirti kito būsenos nustatymui ar stebėjimui. Ir kad neprarastumėte pažangos, tiesiog atidarykite kitą skirtuką.
Įkvėpimas #3
Kolegos iš front-end kūrimo išmokė įvykių rinkimo sistemą atskirti skirtukus. Analizė gali prasidėti. Ir mes pradėjome. Kaip ir tikėtasi, CJM neatitiko tikrų kelių: vartotojai daug laiko praleido prie katalogų puslapių, apleistų seansų ir skirtukų netikėčiausiose vietose. Naudodami perėjimo analizę, kai kuriose „Mozilla“ versijose galėjome rasti problemų. Juose dėl diegimo ypatybių dingo naršymo elementai arba buvo rodomi pustušti puslapiai, kurie turėtų būti prieinami tik administratoriui. Puslapis atidarytas, bet joks turinys neatėjo iš užpakalinės programos. Perėjimų skaičiavimas leido įvertinti, kurios funkcijos iš tikrųjų buvo naudojamos. Grandinės leido suprasti, kaip vartotojas gavo tą ar kitą klaidą. Duomenys leidžiami testuoti pagal naudotojo elgesį. Tai pavyko, idėja nenuėjo veltui.
Analitikos automatizavimas
Vienoje iš rezultatų demonstravimo parodėme, kaip Gephi naudojamas grafikų analizei. Šiame įrankyje konversijų duomenys gali būti rodomi lentelėje. O UX skyriaus vadovas pasakė vieną labai svarbią mintį, turėjusią įtakos visos elgsenos analizės krypties plėtrai įmonėje: „Darykime taip pat, bet Tableau ir su filtrais – bus patogiau“.
Tada pagalvojau: kodėl gi ne, Retentioneering saugo visus duomenis pandas.DataFrame struktūroje. Ir tai iš esmės yra stalas. Taip atsirado dar viena paslauga: Duomenų teikėjas. Iš grafiko jis ne tik sudarė lentelę, bet ir apskaičiavo, koks puslapis ir su juo susijęs funkcionalumas yra populiarus, kaip tai įtakoja vartotojų išlaikymą, kiek laiko vartotojai jame išbūna, iš kurių puslapių vartotojai dažniausiai išeina. Ir vizualizacijos naudojimas Tableau sumažino grafiko tyrimo išlaidas tiek, kad produkto elgesio analizės iteracijos laikas buvo beveik perpus mažesnis.
Danilas kalbės apie tai, kaip ši vizualizacija naudojama ir kokias išvadas ji leidžia padaryti.
Daugiau staliukų stalo dievui!
Supaprastinta forma užduotis buvo suformuluota taip: rodyti perėjimo grafiką Tableau, suteikti galimybę filtruoti ir padaryti jį kuo aiškesnį ir patogesnį.
Aš tikrai nenorėjau piešti nukreipto grafiko Tableau. Ir net jei pasisekė, pelnas, palyginti su Gephi, neatrodė akivaizdus. Mums reikėjo kažko daug paprastesnio ir prieinamesnio. Stalas! Galų gale, grafiką galima lengvai pavaizduoti lentelės eilučių pavidalu, kur kiekviena eilutė yra „šaltinis-paskirties“ tipo kraštas. Be to, tokią lentelę jau kruopščiai paruošėme naudodami Retentioneering ir Data Provider įrankius. Liko tik iškabinti lentelę Tableau ir pasinerti į ataskaitą.
Kalbant apie tai, kaip visi mėgsta stalus.
Tačiau čia susiduriame su kita problema. Ką daryti su duomenų šaltiniu? Neįmanoma prijungti pandų. DataFrame Tableau neturi tokios jungties. Atskiros bazės kėlimas grafikui saugoti atrodė pernelyg radikalus sprendimas su miglotomis perspektyvomis. O vietinės iškrovimo galimybės nebuvo tinkamos dėl nuolatinių rankinių operacijų poreikio. Peržiūrėjome galimų jungčių sąrašą ir mūsų žvilgsnis nukrypo į prekę , kuris gailiai glaudėsi pačiame apačioje.
„Tableau“ turi gausų jungčių pasirinkimą. Radome vieną, kuri išsprendė mūsų problemą
Koks gyvūnas? Keletas naujų atidarytų skirtukų naršyklėje – ir tapo aišku, kad ši jungtis leidžia gauti duomenis, kai pasiekiate URL. Pati duomenų skaičiavimo backend buvo beveik paruošta, beliko tik susidraugauti su WDC. Keletą dienų Denisas studijavo dokumentaciją ir kovojo su Tableau mechanizmais, o tada atsiuntė man nuorodą, kurią įklijavau į ryšio langą.
Prisijungimo prie mūsų WDC forma. Denisas padarė savo priekį ir pasirūpino saugumu
Po kelių minučių laukimo (pareikalavus duomenys skaičiuojami dinamiškai), pasirodė lentelė:
Taip atrodo neapdorotų duomenų masyvas „Tableau“ sąsajoje
Kaip ir buvo žadėta, kiekviena tokios lentelės eilutė reiškė grafiko kraštą, tai yra nukreiptą vartotojo perėjimą. Jame taip pat buvo keletas papildomų savybių. Pavyzdžiui, unikalių vartotojų skaičius, bendras perėjimų skaičius ir kt.
Šią lentelę būtų galima ataskaitoje rodyti tokią, kokia yra, dosniai pabarstyti filtrais ir išsiųsti įrankį. Skamba logiškai. Ką galite padaryti su stalu? Bet tai ne mūsų kelias, nes kuriame ne šiaip lentelę, o įrankį analizei ir produktų sprendimams priimti.
Paprastai analizuodamas duomenis žmogus nori gauti atsakymus į klausimus. Puiku. Pradėkime nuo jų.
- Kokie yra dažniausiai perėjimai?
- Kur jie patenka iš konkrečių puslapių?
- Kiek vidutiniškai laiko praleidžiate šiame puslapyje prieš išeidami?
- Kaip dažnai pereinate iš A į B?
- Kuriuose puslapiuose sesija baigiasi?
Kiekviena ataskaita arba jų derinys turėtų leisti vartotojui savarankiškai rasti atsakymus į šiuos klausimus. Pagrindinė strategija yra suteikti jums įrankius, kad galėtumėte tai padaryti patys. Tai naudinga tiek mažinant analitikos skyriaus apkrovą, tiek sutrumpinant sprendimų priėmimo laiką – juk nebereikia eiti į Youtrack ir kurti užduoties analitikui, tereikia atsidaryti ataskaitą.
Ką mes gavome?
Kur žmonės dažniausiai nukrypsta nuo prietaisų skydelio?
Mūsų ataskaitos fragmentas. Po prietaisų skydelio visi nuėjo arba į VM sąrašą, arba į mazgų sąrašą
Paimkime bendrą lentelę su perėjimais ir filtruokite pagal šaltinio puslapį. Dažniausiai jie pereina iš prietaisų skydelio į virtualių mašinų sąrašą. Be to, stulpelis Taisyklingumas rodo, kad tai pasikartojantis veiksmas.
Iš kur jie patenka į klasterių sąrašą?
Ataskaitų filtrai veikia abiem kryptimis: galite sužinoti, kur išvykote arba kur nuėjote
Iš pavyzdžių aišku, kad net du paprasti filtrai ir reitingavimo eilutės pagal vertes leidžia greitai gauti informaciją.
Paklauskime kažko sunkesnio.
Kur vartotojai dažniausiai atsisako seanso?
VMmanager vartotojai dažnai dirba atskiruose skirtukuose
Norėdami tai padaryti, mums reikia ataskaitos, kurios duomenys yra apibendrinti pagal persiuntimo šaltinius. O vadinamieji lūžio taškai buvo imami kaip užduotys – įvykiai, kurie tarnavo kaip perėjimų grandinės pabaiga.
Čia svarbu pažymėti, kad tai gali būti seanso pabaiga arba naujo skirtuko atidarymas. Pavyzdys rodo, kad grandinė dažniausiai baigiasi prie lentelės su virtualių mašinų sąrašu. Šiuo atveju būdingas elgesys yra perjungimas į kitą skirtuką, kuris atitinka numatomą modelį.
Šių ataskaitų naudingumą visų pirma išbandėme patys, kai atlikome analizę panašiu būdu , kitas mūsų produktas. Atsiradus lentelėms ir filtrams, hipotezės buvo patikrintos greičiau, akys mažiau pavargdavo.
Kurdami ataskaitas nepamiršome ir vizualinio dizaino. Dirbant su tokio dydžio lentelėmis, tai yra svarbus veiksnys. Pavyzdžiui, naudojome ramią, lengvai suvokiamą spalvų gamą skaičiams, linijų spalvinis paryškinimas pagal skaitines charakteristikų reikšmes. Tokios detalės pagerina vartotojo patirtį ir padidina tikimybę, kad įrankis sėkmingai įsibėgės įmonėje.
Lentelė pasirodė gana didelė, tačiau tikimės, kad ji nenustojo būti skaitoma
Atskirai verta paminėti mūsų vidinių klientų: produktų specialistų ir UX dizainerių mokymus. Specialiai jiems buvo parengti vadovai su analizės pavyzdžiais ir patarimais, kaip dirbti su filtrais. Nuorodas į vadovus įdėjome tiesiai į ataskaitų puslapius.
Vadovą sukūrėme tiesiog kaip pristatymą „Google“ dokumentuose. Lentelės įrankiai leidžia rodyti tinklalapius tiesiai ataskaitos darbaknygėje.
vietoj Epilogas
Kas yra apatinėje eilutėje? Palyginti greitai ir pigiai galėjome gauti po įrankį kiekvienai dienai. Taip, tai tikrai nepakeičia paties grafiko, paspaudimų karščio žemėlapio ar žiniatinklio peržiūros priemonės. Tačiau tokios ataskaitos gerokai papildo išvardytas priemones ir suteikia peno apmąstymams bei naujų produktų ir sąsajų hipotezėms.
Ši istorija pasitarnavo tik kaip analitikos kūrimo IPT sistemoje pradžia. Per pastaruosius šešis mėnesius pasirodė dar septynios naujos paslaugos, įskaitant skaitmeninius vartotojo portretus gaminyje ir duomenų bazių kūrimo paslaugą, skirtą „Look-alike“ taikymui, tačiau apie jas kalbėsime kituose epizoduose.
Šaltinis: www.habr.com