Метрики SaaS і застосунку: MRR, відтік, активація в одному дашборді

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

#Гроші: MRR і його рух

MRR (monthly recurring revenue) — регулярний дохід за місяць, нормалізований: річна підписка ділиться на 12, разові платежі не входять.

Ключова деталь — розкласти зміну MRR на компоненти:

Net new MRR = New + Expansion + Reactivation − Contraction − Churned

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

#Відтік: клієнтів і виручки

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

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

#Продукт: активація і утримання

• Активація — частка нових користувачів, що дійшли до «моменту цінності» (створили перший проєкт, підключили інтеграцію, завершили онбординг) за N днів.
• Утримання D1/D7/D30 для застосунків, тижневе або місячне — для SaaS (когортний аналіз).
• DAU/MAU — «липкість» продукту.
• Конверсія trial → paid за когортами старту.

Визначення «активації» — завжди рішення продуктової команди. Я допомагаю знайти подію, після якої утримання різко вище, і закріплюю її як метрику.

#Якість застосунку

Для мобільних застосунків поруч із грошима потрібні:

• частка сесій без крашів (crash-free sessions/users) за версіями;
• топ крашів за кількістю користувачів;
• рейтинг і відгуки в сторах;
• час запуску.

Різке падіння утримання після релізу часто пояснюється не маркетингом, а новим крашем на певній версії ОС.

#Атрибуція встановлень

Для застосунків канал встановлення визначає MMP (наприклад, AppsFlyer). Щоб порахувати CAC і LTV за каналами, дані MMP з'єднуються з подіями підписки. Деталі — у статті про атрибуцію AppsFlyer.

#Джерела даних

Модель даних тримається на одній таблиці підписок з історією змін (статус, план, сума, дати). З неї рахуються MRR-рух, відтік і когорти.

#Перший екран SaaS-дашборда

Для застосунків додайте crash-free users і D7 retention. Приклад — на сторінці для SaaS і застосунків.

#Типові помилки

• Включати разові платежі й налаштування в MRR.
• Рахувати річну підписку як MRR місяця оплати.
• Не відрізняти вимушений відтік від добровільного.
• Брати активних користувачів без чіткого визначення «активності».
• Дивитися на загальний відтік без когорт.

#Чекліст

• MRR нормалізований (річні / 12, без разових)
• Рух MRR розкладено на компоненти
• Logo churn і revenue churn окремо
• Вимушений відтік відстежується
• Визначено подію активації
• Утримання за когортами
• Краші за версіями поруч з утриманням

#Приклад: міст MRR

Найкорисніший графік для SaaS — міст MRR: звідки взявся MRR цього місяця. Ілюстративний місяць:

З тих самих чисел:

• Валовий відтік виручки = (скорочення + відтік) / MRR на початок = 6 000 / 100 000 = 6,0%
• Чисте утримання виручки (місячне) = (початок + розширення + повернення − скорочення − відтік) / початок = 98 200 / 100 000 = 98,2%
• Quick ratio = (нові + розширення + повернення) / (скорочення + відтік) = 12 200 / 6 000 ≈ 2,0

Деякі команди рахують повернення як нових клієнтів, а не як частину утримання. Оберіть одну конвенцію і запишіть її. Зростання на 6,2% виглядає здоровим, але 6% місячного валового відтоку означає, що за півтора року ви заміните більшу частину бази виручки. Міст робить це видимим, а одна лінія MRR — ні.

#SQL: будуємо міст з даних підписок

