Der er hundredvis af artikler på internettet om fordelene ved at analysere kundeadfærd. Oftest drejer det sig om detailsektoren. Fra madkurvanalyse, ABC- og XYZ-analyse til fastholdelsesmarkedsføring og personlige tilbud. Forskellige teknikker er blevet brugt i årtier, algoritmerne er gennemtænkte, koden er skrevet og fejlrettet – tag den og brug den. I vores tilfælde opstod der et grundlæggende problem - vi hos ISPsystem er engageret i softwareudvikling, ikke detailhandel.
Mit navn er Denis og jeg er i øjeblikket ansvarlig for backend af analytiske systemer hos ISPsystem. Og dette er historien om, hvordan min kollega og jeg — de ansvarlige for datavisualisering — forsøgte at se på vores softwareprodukter gennem prisme af denne viden. Lad os som sædvanlig starte med historien.
I begyndelsen var der et ord, og ordet var "Skal vi prøve?"
På det tidspunkt arbejdede jeg som udvikler i R&D-afdelingen. Det hele startede, da Danil læste her på Habré — et værktøj til at analysere brugerovergange i applikationer. Jeg var noget skeptisk over for ideen om at bruge det her. Som eksempler nævnte biblioteksudviklerne en analyse af applikationer, hvor målhandlingen var klart defineret - afgivelse af en ordre eller en anden variation af, hvordan man betaler ejervirksomheden. Vores produkter leveres på stedet. Det vil sige, at brugeren først køber en licens, og først derefter begynder sin rejse i applikationen. Ja, vi har demoversioner. Du kan prøve produktet der, så du ikke har en gris i spidsen.
Men de fleste af vores produkter er rettet mod hostingmarkedet. Det er store kunder, og forretningsudviklingsafdelingen rådgiver dem om produktkapaciteter. Det følger også, at på købstidspunktet ved vores kunder allerede, hvilke problemer vores software vil hjælpe dem med at løse. Deres ruter i applikationen skal falde sammen med den CJM, der er indlejret i produktet, og UX-løsninger vil hjælpe dem med at holde sig på sporet. Spoiler: dette sker ikke altid. Introduktionen til biblioteket blev udskudt... men ikke længe.
Alt ændrede sig med udgivelsen af vores opstart - — platforme til at oprette en onlinebutik fra en Instagram-konto. I denne applikation fik brugeren en to-ugers periode til at bruge al funktionalitet gratis. Så skulle du beslutte dig for, om du ville abonnere. Og dette passede perfekt ind i konceptet "rutemålhandling". Det blev besluttet: lad os prøve!
Første resultater eller hvor man kan få ideer fra
Udviklingsteamet og jeg koblede produktet til arrangementsindsamlingssystemet bogstaveligt talt på en dag. Jeg vil med det samme sige, at ISPsystem bruger sit eget system til at indsamle begivenheder om sidebesøg, men intet forhindrer dig i at bruge Yandex.Metrica til de samme formål, som giver dig mulighed for at downloade rådata gratis. Eksempler på brug af biblioteket blev undersøgt, og efter en uges dataindsamling modtog vi en overgangsgraf.
Overgangsgraf. Grundlæggende funktionalitet, andre overgange fjernet for klarhedens skyld
Det viste sig ligesom i eksemplet: plan, klar, smuk. Fra denne graf var vi i stand til at identificere de hyppigste ruter og krydsninger, hvor folk tilbringer længst tid. Dette gav os mulighed for at forstå følgende:
- I stedet for et stort CJM, som dækker et dusin enheder, bruges kun to aktivt. Det er nødvendigt yderligere at dirigere brugerne hen til de steder, vi har brug for ved hjælp af UX-løsninger.
- Nogle sider, designet af UX-designere til at være end-to-end, ender med, at folk bruger urimelig meget tid på dem. Du skal finde ud af, hvad stopelementerne er på en bestemt side og justere dem.
- Efter 10 overgange begyndte 20 % af folk at blive trætte og afslutte sessionen i applikationen. Og dette er taget i betragtning, at vi havde hele 5 onboarding-sider i applikationen! Du skal identificere sider, hvor brugere regelmæssigt forlader sessioner og forkorte vejen til dem. Endnu bedre: Identificer eventuelle almindelige ruter og tillad en hurtig overgang fra kildesiden til destinationssiden. Noget til fælles med ABC-analyse og analyse af forladt vogn, synes du ikke?
Og her genovervejede vi vores holdning til anvendeligheden af dette værktøj til on-premise produkter. Det blev besluttet at analysere et aktivt solgt og brugt produkt - . Det er meget mere komplekst, der er en størrelsesorden flere enheder. Vi ventede spændt på at se, hvad overgangsgrafen ville vise sig at være.
Om skuffelser og inspirationer
Skuffelse #1
Det var slutningen af arbejdsdagen, slutningen af måneden og slutningen af året på samme tid - 27. december. Data er blevet akkumuleret, forespørgsler er skrevet. Der var sekunder tilbage, før alt var behandlet, og vi kunne se på resultatet af vores arbejde for at finde ud af, hvor det næste arbejdsår ville begynde. R&D-afdelingen, produktchef, UX-designere, teamleder, udviklere samledes foran skærmen for at se, hvordan brugerstierne ser ud i deres produkt, men... vi så dette:
Overgangsgraf bygget af Retentioneering-biblioteket
Inspiration #1
Stærkt forbundet, snesevis af enheder, ikke-oplagte scenarier. Det var kun klart, at det nye arbejdsår ikke ville begynde med analyse, men med opfindelsen af en måde at forenkle arbejdet med en sådan graf. Men jeg kunne ikke slippe følelsen af, at alt var meget enklere, end det så ud. Og efter femten minutters undersøgelse af Retentioneering-kildekoden var vi i stand til at eksportere den konstruerede graf til punktformat. Dette gjorde det muligt at uploade grafen til et andet værktøj - Gephi. Og der er allerede mulighed for at analysere grafer: layout, filtre, statistik - alt du skal gøre er at konfigurere de nødvendige parametre i grænsefladen. Med denne tanke i tankerne tog vi afsted til nytårsweekend.
Skuffelse #2
Efter at være vendt tilbage til arbejdet, viste det sig, at mens alle hvilede sig, studerede vores kunder produktet. Ja, så hårdt, at der dukkede begivenheder op i lageret, som ikke fandtes før. Det betød, at forespørgslerne skulle opdateres.
Lidt baggrund for at forstå tristheden ved dette faktum. Vi transmitterer både de begivenheder, vi har markeret (f.eks. klik på nogle knapper) og URL'erne på de sider, som brugeren har besøgt. I tilfældet med Cartbee fungerede modellen "én handling - én side". Men med VMmanager var situationen en helt anden: flere modale vinduer kunne åbnes på én side. I dem kunne brugeren løse forskellige problemer. For eksempel URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
betyder, at brugeren tilføjede en IP-adresse på siden "IP-adresser". Og her er to problemer synlige på én gang:
- URL'en indeholder en slags stiparameter - ID'et for den virtuelle maskine. Det skal udelukkes.
- URL'en indeholder det modale vindues-id. Du skal på en eller anden måde "pakke ud" sådanne URL'er.
Et andet problem var, at netop de begivenheder, vi markerede, havde parametre. For eksempel var der fem forskellige måder at komme til siden med information om en virtuel maskine fra listen. Derfor blev der sendt én hændelse, men med en parameter, der indikerede, hvilken metode brugeren foretog overgangen. Der var mange sådanne begivenheder, og alle parametrene var forskellige. Og vi har al datahentningslogikken i SQL-dialekten til Clickhouse. Forespørgsler på 150-200 linjer begyndte at virke noget almindelige. Problemer omgav os.
Inspiration #2
En tidlig morgen foreslog Danil mig, da han desværre rullede gennem anmodningen i det andet minut: "Lad os skrive databehandlingspipelines?" Vi tænkte over det og besluttede, at hvis vi skulle gøre det, ville det være noget som ETL. Så den filtrerer med det samme og trækker de nødvendige data op fra andre kilder. Sådan blev vores første analytiske service med en fuldgyldig backend født. Den implementerer fem hovedstadier af databehandling:
- Aflæsning af hændelser fra rådatalageret og klargøring af dem til behandling.
- Afklaring er "udpakningen" af netop disse identifikatorer af modale vinduer, hændelsesparametre og andre detaljer, der tydeliggør hændelsen.
- Berigelse (fra ordet "at blive rig") er tilføjelsen af begivenheder med data fra tredjepartskilder. På det tidspunkt omfattede dette kun vores faktureringssystem BILLmanager.
- Filtrering er processen med at bortfiltrere hændelser, der forvrænger resultaterne af analysen (hændelser fra interne stande, outliers osv.).
- Uploader modtagne hændelser til lageret, som vi kaldte rene data.
Nu var det muligt at bevare relevansen ved at tilføje regler for behandling af en begivenhed eller endda grupper af lignende begivenheder. For eksempel, siden da har vi aldrig opdateret URL-udpakning. Selvom der i løbet af denne tid er blevet tilføjet flere nye URL-varianter. De overholder de regler, der allerede er fastsat i tjenesten og behandles korrekt.
Skuffelse #3
Da vi begyndte at analysere, indså vi, hvorfor grafen var så sammenhængende. Faktum er, at næsten hvert N-gram indeholdt overgange, der ikke kunne udføres gennem grænsefladen.
En lille undersøgelse begyndte. Jeg var forvirret over, at der ikke var nogen umulige overgange inden for en enhed. Det betyder, at dette ikke er en fejl i hændelsesindsamlingssystemet eller vores ETL-tjeneste. Der var en følelse af, at brugeren samtidig arbejdede i flere entiteter uden at flytte fra den ene til den anden. Hvordan opnår man dette? Brug af forskellige faner i browseren.
Da vi analyserede Cartbee, blev vi reddet af dens specificitet. Applikationen blev brugt fra mobile enheder, hvor det simpelthen er ubelejligt at arbejde fra flere faner. Her har vi en desktop, og mens en opgave udføres i en enhed, er det rimeligt at bruge denne tid på at opsætte eller overvåge status i en anden. Og for ikke at miste fremskridt, skal du bare åbne en anden fane.
Inspiration #3
Kolleger fra frontend-udvikling lærte hændelsesindsamlingssystemet at skelne mellem faner. Analysen kunne begynde. Og vi startede. Som forventet matchede CJM ikke rigtige stier: brugere brugte meget tid på mappesider, forladte sessioner og faner på de mest uventede steder. Ved hjælp af overgangsanalyse var vi i stand til at finde problemer i nogle Mozilla-builds. I dem forsvandt navigationselementer på grund af implementeringsfunktioner, eller der blev vist halvtomme sider, som kun skulle være tilgængelige for administratoren. Siden åbnede, men der kom intet indhold fra backend. Optælling af overgange gjorde det muligt at evaluere, hvilke funktioner der rent faktisk blev brugt. Kæderne gjorde det muligt at forstå, hvordan brugeren modtog denne eller hin fejl. De data, der er tilladt for test baseret på brugeradfærd. Det var en succes, ideen var ikke forgæves.
Analytics automatisering
I en af resultatdemonstrationerne viste vi, hvordan Gephi bruges til grafanalyse. I dette værktøj kan konverteringsdata vises i en tabel. Og lederen af UX-afdelingen sagde en meget vigtig tanke, der påvirkede udviklingen af hele adfærdsanalyseretningen i virksomheden: "Lad os gøre det samme, men i Tableau og med filtre - det vil være mere bekvemt."
Så tænkte jeg: hvorfor ikke, Retentioneering gemmer alle data i en pandas.DataFrame-struktur. Og det her er i det store og hele et bord. Sådan fremstod en anden tjeneste: Dataudbyder. Han lavede ikke kun en tabel ud fra grafen, men beregnede også, hvor populær siden og den funktionalitet, der er forbundet med den, er, hvordan den påvirker brugerfastholdelsen, hvor længe brugerne bliver på den, og hvilke sider brugerne forlader oftest. Og brugen af visualisering i Tableau reducerede omkostningerne ved at studere grafen så meget, at iterationstiden for adfærdsanalyse i produktet næsten blev halveret.
Danil vil fortælle om, hvordan denne visualisering bruges, og hvilke konklusioner den tillader at drage.
Flere borde til bordguden!
I en forenklet form var opgaven formuleret som følger: Vis overgangsgrafen i Tableau, giv mulighed for filtrering og gør den så overskuelig og bekvem som muligt.
Jeg havde ikke rigtig lyst til at tegne en rettet graf i Tableau. Og selvom det lykkedes, virkede gevinsten, sammenlignet med Gephi, ikke indlysende. Vi havde brug for noget meget enklere og mere tilgængeligt. Bord! Grafen kan trods alt nemt repræsenteres i form af tabelrækker, hvor hver række er en kant af typen "kilde-destination". Desuden har vi allerede omhyggeligt udarbejdet en sådan tabel ved hjælp af Retentioneering og Data Provider værktøjer. Det eneste, der var tilbage at gøre, var at vise bordet i Tableau og rode i rapporten.
Apropos hvordan alle elsker borde.
Men her står vi med et andet problem. Hvad skal man gøre med datakilden? Det var umuligt at forbinde pandaer. DataFrame; Tableau har ikke sådan et stik. At rejse en separat base til lagring af grafen virkede for radikal en løsning med vage udsigter. Og lokale lossemuligheder var ikke egnede på grund af behovet for konstant manuelle operationer. Vi kiggede listen over tilgængelige stik igennem, og vores blik faldt på emnet , der krøb forladt helt nede i bunden.
Tableau har et rigt udvalg af stik. Vi fandt en, der løste vores problem
Hvilken slags dyr? Et par nye åbne faner i browseren - og det blev klart, at denne connector giver dig mulighed for at modtage data, når du tilgår en URL. Backend'en til at beregne selve dataene var næsten klar, der var kun tilbage at blive venner med WDC. I flere dage studerede Denis dokumentationen og kæmpede med Tableau-mekanismerne, og sendte mig derefter et link, som jeg indsatte i forbindelsesvinduet.
Tilslutningsformular til vores WDC. Denis stod foran og tog sig af sikkerheden
Efter et par minutters ventetid (dataene beregnes dynamisk, når de anmodes om det), dukkede tabellen op:
Sådan ser et rådataarray ud i Tableau-grænsefladen
Som lovet repræsenterede hver række i en sådan tabel en kant af grafen, det vil sige en rettet overgang af brugeren. Den indeholdt også flere yderligere egenskaber. For eksempel antallet af unikke brugere, det samlede antal overgange og andre.
Det ville være muligt at vise denne tabel i rapporten, som den er, drys generøst med filtre og sende værktøjet afsted. Lyder logisk. Hvad kan du gøre med bordet? Men det er ikke vores måde, for vi laver ikke bare en tabel, men et værktøj til at analysere og træffe produktbeslutninger.
Typisk, når en person analyserer data, ønsker en person at få svar på spørgsmål. Store. Lad os starte med dem.
- Hvad er de hyppigste overgange?
- Hvor går de fra bestemte sider?
- Hvor lang tid bruger du i gennemsnit på denne side, før du rejser?
- Hvor ofte skifter du fra A til B?
- På hvilke sider slutter sessionen?
Hver af rapporterne eller en kombination af dem skal give brugeren mulighed for selvstændigt at finde svar på disse spørgsmål. Nøglestrategien her er at give dig værktøjerne til at gøre det selv. Dette er nyttigt både til at reducere belastningen på analyseafdelingen og til at reducere tiden til at træffe beslutninger – du behøver trods alt ikke længere at gå til Youtrack og oprette en opgave til analytikeren, du skal bare åbne rapporten.
Hvad fik vi?
Hvor afviger folk oftest fra dashboardet?
Fragment af vores rapport. Efter dashboardet gik alle enten til listen over VM'er eller til listen over noder
Lad os tage en generel tabel med overgange og filtrere efter kildeside. Oftest går de fra dashboardet til listen over virtuelle maskiner. Desuden antyder kolonnen Regelmæssighed, at dette er en gentagelseshandling.
Hvor kommer de fra til listen over klynger?
Filtre i rapporter virker i begge retninger: Du kan finde ud af, hvor du tog afsted, eller hvor du gik
Fra eksemplerne er det klart, at selv tilstedeværelsen af to simple filtre og rangordning af rækker efter værdier giver dig mulighed for hurtigt at få information.
Lad os spørge om noget sværere.
Hvor forlader brugere oftest deres session?
VMmanager-brugere arbejder ofte i separate faner
For at gøre dette har vi brug for en rapport, hvis data er aggregeret af henvisningskilder. Og de såkaldte breakepoints blev taget som opgaver - begivenheder, der fungerede som afslutningen på kæden af overgange.
Det er vigtigt at bemærke her, at dette enten kan være slutningen af sessionen eller åbningen af en ny fane. Eksemplet viser, at kæden oftest ender ved et bord med en liste over virtuelle maskiner. I dette tilfælde er den karakteristiske adfærd at skifte til en anden fane, som er i overensstemmelse med det forventede mønster.
Vi testede først og fremmest nytten af disse rapporter på os selv, da vi udførte analysen på lignende måde , et andet af vores produkter. Med fremkomsten af tabeller og filtre blev hypoteser testet hurtigere, og øjnene var mindre trætte.
Når vi udviklede rapporter, glemte vi ikke visuelt design. Når man arbejder med borde af denne størrelse, er dette en vigtig faktor. For eksempel brugte vi et roligt udvalg af farver, let at opfatte for tal, farvefremhævning af linjer i overensstemmelse med de numeriske værdier af egenskaberne. Sådanne detaljer forbedrer brugeroplevelsen og øger sandsynligheden for, at værktøjet lykkes i virksomheden.
Tabellen viste sig at være ret omfangsrig, men vi håber ikke, den er holdt op med at læse
Det er værd at nævne separat om uddannelsen af vores interne kunder: produktspecialister og UX-designere. Manualer med analyseeksempler og tips til at arbejde med filtre blev specielt udarbejdet til dem. Vi indsatte links til manualer direkte på rapportsiderne.
Vi lavede manualen blot som en præsentation i Google Docs. Tableau-værktøjer giver dig mulighed for at vise websider direkte i en rapportprojektmappe.
i stedet for en epilog
Hvad står der på bundlinjen? Vi kunne relativt hurtigt og billigt få et værktøj til hver dag. Ja, dette er bestemt ikke en erstatning for selve grafen, varmekortet med klik eller webfremviseren. Men sådanne rapporter supplerer i væsentlig grad de anførte værktøjer og giver stof til eftertanke og nye produkt- og grænsefladehypoteser.
Denne historie tjente kun som begyndelsen til udviklingen af analyser i ISPsystem. I løbet af det seneste halve år er der dukket yderligere syv nye tjenester op, herunder digitale portrætter af brugeren i produktet og en tjeneste til oprettelse af databaser til Look-alike-målretning, men dem vil vi tale om i de følgende afsnit.
Kilde: www.habr.com