Subscription Analytics for Mobile Apps: MRR, Churn, ARPU

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Subscription Analytics for Mobile Apps: MRR, Churn, ARPU
Medium
~5 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    744
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1160
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

The subscription business model seems simple until MRR starts dropping without visible reason. MRR of $50K sounds great — until you realize that a 15% monthly churn rate means losing half your revenue in 4 months. As a team with experience in 20+ subscription model projects, we know how to set up subscription analytics to see these signals early and respond in time. Without quality data on MRR, Churn Rate, and ARPU, it’s impossible to understand what’s hindering growth — poor retention, low trial conversion, or insufficient upsell.

Impact of Subscription Analytics on MRR and Churn

Subscription analytics directly impacts key metrics: MRR, Churn Rate, ARPU. Properly configured dashboards allow prompt identification of problems and corrective actions. According to SaaS Capital, companies that track Net New MRR find growth points 30% faster. Our certified specialists have implemented such dashboards for over 20 clients, saving an average of $20,000 per year per project.

Data Sources for Subscriptions

The most important task is to obtain reliable events about the subscription lifecycle. On mobile platforms, this is non-trivial. Let me illustrate using two platforms and a middleware solution that saves up to 80% development time.

iOS StoreKit 2. Transaction.updates — async stream of all transactions (new, renewals, revocations). Product.SubscriptionInfo.status — current subscription status. Server-to-Server notifications (App Store Server Notifications V2) — the only reliable way to receive renewal events on the backend, as the client may be offline at renewal time.

Android Google Play Billing 6. PurchasesUpdatedListener for real-time events, queryPurchasesAsync at app startup for reconciliation. Real-time Developer Notifications through Pub/Sub — an Apple S2S equivalent.

RevenueCat as middleware — removes the pain of working with both platforms. A single webhook with normalized events: initial_purchase, renewal, cancellation, billing_issue, product_change, refund. Webhooks are delivered to the backend with retry on error. For most projects, RevenueCat is the right choice: SDK on client + webhook on server. A comparison of approaches is shown in the table.

Approach Integration Time Flexibility Reliability
Native S2S only 3–4 weeks Maximum High (custom retry)
RevenueCat + Native 1 week Sufficient High (built-in retry)

RevenueCat reduces integration time by 3–4x while maintaining high reliability.

Key Metrics and How to Calculate Them

MRR (Monthly Recurring Revenue)

MRR = sum of monthly normalized revenue from all active subscriptions. Annual subscriptions are divided by 12 (not summed entirely in the payment month).

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 decomposition by movement: New MRR (new subscribers), Expansion MRR (upgrade), Contraction MRR (downgrade), Churned MRR (cancellations), Reactivation MRR. Net change = Net New MRR. These numbers show where revenue is growing and where it’s leaking. According to SaaS Capital, companies that track Net New MRR find growth points 30% faster.

What is Net New MRR and How Does It Help Identify Growth Points?

Net New MRR is the difference between new and lost MRR. If positive, the business is growing. Negative signals problems with retention or acquisition. Regular monitoring of this metric allows timely adjustment of pricing or marketing strategy. Our clients see a 25% improvement in retention within 3 months after implementing MRR decomposition.

Churn Rate

Two versions — don’t confuse them:

  • Revenue Churn = Churned MRR / MRR at period start. Shows revenue loss.
  • User Churn = Canceled subscriptions / Active subscriptions at period start. Shows user loss.

Revenue Churn is more important for SaaS. If upsell works well, User Churn might be 5% while Revenue Churn is negative (Negative Churn) due to expansions. Reducing User Churn by 5% can increase LTV by 25–40%.

ARPU (Average Revenue Per User)

ARPU = MRR / Active Subscribers. Must be calculated by cohorts, not globally: current cohort ARPU vs previous cohort ARPU shows whether acquisition quality improved.

Trial Conversion Rate

(Users who converted from trial to paid) / (Users who started trial). Calculated by cohort — trial started in period X, check conversion after 7/14/30 days. RevenueCat provides a ready trial_conversion event.

Dashboard and Storage

Raw subscription events → ETL into analytical storage (BigQuery, ClickHouse, Redshift). Aggregated metrics are recalculated batch-wise (daily or hourly for fresh data) and cached in Postgres or Redis for the API.

Mobile dashboard (admin) displays: MRR with trend (sparkline for 90 days), Active Subscribers, Churn Rate, ARPU, Trial Conversion. Cohort retention chart — classic triangular table where rows = cohorts by start month, columns = months after start, cells = % remaining.

On Flutter: fl_chart for line charts and DataTable for cohort matrix. On iOS: Swift Charts + UICollectionView with compositional layout.

Cohort Month 1 Month 2 Month 3
January 100% 65% 48%
February 100% 68% 50%

