Mobile App Analytics: 10 Metrics That Actually Matter

Mobile app analytics is the practice of measuring how people use your app, where they drop off and how much revenue they bring, using event data. Downloads don't show an app's real health; activation, D1/D7/D30 retention, churn, DAU/MAU, funnel conversion, crash-free rate, LTV and CAC do.

The numbers are harsh. According to Adjust's Mobile App Trends 2026 report, average retention across all platforms and verticals falls to 26% on day 1, 13% on day 7 and 7% on day 30. Out of every 100 new users, only about 7 open the app again a month later. Teams that can't see where that loss starts usually try to fix it with a bigger ad budget.

Your platform mix changes the picture too. In the same Adjust data, Android day-30 retention (6%) trails iOS (8%). That gap matters a lot in Android-heavy markets: in Turkey, for example, StatCounter data shows Android at 73.77% of mobile OS share in August 2026, with iOS at 26.22%.

In this guide you'll find all 10 metrics in one table, with formulas and reference values. Then we walk through Firebase setup, privacy rules such as GDPR and ATT, and four product decisions driven by data.

What's in this guide

• Why downloads are not enough
• The 10 metrics at a glance: meaning and healthy ranges
• Retention metrics: activation, retention and churn
• Engagement and quality metrics
• Revenue metrics: LTV and CAC
• How to set up Firebase Analytics the right way
• Privacy: GDPR, ATT and store disclosures
• Data-driven product decisions: 4 example scenarios
• Frequently Asked Questions

Why downloads are not enough

Downloads measure how well your store page performs, not how well your app performs. As we explain in our App Store Optimization guide, you can raise store conversion. But if someone installs the app and sees no value in the first session, that download never turns into revenue.

Analytics tools draw this line from the start. Google's list of automatically collected events says the first_open event fires the first time a user launches the app after installing it, not at download. On Android, the app_remove event records the moment the app is uninstalled. The real story of your app lives between those two events.

A healthy mobile app analytics setup groups metrics into three layers:

• Outcome metrics: Revenue, LTV and the LTV:CAC ratio. They answer the leadership question: "Does this app make money?"
• Product metrics: Activation, retention and DAU/MAU. They show whether the product builds a habit.
• Diagnostic metrics: Funnel steps, crash rate and ANR rate. They answer the "why?" behind the other two layers.

Any single metric can mislead you. If DAU grows while D30 retention falls, ads are carrying your growth, not the product. If the reverse happens, your product is solid but your acquisition channels are weak.

The 10 metrics at a glance: meaning and healthy ranges

The table below summarizes the 10 metrics every mobile app analytics plan should cover. The reference column shows sourced averages; your own category will likely look different, and that's normal.

Use reference values as a compass, not a target. Apple offers peer group benchmarks inside App Store Connect. Your app joins a group based on its category, business model and download volume. You then see how you compare with the group's 25th, 50th and 75th percentiles for conversion rate, D1, D7 and D28 retention, and crash rate.

Apple protects this data with differential privacy and adds a certain amount of noise to each data point. Even so, a comparison against apps like yours beats any global market average.

Retention metrics: activation, retention and churn

Retention metrics drive more decisions than any other group in mobile app analytics. If an app can't keep users, every dollar spent on acquisition pours water into a leaking bucket.

1. Activation rate

Activation is the moment a new user first experiences the value your app promises. In a food delivery app, it's the first order. In a fitness app, it's the first completed workout; in a booking app, the first confirmed appointment.

The formula is simple: divide the number of users who complete the activation event by the number of new users in the same period. The hard part is choosing the right event. "Signed up" is rarely activation, because the user hasn't seen any value yet.

The data shows why activation matters. Amplitude's 2025 Product Benchmark Report, covering more than 2,600 companies, found that 69% of top performers in day-seven activation were also top performers in three-month retention. The same research says products that bring back at least 7% of their original cohort on day seven land in the top 25% for activation.

Practical tips:

• Count the steps between sign-up and the value moment, and challenge every step you don't need.
• Measure time to value in minutes, not days.
• Treat activation as the first signal to validate at the MVP stage.

2–4. D1, D7 and D30 retention

Retention shows what share of a cohort (users who first opened the app on a given day) comes back N days later. The three checkpoints answer different questions:

• D1 retention: Was the first session good enough? It grades onboarding and the first experience.
• D7 retention: Is the app becoming a habit? It reflects notifications, content and reasons to return.
• D30 retention: Does the product meet a lasting need? It's the closest signal to product-market fit.

