Det er hundrevis av artikler på Internett om fordelene ved å analysere kundeatferd. Oftest dreier dette seg om detaljhandel. Fra matkurvanalyse, ABC- og XYZ-analyse til retentionsmarkedsføring og personlige tilbud. Ulike teknikker har blitt brukt i flere tiår, algoritmene er gjennomtenkt, koden er skrevet og feilsøkt – ta den og bruk den. I vårt tilfelle dukket det opp et grunnleggende problem - vi i ISPsystem er engasjert i programvareutvikling, ikke detaljhandel.
Mitt navn er Denis og jeg er for tiden ansvarlig for backend av analytiske systemer hos ISPsystem. Og dette er historien om hvordan min kollega og jeg — de ansvarlige for datavisualisering — prøvde å se på programvareproduktene våre gjennom prisme av denne kunnskapen. La oss starte, som vanlig, med historien.
I begynnelsen var det et ord, og ordet var "Skal vi prøve?"
I det øyeblikket jobbet jeg som utvikler i R&D-avdelingen. Det hele startet da Danil leste her på Habré — et verktøy for å analysere brukeroverganger i applikasjoner. Jeg var noe skeptisk til ideen om å bruke den her. Som eksempler nevnte bibliotekutviklerne en analyse av applikasjoner der målhandlingen var klart definert - å legge inn en ordre eller en annen variant av hvordan man betaler eierselskapet. Våre produkter leveres på stedet. Det vil si at brukeren først kjøper en lisens, og først deretter begynner reisen i applikasjonen. Ja, vi har demoversjoner. Du kan prøve produktet der, slik at du ikke har en gris i en poke.
Men de fleste av produktene våre er rettet mot hostingmarkedet. Dette er store kunder, og forretningsutviklingsavdelingen gir dem råd om produktegenskaper. Det følger også at på kjøpstidspunktet vet kundene våre allerede hvilke problemer programvaren vår vil hjelpe dem med å løse. Rutene deres i applikasjonen må falle sammen med CJM som er innebygd i produktet, og UX-løsninger vil hjelpe dem å holde seg på sporet. Spoiler: dette skjer ikke alltid. Introduksjonen til biblioteket ble utsatt...men ikke lenge.
Alt endret seg med lanseringen av oppstarten vår - — plattformer for å lage en nettbutikk fra en Instagram-konto. I denne applikasjonen fikk brukeren en to ukers periode til å bruke all funksjonalitet gratis. Så måtte du bestemme deg for om du skulle abonnere. Og dette passet perfekt inn i konseptet "rutemålhandling". Det ble bestemt: la oss prøve!
Første resultater eller hvor du kan hente ideer fra
Utviklingsteamet og jeg koblet produktet til hendelsesinnsamlingssystemet bokstavelig talt på en dag. Jeg vil si med en gang at ISPsystem bruker sitt eget system for å samle hendelser om sidebesøk, men ingenting hindrer deg i å bruke Yandex.Metrica til samme formål, som lar deg laste ned rådata gratis. Eksempler på bruk av biblioteket ble studert, og etter en ukes datainnsamling fikk vi en overgangsgraf.
Overgangsgraf. Grunnleggende funksjonalitet, andre overganger fjernet for klarhet
Det ble akkurat som i eksemplet: plan, klar, vakker. Fra denne grafen var vi i stand til å identifisere de hyppigste rutene og kryssingene der folk tilbringer lengst tid. Dette tillot oss å forstå følgende:
- I stedet for en stor CJM, som dekker et dusin enheter, brukes bare to aktivt. Det er nødvendig å i tillegg henvise brukere til stedene vi trenger ved å bruke UX-løsninger.
- Noen sider, designet av UX-designere for å være ende-til-ende, ender opp med at folk bruker urimelig mye tid på dem. Du må finne ut hva stoppelementene er på en bestemt side og justere det.
- Etter 10 overganger begynte 20 % av folk å bli slitne og avslutte økten i applikasjonen. Og dette er tatt i betraktning at vi hadde så mange som 5 onboarding-sider i applikasjonen! Du må identifisere sider der brukere regelmessig forlater økter og forkorte veien til dem. Enda bedre: identifiser eventuelle vanlige ruter og tillat en rask overgang fra kildesiden til destinasjonssiden. Noe til felles med ABC-analyse og analyse av forlatt handlevogn, tror du ikke?
Og her revurderte vi vår holdning til anvendeligheten av dette verktøyet for lokale produkter. Det ble besluttet å analysere et aktivt solgt og brukt produkt - . Det er mye mer komplekst, det er en størrelsesorden flere enheter. Vi ventet spent på å se hvordan overgangsgrafen skulle vise seg å bli.
Om skuffelser og inspirasjoner
Skuffelse #1
Det var slutt på arbeidsdagen, slutten av måneden og slutten av året på samme tid – 27. desember. Data har blitt samlet, forespørsler er skrevet. Det var sekunder igjen før alt var behandlet og vi kunne se på resultatet av arbeidet vårt for å finne ut hvor neste arbeidsår ville begynne. FoU-avdelingen, produktsjef, UX-designere, teamleder, utviklere samlet seg foran skjermen for å se hvordan brukerbanene ser ut i produktet deres, men... vi så dette:
Overgangsgraf bygget av Retentioneering-biblioteket
Inspirasjon #1
Sterkt forbundet, dusinvis av enheter, ikke-opplagte scenarier. Det var bare klart at det nye arbeidsåret ikke ville begynne med analyse, men med oppfinnelsen av en måte å forenkle arbeidet med en slik graf. Men jeg kunne ikke rokke ved følelsen av at alt var mye enklere enn det så ut til. Og etter femten minutter med å studere Retentioneering-kildekoden, var vi i stand til å eksportere den konstruerte grafen til punktformat. Dette gjorde det mulig å laste opp grafen til et annet verktøy – Gephi. Og det er allerede rom for å analysere grafer: oppsett, filtre, statistikk - alt du trenger å gjøre er å konfigurere de nødvendige parameterne i grensesnittet. Med denne tanken i bakhodet dro vi til nyttårshelgen.
Skuffelse #2
Etter at de kom tilbake på jobb, viste det seg at mens alle hvilte, studerte kundene våre produktet. Ja, så hardt at det dukket opp hendelser i lageret som ikke fantes før. Dette medførte at spørringene måtte oppdateres.
Litt bakgrunn for å forstå tristheten i dette faktum. Vi overfører både hendelsene vi har merket (for eksempel klikk på noen knapper) og nettadressene til sidene brukeren besøkte. I tilfellet med Cartbee fungerte modellen "én handling - én side". Men med VMmanager var situasjonen en helt annen: flere modale vinduer kunne åpnes på én side. I dem kunne brukeren løse ulike problemer. For eksempel URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
betyr at brukeren har lagt til en IP-adresse på siden "IP-adresser". Og her er to problemer synlige samtidig:
- URL-en inneholder en slags baneparameter - IDen til den virtuelle maskinen. Det må utelukkes.
- URL-en inneholder den modale vindu-IDen. Du må på en eller annen måte "pakke ut" slike nettadresser.
Et annet problem var at selve hendelsene vi markerte hadde parametere. For eksempel var det fem forskjellige måter å komme til siden med informasjon om en virtuell maskin fra listen. Følgelig ble én hendelse sendt, men med en parameter som indikerte hvilken metode brukeren foretok overgangen. Det var mange slike hendelser, og alle parameterne var forskjellige. Og vi har all datainnhentingslogikken på SQL-dialekten for Clickhouse. Forespørsler på 150-200 linjer begynte å virke noe vanlige. Problemer omringet oss.
Inspirasjon #2
En tidlig morgen foreslo Danil meg, mens han trist rullet gjennom forespørselen i det andre minuttet: «La oss skrive databehandlingsrørledninger?» Vi tenkte på det og bestemte oss for at hvis vi skulle gjøre det, ville det være noe sånt som ETL. Slik at den filtrerer umiddelbart og henter nødvendige data fra andre kilder. Slik ble vår første analytiske tjeneste med en fullverdig backend født. Den implementerer fem hovedtrinn av databehandling:
- Lose hendelser fra rådatalageret og klargjøre dem for behandling.
- Klargjøring er «utpakking» av disse identifikatorene til modale vinduer, hendelsesparametere og andre detaljer som tydeliggjør hendelsen.
- Berikelse (fra ordet «å bli rik») er tillegg av hendelser med data fra tredjepartskilder. På den tiden inkluderte dette bare faktureringssystemet vårt BILLmanager.
- Filtrering er prosessen med å filtrere ut hendelser som forvrenger resultatene av analysen (hendelser fra interne stands, uteliggere, etc.).
- Laster opp mottatte hendelser til lagring, som vi kalte rene data.
Nå var det mulig å opprettholde relevansen ved å legge til regler for behandling av en hendelse eller til og med grupper av lignende hendelser. Siden da har vi for eksempel aldri oppdatert URL-utpakking. Men i løpet av denne tiden har flere nye URL-varianter blitt lagt til. De overholder reglene som allerede er fastsatt i tjenesten og behandles korrekt.
Skuffelse #3
Når vi begynte å analysere, innså vi hvorfor grafen var så sammenhengende. Faktum er at nesten hvert N-gram inneholdt overganger som ikke kunne utføres gjennom grensesnittet.
En liten etterforskning startet. Jeg var forvirret over at det ikke var noen umulige overganger innenfor en enhet. Dette betyr at dette ikke er en feil i hendelsesinnsamlingssystemet eller vår ETL-tjeneste. Det var en følelse av at brukeren jobbet i flere enheter samtidig, uten å flytte fra den ene til den andre. Hvordan oppnå dette? Bruke forskjellige faner i nettleseren.
Da vi analyserte Cartbee, ble vi reddet av dens spesifisitet. Applikasjonen ble brukt fra mobile enheter, hvor det rett og slett er upraktisk å jobbe fra flere faner. Her har vi et skrivebord og mens en oppgave utføres i en enhet, er det rimelig å ønske å bruke denne tiden på å sette opp eller overvåke status i en annen. Og for ikke å miste fremgang, bare åpne en annen fane.
Inspirasjon #3
Kolleger fra frontend-utvikling lærte hendelsesinnsamlingssystemet å skille mellom faner. Analysen kan begynne. Og vi startet. Som forventet samsvarte ikke CJM med ekte stier: brukere brukte mye tid på katalogsider, forlatte økter og faner på de mest uventede stedene. Ved hjelp av overgangsanalyse var vi i stand til å finne problemer i noen Mozilla-bygg. I dem, på grunn av implementeringsfunksjoner, forsvant navigasjonselementer eller halvtomme sider ble vist, som bare skal være tilgjengelige for administratoren. Siden åpnet, men det kom ikke noe innhold fra backend. Å telle overganger gjorde det mulig å evaluere hvilke funksjoner som faktisk ble brukt. Kjedene gjorde det mulig å forstå hvordan brukeren mottok denne eller hin feilen. Dataene tillot for testing basert på brukeratferd. Det ble en suksess, ideen var ikke forgjeves.
Analytics automatisering
I en av resultatdemonstrasjonene viste vi hvordan Gephi brukes til grafanalyse. I dette verktøyet kan konverteringsdata vises i en tabell. Og lederen for UX-avdelingen sa en veldig viktig tanke som påvirket utviklingen av hele atferdsanalyseretningen i selskapet: "La oss gjøre det samme, men i Tableau og med filtre - det vil være mer praktisk."
Da tenkte jeg: hvorfor ikke, Retentioneering lagrer all data i en pandas.DataFrame-struktur. Og dette er i det store og hele et bord. Slik dukket det opp en annen tjeneste: Dataleverandør. Han laget ikke bare en tabell fra grafen, men regnet også ut hvor populær siden og funksjonaliteten knyttet til den er, hvordan den påvirker brukeroppbevaring, hvor lenge brukerne blir på den, og hvilke sider brukerne forlater oftest. Og bruken av visualisering i Tableau reduserte kostnadene ved å studere grafen så mye at iterasjonstiden for atferdsanalyse i produktet ble nesten halvert.
Danil vil snakke om hvordan denne visualiseringen brukes og hvilke konklusjoner den tillater å trekke.
Flere bord til bordguden!
I en forenklet form ble oppgaven formulert som følger: vis overgangsgrafen i Tableau, gi muligheten til å filtrere, og gjør den så oversiktlig og praktisk som mulig.
Jeg ville egentlig ikke tegne en rettet graf i Tableau. Og selv om det var vellykket, virket ikke gevinsten, sammenlignet med Gephi, åpenbar. Vi trengte noe mye enklere og mer tilgjengelig. Bord! Tross alt kan grafen enkelt representeres i form av tabellrader, der hver rad er en kant av typen "kildedestinasjon". Dessuten har vi allerede nøye utarbeidet en slik tabell ved hjelp av Retentioneering og Data Provider-verktøy. Alt som gjensto var å vise tabellen i Tableau og rote gjennom rapporten.
Apropos hvordan alle elsker bord.
Men her står vi overfor et annet problem. Hva skal man gjøre med datakilden? Det var umulig å koble til pandaer.DataFrame; Tableau har ikke en slik kontakt. Å heve en egen base for lagring av grafen virket som en for radikal løsning med vage utsikter. Og lokale lossemuligheter var ikke egnet på grunn av behovet for konstante manuelle operasjoner. Vi så gjennom listen over tilgjengelige kontakter, og blikket vårt falt på varen , som krøp fortvilt helt nederst.
Tableau har et rikt utvalg av kontakter. Vi fant en som løste problemet vårt
Hva slags dyr? Et par nye åpne faner i nettleseren - og det ble klart at denne koblingen lar deg motta data når du får tilgang til en URL. Bakenden for å beregne selve dataene var nesten klar, alt som gjensto var å bli venn med WDC. I flere dager studerte Denis dokumentasjonen og kjempet med Tableau-mekanismene, og sendte meg deretter en lenke som jeg limte inn i tilkoblingsvinduet.
Tilkoblingsskjema til vår WDC. Denis gjorde sin front og tok seg av sikkerheten
Etter et par minutters venting (dataene beregnes dynamisk ved forespørsel), dukket tabellen opp:
Slik ser en rådatamatrise ut i Tableau-grensesnittet
Som lovet representerte hver rad i en slik tabell en kant av grafen, det vil si en rettet overgang til brukeren. Den inneholdt også flere tilleggsegenskaper. For eksempel antall unike brukere, totalt antall overganger og andre.
Det ville være mulig å vise denne tabellen i rapporten som den er, strø filtre sjenerøst og sende verktøyet på seiling. Høres logisk ut. Hva kan du gjøre med bordet? Men dette er ikke vår måte, fordi vi lager ikke bare en tabell, men et verktøy for å analysere og ta produktbeslutninger.
Vanligvis, når man analyserer data, ønsker en person å få svar på spørsmål. Flott. La oss begynne med dem.
- Hva er de hyppigste overgangene?
- Hvor går de fra bestemte sider?
- Hvor lang tid bruker du i gjennomsnitt på denne siden før du drar?
- Hvor ofte gjør du overgangen fra A til B?
- På hvilke sider avsluttes økten?
Hver av rapportene eller en kombinasjon av dem skal tillate brukeren å uavhengig finne svar på disse spørsmålene. Nøkkelstrategien her er å gi deg verktøyene til å gjøre det selv. Dette er nyttig både for å redusere belastningen på analyseavdelingen og for å redusere tiden for å ta beslutninger – du trenger tross alt ikke lenger å gå til Youtrack og lage en oppgave for analytikeren, du trenger bare å åpne rapporten.
Hva fikk vi?
Hvor avviker folk oftest fra dashbordet?
Fragment av rapporten vår. Etter dashbordet gikk alle enten til listen over VM-er eller til listen over noder
La oss ta en generell tabell med overganger og filtrere etter kildeside. Oftest går de fra dashbordet til listen over virtuelle maskiner. Dessuten antyder kolonnen Regelmessighet at dette er en gjentatt handling.
Hvor kommer de fra til listen over klynger?
Filtre i rapporter fungerer i begge retninger: du kan finne ut hvor du dro, eller hvor du dro
Fra eksemplene er det klart at selv tilstedeværelsen av to enkle filtre og rangering av rader etter verdier lar deg raskt få informasjon.
La oss spørre om noe vanskeligere.
Hvor forlater brukere oftest økten?
VMmanager-brukere jobber ofte i separate faner
For å gjøre dette trenger vi en rapport hvis data er aggregert av henvisningskilder. Og de såkalte bruddpunktene ble tatt som oppdrag - hendelser som fungerte som slutten på kjeden av overganger.
Det er viktig å merke seg her at dette enten kan være slutten av økten eller åpningen av en ny fane. Eksemplet viser at kjeden oftest ender ved et bord med en liste over virtuelle maskiner. I dette tilfellet er den karakteristiske oppførselen å bytte til en annen fane, som er i samsvar med det forventede mønsteret.
Vi testet først og fremst nytten av disse rapportene på oss selv da vi utførte analysen på lignende måte , et annet av våre produkter. Med bruken av tabeller og filtre ble hypoteser testet raskere, og øynene ble mindre slitne.
Når vi utviklet rapporter, glemte vi ikke visuell design. Når du arbeider med bord av denne størrelsen, er dette en viktig faktor. For eksempel brukte vi et rolig utvalg av farger, lett å oppfatte for tall, fargeutheving av linjer i samsvar med de numeriske verdiene til egenskapene. Slike detaljer forbedrer brukeropplevelsen og øker sannsynligheten for at verktøyet lykkes i selskapet.
Tabellen viste seg å være ganske omfangsrik, men vi håper den ikke har sluttet å være lesbar
Det er verdt å nevne separat om opplæringen av våre interne kunder: produktspesialister og UX-designere. Håndbøker med analyseeksempler og tips for arbeid med filtre ble spesielt utarbeidet for dem. Vi la inn lenker til manualer direkte på rapportsidene.
Vi laget håndboken som en presentasjon i Google Docs. Tableau-verktøy lar deg vise nettsider direkte i en rapportarbeidsbok.
i stedet for en epilog
Hva står på bunnlinjen? Vi fikk relativt raskt og billig et verktøy for hver dag. Ja, dette er definitivt ikke en erstatning for selve grafen, varmekartet med klikk eller nettvisningen. Men slike rapporter kompletterer de listede verktøyene i betydelig grad og gir mat til ettertanke og nye produkt- og grensesnitthypoteser.
Denne historien fungerte bare som begynnelsen for utviklingen av analyse i ISPsystem. I løpet av det siste halvåret har det dukket opp ytterligere syv nye tjenester, inkludert digitale portretter av brukeren i produktet og en tjeneste for å lage databaser for Look-alike-målretting, men vi skal snakke om dem i de følgende episodene.
Kilde: www.habr.com