Дослідження в продукті: мій підхід після чотирьох років в аналітиці даних

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

Всім привіт. Мене звати Роман Повзик. Як Product Analyst співпрацюю з продуктовою геймдев-компанією Burny Games й нині розвиваю гру-криптограму Colorwood Words.

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

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

Дані, метрики й чотири типи питань до аналітика

Що бачить аналітик у продукті? Є користувачі, які заходять у застосунок і роблять там певні дії: проходять опитувальник, вирішують, чи підписуватися, дивляться рекламу, грають у рівні, користуються тим функціоналом, заради якого встановили гру.

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

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

Далі команда домовляється, на які метрики дивиться і як за ними оцінює здоров’я продукту. Частина з них — індустріальні стандарти. Наприклад, у мобільних іграх з рекламною монетизацією це:

• ARPU — середній дохід на користувача; базова метрика для більшості застосунків.
• ARPDAU — середній дохід на щоденного активного користувача.
• Conversion rate — відсоток користувачів, які перейшли з одного кроку на інший (у підписку, з тріалу в оплату, з рівня на рівень, по воронці онбордингу чи опитувальника).
• Retention — частка користувачів, які повернулися в продукт у певний день життя (частіше дивляться 1-й, 3-й, 7-й, 14-й, 28-й день).
• Win rate — відсоток успішних спроб пройти рівень. У геймдеві це спосіб налаштовувати складність: має бути цікаво, але не безнадійно.

Приклад на скріні — win rate та середня тривалість певних рівнів на двох платформах

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

Чотири базові питання

«Що?» Найпростіше питання про стан продукту. Яке в нас ARPU? Яка конверсія в підписку? Який ретеншн третього дня в Японії?

«Чому?» Тут потрібні аргументи й пояснення: Чому просіла конверсія в Німеччині? Чому зросло ARPU в США? Доводиться занурюватися в сегменти, перерізи, порівнювати когорти.

«Що буде, якщо?» Це вже гіпотеза: Що буде, якщо запустимо нову фічу, яка піднімає монетизацію, але може шкодити ретеншну?

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

Питання, які аналітик даних чує ледь не щодня

Цим питанням відповідають чотири типи аналітики:

1. Описова (descriptive) — «Що сталося?»
2. Діагностична (diagnostic) — «Чому це сталося?»
3. Прогнозна (predictive) — «Що може статися далі?»
4. Прескриптивна (prescriptive) — «Що з цим робити?»

Невеликий приклад з Colorwood Words

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

Переписка з продюсеркою гри щодо багу 801-го рівня

• Що? Користувачі «застрягли» на неіснуючому рівні.
• Чому? Дані в Amplitude показали, що двоє користувачів таки потрапили в 801-й рівень, який дублював 800-й. Це виявився баг через недозаливку рівнів.
• Що буде, якщо? Якщо нічого не зробити, більше іспаномовних користувачів досягатимуть цього «фейкового» рівня й відпадатимуть.
• Що робити? Піти до QA і дозалити потрібні рівні.

Це простий кейс, але логіка та сама, що й у складніших продуктових дослідженнях.

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

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

Для себе я запускаю ресерч, коли:

Команда або аналітик не можуть швидко відповісти на питання «як?» чи «чому?».

Наприклад, у Colorwood Words є фіча Daily Challenge — календар із щоденним спеціальним рівнем. Питання для дослідження: Як поводяться користувачі, які регулярно грають у Daily Challenge? Чи треба вже створювати додатковий контент, чи більшість справді проходить лише сьогоднішній день?

Фіча Daily Challenge в Colorwood Words

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

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

1. «Чи розумію я, навіщо це дослідження?». Якщо немає чіткої зв’язки з продуктом (яку метрику хочемо покращити, яку гіпотезу перевірити), є ризик зробити красивий аналіз, який нікому не потрібен.
2. «Чи справді відповідь не лежить на дашборді?». Іноді на пошук відповіді йде кілька годин, хоча команда вже має готовий звіт. Тому я намагаюся добре знати, які в компанії є дашборди та що вони показують. Якщо розумію, що відповідь є на дашборді, — просто сідаю з ініціатором задачі на короткий дзвінок і показую дані. У мене мінус одна задача, у колеги — готові відповіді.