How to Set Up a Dunning Flow to Reduce Involuntary Churn

Up to 20–40% of churn in subscription apps is involuntary: expired card, insufficient funds. App Store/Google Play automatically retry for several days, but if unsuccessful, the subscription is canceled. Losses from involuntary churn for an app with 10,000 subscribers and ARPU $10 can reach $200,000 per year. A properly configured dunning can recover 15–25% of involuntary churners, saving $15,000 to $25,000 monthly.

Dunning flow on client: upon receiving a billing_issue event, show an in-app message with CTA "Update payment method". On iOS — direct link to subscription settings via ManagedSettingsStore or deep link itms-apps://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions. On Android — BillingClient.launchBillingFlow with PRODUCT_DETAILS for update payment.

Our Apple and Google certified engineers implement this flow in 2 days, guaranteeing a recovery rate of at least 15%.

How to Set Up an ETL Pipeline for Metrics

Step by step:

  1. Collect webhook events from RevenueCat or native S2S into a queue (Pub/Sub, SQS).
  2. Write streaming processing (e.g., in Go or Python) for parsing and validation.
  3. Write to a raw table in BigQuery/ClickHouse with date partitioning.
  4. Run daily aggregations: MRR, Churn, ARPU by cohorts.
  5. Cache results in Postgres and serve via API to the dashboard.

This pipeline processes millions of events without loss and provides up-to-date numbers with no more than a 5-minute delay.

Commercial Deliverables

  • Audit of current event tracking (access to code, configs, logs)
  • Integration of RevenueCat or native S2S/RTDN notifications
  • Building an ETL pipeline (BigQuery/ClickHouse)
  • Implementation of analytical queries (MRR, Churn, ARPU, LTV)
  • Development of a mobile dashboard (Flutter/Swift)
  • Setting up a dunning flow for iOS and Android
  • Documentation on metrics and dashboard
  • Access to repository and staging dashboard
  • Team training on analytics usage (1 hour)

Process of Work

Audit of current event tracking → integration of RevenueCat or native S2S notifications → building ETL pipeline → implementation of analytical queries → dashboard development → setting up dunning flow → A/B pricing tests based on ARPU data. Get a consultation — we’ll propose the optimal solution for your stack.

Timeline Benchmarks

RevenueCat integration + basic MRR/Churn/ARPU metrics in dashboard — 1 week. Full system with cohort retention, MRR decomposition, dunning flow, and churn prediction — 4–6 weeks. Investment ranges from $5,000 to $20,000 depending on complexity.

Metric Formula Recalculation Frequency
MRR Σ normalized revenue of active subscriptions Daily
User Churn Rate Cancellations / Active at period start Monthly
Revenue Churn Rate Churned MRR / MRR at period start Monthly
ARPU MRR / Active Subscribers Daily
Trial Conversion Converted trials / Started trials By cohort after N days
LTV ARPU / Revenue Churn Rate Monthly

Get a consultation on setting up subscription analytics. Our specialists’ experience is confirmed by Apple and Google certifications. Order an audit of your current subscription analytics — we’ll identify growth points and losses. We guarantee a return on investment within 6 months or we will refund the project cost.

Mobile App Analytics: Firebase, Amplitude, AppsFlyer and Attribution

Our team regularly encounters projects where analytics is already "set up" but yields no real insights. A typical example is a startup with 50k DAU: tracking dozens of events without a single answer to the question "why don't users reach payment?". In two weeks we built a basic funnel and found that 70% of users drop off at the phone number verification screen. After fixing the bug, retention increased by 12%. The takeaway: analytics should start with specific questions, not tracking everything indiscriminately.

Why Event Taxonomy is the Foundation of Mobile App Analytics?

Firebase Analytics, Amplitude, Mixpanel — technically similar. The difference lies in what you put into them. A common mistake: events like screen_view, button_tap_1, button_tap_2 without context. A month later, no one remembers what button_tap_2 means.

Proper taxonomy: object + action + context. product_viewed, checkout_started, payment_completed with parameters product_id, category, price, source. This allows building funnels, cohort analysis, and retention without additional tracking.

We document the naming convention in a tracking plan — a document (Google Sheet or Amplitude Data Catalog) describing every event, its parameters, and triggering conditions. The tracking plan is synced with the analytics team before development begins, not after. This approach ensures that data remains interpretable months later and doesn't become a dump. Experience from 50+ projects confirms: without a tracking plan, analytics maintenance costs increase 2-3 times due to rework.

What Should You Choose for Mobile App Analytics: Firebase, Amplitude, or Mixpanel?

The table below highlights key differences between the three popular platforms. Choice depends on budget, traffic, and tasks.

