Na internetu jsou stovky článků o výhodách analýzy chování zákazníků. Nejčastěji se to týká maloobchodního sektoru. Od analýzy potravinového koše, analýzy ABC a XYZ až po retenční marketing a osobní nabídky. Různé techniky byly používány po celá desetiletí, algoritmy byly promyšlené, kód byl napsán a odladěn – vezměte si to a použijte. V našem případě vyvstal jeden zásadní problém – v ISPsystem se zabýváme vývojem softwaru, nikoli retailem.
Jmenuji se Denis a v současné době jsem zodpovědný za backend analytických systémů ve společnosti ISPsystem. A toto je příběh o tom, jak jsme já a můj kolega — ti zodpovědní za vizualizaci dat — se pokusili podívat na naše softwarové produkty prizmatem těchto znalostí. Začněme jako obvykle historií.
Na začátku bylo slovo a to slovo bylo "Zkusíme to?"
V tu chvíli jsem pracoval jako vývojář v oddělení R&D. Všechno to začalo, když Danil četl tady na Habré — nástroj pro analýzu uživatelských přechodů v aplikacích. Byl jsem poněkud skeptický k myšlence použití zde. Jako příklady vývojáři knihoven uvedli analýzu aplikací, kde byla jasně definována cílová akce – zadání objednávky nebo nějakou jinou variantu, jak zaplatit vlastníkovi společnosti. Naše produkty jsou dodávány on-premise. To znamená, že uživatel si nejprve zakoupí licenci a teprve poté začne svou cestu v aplikaci. Ano, máme demo verze. Produkt si tam můžete vyzkoušet, abyste neměli prase v žitě.
Ale většina našich produktů je zaměřena na hostingový trh. Jedná se o velké klienty a oddělení rozvoje obchodu jim radí ohledně možností produktů. Z toho také vyplývá, že naši zákazníci již při nákupu vědí, jaké problémy jim náš software pomůže vyřešit. Jejich trasy v aplikaci se musí shodovat s CJM zabudovaným v produktu a UX řešení jim pomohou zůstat na správné cestě. Spoiler: To se nestává vždy. Úvod do knihovny byl odložen... ale ne na dlouho.
Vše se změnilo s vydáním našeho startupu - — platformy pro vytvoření internetového obchodu z účtu Instagram. V této aplikaci byl uživateli poskytnuta dvoutýdenní lhůta na bezplatné využívání všech funkcí. Pak jste se museli rozhodnout, zda se přihlásit k odběru. A to dokonale zapadá do konceptu akce „trasa-cíl“. Bylo rozhodnuto: zkusíme to!
První výsledky aneb odkud čerpat nápady
S vývojovým týmem jsme propojili produkt se systémem sběru událostí doslova za den. Hned řeknu, že ISPsystem používá svůj vlastní systém pro shromažďování událostí o návštěvách stránek, ale nic vám nebrání používat pro stejné účely Yandex.Metrica, která vám umožňuje stahovat nezpracovaná data zdarma. Byly studovány příklady použití knihovny a po týdnu sběru dat jsme obdrželi přechodový graf.
Přechodový graf. Základní funkčnost, ostatní přechody odstraněny pro přehlednost
Dopadlo to stejně jako v příkladu: rovinné, jasné, krásné. Z tohoto grafu se nám podařilo identifikovat nejčastější trasy a přechody, kde lidé tráví nejdelší dobu. To nám umožnilo pochopit následující:
- Místo velkého CJM, který zastřešuje tucet subjektů, jsou aktivně využívány pouze dva. Je potřeba dodatečně nasměrovat uživatele na místa, která potřebujeme pomocí UX řešení.
- Některé stránky, navržené designéry UX, aby byly úplné, skončí tak, že na nich lidé tráví nepřiměřeně mnoho času. Musíte zjistit, jaké prvky zarážky jsou na konkrétní stránce a upravit je.
- Po 10 přechodech začalo být 20 % lidí unavených a ukončili relaci v aplikaci. A to s přihlédnutím k faktu, že jsme v aplikaci měli hned 5 onboardingových stránek! Musíte identifikovat stránky, kde uživatelé pravidelně opouštějí relace, a zkrátit si k nim cestu. Ještě lepší: identifikujte všechny běžné trasy a umožněte rychlý přechod ze zdrojové stránky na cílovou stránku. Něco společného s analýzou ABC a analýzou opuštěného košíku, nemyslíte?
A zde jsme přehodnotili náš postoj k použitelnosti tohoto nástroje pro on-premise produkty. Bylo rozhodnuto analyzovat aktivně prodávaný a používaný produkt - . Je mnohem složitější, entit je řádově více. Natěšeně jsme čekali, jaký bude přechodový graf.
O zklamáních a inspiracích
Zklamání #1
Byl konec pracovního dne, konec měsíce i konec roku zároveň – 27. prosince. Data byla shromážděna, dotazy byly napsány. Než bylo vše zpracováno, zbývaly vteřiny a my se mohli podívat na výsledek naší práce, abychom zjistili, kde začne další pracovní rok. Oddělení výzkumu a vývoje, produktový manažer, UX designéři, vedoucí týmu, vývojáři se sešli před monitorem, aby viděli, jak vypadají uživatelské cesty v jejich produktu, ale... viděli jsme toto:
Přechodový graf vytvořený knihovnou Retentioneering
Inspirace #1
Silně propojené, desítky entit, nesrozumitelné scénáře. Bylo jen jasné, že nový pracovní rok nezačne rozborem, ale vymýšlením způsobu, jak si práci s takovým grafem zjednodušit. Ale nemohl jsem se zbavit pocitu, že všechno bylo mnohem jednodušší, než se zdálo. A po patnácti minutách studia zdrojového kódu Retentioneering jsme byli schopni exportovat vytvořený graf do formátu teček. To umožnilo nahrát graf do jiného nástroje – Gephi. A již existuje prostor pro analýzu grafů: rozložení, filtry, statistiky - vše, co musíte udělat, je nakonfigurovat potřebné parametry v rozhraní. S touto myšlenkou jsme odjeli na novoroční víkend.
Zklamání #2
Po návratu do práce se ukázalo, že zatímco všichni odpočívali, naši klienti produkt studovali. Ano, tak těžké, že se v úložišti objevily události, které dříve neexistovaly. To znamenalo, že bylo potřeba aktualizovat dotazy.
Trochu pozadí k pochopení smutku této skutečnosti. Přenášíme jak události, které jsme označili (například kliknutí na některá tlačítka), tak adresy URL stránek, které uživatel navštívil. V případě Cartbee fungoval model „jedna akce – jedna stránka“. Ale s VMmanagerem byla situace úplně jiná: na jedné stránce se mohlo otevřít několik modálních oken. V nich mohl uživatel řešit různé problémy. Například URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
znamená, že na stránce „IP Addresses“ uživatel přidal IP adresu. A zde jsou vidět dva problémy najednou:
- URL obsahuje nějaký druh parametru cesty – ID virtuálního počítače. Je potřeba to vyloučit.
- Adresa URL obsahuje ID modálního okna. Takové adresy URL musíte nějak „rozbalit“.
Dalším problémem bylo, že právě námi označené události měly parametry. Například existovalo pět různých způsobů, jak se ze seznamu dostat na stránku s informacemi o virtuálním počítači. V souladu s tím byla odeslána jedna událost, ale s parametrem, který indikoval, kterou metodou uživatel provedl přechod. Takových událostí bylo mnoho a všechny parametry byly jiné. A my máme veškerou logiku načítání dat v dialektu SQL pro Clickhouse. Dotazy na 150-200 řádků se začaly zdát poněkud běžné. Problémy nás obklopovaly.
Inspirace #2
Jednoho časného rána mi Danil smutně procházel žádost druhou minutu a navrhl mi: „Napíšeme kanály pro zpracování dat? Přemýšleli jsme o tom a rozhodli jsme se, že pokud do toho půjdeme, bude to něco jako ETL. Tak, aby okamžitě filtroval a stahoval potřebná data z jiných zdrojů. Tak se zrodila naše první analytická služba s plnohodnotným backendem. Implementuje pět hlavních fází zpracování dat:
- Vyjmutí událostí z úložiště nezpracovaných dat a jejich příprava ke zpracování.
- Objasnění je „rozbalení“ právě těch identifikátorů modálních oken, parametrů události a dalších podrobností, které událost objasňují.
- Obohacení (od slova „zbohatnout“) je přidání událostí o data ze zdrojů třetích stran. V té době to zahrnovalo pouze náš fakturační systém BILLmanager.
- Filtrování je proces odfiltrování událostí, které zkreslují výsledky analýzy (události z interních porostů, odlehlé hodnoty atd.).
- Nahrávání přijatých událostí do úložiště, kterému jsme říkali čistá data.
Nyní bylo možné zachovat relevanci přidáním pravidel pro zpracování události nebo dokonce skupiny podobných událostí. Od té doby jsme například nikdy neaktualizovali rozbalení URL. I když během této doby bylo přidáno několik nových variant URL. Odpovídají pravidlům již stanoveným ve službě a jsou zpracovány správně.
Zklamání #3
Jakmile jsme začali analyzovat, uvědomili jsme si, proč je graf tak koherentní. Faktem je, že téměř každý N-gram obsahoval přechody, které nebylo možné provést přes rozhraní.
Začalo malé vyšetřování. Byl jsem zmatený, že v rámci jedné entity nebyly žádné nemožné přechody. To znamená, že se nejedná o chybu v systému sběru událostí nebo naší ETL službě. Měl pocit, že uživatel současně pracuje v několika entitách, aniž by přecházel z jedné do druhé. Jak toho dosáhnout? Používání různých karet v prohlížeči.
Při analýze Cartbee nás zachránila jeho specifičnost. Aplikace byla použita z mobilních zařízení, kde je práce z několika karet jednoduše nepohodlná. Zde máme pracovní plochu a zatímco se úkol provádí v jedné entitě, je rozumné chtít tento čas strávit nastavováním nebo sledováním stavu v jiné. A abyste o postup nepřišli, stačí otevřít další kartu.
Inspirace #3
Kolegové z frontendového vývoje naučili systém sběru událostí rozlišovat mezi kartami. Analýza mohla začít. A začali jsme. Jak se očekávalo, CJM neodpovídalo skutečným cestám: uživatelé trávili spoustu času na stránkách adresářů, opouštěli relace a karty na nejneočekávanějších místech. Pomocí analýzy přechodů jsme byli schopni najít problémy v některých sestaveních Mozilly. V nich vlivem implementačních funkcí zmizely navigační prvky nebo se zobrazily poloprázdné stránky, které by měl mít přístup pouze administrátor. Stránka se otevřela, ale z backendu nepřišel žádný obsah. Počítání přechodů umožnilo vyhodnotit, které vlastnosti byly skutečně použity. Řetězce umožnily pochopit, jak uživatel přijal tuto nebo tu chybu. Data povolená k testování na základě chování uživatelů. Mělo to úspěch, nápad to nebyl marný.
Automatizace analýzy
V jedné z demonstrací výsledků jsme ukázali, jak se Gephi používá pro grafovou analýzu. V tomto nástroji lze údaje o konverzích zobrazit v tabulce. A vedoucí oddělení UX řekl jednu velmi důležitou myšlenku, která ovlivnila vývoj celého směru analytiky chování ve společnosti: „Udělejme totéž, ale v Tableau a s filtry – bude to pohodlnější.“
Pak jsem si řekl: proč ne, Retentioneering ukládá všechna data do struktury pandas.DataFrame. A tohle je celkově stůl. Tak se objevila další služba: Poskytovatel dat. Z grafu udělal nejen tabulku, ale také spočítal, jak oblíbená je stránka a funkce s ní spojené, jak ovlivňuje udržení uživatelů, jak dlouho na ní uživatelé zůstávají a které stránky uživatelé nejčastěji opouštějí. A použití vizualizace v Tableau snížilo náklady na studium grafu natolik, že doba iterace pro analýzu chování v produktu byla téměř poloviční.
Danil bude hovořit o tom, jak se tato vizualizace používá a jaké závěry umožňuje vyvodit.
Více stolů pro stolního boha!
Ve zjednodušené podobě byl úkol formulován následovně: zobrazit přechodový graf v Tableau, poskytnout možnost filtrování a učinit jej co nejpřehlednějším a nejpohodlnějším.
Opravdu jsem nechtěl kreslit orientovaný graf v Tableau. A i kdyby byl úspěšný, zisk ve srovnání s Gephim se nezdál zjevný. Potřebovali jsme něco mnohem jednoduššího a dostupnějšího. Stůl! Ostatně graf lze snadno znázornit ve formě řádků tabulky, kde každý řádek je hranou typu „zdroj-cíl“. Navíc jsme takovou tabulku již pečlivě připravili pomocí nástrojů Retentioneering a Data Provider. Nezbývalo než zobrazit tabulku v Tableau a prohrabat se ve zprávě.
Když už mluvíme o tom, jak všichni milují stoly.
Zde však narážíme na jiný problém. Co dělat se zdrojem dat? Nebylo možné připojit pandas.DataFrame, Tableau takový konektor nemá. Zvýšení samostatné základny pro uložení grafu se zdálo příliš radikální řešení s nejasnými vyhlídkami. A místní možnosti vykládky nebyly vhodné kvůli nutnosti neustálých ručních operací. Prohlédli jsme si seznam dostupných konektorů a náš pohled padl na položku , který se opuštěně choulil na samém dně.
Tableau má bohatý výběr konektorů. Našli jsme jeden, který vyřešil náš problém
Jaké zvíře? Několik nových otevřených karet v prohlížeči - a bylo jasné, že tento konektor umožňuje přijímat data při přístupu k URL. Samotný backend pro výpočet dat byl téměř hotový, zbývalo ho jen skamarádit s WDC. Denis několik dní studoval dokumentaci a bojoval s mechanismy Tableau a pak mi poslal odkaz, který jsem vložil do okna připojení.
Formulář pro připojení k našemu WDC. Denis se postavil před sebe a postaral se o bezpečnost
Po několika minutách čekání (údaje se na vyžádání dynamicky vypočítávají) se objevila tabulka:
Takto vypadá pole nezpracovaných dat v rozhraní Tableau
Jak bylo slíbeno, každý řádek takové tabulky představoval okraj grafu, tedy řízený přechod uživatele. Obsahoval také několik dalších vlastností. Například počet unikátních uživatelů, celkový počet přechodů a další.
Bylo by možné zobrazit tuto tabulku ve zprávě tak, jak je, velkoryse posypat filtry a odeslat nástroj na odplutí. Zní to logicky. Co můžete dělat se stolem? Ale toto není naše cesta, protože nevytváříme pouze tabulku, ale nástroj pro analýzu a rozhodování o produktu.
Při analýze dat chce člověk obvykle získat odpovědi na otázky. Skvělý. Začněme jimi.
- Jaké jsou nejčastější přechody?
- Kam jdou z konkrétních stránek?
- Jak dlouho průměrně strávíte na této stránce, než odejdete?
- Jak často provádíte přechod z A do B?
- Na jakých stránkách relace končí?
Každá ze sestav nebo jejich kombinace by měla uživateli umožnit samostatně najít odpovědi na tyto otázky. Klíčovou strategií je poskytnout vám nástroje, abyste to udělali sami. To je užitečné jak pro snížení zátěže analytického oddělení, tak pro zkrácení času na rozhodování – koneckonců už nemusíte chodit na Youtrack a vytvářet úkol pro analytika, stačí otevřít sestavu.
co jsme dostali?
Kde se lidé nejčastěji odchylují od palubní desky?
Fragment naší zprávy. Po řídicím panelu šli všichni buď na seznam virtuálních počítačů, nebo na seznam uzlů
Vezměme si obecnou tabulku s přechody a filtrujeme podle zdrojové stránky. Nejčastěji přecházejí z řídicího panelu na seznam virtuálních strojů. Navíc sloupec Pravidelnost naznačuje, že se jedná o opakující se akci.
Odkud pocházejí do seznamu klastrů?
Filtry v přehledech fungují oběma směry: můžete zjistit, kde jste odešli nebo kam jste šli
Z příkladů je zřejmé, že i přítomnost dvou jednoduchých filtrů a řazení řádků podle hodnot umožňuje rychle získat informace.
Zeptejme se na něco těžšího.
Kde uživatelé nejčastěji opouštějí svou relaci?
Uživatelé VMmanageru často pracují na samostatných kartách
K tomu potřebujeme přehled, jehož data jsou agregována podle zdrojů doporučení. A jako přiřazení se braly tzv. breakepointy – události, které sloužily jako konec řetězce přechodů.
Zde je důležité poznamenat, že to může být buď konec relace, nebo otevření nové karty. Příklad ukazuje, že řetězec nejčastěji končí u tabulky se seznamem virtuálních strojů. V tomto případě je charakteristické chování přepnutí na jinou kartu, která je v souladu s očekávaným vzorem.
Užitečnost těchto zpráv jsme si nejprve vyzkoušeli na sobě, když jsme provedli analýzu podobným způsobem , další z našich produktů. S příchodem tabulek a filtrů se hypotézy testovaly rychleji a oči byly méně unavené.
Při vývoji reportů jsme nezapomněli ani na vizuální design. Při práci s tabulkami této velikosti je to důležitý faktor. Použili jsme například klidnou škálu barev, snadno vnímatelnou u čísel barevné zvýraznění řádků v souladu s číselnými hodnotami charakteristik. Takové detaily zlepšují uživatelskou zkušenost a zvyšují pravděpodobnost úspěšného nasazení nástroje v rámci společnosti.
Tabulka se ukázala být poměrně objemná, ale doufáme, že nepřestala být čitelná
Samostatně stojí za zmínku o školení našich interních klientů: produktových specialistů a UX designérů. Speciálně pro ně byly připraveny manuály s příklady rozborů a tipy pro práci s filtry. Přímo do stránek sestav jsme vložili odkazy na manuály.
Manuál jsme vytvořili jednoduše jako prezentaci v Google Docs. Nástroje Tableau umožňují zobrazovat webové stránky přímo v sešitu sestavy.
Namísto následného slova
Co je ve výsledku? Poměrně rychle a levně se nám podařilo sehnat nástroj na každý den. Ano, rozhodně se nejedná o náhradu samotného grafu, tepelné mapy kliknutí nebo webového prohlížeče. Takové zprávy však významně doplňují uvedené nástroje a poskytují podněty k zamyšlení a hypotézám o nových produktech a rozhraních.
Tento příběh sloužil pouze jako začátek pro vývoj analytiky v ISP systému. Během uplynulého půl roku se objevilo dalších sedm nových služeb, včetně digitálních portrétů uživatele v produktu a služby pro vytváření databází pro Look-alike cílení, ale o těch si povíme až v následujících dílech.
Zdroj: www.habr.com