Daar is honderde artikels op die internet oor die voordele van die ontleding van kliëntegedrag. Meestal gaan dit oor die kleinhandelsektor. Van voedselmandjie-ontleding, ABC- en XYZ-analise tot retensiebemarking en persoonlike aanbiedinge. Verskeie tegnieke word al vir dekades gebruik, die algoritmes is uitgedink, die kode is geskryf en ontfout – neem dit en gebruik dit. In ons geval het een fundamentele probleem ontstaan - ons by ISPsystem is besig met sagteware-ontwikkeling, nie kleinhandel nie.
My naam is Denis en ek is tans verantwoordelik vir die agterkant van analitiese stelsels by ISPsystem. En dit is die storie van hoe ek en my kollega - diegene wat verantwoordelik is vir datavisualisering - het probeer om na ons sagtewareprodukte te kyk deur die prisma van hierdie kennis. Kom ons begin, soos gewoonlik, met geskiedenis.
In die begin was daar 'n woord, en die woord was "Sal ons probeer?"
Op daardie oomblik het ek as 'n ontwikkelaar in die R&D-afdeling gewerk. Dit het alles begin toe Danil hier op Habré gelees het - 'n hulpmiddel vir die ontleding van gebruikersoorgange in toepassings. Ek was ietwat skepties oor die idee om dit hier te gebruik. As voorbeelde het die biblioteekontwikkelaars 'n ontleding van toepassings aangehaal waar die teikenaksie duidelik omskryf is - die plaas van 'n bestelling of 'n ander variasie van hoe om die eienaarmaatskappy te betaal. Ons produkte word op die perseel verskaf. Dit wil sê, die gebruiker koop eers 'n lisensie, en begin dan eers sy reis in die toepassing. Ja, ons het demo-weergawes. Jy kan die produk daar probeer sodat jy nie 'n vark in 'n pot het nie.
Maar die meeste van ons produkte is gemik op die gasheermark. Dit is groot kliënte, en die besigheidsontwikkelingsafdeling gee hulle raad oor produkvermoëns. Dit volg ook dat ons kliënte ten tyde van aankoop reeds weet watter probleme ons sagteware hulle sal help om op te los. Hul roetes in die toepassing moet saamval met die CJM wat in die produk ingebed is, en UX-oplossings sal hulle help om op koers te bly. Bederf: dit gebeur nie altyd nie. Die inleiding tot die biblioteek is uitgestel... maar nie vir lank nie.
Alles het verander met die vrystelling van ons opstart - - platforms vir die skep van 'n aanlyn winkel vanaf 'n Instagram-rekening. In hierdie toepassing het die gebruiker 'n tydperk van twee weke gekry om alle funksies gratis te gebruik. Dan moes jy besluit of jy gaan inteken. En dit pas perfek by die "roete-teiken-aksie"-konsep. Daar is besluit: kom ons probeer!
Eerste resultate of waar om idees vandaan te kry
Ek en die ontwikkelingspan het die produk letterlik in 'n dag aan die gebeurtenis-insamelingstelsel gekoppel. Ek sal dadelik sê dat ISPsystem sy eie stelsel gebruik om gebeurtenisse oor bladsybesoeke in te samel, maar niks verhinder jou om Yandex.Metrica vir dieselfde doeleindes te gebruik nie, wat jou toelaat om rou data gratis af te laai. Voorbeelde van die gebruik van die biblioteek is bestudeer, en na 'n week van data-insameling het ons 'n oorgangsgrafiek ontvang.
Oorgangsgrafiek. Basiese funksionaliteit, ander oorgange verwyder vir duidelikheid
Dit het geblyk net soos in die voorbeeld: vlak, helder, pragtig. Uit hierdie grafiek kon ons die mees gereelde roetes en kruisings identifiseer waar mense die langste tyd deurbring. Dit het ons in staat gestel om die volgende te verstaan:
- In plaas van 'n groot CJM, wat 'n dosyn entiteite dek, word slegs twee aktief gebruik. Dit is nodig om gebruikers addisioneel na die plekke te lei wat ons benodig deur UX-oplossings te gebruik.
- Sommige bladsye, ontwerp deur UX-ontwerpers om end-tot-end te wees, eindig met mense wat 'n onredelike hoeveelheid tyd daaraan spandeer. Jy moet uitvind wat die stop-elemente op 'n spesifieke bladsy is en dit aanpas.
- Na 10 oorgange het 20% van mense begin moeg word en die sessie in die toepassing verlaat. En dit neem die feit in ag dat ons soveel as 5 aanboordbladsye in die toepassing gehad het! Jy moet bladsye identifiseer waar gebruikers gereeld sessies laat vaar en die pad na hulle verkort. Nog beter: identifiseer enige gereelde roetes en laat 'n vinnige oorgang van die bronbladsy na die bestemmingbladsy toe. Iets gemeen met ABC-analise en verlate wa-analise, dink jy nie?
En hier het ons ons houding teenoor die toepaslikheid van hierdie instrument vir produkte op die perseel heroorweeg. Daar is besluit om 'n aktief verkoop en gebruikte produk te ontleed - . Dit is baie meer kompleks, daar is 'n orde van grootte meer entiteite. Ons het opgewonde gewag om te sien wat die oorgangsgrafiek sou blyk te wees.
Oor teleurstellings en inspirasies
Teleurstelling #1
Dit was die einde van die werksdag, die einde van die maand en die einde van die jaar op dieselfde tyd – 27 Desember. Data is opgehoop, navrae is geskryf. Daar was sekondes oor voordat alles verwerk is en ons kon na die resultaat van ons arbeid kyk om uit te vind waar die volgende werksjaar sou begin. Die R&D-afdeling, produkbestuurder, UX-ontwerpers, spanleier, ontwikkelaars het voor die monitor bymekaargekom om te sien hoe die gebruikerspaaie in hul produk lyk, maar ... ons het dit gesien:
Oorgangsgrafiek gebou deur die Retentioneering-biblioteek
Inspirasie #1
Sterk verbind, dosyne entiteite, nie-vanselfsprekende scenario's. Dit was net duidelik dat die nuwe werksjaar nie met ontleding sou begin nie, maar met die uitvind van 'n manier om werk met so 'n grafiek te vereenvoudig. Maar ek kon nie die gevoel skud dat alles baie eenvoudiger was as wat dit gelyk het nie. En na vyftien minute se bestudering van die Retentioneering-bronkode, kon ons die gekonstrueerde grafiek na puntformaat uitvoer. Dit het dit moontlik gemaak om die grafiek op te laai na 'n ander instrument - Gephi. En daar is reeds ruimte vir die ontleding van grafieke: uitlegte, filters, statistieke - al wat jy hoef te doen is om die nodige parameters in die koppelvlak op te stel. Met hierdie gedagte in gedagte is ons weg vir Nuwejaarsnaweek.
Teleurstelling #2
Nadat hulle teruggekeer het werk toe, het dit geblyk dat terwyl almal rus, ons kliënte die produk bestudeer het. Ja, so hard dat gebeure in die stoor verskyn het wat nie voorheen bestaan het nie. Dit het beteken dat die navrae opgedateer moes word.
'n Bietjie agtergrond om die hartseer van hierdie feit te verstaan. Ons stuur beide die gebeurtenisse wat ons gemerk het (byvoorbeeld klik op sommige knoppies) en die URL's van die bladsye wat die gebruiker besoek het. In die geval van Cartbee het die "een aksie - een bladsy" model gewerk. Maar met VMmanager was die situasie heeltemal anders: verskeie modale vensters kon op een bladsy oopmaak. Daarin kan die gebruiker verskeie probleme oplos. Byvoorbeeld, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
beteken dat die gebruiker op die "IP-adresse"-bladsy 'n IP-adres bygevoeg het. En hier is twee probleme tegelyk sigbaar:
- Die URL bevat 'n soort padparameter - die ID van die virtuele masjien. Dit moet uitgesluit word.
- Die URL bevat die modale venster ID. Jy moet op een of ander manier sulke URL's "uitpak".
Nog 'n probleem was dat die einste gebeurtenisse wat ons gemerk het, parameters gehad het. Daar was byvoorbeeld vyf verskillende maniere om by die bladsy uit te kom met inligting oor 'n virtuele masjien uit die lys. Gevolglik is een gebeurtenis gestuur, maar met 'n parameter wat aandui watter metode die gebruiker die oorgang gemaak het. Daar was baie sulke gebeurtenisse, en al die parameters was anders. En ons het al die data-herwinningslogika in die SQL-dialek vir Clickhouse. Navrae vir 150-200 reëls het na iets bekend begin lyk. Probleme het ons omring.
Inspirasie #2
Een vroegoggend het Danil, wat ongelukkig vir die tweede minuut deur die versoek blaai, aan my voorgestel: "Kom ons skryf dataverwerkingspyplyne?" Ons het daaroor gedink en besluit dat as ons dit gaan doen, dit iets soos ETL sal wees. Sodat dit onmiddellik filtreer en die nodige data van ander bronne optrek. Dit is hoe ons eerste analitiese diens met 'n volwaardige backend gebore is. Dit implementeer vyf hoofstadia van dataverwerking:
- Laai gebeure uit die stoor van rou data en berei hulle voor vir verwerking.
- Opheldering is die "uitpak" van daardie einste identifiseerders van modale vensters, gebeurtenisparameters en ander besonderhede wat die gebeurtenis verduidelik.
- Verryking (van die woord "om ryk te word") is die byvoeging van gebeurtenisse met data van derdeparty-bronne. Op daardie tydstip het dit net ons faktureringstelsel BILLmanager ingesluit.
- Filtrering is die proses om gebeurtenisse uit te filter wat die resultate van die analise verdraai (gebeurtenisse vanaf interne erwe, uitskieters, ens.).
- Laai van ontvangde gebeurtenisse na berging op, wat ons skoon data genoem het.
Nou was dit moontlik om relevansie te behou deur reëls by te voeg vir die verwerking van 'n gebeurtenis of selfs groepe soortgelyke gebeurtenisse. Byvoorbeeld, sedertdien het ons nooit URL-uitpak opgedateer nie. Alhoewel, gedurende hierdie tyd is verskeie nuwe URL-variasies bygevoeg. Hulle voldoen aan die reëls wat reeds in die diens neergelê is en word korrek verwerk.
Teleurstelling #3
Sodra ons begin analiseer het, het ons besef hoekom die grafiek so koherent was. Die feit is dat byna elke N-gram oorgange bevat het wat nie deur die koppelvlak uitgevoer kon word nie.
’n Klein ondersoek het begin. Ek was verward dat daar geen onmoontlike oorgange binne een entiteit was nie. Dit beteken dat dit nie 'n fout in die gebeurtenis-insamelingstelsel of ons ETL-diens is nie. Daar was 'n gevoel dat die gebruiker gelyktydig in verskeie entiteite werk, sonder om van die een na die ander te beweeg. Hoe om dit te bereik? Gebruik verskillende oortjies in die blaaier.
Toe ons Cartbee ontleed, is ons gered deur sy spesifisiteit. Die toepassing is vanaf mobiele toestelle gebruik, waar dit eenvoudig ongerieflik is om vanaf verskeie oortjies te werk. Hier het ons 'n lessenaar en terwyl 'n taak in een entiteit uitgevoer word, is dit redelik om hierdie tyd te wil spandeer om die status in 'n ander op te stel of te monitor. En om nie vordering te verloor nie, maak net 'n ander oortjie oop.
Inspirasie #3
Kollegas van front-end ontwikkeling het die gebeurtenis-insamelingstelsel geleer om tussen oortjies te onderskei. Die ontleding kan begin. En ons het begin. Soos verwag, het CJM nie ooreenstem met regte paaie nie: gebruikers het baie tyd spandeer op gidsbladsye, verlate sessies en oortjies op die mees onverwagte plekke. Deur oorgangsanalise te gebruik, kon ons probleme in sommige Mozilla-geboue vind. Daarin het navigasie-elemente weens implementeringskenmerke verdwyn of is halfleë bladsye vertoon, wat slegs vir die administrateur toeganklik behoort te wees. Die bladsy het oopgemaak, maar geen inhoud het van die agterkant af gekom nie. Deur oorgange te tel het dit moontlik gemaak om te evalueer watter kenmerke werklik gebruik is. Die kettings het dit moontlik gemaak om te verstaan hoe die gebruiker hierdie of daardie fout ontvang het. Die data wat toegelaat word vir toetsing op grond van gebruikersgedrag. Dit was 'n sukses, die idee was nie verniet nie.
Analytics outomatisering
In een van die resultate-demonstrasies het ons gewys hoe Gephi vir grafiekanalise gebruik word. In hierdie instrument kan omskakelingsdata in 'n tabel vertoon word. En die hoof van die UX-afdeling het gesê een baie belangrike gedagte wat die ontwikkeling van die hele gedragsanalise-rigting in die maatskappy beïnvloed het: "Kom ons doen dieselfde, maar in Tableau en met filters - dit sal geriefliker wees."
Toe dink ek: hoekom nie, Retentioneering stoor alle data in 'n pandas.DataFrame-struktuur. En dit is in die algemeen 'n tafel. Dit is hoe 'n ander diens verskyn het: Data Verskaffer. Hy het nie net 'n tabel uit die grafiek gemaak nie, maar ook bereken hoe gewild die bladsy en die funksionaliteit wat daarmee geassosieer word, is, hoe dit gebruikersbehoud beïnvloed, hoe lank gebruikers daarop bly en watter bladsye gebruikers die meeste verlaat. En die gebruik van visualisering in Tableau het die koste om die grafiek te bestudeer so verminder dat die iterasietyd vir gedragsanalise in die produk byna gehalveer is.
Danil sal praat oor hoe hierdie visualisering gebruik word en watter gevolgtrekkings dit toelaat om te maak.
Meer tafels vir die tafelgod!
In 'n vereenvoudigde vorm is die taak soos volg geformuleer: vertoon die oorgangsgrafiek in Tableau, verskaf die vermoë om te filter, en maak dit so duidelik en gerieflik as moontlik.
Ek wou nie regtig 'n gerigte grafiek in Tableau teken nie. En selfs al was dit suksesvol, het die wins, in vergelyking met Gephi, nie ooglopend gelyk nie. Ons het iets baie eenvoudiger en meer toeganklik nodig gehad. Tafel! Die grafiek kan immers maklik in die vorm van tabelrye voorgestel word, waar elke ry 'n rand van die "bron-bestemming" tipe is. Boonop het ons reeds so 'n tabel noukeurig voorberei deur gebruik te maak van Retentioneering en Data Provider-nutsgoed. Al wat oorgebly het, was om die tabel in Tableau te vertoon en deur die verslag te vroetel.
Gepraat van hoe almal lief is vir tafels.
Hier sit ons egter met 'n ander probleem. Wat om te doen met die databron? Dit was onmoontlik om pandas te koppel.Dataraam; Tableau het nie so 'n koppelaar nie. Om 'n aparte basis vir die stoor van die grafiek op te stel, het te radikale oplossing gelyk met vae vooruitsigte. En plaaslike aflaaiopsies was nie geskik nie weens die behoefte aan konstante handbewerkings. Ons het deur die lys van beskikbare verbindings gekyk, en ons blik het op die item geval , wat verlate heel onder saamgedrom het.
Tableau het 'n ryk keuse van verbindings. Ons het een gevind wat ons probleem opgelos het
Watter soort dier? 'n Paar nuwe oop oortjies in die blaaier - en dit het duidelik geword dat hierdie verbinding jou toelaat om data te ontvang wanneer jy toegang tot 'n URL kry. Die agterkant vir die berekening van die data self was amper gereed, al wat oorgebly het, was om dit vriende te maak met WDC. Vir 'n paar dae het Denis die dokumentasie bestudeer en met die Tableau-meganismes baklei, en toe vir my 'n skakel gestuur wat ek in die verbindingsvenster geplak het.
Aansluitingsvorm na ons WDC. Denis het sy front gemaak en gesorg vir veiligheid
Na 'n paar minute se wag (die data word dinamies bereken wanneer dit versoek word), het die tabel verskyn:
Dit is hoe 'n rou data-skikking lyk in die Tableau-koppelvlak
Soos belowe het elke ry van so 'n tabel 'n rand van die grafiek verteenwoordig, dit wil sê 'n gerigte oorgang van die gebruiker. Dit het ook verskeie bykomende kenmerke bevat. Byvoorbeeld, die aantal unieke gebruikers, die totale aantal oorgange, en ander.
Dit sou moontlik wees om hierdie tabel in die verslag te vertoon soos dit is, mildelik filters te strooi en die gereedskap te laat vaar. Klink logies. Wat kan jy met die tafel doen? Maar dit is nie ons manier nie, want ons maak nie net 'n tabel nie, maar 'n hulpmiddel vir ontleding en produkbesluite.
Tipies, wanneer 'n persoon data ontleed, wil 'n persoon antwoorde op vrae kry. Groot. Kom ons begin met hulle.
- Wat is die mees algemene oorgange?
- Waarheen gaan hulle van spesifieke bladsye af?
- Hoe lank spandeer jy gemiddeld op hierdie bladsy voordat jy vertrek?
- Hoe gereeld maak jy die oorgang van A na B?
- Op watter bladsye eindig die sessie?
Elkeen van die verslae of 'n kombinasie daarvan behoort die gebruiker in staat te stel om onafhanklik antwoorde op hierdie vrae te vind. Die sleutelstrategie hier is om jou die gereedskap te gee om dit self te doen. Dit is nuttig om beide die las op die ontledingsafdeling te verminder en om die tyd vir besluitneming te verminder - jy hoef immers nie meer na Youtrack te gaan en 'n taak vir die ontleder te skep nie, jy hoef net die verslag oop te maak.
Wat het ons gekry?
Waar wyk mense die meeste van die paneelbord af?
Fragment van ons verslag. Na die dashboard het almal óf na die lys van VM's óf na die lys van nodusse gegaan
Kom ons neem 'n algemene tabel met oorgange en filter volgens bronbladsy. Dikwels gaan hulle van die dashboard na die lys van virtuele masjiene. Boonop dui die Gereeldheid-kolom daarop dat dit 'n herhalende aksie is.
Waar kom hulle vandaan na die lys van trosse?
Filters in verslae werk in beide rigtings: jy kan uitvind waar jy weg is, of waarheen jy gegaan het
Uit die voorbeelde is dit duidelik dat selfs die teenwoordigheid van twee eenvoudige filters en rangorde van rye volgens waardes jou in staat stel om vinnig inligting te bekom.
Kom ons vra iets moeiliker.
Waar laat gebruikers hul sessie die meeste?
VMmanager-gebruikers werk dikwels in aparte oortjies
Om dit te doen, benodig ons 'n verslag waarvan die data deur verwysingsbronne saamgevoeg word. En die sogenaamde breekpunte is as opdragte geneem – gebeure wat as die einde van die ketting van oorgange gedien het.
Dit is belangrik om hier op te let dat dit óf die einde van die sessie óf die opening van 'n nuwe oortjie kan wees. Die voorbeeld toon dat die ketting meestal eindig by 'n tafel met 'n lys van virtuele masjiene. In hierdie geval is die kenmerkende gedrag die oorskakeling na 'n ander oortjie, wat ooreenstem met die verwagte patroon.
Ons het eerstens die bruikbaarheid van hierdie verslae op onsself getoets toe ons die ontleding op 'n soortgelyke manier uitgevoer het , nog een van ons produkte. Met die koms van tabelle en filters is hipoteses vinniger getoets, en die oë was minder moeg.
Toe ons verslae ontwikkel het, het ons nie van visuele ontwerp vergeet nie. Wanneer u met tafels van hierdie grootte werk, is dit 'n belangrike faktor. Ons het byvoorbeeld 'n rustige reeks kleure gebruik, maklik om waar te neem vir getalle, kleurverligting van lyne in ooreenstemming met die numeriese waardes van die eienskappe. Sulke besonderhede verbeter die gebruikerservaring en verhoog die waarskynlikheid dat die instrument suksesvol binne die maatskappy sal opstyg.
Die tabel blyk nogal lywig te wees, maar ons hoop dit het nie opgehou om leesbaar te wees nie
Dit is die moeite werd om afsonderlik te noem oor die opleiding van ons interne kliënte: produkspesialiste en UX-ontwerpers. Handleidings met ontledingsvoorbeelde en wenke om met filters te werk is spesiaal daarvoor voorberei. Ons het skakels na handleidings direk in die verslagbladsye ingevoeg.
Ons het die handleiding bloot as 'n aanbieding in Google Docs gemaak. Tableau-nutsgoed laat jou toe om webblaaie direk binne 'n verslagwerkboek te vertoon.
In plaas van 'n naslaanwoord
Wat is in die onderste lyn? Ons kon relatief vinnig en goedkoop 'n gereedskap vir elke dag kry. Ja, dit is beslis nie 'n plaasvervanger vir die grafiek self, die hittekaart van klikke of die webkyker nie. Maar sulke verslae vul die gelyste gereedskap aansienlik aan en verskaf stof tot nadenke en nuwe produk- en koppelvlakhipoteses.
Hierdie storie het slegs gedien as die begin vir die ontwikkeling van analise in ISP-stelsel. Oor die afgelope ses maande het nog sewe nuwe dienste verskyn, insluitend digitale portrette van die gebruiker in die produk en 'n diens om databasisse vir Look-alike teiken te skep, maar ons sal daaroor in die volgende episodes praat.
Bron: will.com