LTV, ARPU та ще понад 20 понять, які має знати кожен продуктовий аналітик

Привіт! Мене звати Роман Повзик. Майже рік співпрацюю у сфері аналітики даних з Bini Bambini, яка спеціалізується на освітніх іграх для дошкільнят. Останні чотири місяці — у ролі продуктового аналітика. Тому розповім про два десятки термінів, з якими стикаються мало не щодня і які варто знати початківцям. Описані поняття стосуються продуктової аналітики, хоча частину з них застосовують і в маркетинговій аналітиці.

Метрики

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

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

LTV та Lifetime

LTV (Lifetime value) — сума коштів, яку в середньому користувач приносить за весь час користування продуктом. У розрахунок включають заробіток із покупок юзера і з його перегляду реклами. А Lifetime — кількість днів, місяців або й років, протягом якого він його використовує.

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

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

ARPU, ARPPU та ARPDAU

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

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

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

Конверсія

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

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

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

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

eCPM

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

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

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

DAU, WAU та MAU

Інколи чуємо про успішні додатки, у яких понад десять мільйонів установок. Але набагато важливішою метрикою є саме кількість активних користувачів (active users). Адже додаток могли завантажити, але навіть не відкрити. Або лише раз зіграти в гру й забути про неї. Чи взагалі видалити.

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

Коефіцієнт прилипливості (sticky factor)

Ще одна цікава метрика, пов’язана з показниками активних користувачів. Рахується як DAU поділене на MAU: тобто який відсоток від місячної активної аудиторії становить ваша денна аудиторія. Чим він більший, тим більше користувачів щодня заходять в сервіс.

Один із хороших прикладів для утримання активності аудиторії можна знайти в додатку з вивчення мов Duolingo. Користувач бачить, скільки днів підряд він виконує навчальні вправи. Якщо забудеш про уроки в додатку й не зайдеш хоча б один день — втратиш таке досягнення (наприклад, понад 1100 днів у мене). Тому це мотивує щодня користуватися Duolingo.

Retention та churn rate

Ретеншеном називають відсоток користувачів, які залишилися в продукті через певний проміжок часу в днях. Наприклад, нашу гру завантажили 100 користувачів. Наступного дня в неї зайшло 30 з них. Отже, ретеншен першого дня складатиме 30 / 100 = 30 %.

Кожна компанія самостійно визначає, за якими ретеншенами слідкуватимуть аналітики. У нашому випадку, під час аналізу АВ-тестів ми порівнюємо ретеншени 1-ого, 3-ого та 7-ого днів. А у випадку визначення успішності нового релізу додатка — ще й 14-ого та 30 днів. «Золотий стандарт» — 1-ий, 7-ий та 28-ий день.

Приклад ретеншену мобільного додатку за даними Firebase

Є обернене ретеншену поняття — churn rate або відтік, тобто який відсоток користувачів втрачаєш через день, три, сім і так далі. У випадку з ретеншеном першого дня у 30 %, відтік складатиме 100 — 30 % = 70 %. Що більше підіймаєш першу метрику, відповідно зменшуватиметься друга.

Окрім такого поняття класичного ретеншену, існує роллінг або накопичувальний ретеншн. Тобто роллінг ретеншн 7-ого дня — це відсоток користувачів, які зайшли в додаток після 7-ого дня від першого відкриття чи пізніше. Тоді як у класичному варіанті ми б пізніших користувачів не рахували б.

AB-тест

Це контрольований експеримент, у якому аудиторію ділять на рівні сегменти й показують різний функціонал, інтерфейс, ціну підписки тощо. Після проведення такого тесту з допомогою статистики визначають варіант-переможець. Якщо перемогло нововведення — воно стає основним робочим варіантом (Baseline). І далі вже його мають перемогти інші варіанти-кандидати.

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

Зразок частини АВ-тесту з відкритим контентом, налаштований у Firebase

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

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

Статзначимість та p-value

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

Зазвичай, p-value приймають на рівні 5 %. Тобто, навіть маючи статзначимість у 95 % потрібно розуміти, що є шанс 1 до 20, що отримані результати — випадковість. У ситуації, коли продукт має справу з життями (наприклад, медтех), то ця планка зростає до 99 % і вище.

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

Приклад роботи онлайн-калькулятора для визначення статзначимості АВ-тесту

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

Тим, хто хотів би глибше зазирнути «під капот» цих понять, раджу два курси: АВ-тестування від фахівців Google та основи статистики від Стенфордського університету.

Також часто зустрічаю як рекомендацію «Statistics and probability» на Khan Academy, але сам ще не проходив його.

SQL-запит

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

Зазвичай, дані зберігаються в хмарному сховищі. Тому великі шанси, що в компанії використовуватимуть або Google Cloud, або AWS від Amazon.

Щоби швидко отримати необхідну інформацію стосовно окремих деталей продукту, потрібно знати мову SQL. Це must have для аналітика, без неї не варто навіть надсилати резюме.

Матеріалів, щоби швидко освоїти SQL — море. Мої фаворити — W3School та базове відео від Моша Хамедані, з якого я й познайомився з цією мовою.

Івент

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

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

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

Дашборд

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

Його можна порівняти з кардіограмою здоров’я компанії. І таке ж значення він має для її майбутнього.

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

Приклад частини дашборду, який показує активації підписки за сесіями в AB-тесті

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

Як зрозуміти, у якому інструменті потрібно прокачуватися аналітику? Ніяк. Це завжди лотерея, результат якої залежатиме від компанії. Але варто дивитися актуальні вакансії, щоби розуміти реальний попит на ці технології. Як на мене, то Power BI та Tableau в лідерах на рівних.

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

Провал та аномалія

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

Продуктовий аналітик шукатиме відповідь або в даних (перестали надсилатися дані частини аудиторії) або в налаштуваннях дашборду. Найгірший сценарій: ці дані — реальна картина й щось трапилося з продуктом. Кожного разу це — детективна історія, у якій роль Еркуля Пуаро покладена на аналітика.

Графік, з якого видно провал у конверсіях за 12 червня цього року

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

Фіча

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

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

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

Це і всі терміни?

Звісно, ні. Їх ще багато. Я охопив лише базові, які варто знати ще на етапі співбесіди. Чому б не виділитися серед кандидатів і не показати, що вже маєш розуміння цих понять?

Якщо рухатися глибше, то ще є:

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

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

Що більше в тебе ставатиме досвіду, то більше нових термінів дізнаватимешся.

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

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини