У інтэрнэце сотні артыкулаў аб тым, якую карысць прыносіць аналіз паводзін кліентаў. Часцей за ўсё гэта датычыцца сферы рытэйла. Ад аналізу прадуктовых кошыкаў, ABC і XYZ аналізу да retention-маркетынгу і персанальных прапаноў. Розныя методыкі выкарыстоўваюцца ўжо дзесяцігоддзямі, алгарытмы прадуманы, код напісаны і адладжаны - бяры і выкарыстоўвай. У нашым выпадку ўзнікла адна фундаментальная праблема – мы ў ISPsystem займаемся распрацоўкай ПЗ, а не рытэйлам.
Мяне клічуць Дзяніс і на дадзены момант я адказваю за бэкенд аналітычных сістэм у ISPsystem. І гэта гісторыя пра тое, як мы з маім калегам - адказным за візуалізацыю дадзеных - паспрабавалі паглядзець на нашы праграмныя прадукты скрозь прызму гэтых ведаў. Пачнём, як звычайна, з гісторыі.
У пачатку было слова, і слова было "Паспрабуем?"
У той момант я працаваў распрацоўшчыкам у R&D аддзеле. Усё пачалося з таго, што тут, на Хабры, Даніл прачытаў - Інструмент для аналізу пераходаў карыстальнікаў у прыкладаннях. Ідэю яго прымянення ў нас я ўспрыняў некалькі скептычна. У якасці прыкладаў распрацоўшчыкі бібліятэкі прыводзілі аналіз прыкладанняў, дзе мэтавае дзеянне было дакладна вызначана - афармленне заказу або іншая варыяцыя таго, як заплаціць кампаніі-ўладальніку. У нас жа прадукты пастаўляюцца on-premise. Гэта значыць карыстач спачатку купляе ліцэнзію, і толькі пасля пачынае свой шлях у дадатку. Так, у нас ёсць дэма-версіі. У іх можна апрабаваць прадукт, каб не браць ката ў мяшку.
Але большасць нашых прадуктаў арыентавана на рынак хостынгу. Гэта буйныя кліенты, і аб магчымасцях прадукта іх кансультуе аддзел бізнес-дэвелапераў. З гэтага ж вынікае, што на момант пакупкі нашы кліенты ўжо ведаюць у вырашэнні якіх задач ім дапаможа наша ПЗ. Іх маршруты ў дадатку павінны супадаць з закладзеным у прадукт CJM, а UX-рашэнні дапамогуць з іх не збівацца. Спойлер: так адбываецца не заўсёды. Знаёмства з бібліятэкай было адкладзена… але ненадоўга.
Усё змянілася з рэлізам нашага стартапа - платформы для стварэння інтэрнэт-крамы з акаўнта ў Instagram. У гэтым дадатку карыстачу даваўся двухтыднёвы перыяд на бясплатнае выкарыстанне ўсёй функцыянальнасці. Пасля трэба было прыняць рашэнне, ці афармляць падпіску. І гэта як нельга добра клалася ў канцэпцыю "маршрут-мэтавае дзеянне". Было вырашана: спрабуем!
Першыя вынікі ці адкуль браць ідэі
Мы з камандай распрацоўкі літаральна за дзень падключылі прадукт да сістэмы збору падзей. Скажу адразу, што ў ISPsystem выкарыстоўваецца свая сістэма збору падзей аб наведванні старонак, аднак нішто не мяшае ўжываць для тых жа мэт Яндекс.Метрику, якая дазваляе бясплатна выгружаць волкія дадзеныя. Былі вывучаны прыклады выкарыстання бібліятэкі, і праз тыдзень збору даных мы атрымалі граф пераходаў.
Граф пераходаў. Асноўная функцыянальнасць, астатнія пераходы прыбраныя для навочнасці
Выйшла прама як у прыкладзе: планарна, зразумела, прыгожа. З гэтага графа мы змаглі выявіць самыя частыя маршруты і пераходы, на якіх людзі затрымліваюцца даўжэй за ўсё. Гэта дазволіла нам зразумець наступнае:
- Замест буйнога CJM, які ахоплівае з дзясятак сутнасцяў, актыўна выкарыстоўваюцца ўсяго дзве. Неабходна дадаткова накіроўваць карыстальнікаў у патрэбныя нам месцы пры дапамозе UX-рашэнняў.
- На некаторых старонках, задуманых UX-праекціроўшчыкамі як скразныя, людзі праводзяць неапраўдана шмат часу. Неабходна высвятляць, што з'яўляецца стоп-элементамі на канкрэтнай старонцы і карэктаваць гэта.
- Пасля 10 пераходаў 20% людзей пачыналі стамляцца і кідаць сесію ў дадатку. І гэта з улікам таго, што ў нас у дадатку было цэлых 5 старонак онбордынгу! Трэба выяўляць старонкі, на якіх карыстачы рэгулярна кідаюць сесіі, і скарачаць шлях да іх. Яшчэ лепш: выяўляць любыя рэгулярныя маршруты і дазваляць здзяйсняць хуткі пераход са старонкі-крыніцы ў старонку-прызначэнне. Нешта агульнае з ABC-аналізам і аналізам кінутых кошыкаў, не знаходзіце?
І тут мы перагледзелі сваё стаўленне да дастасавальнасці гэтай прылады для on-premise прадуктаў. Было вырашана прааналізаваць прадукт, які актыўна прадаецца і выкарыстоўваецца. . Ён значна складаней, сутнасцяў на парадак больш. Мы з хваляваннем чакалі, якім жа акажацца граф пераходаў.
Аб расчараваннях і натхненнях
Расчараванне #1
Гэта быў канец працоўнага дня, канец месяца і канец года адначасова - 27 снежня. Дадзеныя былі назапашаны, запыты напісаны. Заставаліся секунды да таго, як усё апрацуецца, і мы зможам зірнуць на вынік сваёй працы, каб даведацца, з чаго пачнецца наступны працоўны год. R&D аддзел, продакт-мэнэджар, UX-дызайнеры, тымлід, распрацоўшчыкі сабраліся перад маніторам, каб убачыць як выглядаюць шляхі карыстальнікаў у іх прадукце, але… мы ўбачылі гэта:
Граф пераходаў, пабудаваны бібліятэкай Retentioneering
Натхненне #1
Моцна-сувязны, дзясяткі сутнасцяў, невідавочныя сцэнары. Зразумела было толькі тое, што новы працоўны год пачнецца не з аналізу, а з вынаходкі спосабу спрасціць працу з такім графам. Але мяне не пакідала пачуццё, што ўсё нашмат прасцей, чым здаецца. І пасля пятнаццаці хвілін вывучэння зыходнікаў Retentioneering удалося экспартаваць пабудаваны граф у фармат dot. Гэта дазволіла выгрузіць граф у іншую прыладу — Gephi. А ўжо там разлог для аналізу графаў: кладкі, фільтры, статыстыкі - толькі і рабі, што наладжвай у інтэрфейсе патрэбныя параметры. З гэтай думкай мы пайшлі на навагоднія выходныя.
Расчараванне #2
Пасля выхаду на працу аказалася, што пакуль усе адпачывалі, нашы кліенты вывучалі прадукт. Ды так старанна, што ў сховішчы з'явіліся падзеі, якіх раней не было. Гэта азначала тое, што трэба актуалізаваць запыты.
Трохі перадгісторыі для ўсведамлення ўсёй сумнасці гэтага факта. У нас перадаюцца як размечаныя намі падзеі (напрыклад, націскі на некаторыя кнопкі), так і URL старонак, якія наведваў карыстач. У выпадку з Cartbee працавала мадэль адно дзеянне адна старонка . Але з VMmanager сітуацыя была ўжо зусім іншы: на адной старонцы маглі адкрывацца некалькі мадальных вокнаў. У іх карыстач мог вырашаць розныя задачы. Напрыклад, URL:
/host/item/24/ip(modal:modal/host/item/ip/create)
значыць, што на старонцы «IP-адрасы» карыстач дадаваў IP-адрас. І тут бачныя адразу дзве праблемы:
- У URL ёсць нейкі path parameter - ID віртуальнай машыны. Трэба яго выключаць.
- У URL ёсць ідэнтыфікатар мадальнага акна. Трэба неяк "распакоўваць" такія URL.
Іншая праблема заключалася ў тым, што ў тых самых размечаных намі падзеях былі параметры. Напрыклад, патрапіць на старонку з інфармацыяй аб віртуальнай машыне са спісу можна было пяццю рознымі спосабамі. Адпаведна, падзея адпраўлялася адно, але з параметрам, якія паказваў, якім са спосабаў карыстач ажыццявіў пераход. Такіх падзей было мноства, і ўсе параметры розныя. А ў нас уся логіка вымання дадзеных на дыялекце SQL для Clickhouse. Запыты на 150-200 радкоў пачыналі здавацца нечым звыклым. Праблемы атачалі нас.
Натхненне #2
Адной раніцай Даніл, сумна скролячы запыт другую хвіліну, прапанаваў мне: «А давай пайплайны апрацоўкі дадзеных напішам?» Мы падумалі і вырашылі, што раз ужо рабіць, то нешта накшталт ETL. Каб і фільтравала адразу, і з іншых крыніц патрэбныя дадзеныя падцягвала. Так нарадзіўся наш першы аналітычны сэрвіс з паўнавартасным бэкэндам. Ён рэалізуе пяць асноўных стадый апрацоўкі даных:
- Выгрузка падзей са сховішча "волкіх" дадзеных і падрыхтоўка іх да апрацоўкі.
- Удакладненне - "распакоўка" тых самых ідэнтыфікатараў мадальных вокнаў, параметраў падзей і іншых удакладняючых падзея дэталяў.
- Абагачэнне (ад слова "стаць багатым") - дадатак падзей дадзенымі з іншых крыніц. На той момант сюды ўваходзіла толькі наша білінгавая сістэма BILLmanager.
- Фільтраванне - працэс адсявання падзей, якія скажаюць вынікі аналізу (падзеі з унутраных стэндаў, выкіды і г.д.).
- Выгрузка атрыманых падзей у сховішча, якое мы назвалі чыстымі дадзенымі.
Цяпер падтрымліваць актуальнасць можна было дадаючы правілы апрацоўкі падзеі ці нават групы падобных падзей. Напрыклад, з таго моманту мы ні разу не актуалізавалі распакаванне URL. Хаця, за гэты час дадалося некалькі новых варыяцый URL. Яны адпавядаюць ужо закладзеным у сэрвіс правілам і карэктна апрацоўваюцца.
Расчараванне #3
Як толькі мы прыступілі да аналізу, мы ўсвядомілі, чаму граф быў настолькі сувязным. Справа ў тым, што практычна кожная N-грама ўтрымоўвала ў сабе пераходы, якія немагчыма ажыццявіць праз інтэрфейс.
Пачалося невялікае расследаванне. Мяне бянтэжыла, што не было няздзейсных пераходаў у рамках адной сутнасці. Значыць, гэта не баг сістэмы збору падзей ці нашага ETL-сэрвісу. Складалася адчуванне, што карыстач адначасова працуе ў некалькіх сутнасцях, не пераходзячы з адной у іншую. Як такога дабіцца? Выкарыстоўваючы розныя ўкладкі ў браўзэры.
Пры аналізе Cartbee нас выратавала яго спецыфіка. Прыкладанне выкарыстоўвалі з мабільных прылад, дзе працаваць з некалькіх укладак папросту няёмка. Тутака ж - дэсктоп і, пакуль выконваецца задача ў адной сутнасці, слушна жадаецца заняць гэты час наладамі або маніторынгам стану ў іншы. А каб не губляць прагрэс, проста адчыняеш яшчэ адну ўкладку.
Натхненне #3
Калегі з фронтед-распрацоўкі навучылі сістэму збору падзей адрозніваць укладкі. Можна было пачынаць аналіз. І мы прыступілі. Як і чакалася, CJM не супадалі з рэальнымі шляхамі: карыстачы праводзілі шмат часу на старонках-каталогах, кідалі сесіі і ўкладкі ў самых нечаканых месцах. Пры дапамозе аналізу пераходаў мы змаглі знайсці праблемы ў некаторых білдах Mozilla. У іх, з-за асаблівасцяў рэалізацыі, знікалі элементы навігацыі або адлюстроўваліся напаўпустыя старонкі, якія павінны быць даступныя толькі адміністратару. Старонка адчынялася, але кантэнт з бэкенда не прыходзіў. Падлік пераходаў дазваляў ацаніць, якія фічы рэальна выкарыстоўваюцца. Ланцужкі давалі магчымасць зразумець, як карыстач атрымаў тую ці іншую памылку. Дадзеныя дазвалялі праводзіць тэсціраванне на аснове паводзін карыстальнікаў. Гэта быў поспех, задума была не марнай.
Аўтаматызацыя аналітыкі
На адной з дэманстрацый вынікаў мы паказвалі, як прымяняецца Gephi для аналізу графаў. У гэтай прыладзе дадзеныя аб пераходах можна вывесці ў табліцу. І кіраўнік аддзела UX сказаў адну вельмі важную думку, якая паўплывала на развіццё ўсяго кірунку аналітыкі паводзін у кампаніі: "А давайце зробім гэтак жа, але ў Tableau і з фільтрамі – так будзе зручней".
Тады я падумаў: а чаму б і не, Retentioneering захоўвае ўсе дадзеныя ў pandas.DataFrame структуры. А гэта ўжо, па вялікім рахунку, табліца. Так з'явіўся яшчэ адзін сервіс: Data Provider. Ён не толькі рабіў з графа табліцу, але і разлічваў, наколькі старонка і прывязаная да яе функцыянальнасць карыстаюцца папулярнасцю, як уплывае на ўтрыманне карыстачоў, наколькі карыстачы затрымоўваюцца на ёй, з якіх старонак часцей за ўсё сыходзяць карыстачы. А выкарыстанне візуалізацыі ў Tableau настолькі скараціла выдаткі на вывучэнне графа, што час ітэрацыі аналізу паводзін у прадукце скарацілася практычна ўдвая.
Пра тое, як дадзеная візуалізацыя прымяняецца і якія высновы дазваляе зрабіць раскажа Даніл.
Больш табліц богу табліц!
У спрошчаным выглядзе задача была сфармулявана так: адлюстраваць граф пераходаў у Tableau, забяспечыць магчымасць фільтрацыі, зрабіць максімальна зразумелым і зручным.
Маляваць арыентаваны граф у Tableau не вельмі хацелася. Ды і ў выпадку поспеху выйгрыш, у параўнанні з Gephi, уяўляўся невідавочным. Трэба было нешта значна прасцей і даступней. Табліца! Бо граф лёгка ўявіць у выглядзе радкоў табліцы, дзе кожны радок - рабро выгляду «крыніца-прызначэнне». Больш за тое, такая табліца ў нас ужо была клапатліва падрыхтавана сродкамі Retentioneering і Data Provider. Справа заставалася за малым: вывесці табліцу ў Tableau і памацаць справаздачу.
Дарэчы аб тым, як усе любяць табліцы
Аднак тут мы сутыкнуліся яшчэ з адной праблемай. Што рабіць з крыніцай дадзеных? Падлучыць pandas.DataFrame было нельга, такога канектара ў Tableau няма. Паднімаць асобную базу для захоўвання графа здавалася занадта радыкальным рашэннем з імглістымі даляглядамі. А варыянты лакальных выгрузак не падыходзілі з-за неабходнасці пастаянных ручных аперацый. Мы пагарталі спіс даступных канектараў, і погляд упаў на пункт , Які сіратліва туліўся ў самым нізе.
У Tableau багаты выбар канектараў. Знайшлі і той, які рашыў нашу задачу
Што за звер? Некалькі новых адкрытых укладак у браўзэры - і стала зразумела, што гэты канектар дазваляе атрымліваць дадзеныя пры звароце па URL. Backend для разліку саміх дадзеных ужо быў амаль готаў, заставалася пасябраваць яго з WDC. Некалькі дзён Дзяніс вывучаў дакументацыю і ваяваў з механізмамі Tableau, а затым скінуў мне спасылку, якую я ўставіў у акно падключэння.
Форма падключэння да нашага WDC. Дзяніс зрабіў свой фронт і паклапаціўся аб бяспецы
Праз пару хвілін чакання (дадзеныя разлічваюцца дынамічна пры запыце) з'явілася табліца:
Так выглядае волкі масіў дадзеных у інтэрфейсе Tableau
Як і было абяцана, кожны радок такой табліцы ўяўляў сабой рабро графа, гэта значыць накіраваны пераход карыстальніка. Таксама яна змяшчала некалькі дадатковых характарыстык. Напрыклад, колькасць унікальных карыстачоў, агульная колькасць пераходаў і іншыя.
Можна было б вывесці гэтую табліцу ў справаздачу як ёсць, шчодра пасыпаць фільтраў і адправіць прыладу ў плаванне. Гучыць лагічна. Што можна зрабіць з табліцай? Але гэта не наш шлях, бо мы робім не проста табліцу, а інструмент для аналізу і прыняцці прадуктовых рашэнняў.
Як правіла, пры аналізе дадзеных чалавек жадае атрымаць адказы на пытанні. Выдатна. З іх і пачнем.
- Якія пераходы самыя частыя?
- Куды адыходзяць з канкрэтных старонак?
- Колькі ў сярэднім праводзяць на гэтай старонцы да таго, як адышлі?
- Як часта робяць пераход з A у B?
- А на якіх старонках заканчваецца сэсія?
Кожная са справаздач або іх камбінацыя павінны дазваляць карыстачу самастойна знаходзіць адказы на гэтыя пытанні. Ключавая стратэгія тут - даць інструмент для самастойнай працы. Гэта карысна як для памяншэння нагрузкі на аддзел аналітыкі, так і для памяншэння часу на прыняцце рашэння - бо больш не трэба ісці ў Youtrack і заводзіць задачу аналітыку, дастаткова проста адкрыць справаздачу.
Што ж у нас атрымалася?
Куды часцей за ўсё разыходзяцца з дашборда?
Фрагмент нашай справаздачы. Пасля дашборда ўсё сыходзілі альбо на спіс ВМ альбо на спіс нод
Возьмем агульную табліцу з пераходамі і адфільтруем па старонцы крыніцы. Часцей за ўсё з дашборда ідуць на спіс віртуальных машын. Прычым, калонка Regularity падказвае, што гэта дзеянне, якое паўтараецца.
Адкуль прыходзяць у спіс кластараў?
Фільтры ў справаздачах працуюць у абодва бакі: можна пазнаць адкуль сышлі, а можна куды ішлі
З прыкладаў відаць, што нават наяўнасць двух простых фільтраў і ранжыраванне радкоў па значэннях дазваляюць хутка атрымліваць інфармацыю.
Спытаемся сёе-тое больш складана.
Адкуль карыстачы часцей за ўсё кідаюць сесію?
Карыстальнікі VMmanager часта працуюць у асобных укладках
Для гэтага нам патрэбная справаздача, дадзеныя якой агрэгаваныя па крыніцах пераходаў. А ў якасці прызначэнняў былі ўзятыя так званыя breakepoints - падзеі, якія паслужылі канцом ланцужкі пераходаў.
Тут важна заўважыць, што гэта можа быць як канец сесіі, так і адкрыццё новай укладкі. З прыкладу бачна, што ланцужок часцей за ўсё заканчваецца на табліцы са спісам віртуальных машын. Пры гэтым характэрныя паводзіны - гэта пераход у іншую ўкладку, што ўзгадняецца з чаканым патэрнам.
Карысць гэтых справаздач мы перш за ўсё праверылі на сабе, калі падобным чынам праводзілі аналіз. , яшчэ аднаго нашага прадукта. Са з'яўленнем табліц і фільтраў гіпотэзы правяраліся хутчэй, а вочы стамляліся менш.
Пры распрацоўцы справаздач мы не забыліся і пра візуальнае афармленне. Пры рабоце з табліцамі такога аб'ёму гэта немалаважны фактар. Напрыклад, выкарыстоўвалі спакойную гаму кветак, лёгкі для ўспрымання. для лічбаў, каляровае падсвятленне радкоў у адпаведнасці з лікавымі значэннямі характарыстык. Такія дэталі паляпшаюць карыстацкі досвед і павялічваюць верагоднасць паспяховага ўзлёту прылады ўсярэдзіне кампаній.
Табліца атрымалася даволі аб'ёмнай, але як мы спадзяемся, не перастала быць чытэльнай
Асобна варта сказаць пра навучанне нашых унутраных кліентаў: прадуктолагаў і UX-праекціроўшчыкаў. Для іх спецыяльна былі падрыхтаваны мануалы з прыкладамі аналізу і падказкамі пры рабоце з фільтрамі. Спасылкі на мануалы мы ўставілі проста ў старонкі справаздач.
Мануал мы зрабілі проста ў выглядзе прэзентацыі ў Google Docs. Сродкі Tableau дазваляюць адлюстроўваць вэб-старонкі прама ўсярэдзіне кніг са справаздачамі.
замест пасляслоўя
Што ў сухой рэштцы? Мы адносна хутка і танна змаглі атрымаць інструмент на кожны дзень. Так, вызначана гэта не замена самога графа, цеплавой карты клікаў ці вэб-візара. Але такія справаздачы істотна дапаўняюць пералічаныя прылады, даюць ежу для разважанняў і новых прадуктовых і інтэрфейсных гіпотэз.
Гэтая гісторыя паслужыла толькі пачаткам для развіцця аналітыкі ў ISPsystem. За паўгода з'явілася яшчэ сем новых сэрвісаў, у тым ліку лічбавыя партрэты карыстальніка ў прадукце і сэрвіс для фарміравання баз для Look-alike таргетынгу, але пра іх у наступных эпізодах.
Крыніца: habr.com