Here's a worked example. On September 1, 2,000 people open the app for the first time. On September 2, 480 of them return; on September 8, 220 return; on October 1, 110 return. This cohort's D1 retention is 24%, D7 is 11% and D30 is 5.5%.

Compared with Adjust's 2026 averages, this app sits below average at all three checkpoints. Fix D1 first, because users you lose on day one never reach day seven.

Watch out for three traps when you calculate retention:

1. Lock the definition. Classic retention counts only users active on exactly day N; rolling retention counts anyone active on day N or later. Mixing definitions gives you false conclusions.
2. Don't mix tools. Apple uses D28 instead of D30 and builds weekly cohorts. Don't try to match Firebase and App Store Connect numbers one to one.
3. Split your cohorts. A retention curve that isn't broken down by platform, acquisition channel and app version hides the source of the problem.

The shape of the curve matters as well. If retention flattens after a certain point, your app has a loyal core audience. If it keeps sliding toward zero, the product hasn't found a lasting need yet.

5. Churn rate

Churn is the share of users or subscribers you lose, and you calculate it differently in two contexts.

For non-subscription apps, you define an inactivity window. For example, you can decide that "a user with no session for 30 days counts as churned." In that case, churn is simply the complement of the same cohort's retention rate.

For subscription apps, churn is the number of subscribers who cancel or fail to renew during a period, divided by active subscribers at the start. RevenueCat's State of Subscription Apps 2026 report, covering more than 115,000 apps, offers some striking numbers:

• Only 27% (hard paywall) and 28% (freemium) of annual subscribers are still active after one year.
• 35% of annual plan cancellations happen in the first month.
• 31% of Google Play cancellations are involuntary, caused by billing failures. On the App Store, the figure is 14%.

That last point hits Android-heavy markets hardest. Renewals fail when a card hits its limit or a virtual card expires. Turning on Google Play Billing's recovery features and showing an in-app "update your payment method" message can save subscriptions that users never meant to cancel. We compare revenue models in detail in our guide to app monetization models.

Engagement and quality metrics

In mobile app analytics, retention tells you whether users come back. Engagement and quality metrics tell you how often they come, where they get stuck and how reliable the app is technically.

6. DAU/MAU ratio (stickiness)

DAU/MAU divides daily active users by monthly active users. A ratio of 0.20 means the typical monthly user opens the app on roughly 6 days a month.

This ratio varies widely by category. Mixpanel's State of Digital Analytics 2026, based on data from more than 12,000 companies, puts DAU/MAU at 21% for ecommerce products in EMEA and 31% for mobile games in EMEA. Holding a messaging app and an insurance app to the same target makes no sense.

Two warnings:

• Not every app is a daily app. For billing, rental or booking apps, WAU/MAU (weekly over monthly) is a more honest measure.
• Define "active" carefully. Firebase's user_engagement event fires when the app is in the foreground for at least one second. Pulling users in for a second with a notification inflates DAU without creating value. We cover this trap in our push notification strategy guide.

7. Funnel conversion rate

A funnel measures the steps of a critical flow in order and shows where users drop off. You need separate funnels for onboarding, checkout and subscription flows.

Here's what an onboarding funnel for an example booking app might look like:

In this example, overall conversion is 16%. The biggest losses happen at SMS verification (720 down to 430) and at the first booking. The team should focus on those two steps first; polishing the profile step would gain almost nothing.

For ecommerce flows, Baymard Institute's figure, compiled from 50 studies, is a useful reference: average cart abandonment is 70.22%. Keep the time window between funnel steps fixed (for example, 24 hours) and split results by platform and device model.

8. Crash-free users and ANR rate

An app that crashes drags every other metric down. Firebase Crashlytics defines its crash-free metrics this way: crash-free users = 1 − (unique users who crashed ÷ all users who engaged with the app). The same logic applies at the session level.

Google Play sets concrete thresholds. According to the Android vitals documentation, the bad behavior thresholds are:

• User-perceived crash rate: 1.09% or more of daily users across all devices; 8% on a single phone model.
• User-perceived ANR rate: 0.47% or more across all devices; 8% on a single phone model.
• Evaluation window: Play looks at the last 28 days of data.

If your app crosses a threshold, Play may reduce its visibility and show users a warning on your store listing. The same documentation says memory usage violations may start affecting store visibility in February 2027.

If your daily crash-free user rate in Crashlytics drops below 98.9%, you're getting close to Play's threshold, since both metrics look at the share of daily users who hit a crash. We cover where stability work fits into your post-launch budget in our app maintenance cost guide.

