Аналитика подписок в мобильном приложении: MRR, Churn, ARPU

Подписочная бизнес-модель кажется простой, пока 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 на сервере. Сравнение подходов представлено в таблице.

Ключевые метрики и как их считать

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.

Как настроить 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 для метрик?

Пошагово:

1. Собираем webhook-события от RevenueCat или нативных S2S в очередь (Pub/Sub, SQS).
2. Пишем стриминговую обработку (например, на Go или Python) для парсинга и валидации.
3. Записываем в сырую таблицу BigQuery/ClickHouse с партиционированием по дате.
4. Ежедневно запускаем агрегации: MRR, Churn, ARPU по когортам.
5. Кешируем результаты в 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 недель. Стоимость рассчитывается индивидуально после анализа требований.

Получите консультацию по настройке аналитики подписок. Опыт специалистов подтверждён сертификатами Apple и Google. Закажите аудит вашей текущей аналитики подписок — мы выявим точки роста и потери.