Процес побудови аналітики та data-driven-підхід як рушій продуктового мислення

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Я — Аня Ткаченко, Software Engineer і Data Analyst в Edtech-компанії Mate academy, основним продуктом якої є LMS-платформа. Оскільки наш бізнес операційно складний, ми багато часу присвячуємо аналізу, що у нас працює і як. Розробники та інші спеціалісти створюють аналітику на всі рішення, які імплементують.

Вже довгий час ми використовуємо Amplitude, маємо організований data warehouse (DWH), в який синхронізуємо дані по маркетингу і продуктові показники. За останній рік потреба в аналітиці зростала і ми перейшли до використання Looker, що став наступною ітерацією в аналізі перформансу бізнес-процесів.

Свого часу наш CEO Роман Апостол вже писав статтю, де детально описав, якою є наша інженерна культура, згадуючи роль аналітики в ній. Я ж спробую продовжити цю думку, детально занурюючись, яким є наш процес та етапи побудови аналітики на сьогодні та як це допомагає вирішувати бізнес-задачі. Також проведу кілька паралелей, як data-driven-підхід нашої інженерної культури впливає на розвиток продуктового мислення команди.

Цей блог буде цікавий тим, хто починає впроваджувати аналітику даних у компанії або вже має систему моніторингу процесів. Вона також стане у пригоді тим, хто хоче дізнатися про процес створення графіків та як аналітика даних впливає на розвиток продуктових навичок у розробників.

Для чого потрібна аналітика та до чого тут продуктове мислення

Важливо розуміти, як конкретні дії на щось впливають, і аналіз даних це показує. Бізнес розуміє, куди рухається компанія. Інженери бачать, як їхні рішення впливають на рух компанії у відповідному напрямку.

Це допомагає керівникам реагувати на критичні ситуації в момент їхнього настання, а розробникам відчувати більшу залученість в бізнес-процеси та підвищену зацікавленість в роботі.

Крім цього, сам досвід побудови аналітики допомагає розробникам розвивати продуктове мислення і вчитись системно підходити до розв’язання поставлених задач. Адже на рівні написання коду розробники вже замислюються над тим, наскільки стабільним є поточне рішення і як це можна буде проаналізувати на основі даних. Також аналітика дозволяє знаходити процеси, які можна покращувати, і розуміти, чи твій код працює добре.

У нашому випадку, це напряму корелюється з цінностями, які ми декларуємо в команді. Зокрема, завдяки роботі з даними мейтівці визначають для себе, як діяти в інтересах компанії, бути амбіційними, мати та проявляти абсолютну відповідальність за прийняті рішення.

З чого починати роботу з даними

Перед тим, як перейти безпосередньо до процесу побудови графіків, необхідно визначитись з єдиним місцем для збору даних та інструментом для візуалізації. Більшість сервісів мають вбудовані функції для побудови аналітики. CRM-системи дають можливість будувати аналіз активностей та взаємодії з користувачами для сейлз-відділу, або відділу координаторів.

Системи для опрацювання дзвінків (телефонії) надають можливість аналізувати ефективність роботи сейлз-відділу. Amplitude — потужний сервіс для аналізу івентів, які відповідають за взаємодію користувача з платформою. ClickUp дозволяє будувати графіки для відображення активності роботи команд та опрацювання задач.

На певному етапі виникає потреба аналізу даних, які генеруються в різних системах. Наприклад, перегляд кількості дзвінків в телефонії в порівнянні до кількості створених заявок на платформі.

На початку побудови аналітики, важливо приділити час для вибору місця збереження ваших даних. Одного місця, яке буде відповідати за сховище. В нашому випадку це Amazon Redshift DWH.

Єдине місце збору даних дозволяє інтегрувати його з єдиною платформою для побудови аналітики (в нашому випадку це Looker). Відтак всі працівники мають змогу дивитись на графіки в одному місці та аналізувати процеси, які можуть бути налаштовані в різних системах.

Процес побудови графіку

Задача побудови дашборду і надання можливості аналізувати процес в нашому випадку зазвичай включає наступні процеси:

• пошук та визначення метрик процесу та вимог до них;
• інтеграція системи генерування даних;
• опис даних і моделі для побудови відображення;
• створення дашборду з візуалізацією основних метрик;
• налаштування моніторингу на перевірку якості даних;
• налаштування системи сповіщень та розсилок.

Першим ми побудували в Looker Executive-дашборд. Він містить ключові метрики, які мають бути on-track кожного дня і відображає основні показники, які відповідають за поточний стан процесів в компанії.

Для побудови такого дашборду необхідно:

• отримати контекст від C-level-менеджерів про ключові показники, які вони вважають найбільш критичними для аналізу;
• зрозуміти, на основі яких даних ми це можемо візуалізувати;
• проаналізувати системи, які генерують потрібні дані;
• обрати відображення, яке дозволяє відразу орієнтуватися, на якому етапі ми зараз.

Наступні дашборди ми почали будувати структуровано ‘зверху — вниз’, за принципом піраміди Мінто. На найвищому рівні — ключова метрика процесу. Наступні рівні включають метрики, які можуть на цей процес впливати. Наприклад, на Executive дашборді ми відображаємо кількість студентів на певних статусах і зміну цієї метрики в динаміці. Далі будуємо дашборд, який показує рух студентів в більш деталізованому вигляді:

• наскільки швидко студенти переходять з одного статусу в інший;
• як швидко відбувається перевірка завдань студентів та надання відповіді в чатах;
• метрики активності студентів на етапі працевлаштування.

За допомогою такої структури в нас є можливість перейти в більш детальний аналіз того, як проходить навчання та впроваджувати зміни при виявленні процесів, які можна оптимізувати.

Крім того, завдяки наявності метрик, що відображають роботу процесу, інженери відчувають себе більш залученими. Наприклад, інтеграція нового провайдера може бути просто задачею з написання коду. Але якщо показати графік, що відображає кількість проведених оплат через нового провайдера та частку доходу, яка через нього проходить, то стає зрозуміло, наскільки важливим є запроваджене рішення і як воно вплинуло на бізнес.

Пошук та визначення метрик процесу та вимог до них

Для аналізу процесу потрібно визначити метрики, на основі яких можна аналізувати основні показники. Кожен процес буде мати свій визначений набір метрик. Важливо розуміти, що ми хочемо відстежувати і яка метрика може вказати на те, що з процесом щось пішло не так.

Для marketing-секції такими метриками можуть бути:

• CAC (customer acquisition cost) — вартість залучення клієнта;
• LTV (lifetime value) — отриманий від клієнта прибуток;
• Budget — маркетингові витрати.

Product-секція може бути побудована на основі таких даних:

• кількість запитів на створення нових функцій;
• середній час на закриття задачі;
• кількість успішних деплоїв сервісу.

Після їхнього визначення, важливо перевірити, на основі яких даних ці метрики можуть бути побудовані, і впевнитись в їхній якості. Працюючи з пошуком та визначенням метрик, розробники прокачують своє продуктове мислення, адже думають про роботу процесу, можуть знаходити слабкі місця в наявній архітектурі та планувати те, як будувати її більш стабільною.

Аналізуючи метрики, які необхідно відобразити, у розробника будується розуміння зв’язків між процесами, за які відповідають різні відділи, та бачення бізнесу з погляду цих процесів. Такий data-driven-підхід сприяє розвитку продуктового мислення, адже розробник приймає рішення про те, що було б ефективно реалізувати для покращення метрик, а не просто закриває задачі.

Збір даних, DWH overview. Інтеграція систем, що генерують дані

Дані для метрик можуть зберігатися в різних системах. Для зручності top-level-аналітику краще будувати в одному місці та необхідно впевнитись, що всі дані збираються в один source.

Процес інтеграції даних в DWH залежить від системи, яка ці дані генерує. Для побудови метрик основних секцій Executive-дашборду нам були потрібні дані з наступних джерел:

• база даних з інформацією про користувачів;
• івенти, які користувачі виконували при взаємодії з платформою;
• дані з ClickUp про задачі;
• інформація про стабільність роботи платформи з ArgoCD.

Для синхронізації даних з основної бази ми налаштували міграційні задачі за допомогою AWS Database Migration Service. Під час створення таких задач важливо звертати увагу на їхній тип: full load чи full load, ongoing replication.

Під час створення першої задачі ми обрали другий тип, за якого дані синхронізуються real-time, що дозволило миттєво бачити всі зміни. Зі збільшенням кількості таблиць, які необхідно синхронізувати для аналізу, ми зіткнулись з проблемою перевантаження DWH-запитами на оновлення даних. Своєю чергою, це вплинуло на час виконання запитів та завантаження дашбордів.

Для розв’язання цієї проблеми ми визначили рівень критичності даних і розбили цей процес на декілька міграційних задач. Станом на зараз критичні дані синхронізуємо real-time, для інших — створили окремі задачі, які запускаємо з необхідною періодичністю.

Отримання даних з інших систем залежить від їхніх технічних можливостей. На основі налаштованої інфраструктури, вони можуть самостійно відправляти івенти про зміни в даних або дозволяти отримувати їх за потреби через API. Вибір способу інтеграції залежить від ваших потреб: чи необхідно опрацьовувати зміни в момент їхнього здійснення, або ж достатньо витягувати дані з певною періодичністю й оновлювати на вашій стороні.

У випадку з ClickUp нам було важливо реагувати на зміни в момент їхнього здійснення. Завантаження даних кожного разу через api вимагало б постійного запису даних з нуля, що не дозволяє зберігати історію змін. ClickUp надсилає webhooks під час оновленні даних. На нашій стороні ми налаштували сервіс для їхнього опрацювання, фільтруємо потрібні івенти (збираємо дані тільки про конкретні типи задач та їхні деталі) і зберігаємо в DWH.

Для взаємодії з ArgoCD нам достатньо за запитом отримувати інформацію про виконані події (deploys та rollbacks). Для цього ми налаштували сервіс, який витягує дані раз на день, опрацьовує їх, перетворюючи в необхідний формат та записує в DWH.

В обох випадках було важливо продумати місце зберігання та вимоги до системи опрацювання даних на нашій стороні. Визначити, які саме дані потрібні та налаштувати процес перетворення даних у визначений формат для подальшого зберігання.

Під час роботи над задачею інтеграції даних з інших систем інженери мають проаналізувати вимоги не тільки до написання процесу вилучення даних, але і мати чітке уявлення про те, як дані мають зберігатись та використовуватись. Це сприяє відчуттю високого рівня ownership за побудований процес і надає можливість працювати над задачею end-to-end.

Налаштування описаних процесів дозволяє аналізувати дані з різних систем в комбінації. Наприклад, у нашому випадку: стабільність роботи сайту (ArgoCD) та кількість створених інцидентів (ClickUp) може корелювати з кількістю нових створених користувачів на платформі. Це можна помітити одразу, якщо візуалізації метрик розташовані поряд.

Впровадження такої системи дозволяє всім командам оцінювати комплексно наявні процеси та знаходити залежності між ними, тим самим розвиваючи своє продуктове мислення.

Побудова моделі та візуалізації

Коли дані опрацьовано і збережено в DWH, можна переходити до етапу побудови графіків. Для побудови візуалізацій ми використовуємо Looker. Його основна перевага в тому, що розробник один раз описує модель, на основі якої можна будувати будь-яку кількість відображень без написання додаткового SQL-коду.

Процес побудови дашбордів в Looker виглядає наступним чином:

• опис таблиць, на основі яких мають бути побудовані дані;
• опис explore: сукупності таблиць, пов’язаних між собою;
• побудова дашборду.

Першим кроком необхідно описати у вигляді view таблиці з DWH, які хочемо використовувати. Кожне статичне поле описуємо як dimension, а обчислення (суми, середні значення) — як measures. Під час побудови моделі корисно використовувати описи (descriptions та labels) для того, щоб назви полів та їхнє основне призначення були зрозумілі кінцевим користувачам. Якщо декілька розробників працюють над однією моделлю в Looker, то наявність описів дозволяє уникнути уточнень і пояснює, чому було застосовано певний фільтр, чи чому метрика побудована саме таким чином.

Після опису таблиць переходимо до створення explore. Тут маємо визначити, яка модель є основною і додати пов’язані дані, які можуть бути корисними при візуалізації. Наприклад, для того, щоб мати можливість вивести дані за країнами, до таблиці користувачів маємо приєднати домени. В результаті опису всіх пов’язаних таблиць ми отримуємо повний список даних, на основі яких можемо будувати дашборд.

Переходимо на рівень відображення. Тут Looker пропонує зручний інтерфейс, який дозволяє інтуїтивно обирати, які поля ми хочемо відображати та налаштувати потрібні фільтри. На цьому етапі в блоці з доступними полями якраз відображаються labels, які ми встановили на етапі моделювання.

Обираємо метрики, які хочемо відобразити та переходимо до вибору візуалізації. Важливо, щоб кінцевому користувачу (не обов’язково технічній людині) було очевидно, що відображається на графіку.