Revenue metrics: LTV and CAC

The last two metrics in your mobile app analytics stack turn product metrics into money. No matter how good retention looks, growth isn't sustainable if revenue per user doesn't cover the cost of acquiring that user.

9. LTV (lifetime value)

LTV is the total revenue a user brings over their relationship with your app. The simplest formula is LTV = ARPU × average user lifetime. You estimate average lifetime as the inverse of monthly churn (1 ÷ monthly churn).

Worked example: say average revenue per user (ARPU) is $4.50 per month and monthly churn is 9%. Average lifetime is 1 ÷ 0.09 ≈ 11.1 months, so LTV ≈ 4.50 × 11.1 ≈ $50. That's a gross figure; after store commissions, payment fees and server costs, the net contribution is lower.

The formula gives you a fast estimate, but cohort-based "realized LTV" shows the true value. Track how much revenue each monthly cohort generates by day 30, 90 and 180. Apple's peer group benchmarks follow the same logic with day-35 download-to-paid conversion and day-35 proceeds per download.

10. CAC and the LTV:CAC ratio

CAC (customer acquisition cost) is your acquisition spend in a period divided by the new users you gained in that period. Divide ad spend by paid users only and you get "paid CAC"; include organic users and you get "blended CAC."

A common rule of thumb for LTV:CAC is at least 3:1. If LTV is $50, as in the example above, any acquisition cost above roughly $16.70 per user breaks the rule. Below 1:1, every new user costs you money.

Measuring CAC by channel is harder on iOS. For users who don't grant App Tracking Transparency permission, ad attribution arrives aggregated and delayed. So evaluate campaigns at the channel and cohort level over a longer window, not user by user. We plan app install campaigns as part of our Google Ads service.

How to set up Firebase Analytics the right way

Firebase Analytics starts collecting events such as sessions, first opens and screen views as soon as you add the SDK. But the real value of mobile app analytics comes from the measurement plan you design, not from that automatic data.

First, get clear on what each tool measures:

For most small and mid-sized apps, Firebase Analytics, Crashlytics and the two store consoles are a solid starting stack. Set them up in this order:

Step 1: Start with questions. Write down 3–5 business questions, such as "Do users who sign up go on to create their first booking?" Every event should serve at least one question; events that serve none just create a data swamp.

Step 2: Build a tracking plan. Keep each event's name, trigger, parameters and owner in a single table:

Step 3: Know the limits up front. Google's event collection limits allow 500 distinct event names for app data streams, 25 parameters per event and 25 user properties per property. Event names can be up to 40 characters, user property names up to 24 and their values up to 36. Make snake_case naming a team standard.

Step 4: Never send personal data. Don't send email addresses, phone numbers or national ID numbers as event parameters or user properties. To match users, use a random internal ID from your own database.

Step 5: Validate with DebugView. On a test device, check that events arrive in the right order with the right parameters. Add this check to your pre-release QA; our app launch checklist tool helps you review these steps before you ship.

Step 6: Set data retention and link BigQuery. The Google Analytics data retention setting directly affects explorations and funnel reports. If it stays at 2 months, you can't run a three-month cohort analysis, so raise it to at least 14 months on standard properties. Daily export to BigQuery on standard properties is limited to 1 million events per day.

Step 7: Turn on Crashlytics in the same release. Collecting analytics and crash data from the same version lets you answer "Why did D7 drop?" release by release.

Step 8: Set a weekly review rhythm. Data only helps if someone looks at it on a schedule. Hold a 30-minute mobile app analytics review each week: check the latest cohorts' D1 and D7, the crash-free rate of the newest release and the biggest leak in your key funnel. Log every product change with its release date next to the metric you expect it to move. After a few months, that log becomes the most valuable mobile app analytics asset your team owns, because it links decisions to outcomes. Keep the meeting short and end it with one decision, one owner and one metric to watch next week.

If you want to see how analytics, crash reporting and an admin panel affect your project scope, try our app cost calculator.

Privacy: GDPR, ATT and store disclosures

Mobile app analytics data can include personal data. That makes the legal and store policy side of your setup as important as the technical side.

GDPR and ePrivacy. In the EU, Article 5(3) of the ePrivacy Directive allows storing or accessing information on a user's device only with consent, or when strictly necessary for a service the user asked for. The European Data Protection Board's Guidelines 2/2023, updated in October 2024, make clear that this rule covers "similar technologies," not just cookies. That includes an SDK instructing a device to send information already stored on it.