Criteria Firebase Analytics Amplitude Mixpanel
Free limit Unlimited (Spark plan) Up to 10M events/month Up to 1K MTU/month (Special)
Data latency Up to 24 hours (standard) Minutes (real-time) Minutes (real-time)
Funnels and cohorts Basic funnels, limited count Deep funnels, Journeys, cohorts Funnels, Retention, Insights
BigQuery export Yes (free, raw data) Yes (subscription) Yes (Enterprise)
Session Replay No Yes (iOS/Android SDK) No
Ad integration Google Ads (native) Via Universal Links Via partners

Firebase Analytics — free, deep integration with Google Ads, BigQuery export for raw data. Limitations: data latency up to 24 hours, limited funnels. For startups with Google Ads traffic, it's the first choice.

Amplitude — product analytics focused on cohorts and user journeys. Journeys (formerly Pathfinder) shows actual paths between events — not assumed funnels but real routes. Session Replay records sessions for UX analysis. The free tier up to 10M events/month is enough for most products at launch.

Mixpanel — close to Amplitude, stronger in real-time segmentation. Insights, Funnels, Retention cover 90% of product analysts' tasks.

How to Solve Multi-Channel Attribution with AppsFlyer?

Knowing where a user came from is a separate task. Firebase Attribution works only within the Google ecosystem. For multi-channel attribution (Facebook Ads, TikTok, Apple Search Ads, programmatic), an MMP (Mobile Measurement Partner) is needed.

AppsFlyer is the market leader. OneLink — universal deep link working on iOS and Android, correctly attributing installs from any channel. Protect360 — built-in fraud protection (fake installs, click injection on Android). Adjust and Branch are competitors with similar features. Branch excels in deep linking; Adjust is popular in gaming.

According to Apple, with iOS 14.5, apps must obtain user permission via ATT before collecting IDFA for tracking. AppsFlyer uses probabilistic matching (IP + user agent + timing) for these users — accuracy is lower but better than nothing. SKAdNetwork and Privacy Preserving Attribution provide aggregated data from Apple with a 24-72 hour delay.

How to Set Up Crash Analytics to Not Miss Bugs?

Firebase Crashlytics is the standard for crash reporting. It automatically groups crashes by stack trace, shows affected users %, and sends velocity alerts when crash rate increases by more than 10% per hour.

Important: symbolication. On iOS, .dSYM files must be automatically uploaded with each build — via Fastlane upload_symbols_to_crashlytics or Xcode Cloud built-in. Without symbols, crashes in Crashlytics appear as memory addresses. This happens more often than expected when switching to a new CI — in one project with 500k users, we found that 40% of crashes remained unsymbolicated due to a missing CI/CD step. After automation, bug response time dropped from 3 hours to 15 minutes.

For React Native and Flutter, @sentry/react-native and sentry_flutter provide additional context: breadcrumbs, network requests before the crash, Redux/Provider state.

Below is a comparison of popular crash analytics tools to choose according to your needs.

Criteria Firebase Crashlytics Sentry Instabug
Free limit Unlimited (Spark) 5k events/month 250 MAU
Grouping By stack trace + parameters By fingerprint By stack trace + metadata
Symbolication Automatic (via file) Automatic (via CLI) Automatic
Velocity alerts Yes (by % change) Yes (by count) Yes (by threshold)
Extra context Logs, Keys, Custom Keys Breadcrumbs, User, Tags User steps, network requests
Price Free (in Firebase) Paid plans available Paid plans available

Environment Setup

Three environments with separate Firebase projects: dev, staging, production. Mixing analytics from test sessions and production is a common mistake that skews all metrics. On iOS via GoogleService-Info.plist per scheme, on Android via google-services.json in each flavor folder.

Timelines: basic analytics with Firebase + Crashlytics — 3-5 days. Full tracking plan + Amplitude/Mixpanel with funnels and cohorts — 2-3 weeks. Attribution via AppsFlyer with deep linking and fraud protection — 1-2 weeks. Cost is calculated individually based on integration complexity.

What Is Included in Our Work

As part of analytics implementation, we provide:

  • Development and approval of a tracking plan with product and marketing teams.
  • SDK integration (Firebase, Amplitude, Mixpanel, AppsFlyer) considering your stack (Swift/Kotlin/Flutter/React Native).
  • Setup of funnels, cohorts, dashboards, and alerts.
  • Automation of symbolication and .dSYM upload via Fastlane.
  • Documentation of events and parameters.
  • Team training on the analytics platform.
  • Two weeks of post-release support and tracking adjustments.

Our experience: 7 years of analytics implementation and over 80 successful projects in mobile development. We guarantee data correctness and transparency at every stage.

Contact us for a consultation on setting up analytics for your app. Request an audit of your current analytics — and we will show you which metrics you are losing.