АВ-тести, дослідження, мітинги. Як виглядає робочий день аналітика даних у продуктовій IT-компанії

Привіт, мене звати Роман Повзик. Уже понад рік як аналітик даних співпрацюю з геймдев-компанією Bini Games (у минулому — Bini Bambini). З них останні шість місяців — у ролі продуктового аналітика.

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

Запитання цих людей і є нині темами для моїх статей — щоби не повторювати постійно одне й те саме на кожній зустрічі. Оскільки майже кожен з початківців запитував про те, що варто вчити, то це мотивувало зробити текст «SQL, BI-системи та статистика. Що, де і як варто вчити, щоби підготуватися до першого офера».

Наступним за частотою стало питання: чим аналітик займається протягом робочого дня? На нього і спробую відповісти в цьому матеріалі.

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

Збір метрик за тиждень

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

Ці метрики — мінімальний набір, який може сказати, як почуває себе додаток. Звісно, їх може бути недостатньо, щоби повноцінно подивитися на здоров’я проєкту та побачити проблему. Але їх досить, щоб орієнтуватися в динаміці.

Подібний збір проводиться швидко, якщо потрібні дашборди налаштовані та не дають збоїв.

Планування тижня

У визначений день тижня (зазвичай, на початку чи наприкінці) продуктова команда (продюсер, проєкт-менеджер, продуктові менеджери, АSO-менеджер, маркетолог, гейм-дизайнер, бізнес-аналітик та аналітик даних) мають зустріч щодо планів та результатів. Саме тут і потрібні будуть тижневі метрики додатків.

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

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

Моніторинг метрик у продукті

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

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

Щоденний перегляд допомагає не проґавити критичне падіння через баг чи інші причини. І швидко виправити його, якщо це можливо.

Серед показників, на які варто дивитися щодня: прибуток з реклами та покупок, конверсії в активацію підписок, рекламні показники, retention, DAU/WAU/MAU, середні тривалості сесій, ігровий час. З часом це вже стає звичкою, без якої не можеш почати день. І заряджає оптимізмом, якщо з метриками все добре.

Щоденна зустріч щодо планів на день

Daily-мітинг — одна з частин робочого дня кожного учасника ІТ-команди, у тому числі й аналітика. На ній проговорюєш вчорашні і сьогоднішні завдання та блокери.

Мій робочий календар на початку тижня

Ці щоденні мітинги новачку можуть здатися неефективними: адже сидиш на них 15-20 хв, щоби розповісти 3-4 речення про свої завдання.

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

Системні онлайн-зустрічі

Частина робочого часу аналітика — повторювані зустрічі щотижня або раз на два тижні. Наприклад:

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

Ще можуть бути брейншторм-зустрічі, зустріч з UA-командою (платне залучення користувачів), але вони трапляються з меншою системністю. Те ж і про внутрішні лекції, сесії «питання-відповідь» з керівництвом, мітингів щодо новин компанії та інших нерегулярних зустрічей.

Непостійні зустрічі можуть бути за різними темами залежно від особистих та командних поточних завдань.

Запуск АВ-тестів

Одне з основних завдань аналітика в продуктовому ІТ — робота з АВ-тестами. Адже ми ніколи не можемо бути впевненими в тому, як саме аудиторія сприймає зміни в додатку. Тому ризиково релізити їх на всіх користувачів.

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

Запуск кожного АВ-тесту — доволі відповідальне завдання. Спочатку потрібно зрозуміти, що саме тестуватимемо. Далі — розібратися, на які саме метрики може вплинути гіпотеза і як їх можна виміряти. Крім, того варто зрозуміти, як у продукті можна змінити потрібний функціонал.

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

Приклад меню з трьома кнопками для подальших дій гравця

Перш ніж стрімголов запустити такий тест, аналітику варто зрозуміти, як саме він отримає (1) кліки за цими кнопками в обох варіантах, (2) кількість юзерів, які ними користувалися, та (3) розуміння, що саме вважати перемогою того чи іншого варіанту. І головне: де саме налаштовуються ці кнопки.

Перегляд запущених АВ-тестів

Запуск АВ-тесту в додатку — разовий процес щонайменше на якусь кількість тижнів. А ось запущені експерименти аналітику варто переглядати щодня.

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

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

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

