Реализация аналитики подписок (MRR, Churn Rate, ARPU) в мобильном приложении

Реализация аналитики подписок (MRR, Churn Rate, ARPU) в мобильном приложении

Подписочная бизнес-модель проще всего испортить неправильной аналитикой. MRR в $50K звучит хорошо — до момента, когда выясняется, что churn rate 15% в месяц означает потерю половины выручки за 4 месяца. Правильно настроенная subscription analytics позволяет видеть эти сигналы заранее.

Источники данных о подписках

Самая важная задача — получать надёжные события о жизненном цикле подписки. На мобильных платформах это нетривиально.

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. Эти цифры говорят, откуда растёт и куда утекает выручка.

Churn Rate

Две версии — не путай их:

Revenue Churn = Churned MRR / MRR начало периода. Показывает потерю выручки.

User Churn = Отмёненные подписки / Активные подписки начало периода. Показывает потерю пользователей.

Revenue Churn важнее для SaaS. Если upsell работает хорошо, User Churn может быть 5%, а Revenue Churn — отрицательным (Negative Churn) за счёт expansions.

ARPU (Average Revenue Per User)

ARPU = MRR / Активные подписчики. Считать нужно по когортам, не глобально: ARPU когорты январь-2025 vs ARPU когорты январь-2024 покажет, улучшилось ли качество привлечения.

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.

Billing issues как причина непроизвольного оттока

До 20–40% churn в подписочных приложениях — involuntary: карта просрочена, недостаточно средств. App Store/Google Play автоматически ретраят несколько дней, но если не конвертировало — подписка отменяется.

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.

Процесс работы

Аудит текущего 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 недель. Стоимость рассчитывается индивидуально после анализа требований.