Az interneten több száz cikk található a vásárlói magatartás elemzésének előnyeiről. Leggyakrabban ez a kiskereskedelmi szektort érinti. Az élelmiszerkosár-elemzéstől az ABC- és XYZ-elemzéseken át a megtartási marketingig és a személyes ajánlatokig. Évtizedek óta alkalmaznak különféle technikákat, átgondolták az algoritmusokat, megírták a kódot és hibakeresést végeztek - vedd és használd. Esetünkben egy alapvető probléma merült fel: mi az ISPsystemnél szoftverfejlesztéssel foglalkozunk, nem kiskereskedelemmel.
A nevem Denis, és jelenleg az ISPsystem elemzőrendszereinek hátteréért vagyok felelős. Ez pedig annak a története, ahogy én és a kollégám — az adatvizualizációért felelősök — ennek a tudásnak a prizmáján keresztül próbálták szemlélni szoftvertermékeinket. Kezdjük szokás szerint a történelemmel.
Az elején volt egy szó, és ez volt: „Megpróbáljuk?”
Abban a pillanatban fejlesztőként dolgoztam a K+F részlegen. Az egész akkor kezdődött, amikor Danil itt olvasott a Habrén — eszköz az alkalmazások felhasználói átmeneteinek elemzésére. Kicsit szkeptikus voltam azzal kapcsolatban, hogy itt használom. Példaként a könyvtár fejlesztői olyan alkalmazások elemzését említették, ahol egyértelműen meghatározták a célműveletet – rendelés leadását vagy a tulajdonos cég fizetésének más változatát. Termékeinket a helyszínen szállítjuk. Vagyis a felhasználó először licencet vásárol, és csak ezután kezdi meg utazását az alkalmazásban. Igen, vannak demó verzióink. Ott kipróbálhatod a terméket, hogy ne legyen disznó a zsebedben.
De a legtöbb termékünk a hosting piacot célozza meg. Nagy ügyfelekről van szó, és az üzletfejlesztési részleg tanácsot ad nekik a termékképességekkel kapcsolatban. Ebből az is következik, hogy vásárlóink már vásárláskor tudják, milyen problémák megoldásában segít a szoftverünk. Az alkalmazásban lévő útvonalaknak egybe kell esnie a termékbe ágyazott CJM-mel, és az UX-megoldások segítenek a pályán maradásban. Spoiler: ez nem mindig történik meg. A könyvtár bemutatkozását elhalasztották... de nem sokáig.
Minden megváltozott a startup megjelenésével - — platformok online áruház létrehozására Instagram-fiókból. Ebben az alkalmazásban a felhasználó két hetes időszakot kapott az összes funkció ingyenes használatára. Ezután el kellett döntenie, hogy feliratkozik-e. És ez tökéletesen illeszkedik az „útvonal-cél akció” koncepcióba. Eldőlt: próbáljuk meg!
Az első eredmények, vagy honnan merítsen ötleteket
A fejlesztőcsapat és én szó szerint egy nap alatt összekapcsoltuk a terméket az eseménygyűjtő rendszerrel. Azonnal elmondom, hogy az ISPsystem saját rendszert használ az oldallátogatások eseményeinek gyűjtésére, de semmi sem akadályozza meg, hogy a Yandex.Metricát ugyanerre a célra használja, amely lehetővé teszi a nyers adatok ingyenes letöltését. Példákat tanulmányoztunk a könyvtár használatára, majd egy hét adatgyűjtés után átmeneti grafikont kaptunk.
Átmeneti grafikon. Alapvető funkciók, a többi átmenet eltávolítva az áttekinthetőség kedvéért
Pont olyan lett, mint a példában: sík, tiszta, szép. Ebből a grafikonból azonosítani tudtuk a leggyakrabban előforduló útvonalakat és kereszteződéseket, ahol az emberek a leghosszabb időt töltik. Ez lehetővé tette számunkra a következők megértését:
- A nagy CJM helyett, amely egy tucat entitást fed le, csak kettőt használnak aktívan. Szükséges továbbá, hogy a felhasználókat a szükséges helyekre irányítsuk UX-megoldások segítségével.
- Egyes oldalak, amelyeket az UX-tervezők úgy terveztek, hogy teljes körűek legyenek, végül az emberek indokolatlanul sok időt töltenek rajtuk. Ki kell találnia, hogy mik a stop elemek egy adott oldalon, és be kell állítani.
- 10 átállás után az emberek 20%-a kezdett elfáradni, és kilépett a munkamenetből az alkalmazásban. És ez figyelembe véve azt a tényt, hogy akár 5 bevezető oldalunk is volt az alkalmazásban! Meg kell határoznia azokat az oldalakat, ahol a felhasználók rendszeresen felhagynak a munkamenetekkel, és le kell rövidítenie a hozzájuk vezető utat. Még jobb: azonosítson minden szokásos útvonalat, és tegye lehetővé a gyors átmenetet a forrásoldalról a céloldalra. Valami közös az ABC elemzéssel és az elhagyott kosár elemzésével, nem gondolod?
És itt átgondoltuk a hozzáállásunkat ennek az eszköznek a helyszíni termékekre való alkalmazhatóságához. Egy aktívan értékesített és használt termék elemzése mellett döntöttek - . Sokkal összetettebb, nagyságrenddel több entitás van. Izgatottan vártuk, hogy mi lesz az átmeneti grafikon.
A csalódásokról és az ihletekről
Csalódás #1
Egyszerre volt a munkanap vége, a hónap vége és az év vége – december 27. Az adatok felhalmozódtak, a lekérdezések megtörténtek. Másodpercek voltak hátra minden feldolgozásig, és megnézhettük a munkánk eredményét, hogy megtudjuk, hol kezdődik a következő munkaév. A K+F részleg, termékmenedzser, UX tervezők, csapatvezető, fejlesztők összegyűltek a monitor előtt, hogy megnézzék, hogyan néznek ki a felhasználói útvonalak a termékükben, de... ezt láttuk:
A Retentioneering könyvtár által épített átmeneti gráf
Inspiráció #1
Erősen összefüggő, tucatnyi entitás, nem nyilvánvaló forgatókönyvek. Egyértelmű volt, hogy az új munkaév nem elemzéssel kezdődik, hanem azzal, hogy feltalálják a munkát egy ilyen grafikon segítségével. De nem tudtam megszabadulni attól az érzéstől, hogy minden sokkal egyszerűbb, mint amilyennek látszik. Tizenöt percnyi Retentioneering forráskód tanulmányozása után pedig exportálhattuk az összeállított grafikont pont formátumba. Ez lehetővé tette a grafikon feltöltését egy másik eszközre - a Gephi-re. És máris van lehetőség a grafikonok elemzésére: elrendezések, szűrők, statisztikák - csak a szükséges paramétereket kell beállítani a felületen. Ezzel a gondolattal indultunk el az újévi hétvégére.
Csalódás #2
Munkába való visszatérés után kiderült, hogy amíg mindenki pihent, ügyfeleink a terméket tanulmányozták. Igen, olyan keményen, hogy olyan események jelentek meg a tárolóban, amelyek korábban nem voltak. Ez azt jelentette, hogy a lekérdezéseket frissíteni kellett.
Egy kis háttér, hogy megértsük ennek a ténynek a szomorúságát. Mind az általunk megjelölt eseményeket (például egyes gombokra való kattintásokat), mind a felhasználó által felkeresett oldalak URL-címét továbbítjuk. A Cartbee esetében az „egy akció – egy oldal” modell működött. De a VMmanagerrel teljesen más volt a helyzet: egy oldalon több modális ablak is megnyílhatott. Ezekben a felhasználó különféle problémákat oldhatott meg. Például URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
azt jelenti, hogy az „IP-címek” oldalon a felhasználó hozzáadott egy IP-címet. És itt két probléma látható egyszerre:
- Az URL tartalmaz valamilyen elérési út paramétert - a virtuális gép azonosítóját. Ki kell zárni.
- Az URL tartalmazza a modális ablak azonosítóját. Az ilyen URL-eket valahogy „ki kell csomagolnia”.
A másik probléma az volt, hogy pont az általunk megjelölt eseményeknek voltak paraméterei. Például öt különböző módon lehet eljutni a listából egy virtuális gépre vonatkozó információkat tartalmazó oldalra. Ennek megfelelően egy eseményt elküldtek, de olyan paraméterrel, amely jelezte, hogy a felhasználó melyik módszerrel hajtott végre átállást. Sok ilyen esemény volt, és minden paraméter más volt. És az összes adatlekérési logikával rendelkezünk a Clickhouse SQL dialektusában. A 150-200 soros lekérdezések már kezdtek általánossá válni. Problémák vettek körül bennünket.
Inspiráció #2
Egy kora reggel Danil, a második percben szomorúan lapozva a kérést, azt javasolta nekem: „Írjunk adatfeldolgozási csővezetékeket?” Átgondoltuk, és úgy döntöttünk, hogy ha meg fogjuk csinálni, akkor valami olyan lesz, mint az ETL. Így azonnal szűr, és más forrásokból előhívja a szükséges adatokat. Így született meg első elemző szolgáltatásunk teljes értékű háttérrendszerrel. Az adatfeldolgozás öt fő szakaszát valósítja meg:
- Események kirakása a nyers adattárból és előkészítése feldolgozásra.
- A tisztázás a modális ablakok ugyanazon azonosítóinak, az eseményparamétereknek és egyéb részleteknek a „kicsomagolása”, amelyek tisztázzák az eseményt.
- A gazdagítás (a „gazdaggá válni”) az események harmadik féltől származó adatokkal való kiegészítése. Ekkor ez csak a BILLmanager számlázási rendszerünket foglalta magában.
- A szűrés olyan események kiszűrésének folyamata, amelyek torzítják az elemzés eredményeit (belső standokról származó események, kiugró értékek stb.).
- Beérkezett események feltöltése a tárhelyre, amit tiszta adatoknak neveztünk.
Mostantól meg lehetett őrizni a relevanciát egy esemény feldolgozására vonatkozó szabályok hozzáadásával, vagy akár hasonló események csoportjaival. Azóta például soha nem frissítettük az URL-kicsomagolást. Ez idő alatt azonban számos új URL-változatot adtunk hozzá. Megfelelnek a szolgáltatásban már lefektetett szabályoknak és helyesen dolgoznak fel.
Csalódás #3
Miután elkezdtük az elemzést, rájöttünk, miért olyan koherens a grafikon. A helyzet az, hogy szinte minden N-gram tartalmazott olyan átmeneteket, amelyeket nem lehetett végrehajtani az interfészen keresztül.
Kisebb nyomozás kezdődött. Zavart, hogy egyetlen entitáson belül nincsenek lehetetlen átmenetek. Ez azt jelenti, hogy ez nem az eseménygyűjtési rendszer vagy az ETL szolgáltatásunk hibája. Olyan érzés volt, hogy a felhasználó egyszerre több entitásban dolgozik, anélkül, hogy egyikről a másikra költözne. Hogyan lehet ezt elérni? Különböző lapok használata a böngészőben.
A Cartbee elemzésekor a sajátossága mentett meg bennünket. Az alkalmazást mobil eszközökről használták, ahol a több lapról történő munkavégzés egyszerűen kényelmetlen. Itt van egy asztalunk, és amíg egy feladatot az egyik entitásban hajtanak végre, ésszerű ezt az időt egy másik entitás beállításával vagy állapotának megfigyelésével tölteni. És annak érdekében, hogy ne veszítse el a fejlődést, csak nyisson meg egy másik lapot.
Inspiráció #3
A front-end fejlesztés munkatársai megtanították az eseménygyűjtő rendszert a lapok megkülönböztetésére. Kezdődhetett az elemzés. És elkezdtük. Ahogy az várható volt, a CJM nem egyezik a valódi útvonalakkal: a felhasználók sok időt töltöttek címtároldalakon, félbehagyott munkameneteken és lapokon a legváratlanabb helyeken. Az átmenetelemzés segítségével problémákat találtunk néhány Mozilla buildben. Ezekben a megvalósítási funkciók miatt eltűntek a navigációs elemek, vagy félig üres oldalak jelentek meg, amelyekhez csak az adminisztrátor férhet hozzá. Az oldal megnyílt, de nem érkezett tartalom a háttérből. Az átmenetek számlálása lehetővé tette annak értékelését, hogy mely funkciókat használták ténylegesen. A láncok lehetővé tették annak megértését, hogy a felhasználó hogyan kapta ezt vagy azt a hibát. A felhasználói viselkedés alapján tesztelhető adatok. Sikeres volt, az ötlet nem volt hiábavaló.
Analytics automatizálás
Az egyik eredménybemutatóban megmutattuk, hogyan használják a Gephi-t gráfelemzésre. Ebben az eszközben a konverziós adatok táblázatban jeleníthetők meg. Az UX osztály vezetője pedig egy nagyon fontos gondolatot mondott, amely a teljes viselkedéselemzési irányvonal fejlődését befolyásolta a vállalatnál: „Tegyük ugyanezt, de Tableauban és szűrőkkel – kényelmesebb lesz.”
Aztán arra gondoltam: miért ne, a Retentioneering minden adatot egy pandas.DataFrame struktúrában tárol. És ez nagyjából egy asztal. Így jelent meg egy másik szolgáltatás: az Adatszolgáltató. Nemcsak táblázatot készített a grafikonból, hanem azt is kiszámolta, hogy az oldal és a hozzá kapcsolódó funkcionalitás mennyire népszerű, hogyan befolyásolja a felhasználók megtartását, mennyi ideig maradnak rajta a felhasználók, és mely oldalakat hagyják el leggyakrabban a felhasználók. A Tableau-ban alkalmazott vizualizáció pedig annyira csökkentette a grafikon tanulmányozásának költségeit, hogy a termékben a viselkedéselemzés iterációs ideje csaknem felére csökkent.
Danil arról fog beszélni, hogyan használják ezt a vizualizációt, és milyen következtetések vonhatók le belőle.
Még több asztal az asztalistennek!
Leegyszerűsített formában a következőképpen fogalmaztuk meg a feladatot: jelenítsük meg az átmeneti grafikont Tableau-ban, biztosítsuk a szűrési lehetőséget, és a lehető legvilágosabbá és kényelmesebbé tegyük.
Nem igazán akartam irányított gráfot rajzolni Tableau-ban. És még ha sikerült is, a nyereség Gephihez képest nem tűnt nyilvánvalónak. Valami sokkal egyszerűbbre és elérhetőbbre volt szükségünk. Asztal! Hiszen a gráf könnyen ábrázolható táblázatsorok formájában, ahol minden sor a „forrás-cél” típusú éle. Sőt, már gondosan elkészítettünk egy ilyen táblázatot a Retentioneering és Data Provider eszközök segítségével. Nem volt más hátra, mint kitenni a táblázatot Tableau-ban, és a jelentésben turkálni.
Arról beszélve, hogy mindenki szereti az asztalokat.
Itt azonban egy másik problémával állunk szemben. Mi a teendő az adatforrással? A pandas.DataFrame csatlakoztatása lehetetlen volt, a Tableau-nak nincs ilyen csatlakozója. A grafikon tárolására külön bázis emelése túl radikális megoldásnak tűnt, homályos kilátásokkal. A helyi kirakodási lehetőségek pedig nem voltak megfelelőek az állandó kézi műveletek szükségessége miatt. Átnéztük az elérhető csatlakozók listáját, és tekintetünk a tételre esett , aki kétségbeesetten húzódott meg a legalján.
A Tableau csatlakozók gazdag választékával rendelkezik. Találtunk egyet, ami megoldotta a problémánkat
Milyen állat? Néhány új megnyitott lap a böngészőben – és világossá vált, hogy ez a csatlakozó lehetővé teszi az adatok fogadását az URL elérésekor. Maga az adatszámítási háttér már majdnem készen volt, már csak a WDC-vel való barátkozás maradt hátra. Denis néhány napig tanulmányozta a dokumentációt és harcolt a Tableau mechanizmusokkal, majd küldött egy linket, amit beillesztettem a kapcsolati ablakba.
Csatlakozási űrlap a WDC-hez. Denis felállt és vigyázott a biztonságra
Pár perc várakozás után (kérésre dinamikusan számítjuk ki az adatokat) megjelent a táblázat:
Így néz ki egy nyers adattömb a Tableau felületen
Ahogy ígértük, egy ilyen táblázat minden sora a gráf egy élét, vagyis a felhasználó irányított átmenetét jelentette. Számos további jellemzőt is tartalmazott. Például az egyedi felhasználók száma, az átmenetek teljes száma és egyebek.
Lehetséges lenne ezt a táblázatot úgy megjeleníteni a jelentésben, ahogy van, bőkezűen megszórni a szűrőket és elküldeni a szerszámot. Logikusan hangzik. Mit lehet csinálni az asztallal? De ez nem a mi utunk, mert nem csak egy táblázatot készítünk, hanem egy eszközt az elemzéshez és a termékdöntésekhez.
Jellemzően az adatok elemzésekor az ember választ szeretne kapni kérdésekre. Nagy. Kezdjük velük.
- Melyek a leggyakoribb átállások?
- Hová kerülnek konkrét oldalakról?
- Átlagosan mennyi időt tölt ezen az oldalon, mielőtt elhagyná?
- Milyen gyakran vált át A-ból B-be?
- Mely oldalakon ér véget a munkamenet?
Mindegyik jelentésnek vagy azok kombinációjának lehetővé kell tennie a felhasználó számára, hogy önállóan választ találjon ezekre a kérdésekre. A kulcsfontosságú stratégia itt az, hogy megadjuk az eszközöket, amelyekkel saját magad is meg tudod csinálni. Ez mind az analitikai részleg terhelésének csökkentése, mind a döntéshozatali idő csökkentése érdekében hasznos - elvégre nem kell többé a Youtrack-re mennie, és feladatot kell létrehoznia az elemző számára, csak meg kell nyitnia a jelentést.
Mit kaptunk?
Hol térnek el leggyakrabban az emberek az irányítópulttól?
Jelentésünk részlete. Az irányítópult után mindenki vagy a virtuális gépek listájára, vagy a csomópontok listájára ment
Vegyünk egy általános táblázatot az átmenetekkel, és szűrjünk forrásoldal szerint. Leggyakrabban az irányítópultról a virtuális gépek listájára lépnek. Ráadásul a Rendszeresség oszlop azt sugallja, hogy ez ismétlődő művelet.
Honnan származnak a klaszterek listájáról?
A jelentésekben lévő szűrők mindkét irányban működnek: megtudhatja, hogy merre indult, vagy hová ment
A példákból világos, hogy még két egyszerű szűrő és az értékek szerinti rangsorolási sorok jelenléte is lehetővé teszi az információk gyors megszerzését.
Kérdezzünk valami nehezebbet.
Hol hagyják fel leggyakrabban a felhasználók munkamenetüket?
A VMmanager felhasználók gyakran külön lapokon dolgoznak
Ehhez szükségünk van egy jelentésre, amelynek adatai a hivatkozási források szerint vannak összesítve. Az úgynevezett töréspontokat pedig megbízásnak vettük – olyan eseményeket, amelyek az átmenetek láncolatának végét jelentettek.
Itt fontos megjegyezni, hogy ez lehet a munkamenet vége vagy egy új lap megnyitása. A példa azt mutatja, hogy a lánc leggyakrabban egy virtuális gépek listáját tartalmazó táblánál végződik. Ebben az esetben a jellemző viselkedés egy másik lapra váltás, amely összhangban van a várt mintával.
E jelentések hasznosságát mindenekelőtt magunkon teszteltük, amikor hasonló módon végeztük az elemzést , egy másik termékünk. A táblázatok és szűrők megjelenésével gyorsabban tesztelték a hipotéziseket, és kevésbé fáradtak el a szemek.
A riportok elkészítésekor nem feledkeztünk meg a látványtervezésről sem. Amikor ilyen méretű asztalokkal dolgozik, ez fontos tényező. Például nyugodt, könnyen érzékelhető színválasztékot használtunk számoknál a vonalak színes kiemelése a jellemzők számértékeinek megfelelően. Az ilyen részletek javítják a felhasználói élményt, és növelik annak valószínűségét, hogy az eszköz sikeresen elindul a vállalaton belül.
A táblázat elég terjedelmesnek bizonyult, de reméljük, nem szűnt meg olvasni
Külön érdemes megemlíteni belső ügyfeleink, termékspecialisták és UX tervezők képzéséről. Kifejezetten ezekhez készültek az elemzési példákat és a szűrőkkel való munkavégzésre vonatkozó tippeket tartalmazó kézikönyvek. A kézikönyvekre mutató hivatkozásokat közvetlenül a jelentés oldalain helyeztük el.
A kézikönyvet egyszerűen prezentációként készítettük el a Google Dokumentumokban. A táblázatos eszközök lehetővé teszik a weboldalak közvetlen megjelenítését a jelentés munkafüzetében.
Helyett utószó
Mi van az alsó sorban? Viszonylag gyorsan és olcsón tudtunk minden napra szerszámot szerezni. Igen, ez biztosan nem helyettesíti magát a grafikont, a kattintások hőtérképét vagy a webnézegetőt. Az ilyen jelentések azonban jelentősen kiegészítik a felsorolt eszközöket, és elgondolkodtató, új termék- és interfész-hipotéziseket adnak.
Ez a történet csak a kezdetként szolgált az ISPsystem analitika fejlesztéséhez. Az elmúlt fél évben további hét új szolgáltatás jelent meg, köztük a felhasználó digitális portréi a termékben, valamint a Look-alike célzáshoz adatbázisokat készítő szolgáltatás, de ezekről a következő epizódokban lesz szó.
Forrás: will.com