Internetissä on satoja artikkeleita asiakkaiden käyttäytymisen analysoinnin eduista. Useimmiten tämä koskee vähittäiskauppaa. Ruokakorianalyysistä, ABC- ja XYZ-analyysistä säilyttämismarkkinointiin ja henkilökohtaisiin tarjouksiin. Erilaisia tekniikoita on käytetty vuosikymmeniä, algoritmit on mietitty, koodi on kirjoitettu ja virheenkorjattu - ota ja käytä. Meidän tapauksessamme syntyi yksi perustavanlaatuinen ongelma - me ISPsystemillä harjoitamme ohjelmistokehitystä, emme vähittäiskauppaa.
Nimeni on Denis ja olen tällä hetkellä vastuussa ISPsystemin analyyttisten järjestelmien taustajärjestelmästä. Ja tämä on tarina siitä, kuinka kollegani ja minä — tietojen visualisoinnista vastaavat — yrittivät tarkastella ohjelmistotuotteitamme tämän tiedon prisman kautta. Aloitetaan, kuten tavallista, historiasta.
Alussa oli sana, ja sana oli "Yritetäänkö?"
Työskentelin sillä hetkellä tuotekehittäjänä T&K-osastolla. Kaikki alkoi, kun Danil luki täällä Habresta — työkalu käyttäjien siirtymien analysoimiseen sovelluksissa. Suhtauduin hieman skeptisesti ajatukseen käyttää sitä täällä. Esimerkkeinä kirjaston kehittäjät nostivat sovellusanalyysin, jossa kohdetoiminta oli selkeästi määritelty - tilaus tai jokin muu muunnelma siitä, miten omistajayritykselle maksetaan. Tuotteemme toimitetaan paikan päällä. Eli käyttäjä ostaa ensin lisenssin ja vasta sitten aloittaa matkansa sovelluksessa. Kyllä, meillä on demoversioita. Voit kokeilla tuotetta siellä, jotta sinulla ei ole sikaa säkissä.
Mutta suurin osa tuotteistamme on suunnattu hosting-markkinoille. Nämä ovat suuria asiakkaita, ja liiketoiminnan kehitysosasto neuvoo heitä tuoteominaisuuksissa. Tästä seuraa myös, että asiakkaamme tietävät jo ostohetkellä, mitä ongelmia ohjelmistomme auttaa ratkaisemaan. Heidän reittiensä sovelluksessa on oltava samat tuotteeseen upotetun CJM:n kanssa, ja UX-ratkaisut auttavat heitä pysymään raiteilla. Spoileri: näin ei aina tapahdu. Kirjaston esittelyä lykättiin... mutta ei kauaa.
Kaikki muuttui käynnistyksemme julkaisun myötä - — alustat verkkokaupan luomiseen Instagram-tililtä. Tässä sovelluksessa käyttäjälle annettiin kahden viikon aika käyttää kaikkia toimintoja ilmaiseksi. Sitten piti päättää, haluatko tilata. Ja tämä sopii täydellisesti "reittikohteen toiminta" -konseptiin. Päätettiin: kokeillaan!
Ensimmäiset tulokset tai mistä saada ideoita
Yhdistimme kehitystiimin kanssa tuotteen tapahtumakeräysjärjestelmään kirjaimellisesti päivässä. Sanon heti, että ISPsystem käyttää omaa järjestelmäänsä kerätäkseen tapahtumia sivuvierailuista, mutta mikään ei estä sinua käyttämästä Yandex.Metricaa samoihin tarkoituksiin, jonka avulla voit ladata raakadataa ilmaiseksi. Esimerkkejä kirjaston käytöstä tutkittiin ja viikon tiedonkeruun jälkeen saimme siirtymäkaavion.
Siirtymäkaavio. Perustoiminnot, muut siirtymät poistettu selvyyden vuoksi
Se osoittautui aivan kuten esimerkissä: tasomainen, selkeä, kaunis. Tämän kaavion perusteella pystyimme tunnistamaan yleisimmät reitit ja risteykset, joissa ihmiset viettävät pisimpään aikaa. Tämä antoi meille mahdollisuuden ymmärtää seuraavaa:
- Suuren CJM:n sijaan, joka kattaa tusina kokonaisuutta, vain kaksi on aktiivisessa käytössä. Lisäksi on tarpeen ohjata käyttäjiä tarvitsemiimme paikkoihin käyttämällä UX-ratkaisuja.
- Jotkut sivut, jotka UX-suunnittelijat ovat suunnitelleet päästä päähän, päätyvät siihen, että ihmiset käyttävät niille kohtuuttoman paljon aikaa. Sinun on selvitettävä, mitkä pysäytyselementit ovat tietyllä sivulla ja säädettävä sitä.
- 10 siirtymän jälkeen 20 % ihmisistä alkoi väsyä ja lopetti istunnon sovelluksessa. Ja tässä otetaan huomioon se tosiasia, että meillä oli hakemuksessa jopa 5 perehdytyssivua! Sinun on tunnistettava sivut, joilla käyttäjät keskeyttävät säännöllisesti istuntoja, ja lyhennettävä polkua niihin. Vielä parempi: tunnista säännölliset reitit ja salli nopea siirtyminen lähdesivulta kohdesivulle. Jotain yhteistä ABC-analyysin ja hylättyjen kärryjen analyysin kanssa, vai mitä?
Ja tässä mietimme uudelleen suhtautumistamme tämän työkalun soveltuvuuteen paikan päällä oleviin tuotteisiin. Aktiivisesti myytyä ja käytettyä tuotetta päätettiin analysoida - . Se on paljon monimutkaisempi, kokonaisuuksia on suuruusluokkaa enemmän. Odotimme innolla, millainen siirtymäkaaviosta tulee.
Pettymyksistä ja inspiraatioista
Pettymys #1
Oli työpäivän, kuukauden ja vuoden loppu samaan aikaan - 27. joulukuuta. Dataa on kertynyt, kyselyitä on kirjoitettu. Jäljellä oli sekunteja ennen kuin kaikki oli käsitelty ja saimme katsoa työmme tulosta selvittääksemme, mistä seuraava työvuosi alkaa. T&K-osasto, tuotepäällikkö, UX-suunnittelijat, tiiminvetäjä, kehittäjät kokoontuivat näytön eteen katsomaan, miltä heidän tuotteensa käyttäjäpolut näyttävät, mutta... näimme tämän:
Retentioneering-kirjaston rakentama siirtymäkaavio
Inspiraatio nro 1
Vahvasti yhteydessä, kymmeniä kokonaisuuksia, ei-ilmeisiä skenaarioita. Oli vain selvää, että uusi työvuosi ei alkaisi analysoinnilla, vaan keksimällä tapa yksinkertaistaa työtä tällaisen kaavion avulla. Mutta en voinut päästä eroon tunteesta, että kaikki oli paljon yksinkertaisempaa kuin miltä näytti. Ja kun olimme tutkineet Retentioneering-lähdekoodia XNUMX minuuttia, pystyimme viemään rakennetun kaavion pistemuotoon. Tämä mahdollisti kaavion lataamisen toiseen työkaluun - Gephiin. Ja kaavioiden analysointiin on jo tilaa: asettelut, suodattimet, tilastot - sinun tarvitsee vain määrittää tarvittavat parametrit käyttöliittymässä. Tällä ajatuksella lähdimme uudenvuoden viikonloppuun.
Pettymys #2
Töihin palattuaan kävi ilmi, että kun kaikki lepäsivät, asiakkaamme tutkivat tuotetta. Kyllä, niin kovaa, että tallennustilaan ilmestyi tapahtumia, joita ei ennen ollut. Tämä tarkoitti, että kyselyt piti päivittää.
Hieman taustaa ymmärtääksesi tämän tosiasian surun. Välitämme sekä merkitsemämme tapahtumat (esimerkiksi joidenkin painikkeiden napsautukset) että niiden sivujen URL-osoitteet, joilla käyttäjä vieraili. Cartbeen tapauksessa "yksi toiminta - yksi sivu" -malli toimi. Mutta VMmanagerin kanssa tilanne oli täysin erilainen: yhdelle sivulle saattoi avautua useita modaalisia ikkunoita. Niissä käyttäjä voi ratkaista erilaisia ongelmia. Esimerkiksi URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
tarkoittaa, että käyttäjä lisäsi IP-osoitteen "IP-osoitteet" -sivulle. Ja tässä näkyy kaksi ongelmaa kerralla:
- URL sisältää jonkinlaisen polkuparametrin - virtuaalikoneen tunnuksen. Se on suljettava pois.
- URL-osoite sisältää modaalisen ikkunan tunnuksen. Sinun on jotenkin "purettava" tällaiset URL-osoitteet.
Toinen ongelma oli, että juuri merkityillä tapahtumilla oli parametreja. Oli esimerkiksi viisi eri tapaa päästä sivulle, jolla on luettelosta virtuaalikoneen tietoja. Vastaavasti lähetettiin yksi tapahtuma, mutta parametrilla, joka osoitti millä menetelmällä käyttäjä siirtyi. Tällaisia tapahtumia oli monia, ja kaikki parametrit olivat erilaisia. Ja meillä on kaikki tiedonhakulogiikka Clickhousen SQL-murteella. 150-200 rivin kyselyt alkoivat tuntua jokseenkin yleisiltä. Ongelmat ympäröivät meitä.
Inspiraatio nro 2
Eräänä varhain aamuna Danil, selaillessaan surullisesti pyyntöä toisen minuutin ajan, ehdotti minulle: "Kirjoitetaanko tietojenkäsittelyputkia?" Ajattelimme sitä ja päätimme, että jos aiomme tehdä sen, se olisi jotain ETL:n kaltaista. Joten se suodattaa välittömästi ja hakee tarvittavat tiedot muista lähteistä. Näin syntyi ensimmäinen analyyttinen palvelumme täysimittaisella taustalla. Se toteuttaa viisi tietojenkäsittelyn päävaihetta:
- Tapahtumien purkaminen raakatietovarastosta ja valmistelu käsittelyä varten.
- Selkeyttäminen on juuri niiden modaaliikkunoiden tunnisteiden, tapahtumaparametrien ja muiden tapahtumaa selventävien yksityiskohtien "purkamista".
- Rikastaminen (sanasta "rikastua") tarkoittaa tapahtumien lisäämistä kolmannen osapuolen lähteistä peräisin olevaan dataan. Tuolloin tähän sisältyi vain laskutusjärjestelmämme BILLmanager.
- Suodatus on prosessi, jossa suodatetaan pois tapahtumat, jotka vääristävät analyysin tuloksia (tapahtumat sisäisiltä osastoilta, poikkeamat jne.).
- Vastaanotettujen tapahtumien lataaminen tallennustilaan, jota kutsuimme puhtaaksi dataksi.
Nyt oli mahdollista ylläpitää relevanssia lisäämällä sääntöjä tapahtuman tai jopa samankaltaisten tapahtumien käsittelyyn. Emme ole esimerkiksi koskaan päivittäneet URL-osoitteen purkamista sen jälkeen. Tänä aikana on kuitenkin lisätty useita uusia URL-muunnelmia. Ne ovat palvelussa jo vahvistettujen sääntöjen mukaisia ja niitä käsitellään oikein.
Pettymys #3
Kun aloimme analysoida, ymmärsimme, miksi kaavio oli niin yhtenäinen. Tosiasia on, että melkein jokainen N-grammi sisälsi siirtymiä, joita ei voitu suorittaa käyttöliittymän kautta.
Alkoi pieni tutkinta. Olin hämmentynyt siitä, ettei yhden kokonaisuuden sisällä ollut mahdottomia siirtymiä. Tämä tarkoittaa, että tämä ei ole virhe tapahtumakeräysjärjestelmässä tai ETL-palvelussamme. Tuli tunne, että käyttäjä työskenteli samanaikaisesti useassa entiteetissä siirtymättä yhdestä toiseen. Miten tämä saavutetaan? Eri välilehtien käyttäminen selaimessa.
Cartbeeta analysoiessamme sen spesifisyys pelasti meidät. Sovellusta käytettiin mobiililaitteista, joissa useista välilehdistä työskentely on yksinkertaisesti hankalaa. Täällä meillä on työpöytä ja kun tehtävää suoritetaan yhdessä entiteetissä, on järkevää haluta käyttää tämä aika määrittämään tai valvomaan tilaa toisessa. Ja jotta et menetä edistymistä, avaa vain toinen välilehti.
Inspiraatio nro 3
Työtoverit käyttöliittymäkehityksestä opettivat tapahtumakeräysjärjestelmän erottamaan välilehdet. Analyysi voi alkaa. Ja aloitimme. Kuten odotettiin, CJM ei vastannut todellisia polkuja: käyttäjät viettivät paljon aikaa hakemistosivuilla, hylätyillä istunnoilla ja välilehdillä odottamattomimmissa paikoissa. Siirtymäanalyysin avulla pystyimme löytämään ongelmia joissakin Mozilla-versioissa. Niissä toteutusominaisuuksien vuoksi navigointielementit katosivat tai näkyi puolityhjät sivut, joihin pitäisi päästä vain ylläpitäjällä. Sivu avattiin, mutta taustaohjelmasta ei tullut sisältöä. Siirtymien laskeminen mahdollisti sen arvioimisen, mitä ominaisuuksia todella käytettiin. Ketjujen avulla oli mahdollista ymmärtää, kuinka käyttäjä sai tämän tai toisen virheen. Data sallittiin testaukseen käyttäjien käyttäytymisen perusteella. Se oli menestys, idea ei ollut turha.
Analyticsin automatisointi
Yhdessä tulosesittelyssä osoitimme, kuinka Gephiä käytetään graafianalyysiin. Tässä työkalussa tulostiedot voidaan näyttää taulukossa. Ja UX-osaston johtaja sanoi yhden erittäin tärkeän ajatuksen, joka vaikutti koko käyttäytymisanalytiikkasuunnan kehitykseen yrityksessä: "Tehdään samoin, mutta Tableaussa ja suodattimilla - se on kätevämpää."
Sitten ajattelin: miksi ei, Retentioneering tallentaa kaikki tiedot pandas.DataFrame-rakenteeseen. Ja tämä on suurelta osin pöytä. Näin ilmestyi toinen palvelu: Data Provider. Hän ei vain tehnyt kaaviosta taulukkoa, vaan myös laskenut, kuinka suosittu sivu ja siihen liittyvät toiminnot ovat, miten se vaikuttaa käyttäjien säilyttämiseen, kuinka kauan käyttäjät viipyvät sillä ja miltä sivuilta käyttäjät poistuvat useimmin. Ja visualisoinnin käyttö Tableaussa alensi graafin tutkimisen kustannuksia niin paljon, että tuotteen käyttäytymisanalyysin iteraatioaika lähes puolet.
Danil kertoo kuinka tätä visualisointia käytetään ja mitä johtopäätöksiä sen avulla voidaan tehdä.
Lisää pöytiä pöytäjumalalle!
Yksinkertaistetussa muodossa tehtävä muotoiltiin seuraavasti: näytä siirtymäkaavio Tableaussa, tarjoa kyky suodattaa ja tee siitä mahdollisimman selkeä ja kätevä.
En todellakaan halunnut piirtää suunnattua kuvaajaa Tableaussa. Ja vaikka onnistuisikin, voitto Gephiin verrattuna ei vaikuttanut ilmeiseltä. Tarvitsimme jotain paljon yksinkertaisempaa ja helpompaa. Pöytä! Loppujen lopuksi graafi voidaan helposti esittää taulukon riveinä, joissa jokainen rivi on "lähde-kohde"-tyypin reuna. Lisäksi olemme jo huolellisesti laatineet tällaisen taulukon Retentioneering- ja Data Provider -työkaluilla. Ei enää tarvinnut kuin laittaa taulukko esille Tableaussa ja selata raporttia.
Puhutaan siitä, kuinka kaikki rakastavat pöytiä.
Tässä olemme kuitenkin toisen ongelman edessä. Mitä tehdä tietolähteen kanssa? Pandas.DataFrame:n yhdistäminen oli mahdotonta; Tableaussa ei ole tällaista liitintä. Erillisen pohjan nostaminen graafin tallentamista varten vaikutti liian radikaalilta ratkaisulta, jonka näkymät olivat epämääräiset. Ja paikalliset purkuvaihtoehdot eivät olleet sopivia jatkuvan manuaalisen toiminnan tarpeen vuoksi. Selasimme saatavilla olevien liittimien luetteloa ja katseemme osui tuotteeseen , joka käpertyi surkeasti aivan pohjaan.
Tableaussa on runsas valikoima liittimiä. Löysimme sellaisen, joka ratkaisi ongelmamme
Millainen eläin? Muutama uusi avoin välilehti selaimessa - ja kävi selväksi, että tämän liittimen avulla voit vastaanottaa tietoja, kun käytät URL-osoitetta. Itse datalaskennan taustaohjelma oli melkein valmis, jäljellä oli vain ystävystyä WDC:n kanssa. Useita päiviä Denis tutki dokumentaatiota ja taisteli Tableau-mekanismeja vastaan ja lähetti sitten minulle linkin, jonka liitin yhteysikkunaan.
Yhteyslomake WDC:hen. Denis teki eturintaman ja huolehti turvallisuudesta
Muutaman minuutin odotuksen jälkeen (tiedot lasketaan dynaamisesti pyydettäessä) ilmestyi taulukko:
Tältä raakadatataulukko näyttää Tableau-rajapinnassa
Kuten luvattiin, tällaisen taulukon jokainen rivi edusti graafin reunaa, eli käyttäjän suunnattua siirtymää. Se sisälsi myös useita lisäominaisuuksia. Esimerkiksi yksittäisten käyttäjien määrä, siirtymien kokonaismäärä ja muut.
Tämä taulukko olisi mahdollista näyttää raportissa sellaisenaan, ripotella runsaasti suodattimia ja lähettää työkalu purjehtimaan. Kuulostaa loogiselta. Mitä pöydälle voi tehdä? Mutta tämä ei ole meidän tapamme, koska emme tee vain taulukkoa, vaan työkalua analysointiin ja tuotepäätösten tekemiseen.
Tyypillisesti henkilö haluaa tietoja analysoidessaan saada vastauksia kysymyksiin. Loistava. Aloitetaan niistä.
- Mitkä ovat yleisimmät siirtymät?
- Mihin ne menevät tietyiltä sivuilta?
- Kuinka kauan keskimäärin vietät tällä sivulla ennen lähtöä?
- Kuinka usein teet siirtymisen paikasta A paikkaan B?
- Millä sivuilla istunto päättyy?
Jokaisen raportin tai niiden yhdistelmän pitäisi antaa käyttäjälle mahdollisuus löytää itsenäisesti vastauksia näihin kysymyksiin. Tärkein strategia tässä on antaa sinulle työkalut tehdä se itse. Tästä on hyötyä sekä analytiikkaosaston kuormituksen vähentämisessä että päätösten tekemiseen kuluvan ajan lyhentämisessä - sinun ei loppujen lopuksi enää tarvitse mennä Youtrackiin luomaan tehtävää analyytikolle, sinun tarvitsee vain avata raportti.
Mitä saimme?
Missä ihmiset useimmiten poikkeavat kojelaudasta?
Katkelma raportistamme. Kojelaudan jälkeen kaikki siirtyivät joko VM-luetteloon tai solmuluetteloon
Otetaan yleinen taulukko siirtymillä ja suodatetaan lähdesivun mukaan. Useimmiten ne siirtyvät kojelaudalta virtuaalikoneiden luetteloon. Lisäksi Säännöllisyys-sarake viittaa siihen, että tämä on toistuva toimenpide.
Mistä ne tulevat klusteriluetteloon?
Raporttien suodattimet toimivat molempiin suuntiin: voit selvittää, minne lähdit tai minne menit
Esimerkeistä on selvää, että jopa kahden yksinkertaisen suodattimen ja arvojen järjestysrivien läsnäolo mahdollistaa tietojen nopean hankkimisen.
Kysytään jotain vaikeampaa.
Missä käyttäjät useimmiten keskeyttävät istunnon?
VMmanagerin käyttäjät työskentelevät usein erillisillä välilehdillä
Tätä varten tarvitsemme raportin, jonka tiedot on koottu viittauslähteiden mukaan. Ja niin sanotut murtopisteet otettiin toimeksiannoiksi - tapahtumia, jotka toimivat siirtymäketjun päätteenä.
Tässä on tärkeää huomata, että tämä voi olla joko istunnon lopetus tai uuden välilehden avaaminen. Esimerkki osoittaa, että ketju päättyy useimmiten taulukkoon, jossa on luettelo virtuaalikoneista. Tässä tapauksessa tyypillinen käyttäytyminen on siirtyminen toiseen välilehteen, mikä on yhdenmukainen odotetun mallin kanssa.
Testasimme ensin näiden raporttien hyödyllisyyttä itsellämme, kun teimme analyysin samalla tavalla , toinen tuotteistamme. Taulukoiden ja suodattimien myötä hypoteesit testattiin nopeammin ja silmät väsyivät vähemmän.
Raportteja kehitettäessä emme unohtaneet visuaalista suunnittelua. Kun työskentelet tämän kokoisten pöytien kanssa, tämä on tärkeä tekijä. Käytimme esimerkiksi rauhallista värivalikoimaa, joka oli helppo havaita numeroille rivien värikorostus ominaisuuksien numeeristen arvojen mukaisesti. Tällaiset yksityiskohdat parantavat käyttökokemusta ja lisäävät työkalun onnistumisen todennäköisyyttä yrityksen sisällä.
Taulukko osoittautui melko tilavaksi, mutta toivomme, että se ei ole lakannut olemasta luettavissa
Erikseen kannattaa mainita sisäisten asiakkaidemme: tuoteasiantuntijoiden ja UX-suunnittelijoiden koulutuksesta. Niitä varten laadittiin erityisesti käsikirjat, joissa oli analyysiesimerkkejä ja vinkkejä suodattimien kanssa työskentelemiseen. Lisäsimme linkit oppaisiin suoraan raporttisivuille.
Teimme oppaan yksinkertaisesti esityksenä Google Docsissa. Taulukkotyökalujen avulla voit näyttää verkkosivuja suoraan raporttityökirjan sisällä.
sijasta epilogin
Mitä on alimmassa rivissä? Saimme jokaiseen päivään työkalun suhteellisen nopeasti ja edullisesti. Kyllä, tämä ei todellakaan korvaa itse kaaviota, napsautusten lämpökarttaa tai verkkokatselijaa. Mutta tällaiset raportit täydentävät merkittävästi lueteltuja työkaluja ja tarjoavat ajattelemisen aihetta sekä uusia tuote- ja käyttöliittymähypoteesia.
Tämä tarina toimi vain alkuna ISP-järjestelmän analytiikan kehitykselle. Viimeisen puolen vuoden aikana on ilmestynyt seitsemän uutta palvelua lisää, mukaan lukien digitaaliset käyttäjäkuvat tuotteessa sekä palvelu Look-alike-kohdistuksen tietokantojen luomiseen, mutta niistä kerromme seuraavissa jaksoissa.
Lähde: will.com