WITH m AS (     -- MRR клієнта за місяць, приведений до місячного (річний / 12)
  SELECT customer_id, month, SUM(mrr) AS mrr
  FROM mart.subscription_mrr_monthly GROUP BY 1, 2
),
pairs AS (
  SELECT COALESCE(cur.customer_id, prev.customer_id) AS customer_id,
         COALESCE(cur.month, DATE_ADD(prev.month, INTERVAL 1 MONTH)) AS month,
         IFNULL(prev.mrr, 0) AS prev_mrr, IFNULL(cur.mrr, 0) AS cur_mrr,
         EXISTS (SELECT 1 FROM m h WHERE h.customer_id = COALESCE(cur.customer_id, prev.customer_id)
                 AND h.month < DATE_SUB(COALESCE(cur.month, prev.month), INTERVAL 1 MONTH)) AS had_history
  FROM m cur
  FULL OUTER JOIN m prev
    ON prev.customer_id = cur.customer_id AND prev.month = DATE_SUB(cur.month, INTERVAL 1 MONTH)
)
SELECT month,
  SUM(IF(prev_mrr = 0 AND cur_mrr > 0 AND NOT had_history, cur_mrr, 0)) AS new_mrr,
  SUM(IF(prev_mrr = 0 AND cur_mrr > 0 AND had_history, cur_mrr, 0))     AS reactivation_mrr,
  SUM(IF(prev_mrr > 0 AND cur_mrr > prev_mrr, cur_mrr - prev_mrr, 0))    AS expansion_mrr,
  SUM(IF(prev_mrr > 0 AND cur_mrr > 0 AND cur_mrr < prev_mrr, cur_mrr - prev_mrr, 0)) AS contraction_mrr,
  SUM(IF(prev_mrr > 0 AND cur_mrr = 0, -prev_mrr, 0))                    AS churned_mrr
FROM pairs GROUP BY month ORDER BY month;

Річні плани приводьте до місячних (сума / 12) ще в таблиці-джерелі, а разові платежі (налаштування, кредити) виключайте з MRR. Інакше кожне річне продовження з'являтиметься як сплеск «розширення».

#Активація: момент, що передбачає утримання

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

1. Складіть список 5–10 кандидатів (створив перший проєкт, запросив колегу, підключив джерело даних, тричі використав основну функцію).
2. Для реєстрацій, старших за 3 місяці, порахуйте утримання на 60-й день для тих, хто зробив і не зробив кожну дію протягом 7 днів.
3. Оберіть дію з великим розривом в утриманні, до якої доходить помітна частка користувачів. Рідкісна дія з величезним розривом — непрактична.
4. Звітуйте частку активації щотижня за когортами реєстрацій і каналами залучення.

Це кореляція, а не доказ, що дія спричиняє утримання. Сприймайте її як гіпотезу і тестуйте зміни онбордингу.

#Невдалі оплати: вимушений відтік

Частина відтоку — це картки, що не пройшли, а не клієнти, які пішли. Розділяйте добровільний (скасували) і вимушений (оплата не пройшла й не відновилась) відтік. Вимушений відтік добре реагує на повторні спроби списання, сервіси оновлення карток і листи-нагадування — часто це найдешевший відтік, який можна зменшити. Поряд показуйте частку відновлення: скільки невдалих оплат відновлено протягом 14 днів.

#Як читати дашборд щомісяця

Коротка рутина тримає дашборд SaaS корисним, а не декоративним:

1. Почніть з мосту MRR: яка складова змінилася найбільше?
2. Якщо змінився відтік — розділіть добровільний і вимушений, потім за планами і когортами реєстрацій.
3. Якщо змінився новий MRR — подивіться на реєстрації, частку активації та конверсію з тріалу в оплату за каналами.
4. Перевірте чисте утримання виручки за когортами: чи встигає розширення за відтоком у старших когортах?
5. Запишіть по одному реченню на знахідку і одну дію. Наступного місяця перегляньте, що з дій вийшло.

#Часті запитання

#Як рахувати MRR, якщо є знижки?

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

#Що важливіше — logo churn чи revenue churn?

Обидва. Logo churn показує задоволеність клієнтів, revenue churn — фінансовий ефект. Великий клієнт, що пішов, може важити більше за десятки малих.

#Звідки брати дані про підписки з App Store?

Через звіти й серверні сповіщення стору або через сервіси керування підписками. Їх треба привести до спільної моделі з веб-підписками.

#Чи потрібна окрема продуктова аналітика?

Для базових метрик достатньо GA4/Firebase з експортом у BigQuery. Глибокий продуктовий аналіз воронок і сегментів зручніший у спеціалізованих інструментах.