Залежно від обраної метрики Looker надає наступні види візуалізації. Вибір необхідної опції залежить від того, що саме ви хочете відобразити:

• stacked bar — корисний для відображення частин цілого і їхнього розподілу в межах обраних фільтрів;
• лінійні графіки гарно підходять для відображення однакових метрик, але залежно від різних ознак (наприклад, країн);
• статичне число корисне для візуалізації певного елементу даних станом на зараз;
• таблична візуалізація дозволяє організувати набір даних різних типів, що є зручним для завантажень або побудови репортів.

Після визначення типу відображення та налаштувань візуалізації зберігаємо побудований експлор в окремому дашборді, і він готовий до використання кінцевими користувачами. На верхньому рівні Looker дозволяє додати фільтри, які допомагають відображати дані в розрізі різних параметрів без залучення розробників.

Система сповіщень. Як показувати дані потрібним людям

Looker дозволяє налаштовувати систему сповіщень для окремих графіків. Можна налаштувати список користувачів, які мають регулярно переглядати побудовані візуалізації та встановити періодичність їхньої відправки.

Якщо є критичні дані по процесу, на які обов’язково мають звернути увагу, краще розташувати їх на верхньому рівні дашборду. Так ви точно будете впевнені, що відповідальні люди не пройдуть повз.

Далі можна досліджувати вбудований Looker marketplace. Він надає можливості налаштування інтеграцій з різними сервісами, наприклад Slack, що дозволяє надсилати сповіщення в потрібний канал при виявленні невідповідностей. Це впливає на швидку реакцію на наявні проблеми в системі або в процесах.

Data моніторинг, перевірка якості даних

На основі побудованих візуалізацій команди можуть приймати певні рішення. Наприклад, у нас зміна трафіку нових користувачів чи заявок може вплинути на рішення по перегляду процесів, пов’язаних з маркетингом. Уповільнення швидкості навчального процесу студентів може вплинути на зміни в програмі. Оскільки рішення приймаються на основі даних, важливо, щоб дані показували дійсні цифри.

Якщо метрика різко спадає / зростає, варто спочатку перевірити, чи не зламався процес генерації та опрацювання даних перед тим, як приймати важливе рішення.

Для аналізу якості даних реалізуйте автоматизоване рішення моніторингу. Для цього важливо визначити основні правила, які свідчать про проблеми в процесі. Такі перевірки можуть бути налаштовані на поля, для яких є розуміння «зламаного» стану: відсутність обов’язкового значення чи наявність неочікуваних даних, які свідчать про неправильне функціонування.

На основі сформованих правил пропишіть набір SQL-запитів, які будуть періодично запускатись в DWH і налаштуйте систему сповіщень на виявлення невідповідностей. Це дозволить автоматизовано перевіряти дані та виправляти процеси до того, як про наявні помилки повідомляють команди, які мають приймати рішення.

Важливо впевнитись, що є відповідальна людина, яка слідкує за тим, що неточності даних будуть виправлені. Це може бути аналітик або відповідальна за процес людина.

Висновки

Про аналітику

Комплексний підхід до побудови аналітики в компанії допомагає розуміти, як працює бізнес і бачити, куди він рухається. Для того, щоб це запрацювало, необхідно приділити час процесам, що містять:

1. Визначення ключових метрик бізнесу та процесів, які відповідають за їхні зміни.
2. Налаштування інфраструктури та підтримки для отримання, опрацювання та зберігання даних.
3. Розробку функцій моніторингу якості даних, на основі яких побудовано аналіз.
4. Налаштування сповіщень та регулярних перевірок побудованих метрик.

Про вплив аналітики на продуктове мислення

1. Впровадження описаних процесів напряму впливає на розвиток продуктового мислення. Розробники починають дивитись на рішення не як на закриття задачі з написання коду, а як на налаштування процесу, який впливає на ключові метрики бізнесу і допомагає компанії рухатись в потрібному напрямку.
2. Розуміння аналітики дозволяє знаходити процеси, які можна оптимізувати, проявляти проактивність, пропонувати рішення і впевнено презентувати свої досягнення на performance review на основі змінених метрик.
3. Для того, щоб бути класним розробником не достатньо лише писати якісний код. Важливо думати в інтересах бізнесу, що своєю чергою зворотно впливатиме і на ріст розробника, як спеціаліста на ринку праці. Аналітика дає розробнику можливість керуватись бізнесовим підходом. Такий підхід до виконання задач особливо цінний в епоху штучного інтелекту, який демократизує розробку.