Estas centoj da artikoloj en la Interreto pri la avantaĝoj de analizo de klienta konduto. Plej ofte tio koncernas la podetala sektoro. De analizo pri manĝkorbo, analizo ABC kaj XYZ ĝis retena merkatado kaj personaj ofertoj. Diversaj teknikoj estas uzataj dum jardekoj, la algoritmoj estas pripensitaj, la kodo estas skribita kaj sencimigita - prenu kaj uzu ĝin. En nia kazo, unu fundamenta problemo ekestis - ni ĉe ISPsystem okupiĝas pri programaro, ne pri podetala komerco.
Mi nomiĝas Denis kaj nuntempe mi respondecas pri la backend de analizaj sistemoj ĉe ISPsystem. Kaj jen la rakonto pri kiel mi kaj mia kolego — tiuj respondecaj pri datuma bildigo — provis rigardi niajn programajn produktojn per la prismo de ĉi tiu scio. Ni komencu, kiel kutime, per historio.
En la komenco estis vorto, kaj la vorto estis "Ĉu ni provu?"
Tiutempe mi laboris kiel programisto en la fako R&D. Ĉio komenciĝis kiam Danil legis ĉi tie sur Habré — ilo por analizi uzanttransirojn en aplikaĵoj. Mi estis iom skeptika pri la ideo uzi ĝin ĉi tie. Kiel ekzemploj, la bibliotekprogramistoj citis analizon de aplikoj kie la cela ago estis klare difinita - farante mendon aŭ iun alian varion de kiel pagi la posedanto-firmaon. Niaj produktoj estas liveritaj surloke. Tio estas, la uzanto unue aĉetas permesilon, kaj nur tiam komencas sian vojaĝon en la aplikaĵo. Jes, ni havas demo-versiojn. Vi povas provi la produkton tie, por ke vi ne havu porkon en poke.
Sed plej multaj el niaj produktoj celas la gastigan merkaton. Ĉi tiuj estas grandaj klientoj, kaj la fako pri komerca disvolviĝo konsilas ilin pri produktaj kapabloj. Ankaŭ sekvas, ke en la momento de la aĉeto, niaj klientoj jam scias, kiajn problemojn helpos ilin solvi nia programaro. Iliaj itineroj en la aplikaĵo devas koincidi kun la CJM enigita en la produkto, kaj UX-solvoj helpos ilin resti survoje. Spoiler: ĉi tio ne ĉiam okazas. La enkonduko al la biblioteko estis prokrastita... sed ne longe.
Ĉio ŝanĝiĝis kun la liberigo de nia starto - — platformoj por krei interretan vendejon el Instagram-konto. En ĉi tiu aplikaĵo, la uzanto ricevis du-semajnan periodon por uzi ĉiujn funkciojn senpage. Tiam vi devis decidi ĉu aboni. Kaj ĉi tio perfekte persvadas en la koncepton "itinero-cela ago". Estis decidite: ni provu!
Unuaj rezultoj aŭ de kie akiri ideojn
La disvolva teamo kaj mi konektis la produkton al la eventa kolektosistemo laŭvorte en tago. Mi tuj diros, ke ISP-sistemo uzas sian propran sistemon por kolekti eventojn pri paĝaj vizitoj, sed nenio malhelpas vin uzi Yandex.Metrica por la samaj celoj, kio ebligas al vi elŝuti krudajn datumojn senpage. Ekzemploj de uzado de la biblioteko estis studitaj, kaj post semajno da datumkolektado ni ricevis transigan grafeon.
Transira grafikaĵo. Baza funkcieco, aliaj transiroj forigitaj por klareco
Ĝi rezultis same kiel en la ekzemplo: ebena, klara, bela. El ĉi tiu grafikaĵo, ni povis identigi la plej oftajn itinerojn kaj transirejojn, kie homoj pasigas la plej longan tempon. Ĉi tio permesis al ni kompreni la jenon:
- Anstataŭ granda CJM, kiu kovras dekduon da entoj, nur du estas aktive uzataj. Necesas aldone direkti uzantojn al la lokoj, kiujn ni bezonas uzante UX-solvojn.
- Iuj paĝoj, dezajnitaj de UX-dizajnistoj por esti fin-al-finaj, finiĝas kun homoj elspezantaj neracian kvanton da tempo por ili. Vi devas ekscii, kiaj estas la haltelementoj sur specifa paĝo kaj ĝustigi ĝin.
- Post 10 transiroj, 20% de homoj komencis laciĝi kaj forlasi la sesion en la aplikaĵo. Kaj ĉi tio konsideras la fakton, ke ni havis eĉ 5 eniĝajn paĝojn en la aplikaĵo! Vi devas identigi paĝojn, kie uzantoj regule forlasas kunsidojn kaj mallongigi la vojon al ili. Eĉ pli bone: identigu ajnajn regulajn itinerojn kaj permesu rapidan transiron de la fontopaĝo al la celpaĝo. Io komuna kun ABC-analizo kaj forlasita ĉaranalizo, ĉu vi ne pensas?
Kaj ĉi tie ni rekonsideris nian sintenon al la aplikebleco de ĉi tiu ilo por surlokaj produktoj. Oni decidis analizi aktive venditan kaj uzatan produkton - . Estas multe pli kompleksa, ekzistas ordo de grandeco pli da entoj. Ni entuziasme atendis vidi kia estos la transira grafiko.
Pri elreviĝoj kaj inspiroj
Seniluziiĝo numero 1
Estis la fino de la labortago, la fino de la monato kaj la fino de la jaro samtempe – la 27-an de decembro. Datenoj estas amasigitaj, demandoj estis skribitaj. Restis sekundoj antaŭ ol ĉio estis prilaborita kaj ni povis rigardi la rezulton de niaj laboroj por ekscii kie komenciĝos la venonta laborjaro. La R&D-sekcio, produktmanaĝero, UX-dizajnistoj, teamgvidanto, programistoj kunvenis antaŭ la monitoro por vidi kiel aspektas la uzantvojoj en sia produkto, sed... ni vidis ĉi tion:
Transira grafeo konstruita de la Retentioneering-biblioteko
Inspiro #1
Forte konektitaj, dekoj da entoj, ne-evidentaj scenaroj. Estis nur klare, ke la nova laborjaro komenciĝos ne per analizo, sed per la invento de maniero simpligi laboron per tia grafikaĵo. Sed mi ne povis skui la senton, ke ĉio estas multe pli simpla ol ĝi ŝajnis. Kaj post dek kvin minutoj de studado de la fontkodo de Retentioneering, ni povis eksporti la konstruitan grafeon al punktoformato. Tio ebligis alŝuti la grafikaĵon al alia ilo - Gephi. Kaj jam ekzistas amplekso por analizi grafikaĵojn: aranĝoj, filtriloj, statistikoj - ĉio, kion vi devas fari, estas agordi la necesajn parametrojn en la interfaco. Kun ĉi tiu penso en menso, ni foriris al novjara semajnfino.
Seniluziiĝo numero 2
Post reveni al laboro, montriĝis, ke dum ĉiuj ripozis, niaj klientoj studis la produkton. Jes, tiel forte, ke en la stokado aperis eventoj, kiuj antaŭe ne ekzistis. Ĉi tio signifis, ke la demandoj devis esti ĝisdatigitaj.
Eta fono por kompreni la malĝojon de ĉi tiu fakto. Ni transdonas kaj la eventojn, kiujn ni markis (ekzemple, klakojn sur iuj butonoj) kaj la URL-ojn de la paĝoj, kiujn la uzanto vizitis. En la kazo de Cartbee, la modelo "unu ago - unu paĝo" funkciis. Sed kun VMmanager la situacio estis tute alia: pluraj modalaj fenestroj povus malfermiĝi sur unu paĝo. En ili la uzanto povus solvi diversajn problemojn. Ekzemple, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
signifas, ke sur la paĝo "IP-Adresoj" la uzanto aldonis IP-adreson. Kaj ĉi tie du problemoj estas videblaj samtempe:
- La URL enhavas ian padan parametron - la ID de la virtuala maŝino. Ĝi devas esti ekskludita.
- La URL enhavas la modalan fenestran ID. Vi devas iel "malpaki" tiajn URL-ojn.
Alia problemo estis, ke la eventoj mem, kiujn ni markis, havis parametrojn. Ekzemple, estis kvin malsamaj manieroj atingi la paĝon kun informoj pri virtuala maŝino el la listo. Sekve, unu evento estis sendita, sed kun parametro kiu indikis kiun metodon la uzanto faris la transiron. Estis multaj tiaj eventoj, kaj ĉiuj parametroj estis malsamaj. Kaj ni havas la tutan datuman rehavigan logikon en la SQL-dialekto por Clickhouse. Demandoj de 150-200 linioj komencis ŝajni iom ordinaraj. Problemoj ĉirkaŭis nin.
Inspiro #2
Iun fruan matenon, Danil, bedaŭrinde trarulante la peton dum la dua minuto, sugestis al mi: "Ni skribu datumtraktadojn?" Ni pensis pri ĝi kaj decidis, ke se ni faros ĝin, ĝi estus io kiel ETL. Por ke ĝi tuj filtriĝu kaj eltiras la necesajn datumojn de aliaj fontoj. Tiel naskiĝis nia unua analiza servo kun plenrajta backend. Ĝi efektivigas kvin ĉefajn stadiojn de datumtraktado:
- Malŝarĝi eventojn el la kruda datuma stokado kaj prepari ilin por prilaborado.
- Klarigo estas la "malpakado" de tiuj mem identigiloj de modalaj fenestroj, eventoparametroj kaj aliaj detaloj kiuj klarigas la eventon.
- Riĉigo (de la vorto "riĉiĝi") estas aldono de eventoj kun datumoj de triaj fontoj. Tiutempe ĉi tio inkludis nur nian fakturan sistemon BILLmanager.
- Filtrado estas la procezo de filtrado de eventoj kiuj distordas la rezultojn de la analizo (okazaĵoj de internaj standoj, eksteruloj, ktp.).
- Alŝuti ricevitajn eventojn en stokadon, kiujn ni nomis puraj datumoj.
Nun eblis konservi gravecon aldonante regulojn por prilaborado de evento aŭ eĉ grupoj de similaj eventoj. Ekzemple, ekde tiam ni neniam ĝisdatigis URL-malpakadon. Kvankam, dum ĉi tiu tempo pluraj novaj URL-varioj estis aldonitaj. Ili konformas al la reguloj jam fiksitaj en la servo kaj estas ĝuste traktataj.
Seniluziiĝo numero 3
Post kiam ni komencis analizi, ni komprenis kial la grafikaĵo estis tiel kohera. Fakte, preskaŭ ĉiu N-gramo enhavis transirojn, kiuj ne povus esti efektivigitaj per la interfaco.
Malgranda esploro komenciĝis. Mi estis konfuzita, ke ne estis neeblaj transiroj ene de unu ento. Ĉi tio signifas, ke ĉi tio ne estas cimo en la eventa kolektosistemo aŭ nia ETL-servo. Estis sento, ke la uzanto samtempe laboras en pluraj estaĵoj, sen moviĝi de unu al alia. Kiel atingi ĉi tion? Uzante malsamajn langetojn en la retumilo.
Analizante Cartbee, ni saviĝis pro ĝia specifeco. La aplikaĵo estis uzata de porteblaj aparatoj, kie labori de pluraj langetoj estas simple maloportuna. Ĉi tie ni havas labortablon kaj dum tasko estas farita en unu ento, estas racie voli pasigi ĉi tiun tempon agordante aŭ monitorante la staton en alia. Kaj por ne perdi progreson, simple malfermu alian langeton.
Inspiro #3
Kolegoj de antaŭa evoluado instruis la eventan kolektosistemon distingi inter langetoj. La analizo povus komenciĝi. Kaj ni komencis. Kiel atendite, CJM ne kongruis kun realaj vojoj: uzantoj pasigis multan tempon sur dosierujoj, forlasis kunsidojn kaj langetojn en la plej neatenditaj lokoj. Uzante transiran analizon, ni povis trovi problemojn en kelkaj Mozilaj konstruoj. En ili, pro efektivigaĵoj malaperis navigadelementoj aŭ montriĝis duonmalplenaj paĝoj, kiuj devus esti alireblaj nur por la administranto. La paĝo malfermiĝis, sed neniu enhavo venis de la malantaŭo. Nombri transirojn ebligis taksi kiuj funkcioj estis efektive uzitaj. La ĉenoj ebligis kompreni kiel la uzanto ricevis tian aŭ alian eraron. La datumoj permesis testi surbaze de uzantkonduto. Estis sukceso, la ideo ne estis vana.
Analitika aŭtomatigo
En unu el la rezultaj pruvoj, ni montris kiel Gephi estas uzata por grafika analizo. En ĉi tiu ilo, konvertaj datumoj povas esti montritaj en tabelo. Kaj la estro de la fako UX diris unu tre grava penso, kiu influis la evoluon de la tuta kondut-analitika direkto en la kompanio: "Ni faru la samon, sed en Tableau kaj per filtriloj - estos pli oportune."
Tiam mi pensis: kial ne, Retentioneering stokas ĉiujn datumojn en strukturo de pandas.DataFrame. Kaj ĉi tio estas, ĝenerale, tablo. Jen kiel aperis alia servo: Datumprovizanto. Li ne nur faris tabelon de la grafikaĵo, sed ankaŭ kalkulis kiom popularaj la paĝo kaj la funkcioj asociitaj kun ĝi estas, kiel ĝi influas retenon de uzantoj, kiom longe uzantoj restas sur ĝi, kaj kiujn paĝojn uzantoj forlasas plej ofte. Kaj la uzo de bildigo en Tableau reduktis la koston de studado de la grafeo tiom multe ke la ripeta tempo por konduta analizo en la produkto preskaŭ duoniĝis.
Danil parolos pri kiel ĉi tiu bildigo estas uzata kaj kiajn konkludojn ĝi permesas eltiri.
Pli da tabloj por la tablodio!
En simpligita formo, la tasko estis formulita jene: montri la transiran grafeon en Tableau, provizi la kapablon filtri, kaj fari ĝin kiel eble plej klara kaj oportuna.
Mi ne vere volis desegni direktitan grafeon en Tableau. Kaj eĉ se sukcesa, la gajno, kompare kun Gephi, ne ŝajnis evidenta. Ni bezonis ion multe pli simplan kaj alireblan. Tablo! Post ĉio, la grafeo povas esti facile reprezentita en la formo de tabelvicoj, kie ĉiu vico estas rando de la "fonto-destina" tipo. Plie, ni jam zorge preparis tian tabelon per Retentioneering kaj Data Provider-iloj. Restis nur montri la tabelon en Tableau kaj trarigardi la raporton.
Parolante pri kiel ĉiuj amas tablojn.
Tamen, ĉi tie ni estas antaŭ alia problemo. Kion fari kun la datumfonto? Estis neeble konekti pandojn.DataFrame; Tableau ne havas tian konektilon. Levigi apartan bazon por konservi la grafeon ŝajnis tro radikala solvo kun neklaraj perspektivoj. Kaj lokaj malŝarĝaj opcioj ne taŭgis pro la bezono de konstantaj manaj operacioj. Ni trarigardis la liston de disponeblaj konektiloj, kaj nia rigardo falis sur la objekton , kiu senĝene puŝiĝis ĉe la fundo mem.
Tableau havas riĉan elekton de konektiloj. Ni trovis unu, kiu solvis nian problemon
Kia besto? Kelkaj novaj malfermitaj langetoj en la retumilo - kaj evidentiĝis, ke ĉi tiu konektilo permesas ricevi datumojn kiam vi aliras URL-on. La backend por kalkuli la datumojn mem estis preskaŭ preta, restis nur amikigi ĝin kun WDC. Dum kelkaj tagoj Denis studis la dokumentadon kaj batalis kun la mekanismoj de Tableau, kaj poste sendis al mi ligilon, kiun mi algluis en la konektan fenestron.
Konektoformularo al nia WDC. Denis faris sian fronton kaj zorgis pri sekureco
Post kelkaj minutoj da atendado (la datumoj estas dinamike kalkulitaj kiam oni petas), la tablo aperis:
Jen kiel aspektas kruda datuma tabelo en la interfaco de Tableau
Kiel promesite, ĉiu vico de tia tablo reprezentis randon de la grafeo, tio estas, direktita transiro de la uzanto. Ĝi ankaŭ enhavis plurajn kromajn karakterizaĵojn. Ekzemple, la nombro da unikaj uzantoj, la totala nombro de transiroj, kaj aliaj.
Eblus montri ĉi tiun tabelon en la raporto kiel estas, malavare aspergi filtrilojn kaj sendi la ilon navigante. Sonas logike. Kion vi povas fari kun la tablo? Sed ĉi tio ne estas nia maniero, ĉar ni faras ne nur tablon, sed ilon por analizo kaj fari produktajn decidojn.
Kutime, kiam oni analizas datumojn, homo volas ricevi respondojn al demandoj. Bonege. Ni komencu per ili.
- Kio estas la plej oftaj transiroj?
- Kien ili iras de specifaj paĝoj?
- Kiom da tempo vi averaĝe pasigas en ĉi tiu paĝo antaŭ ol foriri?
- Kiom ofte vi faras la transiron de A al B?
- Sur kiuj paĝoj finiĝas la kunsido?
Ĉiu el la raportoj aŭ kombinaĵo de ili devus permesi al la uzanto sendepende trovi respondojn al ĉi tiuj demandoj. La ŝlosila strategio ĉi tie estas doni al vi la ilojn por fari ĝin mem. Ĉi tio utilas kaj por redukti la ŝarĝon de la analizfako kaj por redukti la tempon por fari decidojn - finfine vi ne plu bezonas iri al Youtrack kaj krei taskon por la analizisto, vi nur bezonas malfermi la raporton.
Kion ni ricevis?
Kie homoj plej ofte diverĝas de la panelo?
Fragmento de nia raporto. Post la panelo, ĉiuj iris aŭ al la listo de VM-oj aŭ al la listo de nodoj
Ni prenu ĝeneralan tabelon kun transiroj kaj filtru laŭ fontopaĝo. Plej ofte, ili iras de la panelo al la listo de virtualaj maŝinoj. Krome, la kolumno de Reguleco sugestas, ke ĉi tio estas ripeta ago.
De kie ili venas al la listo de aretoj?
Filtriloj en raportoj funkcias ambaŭdirekte: vi povas ekscii kien vi foriris, aŭ kien vi iris
El la ekzemploj estas klare, ke eĉ la ĉeesto de du simplaj filtriloj kaj rangaj vicoj laŭ valoroj permesas vin rapide akiri informojn.
Ni demandu ion pli komplikan.
Kie uzantoj plej ofte forlasas sian sesion?
Uzantoj de VMmanager ofte laboras en apartaj langetoj
Por fari tion, ni bezonas raporton, kies datumoj estas kunigitaj de referencaj fontoj. Kaj la tielnomitaj rompopunktoj estis prenitaj kiel taskoj - okazaĵoj kiuj funkciis kiel fino de la ĉeno de transiroj.
Gravas rimarki ĉi tie, ke ĉi tio povas esti aŭ la fino de la sesio aŭ la malfermo de nova langeto. La ekzemplo montras, ke la ĉeno plej ofte finiĝas ĉe tablo kun listo de virtualaj maŝinoj. En ĉi tiu kazo, la karakteriza konduto ŝanĝas al alia langeto, kiu kongruas kun la atendata ŝablono.
Ni antaŭ ĉio testis la utilecon de ĉi tiuj raportoj sur ni mem, kiam ni faris la analizon simile. , alia el niaj produktoj. Kun la apero de tabeloj kaj filtriloj, hipotezoj estis provitaj pli rapide, kaj la okuloj estis malpli lacaj.
Dum disvolvado de raportoj, ni ne forgesis pri vida dezajno. Kiam vi laboras kun tabloj de ĉi tiu grandeco, ĉi tio estas grava faktoro. Ekzemple, ni uzis trankvilan gamon da koloroj, facile percepteblaj por nombroj, kolora reliefigo de linioj konforme al la nombraj valoroj de la karakterizaĵoj. Tiaj detaloj plibonigas la uzantan sperton kaj pliigas la verŝajnecon, ke la ilo ekflugas sukcese en la kompanio.
La tablo montriĝis sufiĉe granda, sed ni esperas, ke ĝi ne ĉesis esti legebla
Menciindas aparte pri la trejnado de niaj internaj klientoj: produktaj specialistoj kaj UX-dezajnistoj. Manlibroj kun analizekzemploj kaj konsiletoj por labori kun filtriloj estis speciale preparitaj por ili. Ni enmetis ligilojn al manlibroj rekte en la raportajn paĝojn.
Ni faris la manlibron simple kiel prezenton en Google Docs. Tabelaj iloj permesas al vi montri retpaĝojn rekte en raporta laborlibro.
Anstataŭ epilogo
Kio estas en la fundo? Ni povis akiri ilon por ĉiu tago relative rapide kaj malmultekoste. Jes, ĉi tio certe ne estas anstataŭaĵo por la grafikaĵo mem, la varmomapo de klakoj aŭ la retspektilo. Sed tiaj raportoj signife kompletigas la listigitajn ilojn kaj provizas penson kaj novajn produktajn kaj interfacajn hipotezojn.
Ĉi tiu rakonto funkciis nur kiel la komenco por la evoluo de analizo en ISPsistemo. Dum la pasintaj ses monatoj aperis sep pliaj novaj servoj, inkluzive de ciferecaj portretoj de la uzanto en la produkto kaj servo por krei datumbazojn por Simil-celado, sed pri ili ni parolos en la sekvaj epizodoj.
fonto: www.habr.com