В інтернеті сотні статей про те, яку користь дає аналіз поведінки клієнтів. Найчастіше це стосується сфери рітейлу. Від аналізу продуктових кошиків, 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