Ka qindra artikuj në internet në lidhje me përfitimet e analizës së sjelljes së klientit. Më shpesh kjo ka të bëjë me sektorin e shitjes me pakicë. Nga analiza e shportës së ushqimit, analiza ABC dhe XYZ tek marketingu i ruajtjes dhe ofertat personale. Teknika të ndryshme janë përdorur për dekada, algoritmet janë menduar, kodi është shkruar dhe korrigjuar - merre dhe përdore. Në rastin tonë, u ngrit një problem thelbësor - ne në ISPsystem jemi të angazhuar në zhvillimin e softuerit, jo me pakicë.
Emri im është Denis dhe aktualisht jam përgjegjës për backend-in e sistemeve analitike në ISPsystem. Dhe kjo është historia se si unë dhe kolegu im — ata që janë përgjegjës për vizualizimin e të dhënave — u përpoqën të shikonin produktet tona softuerike përmes prizmit të kësaj njohurie. Le të fillojmë, si zakonisht, me historinë.
Në fillim kishte një fjalë, dhe fjala ishte "A të përpiqemi?"
Në atë moment unë punoja si zhvillues në departamentin e R&D. Gjithçka filloi kur Danil lexoi këtu në Habré — një mjet për të analizuar tranzicionet e përdoruesve në aplikacione. Unë isha disi skeptik për idenë e përdorimit të tij këtu. Si shembuj, zhvilluesit e bibliotekës cituan një analizë të aplikacioneve ku veprimi i synuar ishte i përcaktuar qartë - vendosja e një porosie ose ndonjë ndryshim tjetër se si të paguante kompaninë pronare. Produktet tona ofrohen në premisë. Kjo do të thotë, përdoruesi së pari blen një licencë dhe vetëm atëherë fillon udhëtimin e tij në aplikacion. Po, ne kemi versione demo. Ju mund ta provoni produktin atje në mënyrë që të mos keni një derr në thes.
Por shumica e produkteve tona synojnë tregun pritës. Këta janë klientë të mëdhenj dhe departamenti i zhvillimit të biznesit i këshillon ata për aftësitë e produktit. Nga kjo rrjedh gjithashtu se në momentin e blerjes, klientët tanë tashmë e dinë se cilat probleme do t'i ndihmojë ata të zgjidhin softueri ynë. Rrugët e tyre në aplikacion duhet të përkojnë me CJM të ngulitur në produkt dhe zgjidhjet UX do t'i ndihmojnë ata të qëndrojnë në rrugën e duhur. Spoiler: kjo nuk ndodh gjithmonë. Hyrja në bibliotekë u shty... por jo për shumë kohë.
Gjithçka ndryshoi me lëshimin e startup-it tonë - — platforma për krijimin e një dyqani në internet nga një llogari në Instagram. Në këtë aplikacion, përdoruesit iu dha një periudhë dy javore për të përdorur të gjitha funksionet falas. Pastaj ju duhej të vendosni nëse do të abonoheni. Dhe kjo përshtatet në mënyrë të përkryer me konceptin "veprim rrugë-shënjestër". U vendos: le të provojmë!
Rezultatet e para ose nga mund të merrni ide
Ekipi i zhvillimit dhe unë e lidhëm produktin me sistemin e mbledhjes së ngjarjeve fjalë për fjalë brenda një dite. Unë do të them menjëherë se ISPsystem përdor sistemin e vet për mbledhjen e ngjarjeve në lidhje me vizitat e faqeve, por asgjë nuk ju pengon të përdorni Yandex.Metrica për të njëjtat qëllime, e cila ju lejon të shkarkoni të dhëna të papërpunuara falas. U studiuan shembuj të përdorimit të bibliotekës dhe pas një jave mbledhje të të dhënave morëm një grafik tranzicioni.
Grafiku i tranzicionit. Funksionaliteti bazë, tranzicione të tjera janë hequr për qartësi
Doli ashtu si në shembullin: planar, i qartë, i bukur. Nga ky grafik, ne ishim në gjendje të identifikonim rrugët dhe vendkalimet më të shpeshta ku njerëzit kalojnë kohën më të gjatë. Kjo na lejoi të kuptojmë sa vijon:
- Në vend të një CJM të madhe, e cila mbulon një duzinë subjekte, vetëm dy përdoren në mënyrë aktive. Është e nevojshme të drejtojmë gjithashtu përdoruesit në vendet që na duhen duke përdorur zgjidhje UX.
- Disa faqe, të dizajnuara nga dizajnerët UX për të qenë nga fundi në fund, përfundojnë me njerëz që shpenzojnë një kohë të paarsyeshme për to. Ju duhet të kuptoni se cilët janë elementët e ndalimit në një faqe specifike dhe t'i rregulloni ato.
- Pas 10 tranzicioneve, 20% e njerëzve filluan të lodheshin dhe të braktisnin seancën në aplikacion. Dhe kjo duke marrë parasysh faktin se ne kishim deri në 5 faqe të hyrjes në aplikacion! Ju duhet të identifikoni faqet ku përdoruesit braktisin rregullisht seancat dhe të shkurtoni rrugën drejt tyre. Edhe më mirë: identifikoni çdo rrugë të rregullt dhe lejoni një kalim të shpejtë nga faqja e burimit në faqen e destinacionit. Diçka e përbashkët me analizën ABC dhe analizën e karrocave të braktisura, nuk mendoni?
Dhe këtu ne rishqyrtuam qëndrimin tonë ndaj zbatueshmërisë së këtij mjeti për produktet në premisë. U vendos të analizohej një produkt i shitur dhe i përdorur në mënyrë aktive - . Është shumë më komplekse, ka një rend të madhësisë më shumë entitete. Ne prisnim me emocion të shihnim se cili do të ishte grafiku i tranzicionit.
Rreth zhgënjimeve dhe frymëzimeve
Zhgënjimi numër 1
Ishte fundi i ditës së punës, fundi i muajit dhe fundi i vitit në të njëjtën kohë - 27 dhjetor. Të dhënat janë grumbulluar, pyetjet janë shkruar. Kishin mbetur sekonda përpara se gjithçka të përpunohej dhe ne mund të shikonim rezultatin e punës sonë për të gjetur se ku do të fillonte viti i ardhshëm i punës. Departamenti i R&D, menaxheri i produktit, dizajnerët UX, drejtuesit e ekipit, zhvilluesit u mblodhën para monitorit për të parë se si duken shtigjet e përdoruesve në produktin e tyre, por... ne pamë këtë:
Grafiku i tranzicionit i ndërtuar nga biblioteka Retentioneering
Frymëzimi numër 1
Të lidhura fort, dhjetëra subjekte, skenarë jo të dukshëm. Ishte e qartë vetëm se viti i ri i punës do të fillonte jo me analiza, por me shpikjen e një mënyre për të thjeshtuar punën me një grafik të tillë. Por nuk mund ta lëkundema ndjenjën se gjithçka ishte shumë më e thjeshtë nga sa dukej. Dhe pas pesëmbëdhjetë minutash studimi të kodit burimor Retaineering, ne ishim në gjendje të eksportonim grafikun e ndërtuar në formatin dot. Kjo bëri të mundur ngarkimin e grafikut në një mjet tjetër - Gephi. Dhe tashmë ka hapësirë për të analizuar grafikët: paraqitjet, filtrat, statistikat - gjithçka që duhet të bëni është të konfiguroni parametrat e nevojshëm në ndërfaqe. Me këtë mendim u nisëm për në fundjavën e Vitit të Ri.
Zhgënjimi numër 2
Pas kthimit në punë, rezultoi se ndërsa të gjithë po pushonin, klientët tanë po studionin produktin. Po, aq e vështirë sa në ruajtje u shfaqën ngjarje që nuk ekzistonin më parë. Kjo do të thoshte se pyetjet duhej të përditësoheshin.
Pak sfond për të kuptuar trishtimin e këtij fakti. Ne transmetojmë të dyja ngjarjet që kemi shënuar (për shembull, klikimet në disa butona) dhe URL-të e faqeve që përdoruesi ka vizituar. Në rastin e Cartbee, modeli "një veprim - një faqe" funksionoi. Por me VMmanager situata ishte krejtësisht e ndryshme: disa dritare modale mund të hapeshin në një faqe. Në to përdoruesi mund të zgjidhte probleme të ndryshme. Për shembull, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
do të thotë që në faqen “IP Adresat” përdoruesi ka shtuar një adresë IP. Dhe këtu dy probleme janë të dukshme menjëherë:
- URL-ja përmban një lloj parametri të rrugës - ID-në e makinës virtuale. Duhet të përjashtohet.
- URL-ja përmban ID-në e dritares modale. Ju duhet të "zhpaketoni" disi URL të tilla.
Një problem tjetër ishte se vetë ngjarjet që shënuam kishin parametra. Për shembull, kishte pesë mënyra të ndryshme për të shkuar te faqja me informacione për një makinë virtuale nga lista. Prandaj, një ngjarje u dërgua, por me një parametër që tregonte se cila metodë përdoruesi bëri kalimin. Kishte shumë ngjarje të tilla dhe të gjithë parametrat ishin të ndryshëm. Dhe ne kemi të gjithë logjikën e rikthimit të të dhënave në dialektin SQL për Clickhouse. Pyetjet për 150-200 rreshta kishin filluar të dukeshin si diçka e njohur. Na rrethuan problemet.
Frymëzimi numër 2
Një mëngjes herët, Danil, duke e shfletuar me trishtim kërkesën për minutën e dytë, më sugjeroi: "Le të shkruajmë tubacionet e përpunimit të të dhënave?" Ne menduam për këtë dhe vendosëm që nëse do ta bënim, do të ishte diçka si ETL. Në mënyrë që të filtrohet menjëherë dhe të tërheqë të dhënat e nevojshme nga burime të tjera. Kështu lindi shërbimi ynë i parë analitik me një backend të plotë. Ai zbaton pesë faza kryesore të përpunimit të të dhënave:
- Shkarkimi i ngjarjeve nga ruajtja e të dhënave të papërpunuara dhe përgatitja e tyre për përpunim.
- Sqarimi është "zhpaketimi" i atyre vetë identifikuesve të dritareve modale, parametrave të ngjarjes dhe detajeve të tjera që sqarojnë ngjarjen.
- Pasurimi (nga fjala "të bëhesh i pasur") është shtimi i ngjarjeve me të dhëna nga burime të palëve të treta. Në atë kohë, kjo përfshinte vetëm sistemin tonë të faturimit BILLmanager.
- Filtrimi është procesi i filtrimit të ngjarjeve që shtrembërojnë rezultatet e analizës (ngjarje nga stendat e brendshme, pikat e jashtme, etj.).
- Ngarkimi i ngjarjeve të marra në ruajtje, të cilat ne i quajtëm të dhëna të pastra.
Tani ishte e mundur të ruhej rëndësia duke shtuar rregulla për përpunimin e një ngjarjeje apo edhe grupe ngjarjesh të ngjashme. Për shembull, që atëherë nuk e kemi përditësuar asnjëherë zbërthimin e URL-ve. Megjithëse, gjatë kësaj kohe janë shtuar disa variacione të reja URL. Ato janë në përputhje me rregullat e përcaktuara tashmë në shërbim dhe përpunohen në mënyrë korrekte.
Zhgënjimi numër 3
Pasi filluam të analizonim, kuptuam pse grafiku ishte kaq koherent. Fakti është se pothuajse çdo N-gram përmbante tranzicione që nuk mund të kryheshin përmes ndërfaqes.
Filloi një hetim i vogël. Unë isha i hutuar se nuk kishte tranzicione të pamundura brenda një entiteti. Kjo do të thotë që ky nuk është një gabim në sistemin e mbledhjes së ngjarjeve ose në shërbimin tonë ETL. Kishte një ndjenjë që përdoruesi punonte njëkohësisht në disa entitete, pa lëvizur nga njëri në tjetrin. Si të arrihet kjo? Përdorimi i skedave të ndryshme në shfletues.
Kur analizuam Cartbee, ne u shpëtuam nga specifika e tij. Aplikacioni është përdorur nga pajisjet celulare, ku puna nga disa skeda është thjesht e papërshtatshme. Këtu kemi një desktop dhe ndërsa një detyrë është duke u kryer në një entitet, është e arsyeshme të dëshirojmë ta kalojmë këtë kohë duke konfiguruar ose monitoruar statusin në një tjetër. Dhe për të mos humbur përparimin, thjesht hapni një skedë tjetër.
Frymëzimi numër 3
Kolegët nga zhvillimi në front-end mësuan sistemin e mbledhjes së ngjarjeve të dallonte midis skedave. Analiza mund të fillojë. Dhe filluam. Siç pritej, CJM nuk përputhej me shtigjet reale: përdoruesit shpenzuan shumë kohë në faqet e drejtorive, seanca të braktisura dhe skeda në vendet më të papritura. Duke përdorur analizën e tranzicionit, ne mundëm të gjenim probleme në disa ndërtime të Mozilla-s. Në to, për shkak të veçorive të zbatimit, elementët e navigimit u zhdukën ose u shfaqën faqe gjysmë bosh, të cilat duhet të jenë të aksesueshme vetëm për administratorin. Faqja u hap, por asnjë përmbajtje nuk erdhi nga pjesa e pasme. Tranzicionet e numërimit bënë të mundur vlerësimin se cilat veçori ishin përdorur në të vërtetë. Zinxhirët bënë të mundur për të kuptuar se si përdoruesi mori këtë apo atë gabim. Të dhënat e lejuara për testim bazuar në sjelljen e përdoruesit. Ishte një sukses, ideja nuk ishte e kotë.
Automatizimi i analitikës
Në një nga demonstrimet e rezultateve, ne treguam se si përdoret Gephi për analizën e grafikut. Në këtë mjet, të dhënat e konvertimit mund të shfaqen në një tabelë. Dhe kreu i departamentit të UX tha një mendim shumë të rëndësishëm që ndikoi në zhvillimin e të gjithë drejtimit të analitikës së sjelljes në kompani: "Le të bëjmë të njëjtën gjë, por në Tableau dhe me filtra - do të jetë më i përshtatshëm."
Pastaj mendova: pse jo, Retentioneering ruan të gjitha të dhënat në një strukturë panda.DataFrame. Dhe kjo është, në përgjithësi, një tryezë. Kështu u shfaq një shërbim tjetër: Ofruesi i të dhënave. Ai jo vetëm që bëri një tabelë nga grafiku, por gjithashtu llogariti se sa e njohur është faqja dhe funksionaliteti i lidhur me të, si ndikon në mbajtjen e përdoruesve, sa kohë qëndrojnë përdoruesit në të dhe cilat faqe i lënë përdoruesit më shpesh. Dhe përdorimi i vizualizimit në Tableau uli koston e studimit të grafikut aq shumë sa koha e përsëritjes për analizën e sjelljes në produkt u përgjysmua pothuajse.
Danil do të flasë se si përdoret ky vizualizim dhe çfarë përfundimesh lejon të nxjerrë.
Më shumë tavolina për zotin e tryezës!
Në një formë të thjeshtuar, detyra u formulua si më poshtë: shfaqni grafikun e tranzicionit në Tableau, siguroni aftësinë për të filtruar dhe për ta bërë atë sa më të qartë dhe të përshtatshëm.
Nuk doja vërtet të vizatoja një grafik të drejtuar në Tableau. Dhe edhe nëse ishte i suksesshëm, fitimi, në krahasim me Gefin, nuk dukej i dukshëm. Na duhej diçka shumë më e thjeshtë dhe më e arritshme. Tabela! Në fund të fundit, grafiku mund të përfaqësohet lehtësisht në formën e rreshtave të tabelës, ku çdo rresht është një skaj i llojit "burim-destinacion". Për më tepër, ne kemi përgatitur tashmë me kujdes një tabelë të tillë duke përdorur mjetet Retentioneering dhe Data Provider. E tëra çfarë mbetej për të bërë ishte të shfaqej tabela në Tabelë dhe të gërmohej raporti.
Duke folur se si të gjithë i duan tavolinat.
Megjithatë, këtu përballemi me një problem tjetër. Çfarë duhet bërë me burimin e të dhënave? Ishte e pamundur të lidheshin panda.DataFrame; Tabela nuk ka një lidhës të tillë. Ngritja e një baze të veçantë për ruajtjen e grafikut dukej një zgjidhje shumë radikale me perspektiva të paqarta. Dhe opsionet lokale të shkarkimit nuk ishin të përshtatshme për shkak të nevojës për operacione të vazhdueshme manuale. Ne shikuam listën e lidhësve të disponueshëm dhe vështrimi ynë ra mbi artikullin , i cili u grumbullua në mënyrë të mjerë në fund.
Tableau ka një përzgjedhje të pasur lidhësish. Ne gjetëm një që zgjidhi problemin tonë
Çfarë lloj kafshe? Disa skeda të reja të hapura në shfletues - dhe u bë e qartë se ky lidhës ju lejon të merrni të dhëna kur hyni në një URL. Backend-i për llogaritjen e të dhënave ishte pothuajse gati, gjithçka që mbetej ishte ta bënim miq me WDC. Për disa ditë Denisi studioi dokumentacionin dhe luftoi me mekanizmat Tableau, dhe më pas më dërgoi një lidhje që e ngjita në dritaren e lidhjes.
Formulari i lidhjes me WDC-në tonë. Denisi bëri frontin e tij dhe u kujdes për sigurinë
Pas disa minutash pritje (të dhënat llogariten në mënyrë dinamike kur kërkohen), u shfaq tabela:
Kështu duket një grup i të dhënave të papërpunuara në ndërfaqen Tableau
Siç ishte premtuar, çdo rresht i një tabele të tillë përfaqësonte një skaj të grafikut, domethënë një tranzicion të drejtuar të përdoruesit. Ai gjithashtu përmbante disa karakteristika shtesë. Për shembull, numri i përdoruesve unikë, numri i përgjithshëm i tranzicioneve dhe të tjera.
Do të ishte e mundur të shfaqej kjo tabelë në raport ashtu siç është, të spërkateshin bujarisht filtrat dhe të dërgohej mjeti në lundrim. Tingëllon logjike. Çfarë mund të bëni me tryezën? Por kjo nuk është rruga jonë, sepse ne po bëjmë jo thjesht një tabelë, por një mjet për analiza dhe marrjen e vendimeve për produktin.
Në mënyrë tipike, kur analizon të dhënat, një person dëshiron të marrë përgjigje për pyetjet. E madhe. Le të fillojmë me ta.
- Cilat janë tranzicionet më të shpeshta?
- Ku shkojnë nga faqet specifike?
- Sa kohë shpenzoni mesatarisht në këtë faqe përpara se të largoheni?
- Sa shpesh e bëni kalimin nga A në B?
- Në cilat faqe përfundon seanca?
Secili prej raporteve ose një kombinim i tyre duhet t'i lejojë përdoruesit të gjejë në mënyrë të pavarur përgjigjet për këto pyetje. Strategjia kryesore këtu është t'ju japë mjetet për ta bërë vetë. Kjo është e dobishme si për zvogëlimin e ngarkesës në departamentin e analitikës dhe për zvogëlimin e kohës për marrjen e vendimeve - në fund të fundit, nuk keni më nevojë të shkoni në Youtrack dhe të krijoni një detyrë për analistin, thjesht duhet të hapni raportin.
Çfarë morëm?
Ku largohen më shpesh njerëzit nga paneli i kontrollit?
Fragment i raportit tonë. Pas panelit, të gjithë shkuan ose në listën e VM-ve ose në listën e nyjeve
Le të marrim një tabelë të përgjithshme me tranzicione dhe të filtrojmë sipas faqes së burimit. Më shpesh, ata kalojnë nga pulti në listën e makinave virtuale. Për më tepër, kolona e Rregullsisë sugjeron që ky është një veprim i përsëritur.
Nga vijnë ato në listën e grupimeve?
Filtrat në raporte funksionojnë në të dy drejtimet: mund të zbuloni se ku jeni larguar ose ku keni shkuar
Nga shembujt është e qartë se edhe prania e dy filtrave të thjeshtë dhe renditja e rreshtave sipas vlerave ju lejon të merrni shpejt informacion.
Le të pyesim diçka më të vështirë.
Ku e braktisin më shpesh përdoruesit sesionin e tyre?
Përdoruesit e VMmanager shpesh punojnë në skeda të veçanta
Për ta bërë këtë, ne kemi nevojë për një raport, të dhënat e të cilit grumbullohen nga burimet e referimit. Dhe të ashtuquajturat pika të ndërprerjes u morën si detyra - ngjarje që shërbyen si fundi i zinxhirit të tranzicioneve.
Është e rëndësishme të theksohet këtu se ky mund të jetë ose fundi i seancës ose hapja e një skede të re. Shembulli tregon se zinxhiri më së shpeshti përfundon në një tabelë me një listë të makinave virtuale. Në këtë rast, sjellja karakteristike është kalimi në një skedë tjetër, e cila është në përputhje me modelin e pritur.
Para së gjithash, ne testuam dobinë e këtyre raporteve tek ne kur e kryenim analizën në mënyrë të ngjashme , një tjetër nga produktet tona. Me ardhjen e tabelave dhe filtrave, hipotezat u testuan më shpejt dhe sytë ishin më pak të lodhur.
Gjatë zhvillimit të raporteve, ne nuk harruam për dizajnin vizual. Kur punoni me tavolina të kësaj madhësie, ky është një faktor i rëndësishëm. Për shembull, ne përdorëm një gamë të qetë ngjyrash, të lehta për t'u perceptuar për numrat, theksimi me ngjyra i linjave në përputhje me vlerat numerike të karakteristikave. Detaje të tilla përmirësojnë përvojën e përdoruesit dhe rrisin gjasat që mjeti të ngrihet me sukses brenda kompanisë.
Tabela rezultoi mjaft voluminoze, por shpresojmë të mos ketë reshtur së qeni e lexueshme
Vlen të përmendet veçmas për trajnimin e klientëve tanë të brendshëm: specialistët e produkteve dhe dizajnerët UX. Për ta u përgatitën posaçërisht manuale me shembuj analizash dhe këshilla për të punuar me filtra. Ne futëm lidhje me manualet direkt në faqet e raportit.
Ne e bëmë manualin thjesht si një prezantim në Google Docs. Mjetet e tabelës ju lejojnë të shfaqni faqet e internetit direkt brenda një libri pune raporti.
Në vend të një pasuesi
Çfarë ka në fund? Ne ishim në gjendje të merrnim një mjet për çdo ditë relativisht shpejt dhe me çmim të ulët. Po, ky definitivisht nuk është një zëvendësim për vetë grafikun, hartën e nxehtësisë së klikimeve ose shikuesin e uebit. Por raporte të tilla plotësojnë ndjeshëm mjetet e listuara dhe ofrojnë ushqim për mendim dhe hipoteza të produkteve të reja dhe ndërfaqes.
Kjo histori shërbeu vetëm si fillimi për zhvillimin e analitikës në sistemin ISP. Gjatë gjashtë muajve të fundit, janë shfaqur shtatë shërbime të tjera të reja, duke përfshirë portrete dixhitale të përdoruesit në produkt dhe një shërbim për krijimin e bazave të të dhënave për shënjestrimin e "Look-alike", por ne do të flasim për to në episodet e mëposhtme.
Burimi: www.habr.com