The practical approach: ask for analytics and advertising consent separately. Use Google's consent mode for apps to define default consent states, then update them with setConsent based on the user's choice. If you also serve users in Turkey, the KVKK cookie guidance follows similar logic. Review your consent texts with legal counsel, and see our mobile app security and data privacy guide for the bigger picture.

App Tracking Transparency. Apple's user privacy and data use page defines tracking as linking user or device data from your app with other companies' data for targeted advertising or advertising measurement, or sharing it with data brokers. Analytics that only measures usage of your own app, without combining data with other companies' data, falls outside that definition. The same page states that you can't gate features behind tracking permission, under App Review Guideline 5.1.2(i).

Store disclosures. Google Play's Data safety section requires you to declare data collected by SDKs in your app as if you collected it yourself. App Store privacy labels need the same care. Update these disclosures every time you add an analytics SDK.

Data-driven product decisions: 4 example scenarios

Mobile app analytics only creates value when it leads to a decision. The scenarios below are illustrative; each one traces the path from signal to decision to validation.

Scenario 1: A salon booking app loses users at SMS verification. The onboarding funnel shows the biggest drop at SMS verification. A breakdown reveals the loss concentrates on older Android devices and in the evening. The team adds Sign in with Google and Sign in with Apple and lets users browse as guests until they book. To validate, they compare activation and D7 for the two weeks after the change against the two weeks before.

Scenario 2: D7 drops after a new release. When retention cohorts are split by version, the drop appears only in the latest release. Crashlytics shows crashes clustering on a single Android phone model. With Google Play's 8% per-model threshold at risk, the team pauses feature work and ships a fix through a staged rollout. The success metric: crash-free users on that model return to the previous version's level.

Scenario 3: Low DAU/MAU, strong D30. A bill-tracking app shows low DAU/MAU but above-average D30 retention for its category. Users open the app a few times a month, around payment dates. Instead of pushing daily usage with notifications, the team switches its success metric to WAU/MAU and a "payment reminder delivered on time" event.

Scenario 4: Cheap installs, expensive users. Channel A delivers the lowest cost per install, but its cohorts have the weakest D7 retention and 90-day revenue. Channel B costs more per install, yet its LTV:CAC ratio is higher. The team reallocates budget by channel-level LTV:CAC instead of install cost.

All four scenarios teach the same lessons:

• Look at breakdowns, not averages: platform, version, channel and device.
• Validate every change against a metric and cohort comparison you chose in advance.
• Pick metrics that match the app's natural usage frequency.
• Write down what you expect before you look at the result, so the data has a chance to prove you wrong.

Frequently Asked Questions

Which tools should I start with for mobile app analytics?

For most apps, Firebase Analytics, Firebase Crashlytics, App Store Connect and Google Play Console together make a solid starting stack. Add a product analytics tool or a mobile measurement partner once you need ready-made cohort reports or ad attribution.

What is a good D1 retention rate?

According to Adjust's 2026 data, average D1 retention across all categories is 26%, with iOS at 27% and Android at 24%. The most useful target is beating the 50th percentile of your peer group in App Store Connect.

How do you calculate the DAU/MAU ratio?

Divide daily active users by monthly active users. An app with 3,000 DAU and 15,000 MAU has a 20% ratio, which means the typical monthly user opens the app about 6 days a month.

What is the difference between retention and churn?

Retention shows what share of a cohort is still active after a given period. Churn is the share of users or subscribers lost over that period, and for non-subscription apps it's the complement of the retention rate.

Is Firebase Analytics free?

Yes. Firebase's pricing page lists Analytics and Crashlytics as no-cost on both the free Spark plan and the pay-as-you-go Blaze plan. Querying your data in BigQuery is billed separately under BigQuery pricing, and Spark projects use the BigQuery sandbox limits.

Do I need user consent for an analytics SDK?

In the EU, an SDK that accesses information on the user's device generally requires consent under ePrivacy rules unless it's strictly necessary for the service. On iOS, analytics that only measures your own app and isn't combined with other companies' data doesn't require ATT permission.

When does a crash rate become a problem?

Google Play treats an app as crossing its bad behavior threshold when more than 1.09% of daily users hit a user-perceived crash over the last 28 days, or 8% on a single phone model. At that point, the app's store visibility may drop and users may see a warning on the listing.

Mobile app analytics isn't a reporting screen you bolt on after launch; it's an architecture decision you make at the start. When the tracking plan, event names and consent flow ship with the first release, all 10 metrics produce reliable data from day one.

Our mobile app development service includes analytics and crash reporting setup as a standard part of every project. To review the measurement setup of your existing app with us, get in touch.