Як я структурую дослідження: від ідеї до результату

Коли розумієш, що болить, саме дослідження можна розкласти на чотири етапи:

• Пошук ідеї (що досліджувати?). Якщо ідея слабка, навіть технічно бездоганний аналіз не дасть користі. Наприклад, фокус на сегменті з високим ARPU, але мізерною часткою аудиторії.
• Валідація важливості (чи варто це досліджувати?). Потрібно прикинути потенційну цінність: чи може це дослідження вплинути на дохід, ретеншн, досвід? Чи не коштує воно дорожче за можливий ефект?
• Аналіз. Тут уже робота з даними: SQL, Amplitude, Python, BI-інструменти. Важливо не забувати тримати в голові початкове питання.
• «Продаж» результатів (що з цим тепер робити?). Найчастіше аналітик не ухвалює фінальне рішення. Тому важливо вміти пояснити: що саме знайшли, чому цьому можна довіряти, які кроки можe зробити продуктова команда.

Складові кожного дослідження

Фреймворк з «The Craft of Research»

Мені дуже подобається книжка «The Craft of Research». Один із фреймворків звідти я адаптував під продуктові ресерчі. Перед початком я визначаю на три речі:

1. Тема: я вивчаю...
2. Питання: тому що хочу з’ясувати, що / чому / як...
3. Значення: щоб допомогти аудиторії (команді, бізнесу) зрозуміти...

Наприклад, у Colorwood Words ми маємо фічу «рівні з картинками». Користувачу треба спочатку відгадати слово за зображенням (лимонад, гора тощо), а далі ці літери допомагають розгадати всю фразу.

Мій ресерч виглядав так:

1. Тема: я вивчаю воронку користувачів, які рухаються новою кривою рівнів, де є «рівні з картинками».
2. Питання: бо хочу з’ясувати, що могло вплинути на більший відпад користувачів на перших рівнях і гірші метрики монетизації.
3. Значення: щоб допомогти команді покращити фічу та продукт загалом.

Що важливо з цього запам’ятати:

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

Де брати ідеї для досліджень

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

Щоб було з чого вибирати, я використовую кілька джерел.

1. Власні спостереження та сфокусований час

Я свідомо виділяю собі «час на подумати» — в роботі й поза нею. Допомагають прості рамки: сесії по 50 хвилин глибокої роботи та 10 хвилин перерви; у перерві не забиваю голову YouTube чи подкастами, коли в процесі великого ресерчу.

Часто цікава ідея приходить саме тоді, коли мозок виходить із режиму «я зараз щось рахую», але тема ще відгукується десь на фоні.

2. Колеги й їхні рідні

Коли влітку ми додали українську локалізацію, колеги почали надсилати гру своїм рідним. Мама одного зі співробітників сказала, що «пройшла всю гру», хоча була лише на 290-му рівні з понад тисячі.

Відгук від мами колеги

Причина — текст фрази, який звучав як фінальне звернення з пропозицією надсилати свої ідеї для наступних рівнів. Для неї це сприйнялося як кінець контенту.

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

Висновок: слухати колег і їхніх рідних корисно, особливо якщо вони не в продукті щодня. Їхні враження допомагають побачити патерни, які дев-команда вже «не помічає».

3. Dogfooding і плейтести

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

• особисті тригери «щось тут не так»;
• гіпотези, які потім можна перевірити даними;
• іноді — виявлення багів ще до масового релізу.

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

4. Інші продукти

Це не обов’язково мають бути прямі конкуренти. Іноді цікаве рішення зустрічається в іншому жанрі або навіть в іншій індустрії.

Корисні питання:

• Чому тут з’явилася саме така фіча?
• Що могли бачити в даних її автори?
• Чим вона могла б бути корисною нашому продукту?

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

5. Огляд дій конкретних користувачів

