Будуємо аналітику в BI з нуля

Привіт! Мене звуть Марія, я займаю позицію Head of Analytics у Kiss my Apps, і хочу поділитися своїм досвідом у відбудові аналітики. Ця стаття буде особливо корисною, якщо ви перший або перша аналітик на новому проєкті й не знаєте, з чого почати та куди рухатися на старті.

На початкових етапах розвитку не завжди зрозуміло, як та навіщо працювати з даними, щоб вони працювали на вас, тому пропоную почати з базового питання: що таке BI й навіщо воно потрібне?

Насправді BI (Business Intelligence) — це досить широке поняття, яке описує комплекс процесів, стратегій та інструментів, які використовуються для обробки даних та їх підготовки для подальшого бізнес-аналізу. Часто під BI мається на увазі репортинг та/або дашборди, побудовані, наприклад, в Tableau, але це лише верхівка айсберга.

Простіше кажучи, BI — це аналітика в цілому, а не лише готові інструменти. Навіщо це потрібно й кому? Будь-якому проєкту, який хоче будувати свій розвиток на data-driven рішеннях, а не на інтуїції та розкладах таро.

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

Крок перший. Визначаємо потребу

З тим, що таке BI та навіщо він потрібен, наче розібралися, перейдемо до справи!

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

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

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

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

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

Крок другий. Обираємо BI-інструменти

Ми визначили потребу, тепер можемо обирати, як саме ми будемо її закривати.

Тож нам потрібен інструмент, в якому зможемо візуалізувати та аналізувати дані, але який? Можливо, у вас промайнула думка про Excel або Google Sheet, тому почнемо з відповіді на питання, чому не вони :)

Чому не Excel / Google Sheets

Я не буду стверджувати, що Excel чи Google Sheets не можуть задовольнити потребу в аналітиці, бо це не так — у деяких випадках (як би гірко мені не було це визнавати) і такі інструменти підійдуть. До того ж ви точно не зможете їх позбутися назавжди — таблички час від часу нам усім потрібні.

Проте треба розуміти, що не все, що може використовуватись для аналітичних задач — це хороші аналітичні інструменти. Що Excel, що Google Sheet дозволяють нам проводити різноманітні обчислення та будувати візуалізації, але мають також досить багато обмежень. Google Sheets не потягне великі обʼєми даних. Excel — потягне, але його буде важче підтримувати, особливо, коли команда інтенсивно зростатиме. Тому на табличках ми аналітику не будуємо (за можливості).

Який інструмент обрати

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

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

У цьому випадку працюватимемо здебільшого з даними нашого продукту. Основною задачею буде вивчення поведінки користувачів, аналіз утримання, генерація та тестування гіпотез на основі цього аналізу. До речі, про A/B-тестування в нас також є стаття 😉

Наведу кілька прикладів таких інструментів:

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

Google Analytics має дві великих переваги: він безплатний і органічно вписується в інфраструктуру Google, в якій достатньо корисних для аналітики інструментів.

Amplitude та Mixpanel — не безплатні, проте, мабуть, найбільш поширені для задач продуктової аналітики. Особливо якщо ми говоримо про мобільні застосунки. Обидва інструменти мають широкий функціонал, який покриває відстеження подій на продукті, аналіз поведінки користувачів, побудову дашбордів та інструменти для A/B-тестування.

Ми для продуктової аналітики використовуємо Amplitude.

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

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

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

Маркетингова аналітика

Якщо говорити про аналіз маркетингу, тут ми більше працюватимемо з даними third party: нам будуть потрібні дані з маркетингових кабінетів (Meta Ads, Google Adwords тощо), дані про атрибуцію користувачів (Appsflyer / Adjust), а також дані про платежі (їх, як правило, надає бекенд, але існують й зовнішні сервіси, такі як RevenueCat).

Такі дані доведеться обробляти самостійно, і для їх візуалізації та аналізу підійдуть, наприклад, інструменти:

Looker Studio — безплатний сервіс від Google, що дозволяє створювати інтерактивні звіти та дашборди з різним рівнем кастомізації та об’єднувати дані з різних джерел. Він має ті ж переваги, що й Google Analytics, та додатково вирізняється гнучкістю у налаштуванні візуальної складової.

Однак, Looker Studio не оптимізований для деяких популярних баз даних, важко справляється з великими об’ємами інформації, є повністю онлайн-сервісом і часто підвисає. Якщо вам потрібен інструмент для побудови гарних, але простих дашбордів на відносно невеликих обʼємах даних, Looker буде хорошим варіантом. Але в інших випадках я б не радила чіплятись за те, що він безплатний :)

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

Power BI — інструмент, найбільш схожий на Tableau за функціоналом. Основна відмінність — інтеграція в інфраструктуру Microsoft, що робить його хорошим вибором для тих, хто вже з ним працює. Однак він не підходить для команд, які використовують техніку Apple.

Звісно, й тут ми не обмежені прикладами, що я навела. Та й завжди можна написати власний внутрішній інструмент (на Python, наприклад). Головне, щоб була потрібна експертиза.

Крок третій. Підготовка аналітичної інфраструктури

Якщо ми вже обрали інструмент, можемо рухатися далі й готувати аналітичну інфраструктуру. На цьому кроці не буду зупинятись детально та технічно — це задача для data-інженера і я дуже раджу довіряти її саме такому спеціалісту.

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

Якщо немає можливості найняти дата інженера або є інші обмежувальні фактори, існують альтернативні шляхи.

Наприклад, використання Google Cloud Platform — тут одразу є рішення і для зберігання даних (Google Cloud Storage), і для автоматичної обробки й трансформації (Google Dataflow), і для аналізу (BigQuery), і для візуалізації (Looker Studio). Переваги очевидні: хмарне рішення, яке реалізоване в єдиній інфраструктурі та просте в підтримці.

У моїй команді одразу був data-інженер, але на першому місці стояла швидкість реалізації, тому ми йшли шляхом найменшого спротиву й зупинилися на дуже популярному наборі інструментів. Postgres в ролі аналітичної бази даних, Python + Apache Airflow для обробки даних та автоматизації. Таке рішення дешеве й досить просте, проте не завжди оптимальне.

До речі, про автоматизацію: для роботи з даними third party існують готові інструменти, що дозволяють легко налаштовувати імпорт даних в аналітичну базу. Наприклад, Fivetran. На початку роботи над аналітичною інфраструктурою ми використовували його для швидкого налаштування імпорту даних з маркетингових кабінетів.

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

І наостанок, підбиймо підсумки

• Головне під час побудови аналітики — визначити потреби проєкту та задачі, які ви хочете покривати. Цей крок пропускати не можна, бо без розуміння потреби доведеться працювати навмання.
• Вибираючи аналітичні інструменти, враховуйте не тільки їхню популярність, але й прайсинг та функціонал. Завжди можна перейти на більш advanced-інструмент, але навряд хтось захоче платити за те, що не використовується повною мірою.
• Не варто недооцінювати експертизу data-інженерів — такий спеціаліст знадобиться команді рано чи пізно, і що раніше це станеться, то краще та ефективніше для всієї роботи. Якщо ж наразі немає можливості залучити дата-інженера, не соромся використовувати 3rd-party сервіси, які допоможуть зекономити час.

Врешті-решт, після всіх цих кроків можна переходити до побудови «лиця» BI-репортингу (тобто безпосередньо дашбордів) й предиктивної аналітики. Але це ще дві великих та цікавих теми для обговорення, тому лишимо їх на потім ;)