Як побудувати аналітику з нуля в SaaS і не наступити на типові граблі
Якщо ваша продуктова команда дивиться на дані, і вони «не збігаються» — це не проблема з даними, а питання налагодження роботи з ними. Типова ситуація — кожен відділ користується своєю аналітикою: маркетинг покладається на рекламний кабінет, білінг — на провайдерські звіти, продукт — на Amplitude. Рішення ухвалюються або після тривалих дискусій або взагалі за відчуттям.
Це не проблема конкретної команди — скоріше типовий стан аналітики в SaaS-продуктах на етапі зростання. Дані є, але довіряти їм складно. І чим більше джерел, тим складніше.
Своїм досвідом та порадами поділиться в статті Ганна Шепелєва, Data Analyst Lead у Brainstack.
Коли я прийшла в Brainstack, то була єдиним аналітиком у wellness-напрямку. Предикти жили в Google-таблицях, а щоденне зведення «скільки заробили вчора» збирав вручну менеджер. За кілька років ми побудували систему з розбіжністю предиктів по ключових локалях — 1–2%. У цій статті я поділюся, на які граблі наступають SaaS-команди в роботі з аналітикою і які рішення допомагають їх уникнути.
Граблі #1. Дублі та використання різних технологій
Знайома ситуація: дашборди зелені, метрики ростуть, команда задоволена. А потім хтось помічає, що CPA в одному звіті не збігається з іншим або маркетинг-сорси розходяться між собою. Тоді починається розслідування.
З мого досвіду, причина здебільшого у дублі подій і з Amplitude, і з бекенду. Наприклад, користувач купив у Facebook, але до цього бачив рекламу в Instagram, в email-розсилці і в Snapchat. Бекенд про це не знав, бо ніхто не прописав правила атрибуції. Маркетинг рахував одне, продукт — інше. Кожен упевнений, що його цифри правильні.
Аби не потрапляти в цю пастку, маркетингова атрибуція має працювати однаково і в бекенді, і в Amplitude. Проведіть аудит: у яких саме випадках і звідки приходять івенти, де можуть бути дублі. Тоді ваша аналітика буде надійним джерелом для прийняття рішень, а не грою у зіпсований телефон між командами.
Граблі #2. Різні тайм-зони
Підписуйтеся на наші соцмережі
Аналітик відкриває звіт і бачить різкий стрибок даних посеред ночі. Йому здається, що це баг, і він витрачає кілька годин на пошук причини. Виявляється, що нічого не зламалося, просто один кабінет працює за UTC, а інший – за локальним часом.
Якщо ви не хочете, щоб ваші аналітики постійно розбиралися із запитами «а чому в мене не ті дані?», налаштуйте єдину тайм-зону для всіх джерел. Це здається простим правилом, однак у багатьох компаній досі немає єдиного стандарту, а рекламні кабінети відкриваються із власними таймзонами. До того ж, важливо зберігати data contacts: якщо маркетинг-команда відкриває новий кабінет або змінюється тайм-зона, аналітики мають дізнатися про це до запуску. Тоді не буде витрачатися час на пошук причини прогалини в даних.
Граблі #3. Дані є, але їх не можна порівняти
Бізнес просить погодинний дашборд по країнах. На перший погляд, це виглядає нескладно. Однак якщо у вас маркетинг, продукт та білінг-аналітика «живуть окремим життям», тут вже з’являється реальна проблема через різну гранулярність. Наприклад, в Amplitude ви бачите дані в реальному часі, у маркетингу — щоденні зрізи, у білінгу — щогодинні.
Це класична ситуація для продуктів, які масштабуються. Запускаються нові локалі, напрямки, продукти, тести. Пріоритети швидко змінюються, і аналітика за ними не встигає.
Що робити? Тут працює архітектура даних Bronze — Silver — Gold. Bronze — сирі дані, як прийшли з джерел. Silver — очищені й приведені до єдиного формату та гранулярності. Gold — агреговані таблиці, готові до використання в дашбордах. Саме на рівні Silver дані з Amplitude, маркетингу і білінгу нарешті можна об'єднати в один зріз.
Коли архітектура стає впорядкованою, можна йти глибше — в advanced analytics Meta. Це дозволяє робити аналітику в розбивках за віком, за креативами у реальному часі. У попередній архітектурі такий детальний розбір був би просто неможливий.
Граблі #4. Розрізненість джерел і відсутність документації
Декілька джерел даних без єдиної логіки між ними — ще один типовий біль аналітика. Наприклад, дані про користувачів зберігаються в PostgreSQL: хто зареєструвався, яка підписка, який план. Але країни там немає взагалі. Країна — тільки в BigQuery, разом з івентами. На практиці це означатиме, що будь-який аналіз у розрізі країн — це щоразу join через два окремі сховища. І замість того, що витрачати час на аналіз, потрібно ще розібратися, що де лежить, і як це зібрати.
Аби це вирішити, ми ввели single source of truth: одне сховище, один стек, один стандарт метрик. Паралельно запровадили документацію і контроль версій скриптів: кожна зміна фіксується. Таким чином, кожен новий звіт перестає бути детективною історією.
Граблі #5. Аналітика зав’язна на інженерах, і відсутня оркестрація
На початку у більшості проєктів немає дата-інженера. Тому кожне нове питання від бізнесу — це таск у Jira та черга на два тижні. Приємного у цьому мало, адже це дуже уповільнює роботу та прийняття рішень.
Сюди ж — відсутність контролю якості даних. Пайплайн начебто відпрацьовує, але всередині — нульові значення або щось почали хешувати і поламали логіку. І поки хтось один не відкриє звіт і не зверне на це увагу, ніхто і не помітить, що щось пішло не так.
Аби вирішити це питання, на MVP-етапі ми підключили Fivetran і так змогли побудувати базове розуміння метрик без інженера. Це нас рятувало декілька місяців, поки не у команді не з’явився власний інженер. Однак майте на увазі, що такі сервіси можуть створювати великі витрати при зростанні обсягів, тому це рішення на старт, а не назавжди.
Як довгострокове рішення ми впровадили quality gates та алерти в Slack. Якщо дані нульові, є розбіжність між таблицями або щось змінилося в структурі — команда дізнається о 9-й ранку. Додатково зробили окремий дашборд, який показує розбіжності між джерелами даних у реальному часі.
Висновки з практики
Сьогодні в Brainstack ми використовуємо Amplitude і backend events як джерела по продукту, які підстраховують одне одного. Маркетингова аналітика деталізована до рівня креативу, а білінгові дані зведені в єдине сховище в BigQuery.
Що я зрозуміла, будуючи аналітику з нуля? Всі граблі — це відсутність домовленостей до того, як почали будувати, і бажання зробити швидко. Будувати аналітику доведеться в будь-якому разі — питання лише в тому, скільки разів її доведеться перебудовувати.
Ви зможете оминути головні проблеми в роботі з аналітикою свого Saas-продукту, якщо відразу узгодите кілька важливих речей: єдина таймзона, спільні правила атрибуції, одне сховище і один стандарт метрик, data contracts між командами, quality gates з першого дня і документація кожної зміни логіки.