Якщо компанія використовує Amplitude або має зручну SQL-базу, можна «розмотувати» поведінку конкретних користувачів: дивитися ланцюжок івентів, імітувати їхню сесію.

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

Плюси:

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

6. Використання LLM і Deep Research

Сучасні LLM дають змогу делегувати частину «чорнового» ресерчу:
попросити зібрати інформацію про жанр, механіку, причини успіху іншої гри, сформувати список гіпотез.

Мій підхід тут такий: «генерація → селекція → розвиток».

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

Важливо лише пам’ятати про NDA й не ділитися з моделлю тим, що не можна виносити назовні.

7. Відгуки в сторах

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

1. За що вас люблять?
2. За що вас видаляють?

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

Це не завжди привід для великого ресерчу, але точно — джерело ідей, де варто придивитися до даних уважніше.

Проведення дослідження й що вважати успіхом

Сам процес дослідження я тримаю простим і прагматичним. Три технічні питання на старті:

• Що досліджувати? Які когорти беремо; за які періоди життя користувача; які метрики важливі саме тут.
• Чим досліджувати? SQL, Amplitude, Google Sheets, Python, Power BI, Tableau — не так важливо, чим саме; стейкхолдерам зазвичай важливі висновки, а не стек.
• Де шукати? База даних продукту; івенти, логіка трекінгу; наявні звіти й дашборди.

Складові самого процесу дослідження

Дослідження — це завжди ітерації. Якщо питання складне, рідко буває так, що аналітик один раз «пірнув» і одразу приніс фінальну істину. Часто:

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

Це не ознака некомпетентності. Просто у процесі з’являються нові знахідки, які змінюють фокус.

Корисна практика — регулярний міт, де аналітик ділиться проміжними або фінальними результатами, а команда одразу дає фідбек і ставить уточнення.

Важливий момент: уміння вчасно зупинитися.

Якщо після багатьох годин копання в даних немає корисних для продукту висновків, хочеться «докопати ще». Але іноді кнопка try harder нічого не дає, і треба чесно визнати: ця дорога не привела до цінних інсайтів.

Які результати я вважаю хорошими

Для мене гарний результат дослідження — це коли з’являється хоча б щось із цього:

1. Нове знання про користувачів. Наприклад, поведінковий патерн, що відрізняє тих, хто лишається надовго.
2. Зв’язок між активністю та монетизацією. Наприклад, дії в перші дні, які корелюють із високим ARPU.
3. Ідеї для фіч або змін у продукті. Щось, що може зробити сесію довшою, досвід — кращим, а метрики — вищими.

Виграшний екран у грі Colorwood Sort

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

• A/B-тест — найнадійніший спосіб поміряти вплив фічі чи зміни.
• Тест часовими рядами — дивимося на метрики «до» й «після» релізу, розуміючи, що на продукт одночасно впливають й інші фактори.
• Порівняння версій — частина нових користувачів отримує стару версію, частина — нову; щось між класичним A/B і простим «було/стало».

Процес покращення ніколи не закінчується: як тільки ви підняли метрики, саме це значення стає новим дефолтом, і далі команда думає, як рухатися вище.

Мій чекліст ідеального ресерчу

Наприкінці — короткий чекліст, за яким я звіряюся сам:

1. Сформулюйте чітке питання. Сміття на вході = сміття на виході.
2. Зробіть початкові припущення. Можна бути суб’єктивним — дані все одно скажуть своє слово.
3. Визначте, які дані та метрики потрібні. Не тягніть у ресерч усе підряд.
4. Проведіть аналіз і візуалізуйте результати. Чим простіші графіки, тим легше побачити тренди.
5. Інтерпретуйте дані й сформуйте тези. Кілька чітких висновків краще за десяток «можливо».
6. Поясніть знахідки команді. Ідеально — на регулярному мітингу, де можна одразу обговорити наступні кроки.
7. Сформулюйте рекомендації. Що конкретно пропонуєте змінити, додати, протестувати.
8. Задокументуйте результати. Навіть якщо не любите документацію. Через кілька місяців це може зекономити дні роботи, коли хтось повернеться до старої ідеї.

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.