Na internete sú stovky článkov o výhodách analýzy správania zákazníkov. Najčastejšie sa to týka maloobchodného sektora. Od analýzy potravinového koša, analýzy ABC a XYZ až po retenčný marketing a osobné ponuky. Desaťročia sa používajú rôzne techniky, premyslené algoritmy, napísaný a odladený kód – vezmite si ho a použite. V našom prípade nastal jeden zásadný problém – v ISPsystem sa venujeme vývoju softvéru, nie retailu.
Volám sa Denis a momentálne som zodpovedný za backend analytických systémov v ISPsystem. A toto je príbeh o tom, ako sme s kolegom — tí, ktorí sú zodpovední za vizualizáciu dát — sa pokúsili pozrieť na naše softvérové produkty cez prizmu týchto znalostí. Začnime, ako inak, históriou.
Na začiatku bolo slovo a to slovo bolo „Skúsime to?
V tom čase som pracoval ako vývojár na oddelení výskumu a vývoja. Všetko to začalo, keď Danil čítal tu na Habré — nástroj na analýzu používateľských prechodov v aplikáciách. Bol som trochu skeptický k myšlienke použiť ho tu. Ako príklady vývojári knižnice uviedli analýzu aplikácií, kde bola jasne definovaná cieľová akcia – zadanie objednávky alebo iná variácia spôsobu platby vlastníkovi spoločnosti. Naše produkty sú dodávané na mieste. To znamená, že používateľ si najprv kúpi licenciu a až potom začne svoju cestu v aplikácii. Áno, máme demo verzie. Produkt si tam môžete vyskúšať, aby ste nemali prasa v žite.
Väčšina našich produktov je však zameraná na hostingový trh. Ide o veľkých klientov a oddelenie rozvoja podnikania im radí ohľadom možností produktov. Z toho tiež vyplýva, že naši zákazníci už pri kúpe vedia, aké problémy im náš softvér pomôže vyriešiť. Ich trasy v aplikácii sa musia zhodovať s CJM zabudovaným v produkte a riešenia UX im pomôžu zostať na správnej ceste. Spoiler: nie vždy sa to stáva. Úvod do knižnice bol odložený... ale nie na dlho.
Všetko sa zmenilo vydaním nášho startupu - — platformy na vytvorenie internetového obchodu z účtu Instagram. V tejto aplikácii dostal používateľ dvojtýždňovú lehotu na bezplatné využívanie všetkých funkcií. Potom ste sa museli rozhodnúť, či sa prihlásite na odber. A to dokonale zapadá do konceptu „akcia trasa – cieľ“. Bolo rozhodnuté: skúsme!
Prvé výsledky alebo odkiaľ čerpať nápady
S vývojovým tímom sme produkt pripojili k systému zberu udalostí doslova za deň. Hneď poviem, že ISPsystem používa svoj vlastný systém na zhromažďovanie udalostí o návštevách stránok, ale nič vám nebráni používať Yandex.Metrica na rovnaké účely, čo vám umožňuje sťahovať nespracované údaje zadarmo. Študovali sa príklady použitia knižnice a po týždni zberu údajov sme dostali prechodový graf.
Prechodový graf. Základná funkčnosť, ostatné prechody odstránené kvôli prehľadnosti
Ukázalo sa to rovnako ako v príklade: rovinné, jasné, krásne. Z tohto grafu sa nám podarilo identifikovať najčastejšie trasy a prechody, kde ľudia trávia najdlhší čas. To nám umožnilo pochopiť nasledovné:
- Namiesto veľkého CJM, ktorý zastrešuje tucet subjektov, sa aktívne využívajú len dva. Je potrebné dodatočne nasmerovať používateľov na miesta, ktoré potrebujeme pomocou UX riešení.
- Niektoré stránky, navrhnuté dizajnérmi UX, aby boli komplexné, skončia tak, že na nich ľudia trávia neprimerane veľa času. Musíte zistiť, aké sú zastavovacie prvky na konkrétnej stránke a upraviť ich.
- Po 10 prechodoch začalo byť 20% ľudí unavených a ukončili reláciu v aplikácii. A to s prihliadnutím na fakt, že v aplikácii sme mali až 5 vstupných stránok! Musíte identifikovať stránky, na ktorých používatelia pravidelne opúšťajú relácie, a skrátiť si k nim cestu. Ešte lepšie: identifikujte všetky bežné trasy a umožnite rýchly prechod zo zdrojovej stránky na cieľovú. Niečo spoločné s analýzou ABC a analýzou opusteného košíka, nemyslíte?
A tu sme prehodnotili náš postoj k použiteľnosti tohto nástroja pre on-premise produkty. Bolo rozhodnuté analyzovať aktívne predávaný a používaný produkt - . Je to oveľa zložitejšie, entít je rádovo viac. S napätím sme čakali, aký bude prechodový graf.
O sklamaniach a inšpiráciách
Sklamanie #1
Bol koniec pracovného dňa, koniec mesiaca a zároveň koniec roka – 27. decembra. Dáta boli nahromadené, dopyty boli napísané. Do spracovania všetkého zostávali sekundy a my sme sa mohli pozrieť na výsledok našej práce, aby sme zistili, kde sa začne ďalší pracovný rok. Oddelenie výskumu a vývoja, produktový manažér, dizajnéri UX, vedúci tímu, vývojári sa zhromaždili pred monitorom, aby videli, ako vyzerajú cesty používateľov v ich produkte, ale... videli sme toto:
Prechodový graf vytvorený knižnicou Retentioneering
Inšpirácia #1
Silne prepojené, desiatky entít, nesamozrejmé scenáre. Bolo len jasné, že nový pracovný rok sa nezačne rozborom, ale vynájdením spôsobu, ako si prácu s takýmto grafom zjednodušiť. Nemohol som sa však zbaviť pocitu, že všetko bolo oveľa jednoduchšie, ako sa zdalo. A po pätnástich minútach štúdia zdrojového kódu Retentioneering sme dokázali exportovať vytvorený graf do bodkového formátu. To umožnilo nahrať graf do iného nástroja – Gephi. A už existuje priestor na analýzu grafov: rozloženia, filtre, štatistiky - všetko, čo musíte urobiť, je nakonfigurovať potrebné parametre v rozhraní. S touto myšlienkou sme odišli na novoročný víkend.
Sklamanie #2
Po návrate do práce sa ukázalo, že kým všetci oddychovali, naši klienti študovali produkt. Áno, tak tvrdo, že sa v úložisku objavili udalosti, ktoré predtým neexistovali. To znamenalo, že dopyty bolo potrebné aktualizovať.
Trochu pozadia na pochopenie smútku tejto skutočnosti. Prenášame udalosti, ktoré sme označili (napríklad kliknutia na niektoré tlačidlá), ako aj adresy URL stránok, ktoré používateľ navštívil. V prípade Cartbee fungoval model „jedna akcia – jedna stránka“. Ale s VMmanagerom bola situácia úplne iná: na jednej stránke sa mohlo otvoriť niekoľko modálnych okien. V nich mohol užívateľ riešiť rôzne problémy. Napríklad URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
znamená, že na stránke „IP Addresses“ používateľ pridal IP adresu. A tu sú viditeľné dva problémy naraz:
- URL obsahuje nejaký druh parametra cesty – ID virtuálneho počítača. Treba to vylúčiť.
- Adresa URL obsahuje ID modálneho okna. Takéto adresy URL musíte nejako „rozbaliť“.
Ďalším problémom bolo, že práve tie udalosti, ktoré sme označili, mali parametre. Napríklad existovalo päť rôznych spôsobov, ako sa zo zoznamu dostať na stránku s informáciami o virtuálnom stroji. V súlade s tým bola odoslaná jedna udalosť, ale s parametrom, ktorý indikoval, akým spôsobom používateľ vykonal prechod. Takýchto udalostí bolo veľa a všetky parametre boli iné. A máme všetku logiku získavania údajov v dialekte SQL pre Clickhouse. Dopyty na 150-200 riadkov sa začali zdať akousi samozrejmosťou. Problémy nás obklopovali.
Inšpirácia #2
Jedného skorého rána mi Danil, smutne prechádzajúci žiadosťou druhú minútu, navrhol: „Napíšeme kanály na spracovanie údajov? Premýšľali sme o tom a rozhodli sme sa, že ak do toho ideme, bude to niečo ako ETL. Aby okamžite filtroval a stiahol potrebné údaje z iných zdrojov. Takto sa zrodila naša prvá analytická služba s plnohodnotným backendom. Implementuje päť hlavných fáz spracovania údajov:
- Uvoľnenie udalostí z úložiska nespracovaných údajov a ich príprava na spracovanie.
- Objasnenie je „rozbalenie“ práve tých identifikátorov modálnych okien, parametrov udalosti a ďalších podrobností, ktoré udalosť objasňujú.
- Obohatenie (od slova „zbohatnúť“) je pridanie udalostí údajmi zo zdrojov tretích strán. V tom čase to zahŕňalo iba náš fakturačný systém BILLmanager.
- Filtrovanie je proces odfiltrovania udalostí, ktoré skresľujú výsledky analýzy (udalosti z interných porastov, odľahlé hodnoty atď.).
- Nahrávanie prijatých udalostí do úložiska, ktoré sme nazvali čisté dáta.
Teraz bolo možné zachovať relevantnosť pridaním pravidiel pre spracovanie udalosti alebo dokonca skupín podobných udalostí. Odvtedy sme napríklad nikdy neaktualizovali rozbaľovanie adries URL. Počas tejto doby však bolo pridaných niekoľko nových variácií adries URL. Spĺňajú pravidlá už stanovené v službe a sú spracované správne.
Sklamanie #3
Keď sme začali analyzovať, uvedomili sme si, prečo je graf taký koherentný. Faktom je, že takmer každý N-gram obsahoval prechody, ktoré nebolo možné vykonať cez rozhranie.
Začalo sa malé vyšetrovanie. Bol som zmätený, že v rámci jednej entity neexistujú nemožné prechody. To znamená, že toto nie je chyba v systéme zberu udalostí alebo našej ETL služby. Mal pocit, že používateľ súčasne pracuje vo viacerých entitách bez toho, aby sa presúval z jedného do druhého. Ako to dosiahnuť? Používanie rôznych kariet v prehliadači.
Pri analýze Cartbee nás zachránila jeho špecifickosť. Aplikácia bola použitá z mobilných zariadení, kde je práca z niekoľkých kariet jednoducho nepohodlná. Tu máme pracovnú plochu a zatiaľ čo sa úloha vykonáva v jednej entite, je rozumné chcieť stráviť tento čas nastavením alebo monitorovaním stavu v inej. A aby ste nestratili pokrok, stačí otvoriť ďalšiu kartu.
Inšpirácia #3
Kolegovia z front-end developmentu naučili systém zberu udalostí rozlišovať medzi kartami. Analýza mohla začať. A začali sme. Ako sa očakávalo, CJM nezodpovedalo skutočným cestám: používatelia strávili veľa času na stránkach adresárov, opustených reláciách a kartách na najneočakávanejších miestach. Pomocou analýzy prechodov sa nám podarilo nájsť problémy v niektorých zostavách Mozilly. V nich kvôli implementačným funkciám zmizli navigačné prvky alebo sa zobrazovali poloprázdne stránky, ku ktorým by mal mať prístup len administrátor. Stránka sa otvorila, ale z backendu neprišiel žiadny obsah. Počítanie prechodov umožnilo vyhodnotiť, ktoré funkcie boli skutočne použité. Reťazce umožnili pochopiť, ako používateľ dostal túto alebo tú chybu. Údaje povolené na testovanie na základe správania používateľov. Malo to úspech, nápad nebol zbytočný.
Automatizácia analýzy
V jednej z ukážok výsledkov sme ukázali, ako sa Gephi používa na grafovú analýzu. V tomto nástroji môžu byť údaje o konverzii zobrazené v tabuľke. A vedúci oddelenia UX povedal jednu veľmi dôležitú myšlienku, ktorá ovplyvnila vývoj celého smeru analýzy správania v spoločnosti: „Urobme to isté, ale v Tableau a s filtrami – bude to pohodlnejšie.“
Potom som si pomyslel: prečo nie, Retentioneering ukladá všetky dáta do štruktúry pandas.DataFrame. A toto je celkovo stôl. Takto sa objavila ďalšia služba: Poskytovateľ údajov. Z grafu urobil nielen tabuľku, ale aj vypočítal, aká je stránka a s ňou spojená funkcionalita populárna, ako vplýva na udržanie používateľov, ako dlho na nej používatelia zostávajú a ktoré stránky používatelia najčastejšie opúšťajú. A použitie vizualizácie v Tableau znížilo náklady na štúdium grafu natoľko, že iteračný čas analýzy správania v produkte sa skrátil takmer na polovicu.
Danil bude hovoriť o tom, ako sa táto vizualizácia používa a aké závery umožňuje vyvodiť.
Viac stolov pre stolového boha!
V zjednodušenej forme bola úloha formulovaná nasledovne: zobraziť prechodový graf v Tableau, poskytnúť možnosť filtrovania a urobiť ho čo najprehľadnejším a najpohodlnejším.
Naozaj som nechcel kresliť orientovaný graf v Tableau. A aj keby bol úspešný, zisk v porovnaní s Gephim sa nezdal očividný. Potrebovali sme niečo oveľa jednoduchšie a dostupnejšie. Stôl! Koniec koncov, graf sa dá jednoducho znázorniť vo forme riadkov tabuľky, kde každý riadok je hranou typu „zdroj – cieľ“. Navyše sme takúto tabuľku už starostlivo pripravili pomocou nástrojov Retentioneering a Data Provider. Nezostávalo nič iné, len zobraziť tabuľku v Tableau a prehrabať sa v správe.
Keď už hovoríme o tom, ako všetci milujú stoly.
Tu však narážame na ďalší problém. Čo robiť so zdrojom údajov? Nebolo možné pripojiť pandas.DataFrame, Tableau takýto konektor nemá. Zvýšenie samostatnej základne pre uloženie grafu sa zdalo príliš radikálne riešenie s nejasnými vyhliadkami. A miestne možnosti vykládky neboli vhodné kvôli potrebe neustálych manuálnych operácií. Prezreli sme si zoznam dostupných konektorov a náš pohľad padol na položku , ktorý sa bezradne chúlil na samom dne.
Tableau má bohatý výber konektorov. Našli sme jeden, ktorý vyriešil náš problém
Aké zviera? Niekoľko nových otvorených kariet v prehliadači - a bolo jasné, že tento konektor vám umožňuje prijímať údaje pri prístupe k adrese URL. Samotný backend na výpočet dát bol takmer hotový, zostávalo ho len spriateliť s WDC. Denis niekoľko dní študoval dokumentáciu a bojoval s mechanizmami Tableau a potom mi poslal odkaz, ktorý som vložil do okna pripojenia.
Formulár pripojenia k nášmu WDC. Denis urobil predok a postaral sa o bezpečnosť
Po niekoľkých minútach čakania (údaje sa na požiadanie vypočítavajú dynamicky) sa objavila tabuľka:
Takto vyzerá pole nespracovaných údajov v rozhraní Tableau
Ako sme sľúbili, každý riadok takejto tabuľky predstavoval okraj grafu, teda riadený prechod používateľa. Obsahoval aj niekoľko ďalších charakteristík. Napríklad počet jedinečných používateľov, celkový počet prechodov a iné.
Bolo by možné zobraziť túto tabuľku v správe tak, ako je, veľkoryso posypať filtre a odoslať nástroj na plavbu. Znie to logicky. Čo môžete robiť so stolom? Ale toto nie je naša cesta, pretože nevyrábame len tabuľku, ale aj nástroj na analýzu a rozhodovanie o produktoch.
Pri analýze údajov chce človek zvyčajne získať odpovede na otázky. Skvelé. Začnime nimi.
- Aké sú najčastejšie prechody?
- Kam idú z konkrétnych stránok?
- Koľko času v priemere strávite na tejto stránke pred odchodom?
- Ako často robíte prechod z A do B?
- Na ktorých stránkach sa relácia končí?
Každá zo správ alebo ich kombinácia by mala používateľovi umožniť samostatne nájsť odpovede na tieto otázky. Kľúčovou stratégiou je poskytnúť vám nástroje, aby ste to urobili sami. Je to užitočné pre zníženie záťaže analytického oddelenia a pre skrátenie času na rozhodovanie – koniec koncov už nemusíte chodiť na Youtrack a vytvárať úlohu pre analytika, stačí si otvoriť prehľad.
čo sme dostali?
Kde sa ľudia najčastejšie odchyľujú od prístrojovej dosky?
Fragment našej správy. Po dashboarde každý prešiel buď na zoznam VM alebo na zoznam uzlov
Vezmime si všeobecnú tabuľku s prechodmi a filtrujeme podľa zdrojovej stránky. Najčastejšie prechádzajú z ovládacieho panela do zoznamu virtuálnych strojov. Okrem toho stĺpec Pravidelnosť naznačuje, že ide o opakujúcu sa akciu.
Odkiaľ pochádzajú do zoznamu klastrov?
Filtre v prehľadoch fungujú obojsmerne: môžete zistiť, kde ste odišli alebo kam ste išli
Z príkladov je zrejmé, že aj prítomnosť dvoch jednoduchých filtrov a radenia riadkov podľa hodnôt vám umožňuje rýchlo získať informácie.
Spýtajme sa niečo zložitejšie.
Kde používatelia najčastejšie opúšťajú svoju reláciu?
Používatelia VMmanager často pracujú na samostatných kartách
Na to potrebujeme prehľad, ktorého údaje sú agregované podľa zdrojov sprostredkovania. A takzvané body zlomu boli brané ako priradenia – udalosti, ktoré slúžili ako koniec reťazca prechodov.
Tu je dôležité poznamenať, že to môže byť koniec relácie alebo otvorenie novej karty. Príklad ukazuje, že reťazec najčastejšie končí pri tabuľke so zoznamom virtuálnych strojov. V tomto prípade je charakteristickým správaním prepnutie na inú kartu, ktorá je v súlade s očakávaným vzorom.
Užitočnosť týchto správ sme si najskôr vyskúšali na sebe, keď sme analýzu vykonávali podobným spôsobom , ďalší z našich produktov. S príchodom tabuliek a filtrov sa hypotézy testovali rýchlejšie a oči boli menej unavené.
Pri vývoji reportov sme nezabudli ani na vizuálny dizajn. Pri práci s tabuľkami tejto veľkosti je to dôležitý faktor. Napríklad sme použili pokojný rozsah farieb, ľahko vnímateľný pre čísla farebné zvýraznenie riadkov v súlade s číselnými hodnotami charakteristík. Takéto detaily zlepšujú používateľskú skúsenosť a zvyšujú pravdepodobnosť úspešného zavedenia nástroja v rámci spoločnosti.
Tabuľka sa ukázala byť dosť objemná, ale dúfame, že neprestala byť čitateľná
Samostatne stojí za zmienku o školení našich interných klientov: produktových špecialistov a UX dizajnérov. Špeciálne pre nich boli pripravené manuály s príkladmi rozborov a tipy na prácu s filtrami. Odkazy na manuály sme vložili priamo na stránky prehľadov.
Manuál sme vytvorili jednoducho ako prezentáciu v Google Docs. Nástroje Tableau vám umožňujú zobraziť webové stránky priamo v zošite zostavy.
Namiesto následného slova
Čo je na spodnom riadku? Pomerne rýchlo a lacno sa nám podarilo zohnať nástroj na každý deň. Áno, toto rozhodne nie je náhrada za samotný graf, tepelnú mapu klikov či webový prehliadač. Takéto správy však významne dopĺňajú uvedené nástroje a poskytujú podnety na zamyslenie a nové hypotézy o produktoch a rozhraniach.
Tento príbeh slúžil len ako začiatok vývoja analytiky v ISP systéme. Za posledných šesť mesiacov pribudlo ďalších sedem nových služieb vrátane digitálnych portrétov používateľa v produkte a služby na vytváranie databáz pre Look-alike cielenie, o ktorých si však povieme až v nasledujúcich epizódach.
Zdroj: hab.com