продуктова аналітика (product analytics)
Також називають: аналітика продукту, продуктовий аналіз, product analytics, поведінкова аналітика
Практика вимірювання того, що люди насправді роблять усередині продукту, на основі подій, які вони запускають, і перетворення цих чисел на рішення: що будувати, лагодити, як ціноутворювати й рости.
Продуктова аналітика (product analytics) — це робота з відповідями на продуктові питання за допомогою даних про поведінку. Кожну вагому дію користувача в застосунку чи вебпродукті (реєстрація, створення групи, додавання витрати, відкриття paywall, скасування підписки) записують як подію (event) з часом, ID користувача і властивостями. Продуктова аналітика перетворює цей потік на метрики, порівнює їх між людьми, періодами й версіями і завершується рішенням, яке хтось фіксує письмово.
Питання, на які вона відповідає, дуже практичні:
- Хто користується продуктом і як часто — з урахуванням природного ритму продукту (DAU, WAU, MAU, stickiness)?
- Де нові користувачі застрягають на шляху до першої справжньої цінності (воронки, активація)?
- Чи повертаються люди через тиждень, місяць, квартал (утримання за когортами)?
- Чи спрацювала зміна і наскільки ми в цьому впевнені (A/B-тести, обережні порівняння «до / після»)?
- Чи це окупається: конверсія в оплату, дохід на користувача, LTV порівняно з вартістю залучення?
- Як ми будемо рости: які канали приводять людей, що залишаються, скільки дають запрошення?
Вона перетинається із суміжними дисциплінами, але ставить інше питання:
Найкорисніша звичка в продуктовій аналітиці — починати з рішення, а не з дашборду: сформулювати питання, визначити кожну метрику так, щоб двоє людей отримали те саме число, перевірити сирі дані на пастки підрахунку (події, створені сервером, акаунти працівників, часові пояси) і лише тоді будувати графік. Число, до якого не прив'язане рішення, зазвичай виявляється метрикою марнославства.
Приклад
Maya, продуктова лідерка Halves (застосунку для розподілу спільних витрат), питає: «Чи варто далі інвестувати в сканування чеків?» Сканування — одна з функцій Halves Plus, тож воно за paywall.
1. Визначаємо терміни. Місячний активний користувач (MAU) — той, хто сам додав витрату або записав розрахунок за останні 30 днів. Регулярні рахунки, створені сервером, і акаунти працівників не враховуються. У червні в Halves було 40 000 MAU.
2. Дивимося на paywall за тригерами. 3 200 із цих користувачів хоча б раз бачили paywall; кожного зараховано до першого тригера, на який він натрапив:
3. Читаємо. Сканування чеків дає половину всіх переглядів paywall (1 600 / 3 200 = 50%) і 64% тріалів (128 / 200), а ті, хто бачить paywall саме там, починають тріал удвічі частіше, ніж ті, хто бачить його в налаштуваннях (8,0% проти 4,1%).
4. Записуємо рішення. «Сканування чеків — найсильніша причина спробувати Plus. Далі: покращити процес сканування і виміряти конверсію з тріалу в оплату для тріалів зі сканування. Чи сканування ще й утримує людей — окреме питання: ті, хто сканує чеки, відрізняються від тих, хто не сканує, тож ми перевіримо це тестом, а не порівнянням двох груп».
Типові помилки
- Починати з дашборду, а не з питання. Графіки без прив'язаного рішення перетворюються на щотижневий ритуал, після якого ніхто нічого не робить.
- Невизначені метрики. «Активні користувачі» нічого не означають, доки ви не запишете дію, одиницю, вікно, часовий пояс і винятки.
- Довіряти сирим лічильникам подій. Події від сервера, подвійне логування і QA-акаунти роздувають числа; перевірте сирі рядки, перш ніж будувати графік.
- Сприймати кореляцію як причину. «Хто користується функцією X, краще утримується» зазвичай каже, хто обирає X, а не що X робить. Проведіть експеримент або прямо скажіть, чого порівняння не доводить.
- Вважати це покупкою інструмента. SDK аналітики дає події, а не відповіді; справжня робота — план трекінгу й визначення метрик.