Подписочная бизнес-модель кажется простой, пока MRR не начинает падать без видимых причин. MRR в $50K звучит хорошо — до момента, когда выясняется, что churn rate 15% в месяц означает потерю половины выручки за 4 месяца. Мы, как команда с опытом в 20+ проектов подписочной модели, знаем, как настроить subscription analytics, чтобы видеть эти сигналы заранее и своевременно реагировать. Без качественных данных о MRR, Churn Rate и ARPU невозможно понять, что именно тормозит рост — плохое удержание, низкая конверсия триала или недостаточный upsell.
Влияние аналитики подписок на MRR и Churn
Подписочная аналитика напрямую влияет на ключевые метрики: MRR, Churn Rate, ARPU. Правильно настроенные дашборды позволяют оперативно выявлять проблемы и принимать меры.
Источники данных о подписках
Самая важная задача — получать надёжные события о жизненном цикле подписки. На мобильных платформах это нетривиально. Расскажу на примере двух платформ и middleware-решения, которое экономит до 80% времени разработки.
iOS StoreKit 2. Transaction.updates — async stream всех транзакций (новые, renewals, revocations). Product.SubscriptionInfo.status — текущий статус подписки. Server-to-Server notifications (App Store Server Notifications V2) — единственный надёжный способ получать renewal события на бэкенд, так как клиент может быть offline в момент renewal.
Android Google Play Billing 6. PurchasesUpdatedListener для realtime-событий, queryPurchasesAsync при старте приложения для reconciliation. Real-time Developer Notifications через Pub/Sub — аналог Apple S2S notifications.
RevenueCat как middleware — снимает боль работы с обеими платформами. Единый webhook с нормализованными событиями: initial_purchase, renewal, cancellation, billing_issue, product_change, refund. Webhooks доставляются на бэкенд с retry при ошибке. Для большинства проектов RevenueCat — правильный выбор: SDK на клиенте + webhook на сервере. Сравнение подходов представлено в таблице.
| Подход | Время интеграции | Гибкость | Надёжность |
|---|---|---|---|
| Только нативные S2S | 3–4 недели | Максимальная | Высокая (собственный retry) |
| RevenueCat + нативные | 1 неделя | Достаточная | Высокая (встроенный retry) |
Ключевые метрики и как их считать
MRR (Monthly Recurring Revenue)
MRR = сумма ежемесячной нормализованной выручки от всех активных подписок. Годовые подписки делятся на 12 (не суммируются целиком в месяц оплаты).
SELECT
SUM(
CASE plan_interval
WHEN 'monthly' THEN price_usd
WHEN 'yearly' THEN price_usd / 12.0
END
) as mrr
FROM subscriptions
WHERE status = 'active' AND DATE_TRUNC('month', NOW())
BETWEEN started_at AND COALESCE(ended_at, 'infinity')
Декомпозиция MRR по движению: New MRR (новые подписчики), Expansion MRR (upgrade), Contraction MRR (downgrade), Churned MRR (отмены), Reactivation MRR. Суммарное изменение = Net New MRR. Эти цифры говорят, откуда растёт и куда утекает выручка. По данным SaaS Capital, компании, отслеживающие Net New MRR, на 30% быстрее находят точки роста.
Что такое Net New MRR и как он помогает выявить точки роста?
Net New MRR — это разница между новым и потерянным MRR. Если он положительный, бизнес растёт. Отрицательный сигнализирует о проблемах с удержанием или привлечением. Регулярный мониторинг этой метрики позволяет вовремя скорректировать стратегию ценообразования или маркетинга.
Churn Rate
Две версии — не путай их:
Revenue Churn = Churned MRR / MRR начало периода. Показывает потерю выручки. User Churn = Отмёненные подписки / Активные подписки начало периода. Показывает потерю пользователей.
Revenue Churn важнее для SaaS. Если upsell работает хорошо, User Churn может быть 5%, а Revenue Churn — отрицательным (Negative Churn) за счёт expansions. Снижение User Churn на 5% может увеличить LTV на 25–40%.
ARPU (Average Revenue Per User)
ARPU = MRR / Активные подписчики. Считать нужно по когортам, не глобально: ARPU когорты текущего периода vs ARPU предыдущей когорты покажет, улучшилось ли качество привлечения.
Trial Conversion Rate
(Пользователи, перешедшие с trial на платную) / (Пользователи, начавшие trial). Считаем по когорте — trial начался в период X, через 7/14/30 дней проверяем conversion. RevenueCat даёт готовый trial_conversion event.
Дашборд и хранилище
Сырые события подписок → ETL в аналитическое хранилище (BigQuery, ClickHouse, Redshift). Агрегированные метрики пересчитываются батчем (ежедневно или ежечасно для свежих данных) и кешируются в Postgres или Redis для API.
Мобильный дашборд (admin) отображает: MRR с трендом (спарклайн за 90 дней), Active Subscribers, Churn Rate, ARPU, Trial Conversion. Cohort retention chart — классическая треугольная таблица, где строки = когорты по месяцу старта, столбцы = месяцы после старта, ячейки = % оставшихся.
На Flutter: fl_chart для линейных графиков и DataTable для когортной матрицы. На iOS: Swift Charts + UICollectionView с compositional layout.
| Когорта | Месяц 1 | Месяц 2 | Месяц 3 |
|---|---|---|---|
| Январь | 100% | 65% | 48% |
| Февраль | 100% | 68% | 50% |
Как настроить dunning flow для снижения involuntary churn?
До 20–40% churn в подписочных приложениях — involuntary: карта просрочена, недостаточно средств. App Store/Google Play автоматически ретраят несколько дней, но если не конвертировало — подписка отменяется. Потери от involuntary churn для приложения с 10 000 подписчиков и ARPU $10 могут достигать 200 000 долларов в год.
Dunning flow на клиенте: при получении billing_issue event показываем in-app сообщение с CTA «Обновить способ оплаты». На iOS — прямая ссылка в настройки подписки через ManagedSettingsStore или deep link itms-apps://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions. На Android — BillingClient.launchBillingFlow с PRODUCT_DETAILS для update payment.
Правильно настроенный dunning может вернуть 15–25% involuntary churners. Для приложения с 10 000 подписчиков и ARPU $10 это экономия от 15 000 до 25 000 долларов ежемесячно.
Как настроить ETL pipeline для метрик?
Пошагово:
- Собираем webhook-события от RevenueCat или нативных S2S в очередь (Pub/Sub, SQS).
- Пишем стриминговую обработку (например, на Go или Python) для парсинга и валидации.
- Записываем в сырую таблицу BigQuery/ClickHouse с партиционированием по дате.
- Ежедневно запускаем агрегации: MRR, Churn, ARPU по когортам.
- Кешируем результаты в Postgres и отдаём через API дашборду.
Этот пайплайн обрабатывает миллионы событий без потерь и даёт актуальные цифры с задержкой не более 5 минут.
Что входит в работу: deliverables
- Аудит текущего event tracking (доступ к коду, конфиги, логи)
- Интеграция RevenueCat или нативных S2S/RTDN уведомлений
- Построение ETL pipeline (BigQuery/ClickHouse)
- Реализация аналитических запросов (MRR, Churn, ARPU, LTV)
- Разработка мобильного дашборда (Flutter/Swift)
- Настройка dunning flow для iOS и Android
- Документация по метрикам и дашборду
- Доступ к репозиторию и дашборду на staging
- Обучение команды работе с аналитикой (1 час)
Процесс работы
Аудит текущего event tracking → интеграция RevenueCat или нативных S2S notifications → построение ETL pipeline → реализация аналитических запросов → разработка дашборда → настройка dunning flow → A/B тесты ценообразования на основе ARPU-данных. Получите консультацию — мы предложим оптимальное решение под ваш стек.
Ориентиры по срокам
RevenueCat интеграция + базовые метрики MRR/Churn/ARPU в дашборде — 1 неделя. Полная система с cohort retention, декомпозицией MRR, dunning flow и предсказанием churn — 4–6 недель. Стоимость рассчитывается индивидуально после анализа требований.
| Метрика | Формула | Периодичность пересчёта |
|---|---|---|
| MRR | Σ нормализованной выручки активных подписок | Ежедневно |
| User Churn Rate | Отмены / Активные начало периода | Ежемесячно |
| Revenue Churn Rate | Churned MRR / MRR начало периода | Ежемесячно |
| ARPU | MRR / Активные подписчики | Ежедневно |
| Trial Conversion | Конвертировали trial / Начали trial | По когорте через N дней |
| LTV | ARPU / Revenue Churn Rate | Ежемесячно |
Получите консультацию по настройке аналитики подписок. Опыт специалистов подтверждён сертификатами Apple и Google. Закажите аудит вашей текущей аналитики подписок — мы выявим точки роста и потери.