D'r binne hûnderten artikels op it ynternet oer de foardielen fan it analysearjen fan klantgedrach. Meastentiids giet it om de retailsektor. Fan analyse fan itenkorb, ABC- en XYZ-analyse oant retensjonsmarketing en persoanlike oanbiedingen. Ferskate techniken binne al tsientallen jierren brûkt, de algoritmen binne úttocht, de koade is skreaun en debuggen - nim it en brûk it. Yn ús gefal ûntstie ien fûnemintele probleem - wy by ISPsystem binne dwaande mei softwareûntwikkeling, net retail.
Myn namme is Denis en ik bin op it stuit ferantwurdlik foar de efterkant fan analytyske systemen by ISPsystem. En dit is it ferhaal fan hoe't myn kollega en ik - dyjingen dy't ferantwurdlik binne foar fisualisaasje fan gegevens - besochten te sjen nei ús softwareprodukten troch it prisma fan dizze kennis. Litte wy begjinne, lykas gewoanlik, mei skiednis.
Yn it begjin wie der in wurd, en it wurd wie "Sille wy besykje?"
Op dat stuit wurke ik as ûntwikkelder yn de ôfdieling R&D. It begon allegear doe't Danil hjir op Habré lies - in ark foar it analysearjen fan brûkerstransysjes yn applikaasjes. Ik wie wat skeptysk oer it idee om it hjir te brûken. As foarbylden neamden de bibleteekûntwikkelders in analyze fan applikaasjes wêrby't de doelaksje dúdlik definiearre wie - it pleatsen fan in bestelling of in oare fariant fan hoe't jo it bedriuw fan 'e eigner betelje. Us produkten wurde levere op it terrein. Dat is, de brûker earst keapet in lisinsje, en pas dan begjint syn reis yn de applikaasje. Ja, wy hawwe demo ferzjes. Jo kinne it produkt dêr besykje, sadat jo gjin pig yn 'e poke hawwe.
Mar de measte fan ús produkten binne rjochte op de hostingmerk. Dit binne grutte kliïnten, en de ôfdieling bedriuwsûntwikkeling advisearret har oer produktmooglikheden. It folget ek dat op it momint fan oankeap, ús klanten al witte hokker problemen ús software sil helpe harren oplosse. Harren rûtes yn 'e applikaasje moatte gearfalle mei de CJM ynbêde yn it produkt, en UX-oplossingen sille har helpe op koers te bliuwen. Spoiler: dit bart net altyd. De ynlieding yn de bibleteek waard útsteld... mar net foar lang.
Alles feroare mei de frijlitting fan ús opstart - - platfoarms foar it meitsjen fan in online winkel fanút in Instagram-akkount. Yn dizze applikaasje krige de brûker in perioade fan twa wiken om alle funksjonaliteit fergees te brûken. Dan moasten jo beslute oft jo ynskriuwe. En dit paste perfekt yn it konsept "rûte-doel aksje". Der waard besletten: lit ús besykje!
Earste resultaten of wêr kinne jo ideeën krije
It ûntwikkelteam en ik ferbûnen it produkt letterlik yn ien dei oan it systeem foar samling fan eveneminten. Ik sil daliks sizze dat ISPsystem har eigen systeem brûkt foar it sammeljen fan eveneminten oer sidebesites, mar neat foarkomt dat jo Yandex.Metrica brûke foar deselde doelen, wêrtroch jo rûge gegevens fergees kinne downloade. Foarbylden fan it brûken fan de bibleteek waarden studearre, en nei in wike fan gegevenssammeling krigen wy in oergongsgrafyk.
Transysje grafyk. Basisfunksjonaliteit, oare transysjes fuortsmiten foar dúdlikens
It waard krekt as yn it foarbyld: flak, dúdlik, moai. Ut dizze grafyk koenen wy de meast foarkommende rûtes en krusingen identifisearje wêr't minsken de langste tiid trochbringe. Dit liet ús it folgjende begripe:
- Ynstee fan in grutte CJM, dy't in tsiental entiteiten beslacht, wurde mar twa aktyf brûkt. It is needsaaklik om brûkers ekstra te rjochtsjen nei de plakken dy't wy nedich binne mei UX-oplossingen.
- Guon siden, ûntworpen troch UX-ûntwerpers om end-to-end te wêzen, einigje mei minsken dy't in ûnferstannige hoemannichte tiid oan har besteegje. Jo moatte útfine wat de stop-eleminten binne op in spesifike side en oanpasse se.
- Nei 10 oergongen begon 20% fan minsken wurch te wurden en de sesje yn 'e applikaasje te ferlitten. En dit wurdt rekken holden mei it feit dat wy safolle as 5 onboarding-siden yn 'e applikaasje hiene! Jo moatte siden identifisearje wêr't brûkers sesjes regelmjittich ferlitte en it paad nei har ynkoartje. Noch better: identifisearje alle reguliere rûtes en tastean in flugge oergong fan de boarne side nei de bestimming side. Iets gemien mei ABC-analyze en ferlitten cart-analyse, tinke jo net?
En hjir hawwe wy ús hâlding foar de tapasberens fan dit ark foar on-premise produkten opnij besjoen. It waard besletten om in aktyf ferkocht en brûkt produkt te analysearjen - . It is folle komplekser, der binne in folchoarder fan grutte mear entiteiten. Wy wachtsje optein om te sjen wat de oergongsgrafyk soe blike te wêzen.
Oer teloarstellingen en ynspiraasjes
Teloarstelling #1
It wie de ein fan de wurkdei, de ein fan de moanne en de ein fan it jier tagelyk - 27 desimber. Gegevens binne sammele, fragen binne skreaun. Der wiene sekonden oer foardat alles ferwurke wie en wy koenen sjen nei it resultaat fan ús wurk om út te finen wêr't it folgjende wurkjier begjinne soe. De R&D-ôfdieling, produktbehearder, UX-ûntwerpers, teamlieder, ûntwikkelders sammele foar de monitor om te sjen hoe't de brûkerspaden der útsjen yn har produkt, mar ... wy seagen dit:
Transysjegrafyk boud troch de Retentioneering-biblioteek
Ynspiraasje #1
Sterk ferbûn, tsientallen entiteiten, net foar de hân lizzende senario's. It wie allinnich dúdlik dat it nije wurkjier net begjinne soe mei analyze, mar mei de útfining fan in manier om it wurk mei sa'n grafyk te ferienfâldigjen. Mar ik koe it gefoel dat alles folle ienfâldiger wie as it like. En nei fyftjin minuten fan it bestudearjen fan de Retentioneering-boarnekoade, koene wy de konstruearre grafyk eksportearje nei puntformaat. Dit makke it mooglik om de grafyk te uploaden nei in oar ark - Gephi. En d'r is al romte foar it analysearjen fan grafiken: layouts, filters, statistiken - alles wat jo hoege te dwaan is de nedige parameters yn 'e ynterface yn te stellen. Mei dizze gedachte yn gedachten binne wy fuortgien nei it nijjierswykein.
Teloarstelling #2
Nei it weromkommen oan it wurk die bliken dat wylst elkenien rêste, ús kliïnten it produkt bestudearren. Ja, sa hurd dat yn de opslach barrens ferskynden dy't earder net bestienen. Dit betsjutte dat de queries bywurke wurde moasten.
In bytsje eftergrûn om it fertriet fan dit feit te begripen. Wy stjoere sawol de eveneminten dy't wy hawwe markearre (bygelyks klikken op guon knoppen) en de URL's fan 'e siden dy't de brûker besocht hat oer. Yn it gefal fan Cartbee wurke it model "ien aksje - ien side". Mar mei VMmanager wie de situaasje folslein oars: ferskate modale finsters koene op ien side iepenje. Yn harren koe de brûker ferskate problemen oplosse. Bygelyks, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
betsjut dat op 'e side "IP-adressen" de brûker in IP-adres tafoege. En hjir binne twa problemen tagelyk sichtber:
- De URL befettet in soarte fan paadparameter - de ID fan 'e firtuele masine. It moat útsletten wurde.
- De URL befettet de modale finster ID. Jo moatte sokke URL's op ien of oare manier "útpakke".
In oar probleem wie dat de tige eveneminten wy markearre hie parameters. D'r wiene bygelyks fiif ferskillende manieren om nei de side te kommen mei ynformaasje oer in firtuele masine út 'e list. Dêrtroch waard ien evenemint stjoerd, mar mei in parameter dy't oanjûn hokker metoade de brûker makke de oergong. Der wiene in protte sokke eveneminten, en alle parameters wiene oars. En wy hawwe alle logika foar it opheljen fan gegevens yn it SQL-dialekt foar Clickhouse. Fragen fan 150-200 rigels begûnen wat gewoan te lykjen. Problemen omjûn ús.
Ynspiraasje #2
Op in iere moarn stelde Danil, spitigernôch troch it fersyk foar de twadde minút, my foar: "Litte wy pipelines foar gegevensferwurking skriuwe?" Wy tochten der oer en besletten dat as wy it soene dwaan, it soe wêze as ETL. Sadat it direkt filtert en de nedige gegevens út oare boarnen ophellet. Dit is hoe't ús earste analytyske tsjinst mei in folsleine backend waard berne. It ymplementearret fiif haadstappen fan gegevensferwurking:
- It laden fan eveneminten út 'e opslach fan rau gegevens en tariede se foar ferwurking.
- Ferklearring is it "útpakke" fan dy tige identifiers fan modale finsters, evenemintparameters en oare details dy't it barren ferdúdlikje.
- Ferriking (fan it wurd "ryk wurde") is it tafoegjen fan eveneminten mei gegevens fan boarnen fan tredden. Op dat stuit omfette dit allinich ús billingsysteem BILLmanager.
- Filterjen is it proses fan it filterjen fan eveneminten dy't de resultaten fan 'e analyse fersteure (barrens fan ynterne tribunes, útfallers, ensfh.).
- Opladen fan ûntfongen eveneminten yn opslach, dy't wy skjinne gegevens neamden.
No wie it mooglik om relevânsje te behâlden troch regels ta te foegjen foar it ferwurkjen fan in evenemint of sels groepen fan ferlykbere eveneminten. Bygelyks, sûnt doe hawwe wy nea bywurke URL unpacking. Hoewol, yn dizze tiid binne ferskate nije URL-fariaasjes tafoege. Se foldogge oan de regels dy't al fêstlein binne yn 'e tsjinst en wurde goed ferwurke.
Teloarstelling #3
Sadree't wy begûn te analysearjen, wy realisearre wêrom't de grafyk wie sa gearhingjend. It feit is dat hast elke N-gram transysjes befette dy't net troch de ynterface koe wurde útfierd.
In lyts ûndersyk begûn. Ik wie yn 'e war dat d'r gjin ûnmooglike transysjes wiene binnen ien entiteit. Dit betsjut dat dit gjin brek is yn it systeem foar samling fan eveneminten of ús ETL-tsjinst. D'r wie in gefoel dat de brûker tagelyk yn ferskate entiteiten wurke, sûnder fan de iene nei de oare te ferpleatsen. Hoe dit te berikken? It brûken fan ferskate ljeppers yn 'e browser.
By it analysearjen fan Cartbee waarden wy bewarre troch syn spesifisiteit. De applikaasje waard brûkt fan mobile apparaten, wêr't wurkjen fan ferskate ljeppers gewoan ûngemaklik is. Hjir hawwe wy in buroblêd en wylst in taak wurdt útfierd yn ien entiteit, is it ridlik om dizze tiid te besteegjen oan it ynstellen of kontrolearjen fan de status yn in oare. En om de foarútgong net te ferliezen, iepenje gewoan in oare ljepper.
Ynspiraasje #3
Kollega's fan front-end-ûntwikkeling learden it systeem foar samling fan eveneminten om te ûnderskieden tusken ljeppers. De analyze koe begjinne. En wy begûnen. Lykas ferwachte, kaam CJM net oerien mei echte paden: brûkers bestege in protte tiid oan mapsiden, ferlitten sesjes en ljeppers op 'e meast ûnferwachte plakken. Mei help fan oergongsanalyse koene wy problemen fine yn guon Mozilla-builds. Dêryn, troch ymplemintaasjefunksjes, ferdwûnen navigaasje-eleminten of waarden heallege siden werjûn, dy't allinich tagonklik wêze moatte foar de behearder. De side iepene, mar gjin ynhâld kaam fan 'e efterkant. It tellen fan transysjes makke it mooglik om te evaluearjen hokker funksjes eins waarden brûkt. De keatlingen makken it mooglik om te begripen hoe't de brûker dizze of dy flater krige. De gegevens tastien foar testen basearre op brûkersgedrach. It wie in súkses, it idee wie net om 'e nocht.
Analytics automatisearring
Yn ien fan 'e resultaten demonstraasjes hawwe wy sjen litten hoe't Gephi wurdt brûkt foar grafyk analyze. Yn dit ark kinne konverzjegegevens yn in tabel werjûn wurde. En it haad fan 'e UX-ôfdieling sei ien heul wichtige gedachte dy't de ûntwikkeling fan' e hiele gedrachsanalytyske rjochting yn it bedriuw beynfloede: "Litte wy itselde dwaan, mar yn Tableau en mei filters - it sil handiger wêze."
Doe tocht ik: wêrom net, Retentioneering bewarret alle gegevens yn in pandas.DataFrame-struktuer. En dit is, troch en grut, in tafel. Dit is hoe't in oare tsjinst ferskynde: Data Provider. Hy makke net allinnich in tabel út 'e grafyk, mar berekkene ek hoe populêr de side en de funksjonaliteit dy't dêrmei ferbûn binne, hoe't it ynfloed hat op brûkersbehâld, hoe lang brûkers der op bliuwe, en hokker siden brûkers it meast ferlitte. En it brûken fan fisualisaasje yn Tableau fermindere de kosten fan it studearjen fan 'e grafyk safolle dat de iteraasjetiid foar gedrachsanalyse yn it produkt hast halve waard.
Danil sil prate oer hoe't dizze fisualisaasje wurdt brûkt en hokker konklúzjes it kin lûke.
Mear tabellen foar de tafel god!
Yn in ferienfâldige foarm waard de taak as folget formulearre: werjaan de oergongsgrafyk yn Tableau, jouwe de mooglikheid om te filterjen, en meitsje it sa dúdlik en maklik mooglik.
Ik woe net echt tekenje in rjochte grafyk yn Tableau. En sels as suksesfol, like de winst, yn ferliking mei Gephi, net fanselssprekkend. Wy hiene wat folle ienfâldiger en tagonkliker nedich. Tafel! Ommers, de grafyk kin maklik wurde fertsjintwurdige yn 'e foarm fan tabel rigen, dêr't elke rige is in râne fan it type "boarne-bestimming". Boppedat hawwe wy sa'n tabel al soarchfâldich taret mei help fan Retentioneering en Data Provider-ark. Alles wat oerbleaun wie om de tabel yn Tableau wer te jaan en troch it rapport te rommeljen.
It praten oer hoe't elkenien hâldt fan tafels.
Hjir steane wy lykwols foar in oar probleem. Wat te dwaan mei de gegevensboarne? It wie ûnmooglik om panda's te ferbinen.DataFrame hat net sa'n ferbining. It ferheegjen fan in aparte basis foar it opslaan fan de grafyk like in te radikale oplossing mei vage perspektiven. En lokale lossen opsjes wiene net geskikt fanwege de needsaak foar konstante hânmjittich operaasjes. Wy seagen troch de list mei beskikbere Anschlüsse, en ús blik foel op it item , dy't fertrietlik op 'e ûnderen bûgde.
Tableau hat in rike seleksje fan Anschlüsse. Wy fûnen ien dy't ús probleem oplost
Wat foar bist? In pear nije iepen ljeppers yn 'e browser - en it waard dúdlik dat dizze ferbining jo gegevens kinne ûntfange as jo tagong krije ta in URL. De backend foar it berekkenjen fan de gegevens sels wie hast klear, alles wat oerbleau wie it befreone te meitsjen mei WDC. Foar ferskate dagen studearre Denis de dokumintaasje en fochten mei de Tableau-meganismen, en stjoerde my dan in keppeling dy't ik yn it ferbiningsfinster plakke.
Ferbiningsformulier nei ús WDC. Denis makke syn front en soarge foar feiligens
Nei in pear minuten wachtsjen (de gegevens wurde dynamysk berekkene op oanfrege), ferskynde de tabel:
Dit is hoe't in rûge gegevensarray derút sjocht yn 'e Tableau-ynterface
Lykas tasein, elke rige fan sa'n tabel fertsjintwurdige in râne fan 'e grafyk, dat is, in rjochte oergong fan de brûker. It befette ek ferskate ekstra skaaimerken. Bygelyks, it oantal unike brûkers, it totale oantal oergongen, en oaren.
It soe wêze mooglik om te werjaan dizze tabel yn it rapport as is, royaal sprinkle filters en stjoer it ark silen. Klinkt logysk. Wat kinne jo dwaan mei de tafel? Mar dit is net ús manier, om't wy net allinich in tabel meitsje, mar in ark foar analyse en it meitsjen fan produktbesluten.
Typysk, by it analysearjen fan gegevens, wol in persoan antwurden krije op fragen. Grut. Litte wy begjinne mei harren.
- Wat binne de meast foarkommende oergongen?
- Wêr komme se fan spesifike siden wei?
- Hoe lang besteegje jo gemiddeld op dizze side foardat jo fuortgean?
- Hoe faak meitsje jo de oergong fan A nei B?
- Op hokker siden einiget de sesje?
Elk fan 'e rapporten as in kombinaasje dêrfan moat de brûker selsstannich antwurden fine op dizze fragen. De wichtichste strategy hjir is om jo de ark te jaan om it sels te dwaan. Dit is nuttich sawol foar it ferminderjen fan de lading op 'e analytyske ôfdieling en foar it ferminderjen fan de tiid foar it meitsjen fan besluten - jo hoege ommers net mear nei Youtrack te gean en in taak foar de analyst te meitsjen, jo moatte gewoan it rapport iepenje.
Wat hawwe wy krigen?
Wêr divergje minsken it meast fan it dashboard?
Fragmint fan ús rapport. Nei it dashboard gie elkenien nei de list mei VM's of nei de list mei knopen
Litte wy in algemiene tabel nimme mei transysjes en filterje op boarneside. Meastentiids geane se fan it dashboard nei de list mei firtuele masines. Boppedat suggerearret de kolom Regelmjittichheid dat dit in werhelle aksje is.
Wêr komme se wei nei de list fan klusters?
Filters yn rapporten wurkje yn beide rjochtingen: jo kinne útfine wêr't jo fuortgien binne, of wêr't jo hinne gien binne
Ut de foarbylden is it dúdlik dat sels de oanwêzigens fan twa ienfâldige filters en ranglist rigen troch wearden kinne jo fluch krije ynformaasje.
Litte wy wat dreecher freegje.
Wêr ferlitte brûkers it meast har sesje?
VMmanager-brûkers wurkje faak yn aparte ljeppers
Om dit te dwaan, hawwe wy in rapport nedich wêrfan de gegevens wurde aggregearre troch ferwizingsboarnen. En de saneamde breakepoints waarden nommen as opdrachten - eveneminten dy't tsjinne as it ein fan 'e keten fan transysjes.
It is hjir wichtich om te notearjen dat dit it ein fan 'e sesje kin wêze as de iepening fan in nije ljepper. It foarbyld lit sjen dat de ketting meastentiids einiget oan in tafel mei in list mei firtuele masines. Yn dit gefal is it karakteristike gedrach oerskeakelje nei in oare ljepper, dy't oerienkomt mei it ferwachte patroan.
Wy hawwe earst it nut fan dizze rapporten op ússels hifke doe't wy de analyse op in fergelykbere manier útfierden , in oar fan ús produkten. Mei de komst fan tabellen en filters waarden hypotezen flugger hifke, en de eagen wiene minder wurch.
By it ûntwikkeljen fan rapporten binne wy net fergetten oer fisueel ûntwerp. By it wurkjen mei tabellen fan dizze grutte is dit in wichtige faktor. Bygelyks, wy brûkten in kalm oanbod fan kleuren, maklik te waarnimme foar nûmers, kleurmarkearring fan rigels yn oerienstimming mei de numerike wearden fan 'e skaaimerken. Sokke details ferbetterje de brûkersûnderfining en ferheegje de kâns dat it ark mei súkses nimt binnen it bedriuw.
De tabel blykte aardich voluminous te wêzen, mar wy hoopje dat it net langer lêsber is
It is it wurdich om apart te neamen oer de training fan ús ynterne kliïnten: produktspesjalisten en UX-ûntwerpers. Hânboeken mei analysefoarbylden en tips foar it wurkjen mei filters waarden spesjaal foar har taret. Wy ynfoege keppelings nei hânboeken direkt yn de rapport siden.
Wy makken de hantlieding gewoan as in presintaasje yn Google Docs. Tableau-ark kinne jo websiden direkt yn in rapportwurkboek werjaan.
Ynstee fan epilogue
Wat is yn 'e ûnderste rigel? Wy koene relatyf fluch en goedkeap in ark foar elke dei krije. Ja, dit is perfoarst gjin ferfanging foar de grafyk sels, de waarmtekaart fan klikken of de webwerjouwer. Mar sokke rapporten komplementearje de neamde ark signifikant en jouwe iten foar tinken en nije produkt- en ynterface-hypoteses.
Dit ferhaal tsjinne allinnich as it begjin foar de ûntwikkeling fan analytics yn ISPsystem. Yn 'e ôfrûne seis moannen binne noch sân nije tsjinsten ferskynd, ynklusyf digitale portretten fan' e brûker yn it produkt en in tsjinst foar it meitsjen fan databases foar Look-alike-targeting, mar wy sille oer har prate yn 'e folgjende ôfleverings.
Boarne: www.habr.com