Det finns hundratals artiklar på Internet om fördelarna med att analysera kundbeteende. Oftast handlar det om detaljhandeln. Från matkorgsanalys, ABC- och XYZ-analys till retentionsmarknadsföring och personliga erbjudanden. Olika tekniker har använts i decennier, algoritmerna är genomtänkta, koden har skrivits och felsökts – ta den och använd den. I vårt fall uppstod ett grundläggande problem - vi på ISPsystem är engagerade i mjukvaruutveckling, inte detaljhandel.
Jag heter Denis och är för närvarande ansvarig för backend av analytiska system på ISPsystem. Och det här är historien om hur min kollega och jag — de ansvariga för datavisualisering — försökte titta på våra mjukvaruprodukter genom prismat av denna kunskap. Låt oss börja, som vanligt, med historia.
I början fanns det ett ord, och ordet var "Ska vi försöka?"
Vid det tillfället arbetade jag som utvecklare på R&D-avdelningen. Allt började när Danil läste här på Habré — ett verktyg för att analysera användarövergångar i applikationer. Jag var något skeptisk till idén att använda den här. Som exempel nämnde biblioteksutvecklarna en analys av applikationer där målåtgärden var tydligt definierad - att lägga en beställning eller någon annan variant av hur man betalar ägarföretaget. Våra produkter levereras på plats. Det vill säga att användaren först köper en licens, och först därefter börjar sin resa i applikationen. Ja, vi har demoversioner. Du kan prova produkten där så att du inte har en gris i säcken.
Men de flesta av våra produkter är inriktade på hostingmarknaden. Det är stora kunder och affärsutvecklingsavdelningen ger dem råd om produktkapacitet. Det följer också att vid köptillfället vet våra kunder redan vilka problem vår programvara hjälper dem att lösa. Deras rutter i applikationen måste sammanfalla med CJM som är inbäddad i produkten, och UX-lösningar hjälper dem att hålla sig på rätt spår. Spoiler: detta händer inte alltid. Introduktionen till biblioteket sköts upp... men inte länge.
Allt förändrades med lanseringen av vår startup - — plattformar för att skapa en onlinebutik från ett Instagram-konto. I den här applikationen fick användaren en tvåveckorsperiod för att använda all funktionalitet gratis. Sedan fick man bestämma sig för om man skulle prenumerera. Och detta passar perfekt in i konceptet "ruttmålåtgärd". Det bestämdes: låt oss försöka!
Första resultaten eller var man kan få idéer ifrån
Utvecklingsteamet och jag kopplade produkten till evenemangsinsamlingssystemet bokstavligen på en dag. Jag kommer genast att säga att ISPsystem använder sitt eget system för att samla in händelser om sidbesök, men ingenting hindrar dig från att använda Yandex.Metrica för samma ändamål, vilket låter dig ladda ner rådata gratis. Exempel på användning av biblioteket studerades och efter en veckas datainsamling fick vi en övergångsgraf.
Övergångsdiagram. Grundläggande funktionalitet, andra övergångar borttagna för tydlighetens skull
Det blev precis som i exemplet: plan, klar, vacker. Från denna graf kunde vi identifiera de vanligaste rutterna och korsningarna där människor tillbringar längst tid. Detta gjorde att vi kunde förstå följande:
- Istället för ett stort CJM, som täcker ett dussin enheter, används endast två aktivt. Det är nödvändigt att dessutom dirigera användare till de platser vi behöver med hjälp av UX-lösningar.
- Vissa sidor, designade av UX-designers för att vara end-to-end, slutar med att människor spenderar orimligt mycket tid på dem. Du måste ta reda på vad stoppelementen är på en specifik sida och justera det.
- Efter 10 övergångar började 20 % av människorna att tröttna och avsluta sessionen i applikationen. Och detta med hänsyn till det faktum att vi hade så många som 5 onboarding-sidor i applikationen! Du måste identifiera sidor där användare regelbundet överger sessioner och förkorta vägen till dem. Ännu bättre: identifiera alla vanliga rutter och tillåt en snabb övergång från källsidan till målsidan. Något gemensamt med ABC-analys och analys av övergiven vagn, tror du inte?
Och här omprövade vi vår inställning till användbarheten av detta verktyg för produkter på plats. Det beslutades att analysera en aktivt såld och använd produkt - . Det är mycket mer komplext, det finns en storleksordning fler enheter. Vi väntade med spänning på att se vad övergångsgrafen skulle visa sig vara.
Om besvikelser och inspirationer
Besvikelse #1
Det var slutet av arbetsdagen, slutet av månaden och slutet av året vid samma tidpunkt - 27 december. Data har samlats, frågor har skrivits. Det var sekunder kvar innan allt var bearbetat och vi kunde titta på resultatet av vårt arbete för att ta reda på var nästa arbetsår skulle börja. FoU-avdelningen, produktchef, UX-designers, teamledare, utvecklare samlades framför monitorn för att se hur användarvägarna ser ut i deras produkt, men... vi såg detta:
Övergångsdiagram byggt av Retentioneering-biblioteket
Inspiration #1
Starkt sammankopplade, dussintals enheter, icke-uppenbara scenarier. Det stod bara klart att det nya arbetsåret inte skulle börja med analys, utan med uppfinnandet av ett sätt att förenkla arbetet med en sådan graf. Men jag kunde inte skaka av mig känslan av att allt var mycket enklare än det verkade. Och efter femton minuters studie av Retentioneering-källkoden kunde vi exportera den konstruerade grafen till punktformat. Detta gjorde det möjligt att ladda upp grafen till ett annat verktyg - Gephi. Och det finns redan utrymme för att analysera grafer: layouter, filter, statistik - allt du behöver göra är att konfigurera de nödvändiga parametrarna i gränssnittet. Med denna tanke i åtanke åkte vi till nyårshelgen.
Besvikelse #2
Efter att ha återvänt till jobbet visade det sig att medan alla vilade studerade våra kunder produkten. Ja, så hårt att det dök upp händelser i förrådet som inte fanns tidigare. Detta innebar att frågorna behövde uppdateras.
Lite bakgrund för att förstå sorgen i detta faktum. Vi överför både de händelser vi har markerat (till exempel klick på några knappar) och webbadresserna till de sidor som användaren besökte. I fallet med Cartbee fungerade modellen "en åtgärd - en sida". Men med VMmanager var situationen helt annorlunda: flera modala fönster kunde öppnas på en sida. I dem kunde användaren lösa olika problem. Till exempel URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
betyder att användaren har lagt till en IP-adress på sidan "IP-adresser". Och här syns två problem samtidigt:
- URL:en innehåller någon slags sökvägsparameter - ID:t för den virtuella maskinen. Det måste uteslutas.
- URL:en innehåller det modala fönster-ID:t. Du måste på något sätt "packa upp" sådana webbadresser.
Ett annat problem var att just de händelser vi markerade hade parametrar. Det fanns till exempel fem olika sätt att komma till sidan med information om en virtuell maskin från listan. Följaktligen skickades en händelse, men med en parameter som angav vilken metod användaren gjorde övergången. Det fanns många sådana händelser, och alla parametrar var olika. Och vi har all logik för datahämtning i SQL-dialekten för Clickhouse. Förfrågningar på 150-200 rader började verka något vanliga. Problem omgav oss.
Inspiration #2
En tidig morgon föreslog Danil, som sorgset bläddrade igenom begäran för den andra minuten, för mig: "Låt oss skriva databehandlingspipelines?" Vi funderade på det och bestämde oss för att om vi skulle göra det skulle det vara något som ETL. Så att den filtrerar omedelbart och hämtar nödvändig data från andra källor. Så här föddes vår första analytiska tjänst med en fullfjädrad backend. Den implementerar fem huvudsteg av databehandling:
- Lossa händelser från rådatalagringen och förbereda dem för bearbetning.
- Förtydligande är "uppackning" av just dessa identifierare av modala fönster, händelseparametrar och andra detaljer som förtydligar händelsen.
- Anrikning (från ordet "att bli rik") är tillägg av händelser med data från tredjepartskällor. På den tiden inkluderade detta bara vårt faktureringssystem BILLmanager.
- Filtrering är processen att filtrera bort händelser som förvränger resultaten av analysen (händelser från interna montrar, extremvärden, etc.).
- Ladda upp mottagna händelser till lagring, som vi kallade ren data.
Nu var det möjligt att behålla relevansen genom att lägga till regler för bearbetning av en händelse eller till och med grupper av liknande händelser. Sedan dess har vi till exempel aldrig uppdaterat URL-uppackning. Även om flera nya URL-varianter har lagts till under denna tid. De följer de regler som redan finns i tjänsten och behandlas korrekt.
Besvikelse #3
När vi väl började analysera insåg vi varför grafen var så sammanhängande. Faktum är att nästan varje N-gram innehöll övergångar som inte kunde utföras via gränssnittet.
En liten utredning började. Jag var förvirrad över att det inte fanns några omöjliga övergångar inom en enhet. Detta betyder att detta inte är en bugg i händelseinsamlingssystemet eller vår ETL-tjänst. Det fanns en känsla av att användaren samtidigt arbetade i flera enheter, utan att flytta från en till en annan. Hur uppnår man detta? Använda olika flikar i webbläsaren.
När vi analyserade Cartbee räddades vi av dess specificitet. Applikationen användes från mobila enheter, där det helt enkelt är obekvämt att arbeta från flera flikar. Här har vi ett skrivbord och medan en uppgift utförs i en enhet är det rimligt att vilja lägga den här tiden på att ställa in eller övervaka status i en annan. Och för att inte tappa framsteg, öppna bara en annan flik.
Inspiration #3
Kollegor från frontend-utveckling lärde evenemangsinsamlingssystemet att skilja mellan flikar. Analysen kan börja. Och vi började. Som förväntat matchade CJM inte verkliga vägar: användare spenderade mycket tid på katalogsidor, övergivna sessioner och flikar på de mest oväntade platserna. Med hjälp av övergångsanalys kunde vi hitta problem i vissa Mozilla-byggen. I dem, på grund av implementeringsfunktioner, försvann navigeringselement eller halvtomma sidor visades, som endast borde vara tillgängliga för administratören. Sidan öppnades, men inget innehåll kom från backend. Att räkna övergångar gjorde det möjligt att utvärdera vilka funktioner som faktiskt användes. Kedjorna gjorde det möjligt att förstå hur användaren fick det eller det felet. Data som tillåts för testning baserat på användarbeteende. Det blev en succé, idén var inte förgäves.
Analytics automatisering
I en av resultatdemonstrationerna visade vi hur Gephi används för grafanalys. I det här verktyget kan konverteringsdata visas i en tabell. Och chefen för UX-avdelningen sa en mycket viktig tanke som påverkade utvecklingen av hela beteendeanalysriktningen i företaget: "Låt oss göra detsamma, men i Tableau och med filter - det kommer att vara bekvämare."
Då tänkte jag: varför inte, Retentioneering lagrar all data i en pandas.DataFrame-struktur. Och det här är i stort sett ett bord. Så här dök en annan tjänst ut: Dataleverantör. Han gjorde inte bara en tabell från grafen, utan räknade också ut hur populär sidan och den funktionalitet som är förknippad med den är, hur den påverkar användarretention, hur länge användare stannar på den och vilka sidor användare lämnar oftast. Och användningen av visualisering i Tableau minskade kostnaden för att studera grafen så mycket att iterationstiden för beteendeanalys i produkten nästan halverades.
Danil kommer att prata om hur denna visualisering används och vilka slutsatser den tillåter att dra.
Fler bord till bordsguden!
I en förenklad form formulerades uppgiften enligt följande: visa övergångsgrafen i Tableau, ge möjligheten att filtrera och göra den så tydlig och bekväm som möjligt.
Jag ville egentligen inte rita en riktad graf i Tableau. Och även om den lyckades, verkade vinsten, jämfört med Gephi, inte uppenbar. Vi behövde något mycket enklare och mer tillgängligt. Tabell! När allt kommer omkring kan grafen enkelt representeras i form av tabellrader, där varje rad är en kant av typen "källa-destination". Dessutom har vi redan noggrant förberett en sådan tabell med hjälp av verktygen Retentioneering och Data Provider. Allt som återstod att göra var att visa tabellen i Tableau och rota igenom rapporten.
På tal om hur alla älskar bord.
Men här står vi inför ett annat problem. Vad ska man göra med datakällan? Det var omöjligt att ansluta pandas.DataFrame, Tableau har inte en sådan kontakt. Att höja en separat bas för att lagra grafen verkade vara en alltför radikal lösning med vaga utsikter. Och lokala lossningsmöjligheter var inte lämpliga på grund av behovet av konstanta manuella operationer. Vi tittade igenom listan över tillgängliga kontakter, och vår blick föll på föremålet , som trängde ihop sig övergiven längst ner.
Tableau har ett rikt urval av kontakter. Vi hittade en som löste vårt problem
Vad för djur? Några nya öppna flikar i webbläsaren - och det blev tydligt att denna anslutning låter dig ta emot data när du kommer åt en URL. Backend för att beräkna själva data var nästan klar, allt som återstod var att bli vän med WDC. I flera dagar studerade Denis dokumentationen och slogs med Tableau-mekanismerna och skickade sedan en länk till mig som jag klistrade in i anslutningsfönstret.
Anslutningsformulär till vår WDC. Denis gjorde sin front och tog hand om säkerheten
Efter ett par minuters väntan (data beräknas dynamiskt vid begäran) dök tabellen upp:
Så här ser en rådatamatris ut i Tableau-gränssnittet
Som utlovat representerade varje rad i en sådan tabell en kant av grafen, det vill säga en riktad övergång för användaren. Den innehöll också flera ytterligare egenskaper. Till exempel antalet unika användare, det totala antalet övergångar och andra.
Det skulle vara möjligt att visa denna tabell i rapporten som den är, strö över filter generöst och skicka verktyget i väg. Låter logiskt. Vad kan du göra med bordet? Men det här är inte vårt sätt, för vi gör inte bara en tabell, utan ett verktyg för att analysera och fatta produktbeslut.
Vanligtvis, när man analyserar data, vill en person få svar på frågor. Bra. Låt oss börja med dem.
- Vilka är de vanligaste övergångarna?
- Vart tar de vägen från specifika sidor?
- Hur lång tid spenderar du i genomsnitt på den här sidan innan du lämnar?
- Hur ofta gör du övergången från A till B?
- På vilka sidor slutar sessionen?
Var och en av rapporterna eller en kombination av dem bör göra det möjligt för användaren att självständigt hitta svar på dessa frågor. Nyckelstrategin här är att ge dig verktygen för att göra det själv. Detta är användbart både för att minska belastningen på analysavdelningen och för att minska tiden för att fatta beslut – trots allt behöver du inte längre gå till Youtrack och skapa en uppgift för analytikern, du behöver bara öppna rapporten.
Vad fick vi?
Var avviker människor oftast från instrumentpanelen?
Fragment av vår rapport. Efter instrumentpanelen gick alla antingen till listan över virtuella datorer eller till listan med noder
Låt oss ta en allmän tabell med övergångar och filtrera efter källsida. Oftast går de från instrumentpanelen till listan över virtuella maskiner. Dessutom antyder kolumnen Regularitet att detta är en återkommande åtgärd.
Var kommer de ifrån till listan över kluster?
Filter i rapporter fungerar i båda riktningarna: du kan ta reda på var du lämnade eller vart du tog vägen
Från exemplen är det tydligt att även närvaron av två enkla filter och rangordning av rader efter värden gör att du snabbt kan få information.
Låt oss fråga något svårare.
Var överger användare oftast sin session?
VMmanager-användare arbetar ofta på separata flikar
För att göra detta behöver vi en rapport vars data är aggregerad av hänvisningskällor. Och de så kallade brytpunkterna togs som uppdrag - händelser som fungerade som slutet på kedjan av övergångar.
Det är viktigt att notera här att detta antingen kan vara slutet på sessionen eller öppnandet av en ny flik. Exemplet visar att kedjan oftast slutar vid ett bord med en lista över virtuella maskiner. I det här fallet är det karakteristiska beteendet att byta till en annan flik, vilket överensstämmer med det förväntade mönstret.
Vi testade först och främst nyttan av dessa rapporter på oss själva när vi genomförde analysen på liknande sätt , en annan av våra produkter. Med tillkomsten av tabeller och filter testades hypoteser snabbare och ögonen var mindre trötta.
När vi utvecklade rapporter glömde vi inte visuell design. När man arbetar med bord av denna storlek är detta en viktig faktor. Vi använde till exempel ett lugnt urval av färger, lätta att uppfatta för siffror, färgmarkering av linjer i enlighet med de numeriska värdena för egenskaperna. Sådana detaljer förbättrar användarupplevelsen och ökar sannolikheten för att verktyget kommer igång framgångsrikt inom företaget.
Tabellen visade sig vara ganska omfångsrik, men vi hoppas att den inte har upphört att vara läsbar
Det är värt att nämna separat om utbildningen av våra interna kunder: produktspecialister och UX-designers. Manualer med analysexempel och tips för att arbeta med filter utarbetades speciellt för dem. Vi la in länkar till manualer direkt på rapportsidorna.
Vi gjorde manualen helt enkelt som en presentation i Google Docs. Med tabellverktyg kan du visa webbsidor direkt i en rapportarbetsbok.
i stället för en epilog
Vad står på den nedersta raden? Vi kunde få ett verktyg för varje dag relativt snabbt och billigt. Ja, detta är definitivt inte en ersättning för själva grafen, värmekartan över klick eller webbvisaren. Men sådana rapporter kompletterar avsevärt de listade verktygen och ger mat till eftertanke och nya produkt- och gränssnittshypoteser.
Denna historia fungerade bara som början för utvecklingen av analys i ISPsystem. Under det senaste halvåret har ytterligare sju nya tjänster dykt upp, inklusive digitala porträtt av användaren i produkten och en tjänst för att skapa databaser för Look-alike-inriktning, men vi kommer att prata om dem i följande avsnitt.
Källa: will.com