Аналіз зупинених АВ-тестів

Остання складова роботи аналітика, пов’язана з АВ-тестами, — аналіз експериментів, які вже закінчилися. Тепер потрібно дослідити ключові для тесту метрики та визначити, який саме варіант переміг, і чи була це випадковість, чи закономірність.

Докладніше про АВ-тести та статзначущість для них розповідаю тут, а навчальні ресурси для розуміння теорії контрольованих експериментів раджу тут.

Калькулятор статзначущості, з якого зазвичай починається аналіз АВ-тестів

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

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

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

Аналіз показників останнього релізу

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

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

Автоматизувавши збір метрик у дашборди, робити аналіз релізів набагато простіше

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

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

Опис необхідної аналітики для нових фіч у продукті

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

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

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

Робота з ad hoc запитами від колег

Одна з навичок аналітика, яка мало в кого є з продуктової команди, — знання мови запитів SQL та можливість діставати з бази даних будь-яку інформацію щодо продукту, якщо вона туди логується.

Тому аналітик мусить допомагати колегам з ad hoc запитами. Це одноразові запити, які потрібні для ухвалення певного рішення. Вони спонтанні й навряд чи ще колись знадобляться в майбутньому.

Найсвіжіший приклад: список найкращих 5 країн за доходом у вересні на iOS, бажано з відсотками за кожною з країн.

Приклад ad hoc запиту до аналітика

Інший запит: кількість користувачів на певному пристрої на Android, де помітили певний баг. Треба взяти до уваги кількість користувачів з цього типу девайсів (що конвертується в дохід з реклами) і скільки часу займе в розробника виправлення недоліку (тобто, фінансові витрати на це).

Доопрацювання та ремонт дашбордів

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

Аналітик має вміти працювати з BI-системами. Компанії найчастіше використовують Power BI або Tableau, рідше — Google Data Studio або Looker. У вакансіях пишуть саме ті сервіси, які використовують.

Чи будеш ти як аналітик створювати дашборди? Залежить від компанії. Якщо у її штаті немає ВІ-інженера, його обов’язки частково перейдуть на тебе.

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

Розбір проблем і багів у продукті

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

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

Щоби розробник поправив проблему, якщо вона закралася в код, недостатньо просто сказати, що впали конверсії. Потрібно чітко вказати, у чому справа.

Передрелізні налаштування продукту

Додатки, як і будь-який складний технічний продукт, можуть мати сотні різних конфігурацій: де показуватиметься реклама, які види покупок побачить користувач, кількість відкритого контенту. Ці налаштування можна виставити з допомогою різних інструментів, наприклад ремоутів Firebase або Unity. Звісно, розробники наперед подбали про цю можливість на етапі роботи над тією чи іншою фічею продукту. Але надалі аналітик (або й хтось інший, наприклад, тестувальник) може самостійно керувати налаштуваннями на запущеному продукті.

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

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

Ідеї для брейншторму

Ця активність може мати різні форми. Раз на кілька тижнів продуктова команда збирається на спеціальний міт-брейншторм.

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

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

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

Прокрастинація

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

Для себе розв’язую цю проблему Помодоро: концентрована робота протягом 50 хв (фокус-режим) і відпочинок мозку на 10 хв (режим розфокусу). Звісно, якщо в цей час немає онлайн-зустрічі. У ці 10 хвилин я перекушую, застеляю ліжко, годую кота й черепах тощо. Обідня перерва — також хороша можливість для розфокусу.

Похвилинний приклад мого робочого тижня на початку жовтня

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

Усе індивідуально, але багато спільного

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

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

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

А чи почнеш кар’єру в аналізі — залежить від наполегливості та бажання вчитися нового. На щастя (чи на жаль) — протягом усього часу в цій професії.

👍ПодобаєтьсяСподобалось21
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

Слава Україні!

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

Так АВ-тести — лише частина аналізу, який потрібний для прийняття рішень у продуктовій команді.

Чекатиму на статтю наступного року. Дуже цікаво прочитати досвід інших аналітиків.

Дякую за роботу, радий, що є що почитати і подивитись за DA українською)

Дякую, що читаєте. Чим більше аналітиків розповідатимуть про свій досвід українською — тим більше буде контенту про DA)

Підписатись на коментарі