Er zijn honderden artikelen op internet over de voordelen van het analyseren van klantgedrag. Meestal betreft dit de detailhandel. Van voedselmandanalyse, ABC- en XYZ-analyse tot retentiemarketing en persoonlijke aanbiedingen. Er worden al tientallen jaren verschillende technieken gebruikt, de algoritmen zijn uitgedacht, de code is geschreven en gedebugd - neem het en gebruik het. In ons geval deed zich één fundamenteel probleem voor: wij bij ISPsystem houden ons bezig met softwareontwikkeling, niet met detailhandel.
Mijn naam is Denis en momenteel ben ik verantwoordelijk voor de backend van analytische systemen bij ISPsystem. En dit is het verhaal van hoe mijn collega en ik – degenen die verantwoordelijk zijn voor de datavisualisatie – probeerden door het prisma van deze kennis naar onze softwareproducten te kijken. Laten we, zoals gewoonlijk, beginnen met de geschiedenis.
In het begin was er een woord, en het woord was: "Zullen we het proberen?"
Op dat moment werkte ik als ontwikkelaar op de R&D-afdeling. Het begon allemaal toen Danil hier op Habré las — een hulpmiddel voor het analyseren van gebruikersovergangen in applicaties. Ik was enigszins sceptisch over het idee om het hier te gebruiken. Als voorbeeld noemden de bibliotheekontwikkelaars een analyse van applicaties waarbij de beoogde actie duidelijk was gedefinieerd: het plaatsen van een bestelling of een andere variant van hoe het bedrijf van de eigenaar moest worden betaald. Onze producten worden op locatie geleverd. Dat wil zeggen dat de gebruiker eerst een licentie koopt en pas daarna aan zijn reis in de applicatie begint. Ja, we hebben demoversies. Je kunt het product daar uitproberen, zodat je geen varken in de zak hebt.
Maar de meeste van onze producten zijn gericht op de hostingmarkt. Dit zijn grote klanten en de afdeling business development adviseert hen over de productmogelijkheden. Hieruit volgt ook dat onze klanten op het moment van aankoop al weten welke problemen onze software hen zal helpen oplossen. Hun routes in de applicatie moeten samenvallen met de CJM die in het product is ingebed, en UX-oplossingen helpen hen op koers te blijven. Spoiler: dit gebeurt niet altijd. De kennismaking met de bibliotheek werd uitgesteld... maar niet voor lang.
Alles veranderde met de release van onze startup - — platforms voor het creëren van een online winkel vanaf een Instagram-account. In deze applicatie kreeg de gebruiker twee weken de tijd om gratis gebruik te maken van alle functionaliteit. Vervolgens moest u beslissen of u zich wilde abonneren. En dit paste perfect in het concept van ‘route-target action’. Er werd besloten: laten we het proberen!
Eerste resultaten of waar u ideeën vandaan kunt halen
Het ontwikkelingsteam en ik hebben het product letterlijk binnen een dag aan het evenementenverzamelingssysteem gekoppeld. Ik zal meteen zeggen dat ISPsystem zijn eigen systeem gebruikt voor het verzamelen van gebeurtenissen over paginabezoeken, maar niets belet je om Yandex.Metrica voor dezelfde doeleinden te gebruiken, waardoor je gratis onbewerkte gegevens kunt downloaden. Er werden voorbeelden van het gebruik van de bibliotheek bestudeerd en na een week gegevensverzameling ontvingen we een overgangsgrafiek.
Overgangsgrafiek. Basisfunctionaliteit, andere overgangen verwijderd voor de duidelijkheid
Het bleek precies zoals in het voorbeeld: vlak, helder, mooi. Uit deze grafiek konden we de meest voorkomende routes en kruispunten identificeren waar mensen de langste tijd doorbrengen. Hierdoor konden we het volgende begrijpen:
- In plaats van een grote CJM, die een tiental entiteiten bestrijkt, worden er slechts twee actief gebruikt. Het is noodzakelijk om gebruikers bovendien naar de plaatsen te leiden die we nodig hebben met behulp van UX-oplossingen.
- Sommige pagina's, ontworpen door UX-ontwerpers om end-to-end te zijn, zorgen ervoor dat mensen er onredelijk veel tijd aan besteden. U moet uitzoeken wat de stopelementen op een specifieke pagina zijn en deze aanpassen.
- Na 10 overgangen begon 20% van de mensen moe te worden en verlieten ze de sessie in de applicatie. En hierbij wordt rekening gehouden met het feit dat we maar liefst 5 onboardingpagina's in de applicatie hadden! U moet pagina's identificeren waar gebruikers regelmatig sessies verlaten en het pad ernaartoe verkorten. Nog beter: identificeer eventuele reguliere routes en zorg voor een snelle overgang van de bronpagina naar de bestemmingspagina. Iets wat gemeen heeft met ABC-analyse en verlaten kar-analyse, vind je niet?
En hier hebben we onze houding ten opzichte van de toepasbaarheid van deze tool voor on-premise producten heroverwogen. Er werd besloten een actief verkocht en gebruikt product te analyseren - . Het is veel complexer, er zijn een orde van grootte meer entiteiten. We wachtten opgewonden om te zien wat de overgangsgrafiek zou blijken te zijn.
Over teleurstellingen en inspiraties
Teleurstelling nummer 1
Het was het einde van de werkdag, het einde van de maand en het einde van het jaar tegelijkertijd: 27 december. Er zijn gegevens verzameld, er zijn vragen geschreven. Er waren nog enkele seconden voordat alles verwerkt was en we naar het resultaat van onze inspanningen konden kijken om erachter te komen waar het volgende werkjaar zou beginnen. De R&D-afdeling, productmanager, UX-ontwerpers, teamleider, ontwikkelaars verzamelden zich voor de monitor om te zien hoe de gebruikerspaden er in hun product uitzien, maar... we zagen dit:
Overgangsgrafiek gebouwd door de Retentioneering-bibliotheek
Inspiratie #1
Sterk verbonden, tientallen entiteiten, niet voor de hand liggende scenario's. Het was alleen duidelijk dat het nieuwe werkjaar niet zou beginnen met analyse, maar met de uitvinding van een manier om het werk met zo'n grafiek te vereenvoudigen. Maar ik kon het gevoel niet van me afschudden dat alles veel eenvoudiger was dan het leek. En na vijftien minuten bestuderen van de Retentioneering-broncode konden we de geconstrueerde grafiek naar puntformaat exporteren. Dit maakte het mogelijk om de grafiek naar een andere tool te uploaden: Gephi. En er is al ruimte voor het analyseren van grafieken: lay-outs, filters, statistieken - het enige wat u hoeft te doen is de noodzakelijke parameters in de interface te configureren. Met deze gedachte in ons achterhoofd vertrokken we naar het nieuwjaarsweekend.
Teleurstelling nummer 2
Toen we weer aan het werk gingen, bleek dat terwijl iedereen rustte, onze klanten het product bestudeerden. Ja, zo hard dat er gebeurtenissen in de opslag verschenen die voorheen niet bestonden. Dit betekende dat de queries moesten worden bijgewerkt.
Een beetje achtergrondinformatie om de droefheid van dit feit te begrijpen. We verzenden zowel de gebeurtenissen die we hebben gemarkeerd (bijvoorbeeld klikken op sommige knoppen) als de URL's van de pagina's die de gebruiker heeft bezocht. In het geval van Cartbee werkte het ‘één actie – één pagina’-model. Maar met VMmanager was de situatie compleet anders: er konden meerdere modale vensters op één pagina worden geopend. Daarin kon de gebruiker verschillende problemen oplossen. Bijvoorbeeld URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
betekent dat de gebruiker op de pagina “IP-adressen” een IP-adres heeft toegevoegd. En hier zijn twee problemen tegelijk zichtbaar:
- De URL bevat een soort padparameter: de ID van de virtuele machine. Het moet worden uitgesloten.
- De URL bevat de modale venster-ID. U moet dergelijke URL's op de een of andere manier "uitpakken".
Een ander probleem was dat juist de gebeurtenissen die we markeerden parameters hadden. Er waren bijvoorbeeld vijf verschillende manieren om op de pagina met informatie over een virtuele machine uit de lijst te komen. Dienovereenkomstig werd één gebeurtenis verzonden, maar met een parameter die aangaf welke methode de gebruiker de overstap maakte. Er waren veel van dergelijke evenementen en alle parameters waren verschillend. En we hebben alle logica voor het ophalen van gegevens in het SQL-dialect voor Clickhouse. Zoekopdrachten van 150 tot 200 regels begonnen enigszins gebruikelijk te lijken. Problemen omringden ons.
Inspiratie #2
Op een vroege ochtend stelde Danil, die verdrietig door het verzoek voor de tweede minuut bladerde, mij voor: "Laten we pijplijnen voor gegevensverwerking schrijven?" We hebben erover nagedacht en besloten dat als we het zouden doen, het zoiets als ETL zou zijn. Zodat het direct filtert en de benodigde data uit andere bronnen haalt. Zo ontstond onze eerste analytische dienst met een volwaardige backend. Het implementeert vijf hoofdfasen van gegevensverwerking:
- Gebeurtenissen uit de ruwe gegevensopslag halen en voorbereiden voor verwerking.
- Verduidelijking is het ‘uitpakken’ van juist die identificatiegegevens van modale vensters, gebeurtenisparameters en andere details die de gebeurtenis verduidelijken.
- Verrijking (van het woord ‘rijk worden’) is de toevoeging van gebeurtenissen met gegevens uit externe bronnen. Destijds omvatte dit alleen ons facturatiesysteem BILLmanager.
- Filteren is het proces waarbij gebeurtenissen worden weggefilterd die de resultaten van de analyse vertekenen (gebeurtenissen van interne standaarden, uitschieters, enz.).
- Het uploaden van ontvangen gebeurtenissen naar de opslag, wat we schone gegevens noemden.
Nu was het mogelijk om de relevantie te behouden door regels toe te voegen voor het verwerken van een gebeurtenis of zelfs groepen van soortgelijke gebeurtenissen. Sindsdien hebben we bijvoorbeeld het uitpakken van URL's nooit meer bijgewerkt. Hoewel er gedurende deze tijd verschillende nieuwe URL-variaties zijn toegevoegd. Ze voldoen aan de regels die al in de dienst zijn vastgelegd en worden correct verwerkt.
Teleurstelling nummer 3
Toen we eenmaal begonnen met analyseren, beseften we waarom de grafiek zo coherent was. Feit is dat bijna elk N-gram overgangen bevatte die niet via de interface konden worden uitgevoerd.
Er werd een klein onderzoek gestart. Ik was in de war dat er binnen één entiteit geen onmogelijke overgangen bestonden. Dit betekent dat dit geen bug is in het evenementenverzamelingssysteem of onze ETL-service. Er was een gevoel dat de gebruiker tegelijkertijd in verschillende entiteiten werkte, zonder van de ene naar de andere te gaan. Hoe dit te bereiken? Verschillende tabbladen in de browser gebruiken.
Bij het analyseren van Cartbee werden we gered door de specificiteit ervan. De applicatie werd gebruikt vanaf mobiele apparaten, waar het werken vanaf meerdere tabbladen simpelweg onhandig is. Hier hebben we een bureaublad en terwijl een taak in de ene entiteit wordt uitgevoerd, is het redelijk om deze tijd te willen besteden aan het opzetten of bewaken van de status in een andere. En om de voortgang niet te verliezen, opent u gewoon een ander tabblad.
Inspiratie #3
Collega's van front-end development leerden het evenementenverzamelsysteem onderscheid maken tussen tabbladen. De analyse kon beginnen. En wij begonnen. Zoals verwacht kwam CJM niet overeen met echte paden: gebruikers brachten veel tijd door op directorypagina's, verlaten sessies en tabbladen op de meest onverwachte plaatsen. Met behulp van transitieanalyse konden we problemen in sommige Mozilla-builds vinden. Daarin verdwenen vanwege implementatiefuncties navigatie-elementen of werden halflege pagina's weergegeven, die alleen toegankelijk zouden moeten zijn voor de beheerder. De pagina werd geopend, maar er kwam geen inhoud uit de backend. Door overgangen te tellen, werd het mogelijk om te evalueren welke kenmerken daadwerkelijk werden gebruikt. De ketens maakten het mogelijk om te begrijpen hoe de gebruiker deze of gene fout ontving. Met de gegevens kon worden getest op basis van gebruikersgedrag. Het was een succes, het idee was niet voor niets.
Automatisering van analyses
In een van de resultaatdemonstraties lieten we zien hoe Gephi wordt gebruikt voor grafiekanalyse. In deze tool kunnen conversiegegevens in een tabel worden weergegeven. En het hoofd van de UX-afdeling zei een zeer belangrijke gedachte die de ontwikkeling van de hele richting van gedragsanalyse in het bedrijf beïnvloedde: "Laten we hetzelfde doen, maar dan in Tableau en met filters - het zal handiger zijn."
Toen dacht ik: waarom niet, Retentioneering slaat alle data op in een pandas.DataFrame-structuur. En dit is over het algemeen een tafel. Zo verscheen er een andere dienst: Data Provider. Hij maakte niet alleen een tabel van de grafiek, maar berekende ook hoe populair de pagina en de bijbehorende functionaliteit zijn, hoe dit de gebruikersretentie beïnvloedt, hoe lang gebruikers erop blijven en welke pagina's gebruikers het vaakst verlaten. En het gebruik van visualisatie in Tableau verminderde de kosten voor het bestuderen van de grafiek zo veel dat de iteratietijd voor gedragsanalyse in het product bijna werd gehalveerd.
Danil zal vertellen hoe deze visualisatie wordt gebruikt en welke conclusies daaruit kunnen worden getrokken.
Meer tafels voor de tafelgod!
In vereenvoudigde vorm was de taak als volgt geformuleerd: toon de overgangsgrafiek in Tableau, zorg voor de mogelijkheid om te filteren en maak deze zo duidelijk en handig mogelijk.
Ik wilde niet echt een gerichte grafiek in Tableau tekenen. En zelfs als het succesvol was, leek de winst, vergeleken met Gephi, niet voor de hand liggend. We hadden iets veel eenvoudigers en toegankelijkers nodig. Tafel! De grafiek kan immers eenvoudig worden weergegeven in de vorm van tabelrijen, waarbij elke rij een rand is van het type ‘bron-bestemming’. Bovendien hebben we zo’n tabel al zorgvuldig voorbereid met behulp van Retentioneering- en Data Provider-tools. Het enige wat we nog moesten doen was de tabel in Tableau weergeven en door het rapport bladeren.
Over hoe iedereen van tafels houdt gesproken.
Hier worden we echter met een ander probleem geconfronteerd. Wat te doen met de gegevensbron? Het was onmogelijk om pandas.DataFrame te verbinden; Tableau beschikt niet over een dergelijke connector. Het oprichten van een aparte basis voor het opslaan van de grafiek leek een te radicale oplossing met vage vooruitzichten. En lokale losmogelijkheden waren niet geschikt vanwege de noodzaak van constante handmatige handelingen. We hebben de lijst met beschikbare connectoren doorgenomen en onze blik viel op het item , die helemaal onderaan ineengedoken zat.
Tableau heeft een rijke selectie connectoren. We hebben er een gevonden die ons probleem oploste
Wat voor dier? Een paar nieuwe geopende tabbladen in de browser - en het werd duidelijk dat je met deze connector gegevens kunt ontvangen bij het openen van een URL. De backend voor het berekenen van de gegevens zelf was bijna klaar, het enige dat nog restte was om hem bevriend te maken met WDC. Dagenlang bestudeerde Denis de documentatie en vocht met de Tableau-mechanismen, en stuurde me toen een link die ik in het verbindingsvenster plakte.
Verbindingsformulier met ons WDC. Denis ging voorop en zorgde voor de veiligheid
Na een paar minuten wachten (de gegevens worden dynamisch berekend wanneer daarom wordt gevraagd), verscheen de tabel:
Zo ziet een array met onbewerkte gegevens eruit in de Tableau-interface
Zoals beloofd vertegenwoordigde elke rij van een dergelijke tabel een rand van de grafiek, dat wil zeggen een gerichte overgang van de gebruiker. Het bevatte ook een aantal aanvullende kenmerken. Bijvoorbeeld het aantal unieke gebruikers, het totale aantal transities en andere.
Het zou mogelijk zijn om deze tabel in het rapport weer te geven zoals hij is, royaal filters te strooien en de tool te laten varen. Klinkt logisch. Wat kun je met de tafel? Maar dit is niet onze manier, omdat we niet alleen een tabel maken, maar een hulpmiddel voor analyse en het nemen van productbeslissingen.
Bij het analyseren van gegevens wil iemand doorgaans antwoorden op vragen krijgen. Geweldig. Laten we met hen beginnen.
- Wat zijn de meest voorkomende transities?
- Waar gaan ze naartoe vanaf specifieke pagina's?
- Hoe lang blijft u gemiddeld op deze pagina voordat u vertrekt?
- Hoe vaak maak jij de overstap van A naar B?
- Op welke pagina's eindigt de sessie?
Elk van de rapporten of een combinatie daarvan moet de gebruiker in staat stellen zelfstandig antwoorden op deze vragen te vinden. De belangrijkste strategie hier is om u de tools te geven om het zelf te doen. Dit is zowel nuttig om de belasting van de analyseafdeling te verminderen als om de tijd voor het nemen van beslissingen te verkorten. U hoeft immers niet langer naar Youtrack te gaan en een taak voor de analist aan te maken, u hoeft alleen maar het rapport te openen.
Wat hebben we gekregen?
Waar wijken mensen het vaakst af van het dashboard?
Fragment van ons rapport. Na het dashboard ging iedereen naar de lijst met VM's of naar de lijst met knooppunten
Laten we een algemene tabel met overgangen nemen en filteren op bronpagina. Meestal gaan ze van het dashboard naar de lijst met virtuele machines. Bovendien suggereert de kolom Regelmaat dat dit een herhalende actie is.
Waar komen ze vandaan in de lijst met clusters?
Filters in rapporten werken twee kanten op: u kunt achterhalen waar u bent gebleven, of waar u naartoe bent gegaan
Uit de voorbeelden wordt duidelijk dat zelfs de aanwezigheid van twee eenvoudige filters en het rangschikken van rijen op waarden u in staat stelt snel informatie te verkrijgen.
Laten we iets moeilijkers vragen.
Waar verlaten gebruikers het vaakst hun sessie?
VMmanager-gebruikers werken vaak in aparte tabbladen
Om dit te doen hebben we een rapport nodig waarvan de gegevens zijn verzameld door verwijzingsbronnen. En de zogenaamde breekpunten werden als opdrachten opgevat: gebeurtenissen die dienden als het einde van de keten van transities.
Het is belangrijk op te merken dat dit het einde van de sessie kan zijn of het openen van een nieuw tabblad. Uit het voorbeeld blijkt dat de keten meestal eindigt bij een tafel met een lijst met virtuele machines. In dit geval is het kenmerkende gedrag het overschakelen naar een ander tabblad, wat consistent is met het verwachte patroon.
Het nut van deze rapporten hebben we allereerst op onszelf getest toen we de analyse op een vergelijkbare manier uitvoerden , nog een van onze producten. Met de komst van tabellen en filters werden hypothesen sneller getest en waren de ogen minder vermoeid.
Bij het ontwikkelen van rapporten zijn we het visuele ontwerp niet vergeten. Bij het werken met tafels van dit formaat is dit een belangrijke factor. We hebben bijvoorbeeld een rustig kleurengamma gebruikt, gemakkelijk waarneembaar voor cijfers, kleuraccentuering van lijnen in overeenstemming met de numerieke waarden van de kenmerken. Dergelijke details verbeteren de gebruikerservaring en vergroten de kans dat de tool succesvol van start gaat binnen het bedrijf.
De tabel bleek behoorlijk omvangrijk te zijn, maar we hopen dat hij nog steeds leesbaar is
Apart vermeldenswaard is de opleiding van onze interne klanten: productspecialisten en UX-designers. Speciaal voor hen zijn handleidingen met analysevoorbeelden en tips voor het werken met filters opgesteld. We hebben links naar handleidingen rechtstreeks op de rapportpagina's ingevoegd.
We hebben de handleiding eenvoudig gemaakt als presentatie in Google Docs. Met Tableau-tools kunt u webpagina's rechtstreeks in een rapportwerkmap weergeven.
In plaats van een nawoord
Wat staat er op de onderste regel? We konden relatief snel en goedkoop een hulpmiddel voor elke dag krijgen. Ja, dit is zeker geen vervanging voor de grafiek zelf, de heatmap van klikken of de webviewer. Maar dergelijke rapporten vormen een aanzienlijke aanvulling op de opgesomde instrumenten en bieden stof tot nadenken en nieuwe product- en interfacehypothesen.
Dit verhaal diende slechts als het begin voor de ontwikkeling van analytics in ISPsystem. De afgelopen zes maanden zijn er nog zeven nieuwe diensten verschenen, waaronder digitale portretten van de gebruiker in het product en een dienst voor het maken van databases voor Look-alike targeting, maar daar zullen we in de volgende afleveringen over praten.
Bron: www.habr.com