App Analytics: What Metrics Actually Matter for Business Growth

Most app dashboards are full of numbers that look important and change nothing.

Downloads go up after a campaign, session counts rise after a push notification, and everyone feels good for a week. Then revenue stays flat, and nobody can say why.

The metrics that actually drive business growth are a much shorter list. They answer five questions in order. Are you acquiring the right users at a sustainable cost? Do new users reach the moment where the app proves its value? Do they come back? Do they pay, directly or indirectly? And is the app reliable enough not to drive them away? Retention sits at the centre of all of this, because without it, every other number eventually collapses.

This guide explains which metrics matter at each stage, how to calculate and interpret them, what good looks like, where the common traps are and how to set up tracking you can trust. It is written for founders, product owners and business leaders who commission or run apps, not only for analysts.

Why most app dashboards mislead

The trouble with many analytics setups is not a lack of data. It is that the easiest numbers to collect are often the least useful for decisions.

Total downloads is the classic example. It only ever goes up, it says nothing about whether anyone still uses the app, and it can be inflated by a single paid campaign that brings in people who leave within a day. Total registered users has the same problem. Page views, screen views and raw session counts can rise because of a confusing interface that forces people to tap around looking for what they need.

These are often called vanity metrics. The test for any metric is simple: if it moved sharply tomorrow, would you know what to do differently? If the answer is no, it belongs in the background, not on the main dashboard.

Useful metrics have three features. They reflect real value to the user, such as completing a booking, finishing a workout or sending a message. They are expressed as rates or ratios rather than totals, so they can be compared over time and between groups. And they connect, directly or through a clear chain of reasoning, to revenue or another business outcome you care about.

Start with a North Star and a simple metric hierarchy

Before choosing individual metrics, decide what single measure best captures the value your app delivers. Product teams often call this a North Star metric. It should describe value received by users, and it should be something that, if it grows steadily, makes business growth very likely.

For a food delivery app, it might be weekly orders completed. For a fitness app, weekly workouts finished. For a B2B field service app, jobs completed through the app each week. Notice that none of these is downloads or revenue. Revenue is the result; the North Star is the behaviour that produces it.

Beneath the North Star sit a handful of input metrics that teams can influence directly. These usually map to the user journey: acquisition, activation, engagement, retention and monetisation, with app quality underpinning all of them. Some teams use frameworks such as AARRR (acquisition, activation, retention, referral, revenue). The labels matter less than the logic. Each input metric should have a clear owner and a plausible link to the North Star.

A practical hierarchy for most businesses has one North Star, four to six input metrics and a set of diagnostic metrics that you investigate when something changes but do not report every week. Keeping the top of the hierarchy small forces focus, while the diagnostic layer gives you somewhere to look when the numbers move.

Acquisition metrics that matter

Acquisition metrics tell you how people find and install your app, and what it costs to bring them in. The key is to judge acquisition by the quality of users it brings, not the quantity of installs.

Cost per install and, more importantly, cost per activated user

Cost per install (CPI) is total acquisition spend divided by installs from that spend. It is useful for comparing ad channels, but it can be badly misleading on its own. A channel that delivers installs at half the price is no bargain if those users never open the app a second time.

A better measure is cost per activated user, or customer acquisition cost (CAC) where you measure cost per paying customer. This divides spend by the number of users who reach your activation milestone (covered in the next section) or make a first purchase. It shifts attention from cheap installs to valuable users.

Store conversion rate

Your app's product page on the Apple App Store or Google Play is a landing page, and its conversion rate, the share of page visitors who install, deserves the same attention you would give a website's checkout. Both App Store Connect and the Google Play Console report this. Screenshots, the first lines of the description, ratings and reviews all affect it. Both stores also let you test product page variations, through product page optimisation in App Store Connect and store listing experiments in Google Play.

Organic versus paid mix

Track how many new users arrive organically, through search, browsing, referrals and word of mouth, versus through paid campaigns. A healthy, growing share of organic users is one of the strongest signs that an app is delivering value. If growth depends entirely on paid acquisition, your unit economics need to work at the paid cost, with no room for error.

A note on attribution after App Tracking Transparency

Since Apple introduced App Tracking Transparency with iOS 14.5 in 2021, apps must ask permission before tracking users across other companies' apps and websites, and many users decline. This made user-level attribution of iOS campaigns much harder. Advertisers now rely heavily on Apple's privacy-preserving frameworks, SKAdNetwork and its successor AdAttributionKit, which report aggregated and delayed conversion data, together with modelling and incrementality testing.

The practical consequence is that you should treat channel-level iOS attribution as an estimate rather than a precise figure. Watch blended metrics, such as total spend divided by total new activated users across all sources, alongside channel reports. If blended CAC rises while individual channels report improvement, trust the blended number. (Internal link suggestion: a guide to app store optimisation or mobile app marketing.)

Activation and onboarding: the metrics most teams overlook

Activation is the point where a new user first experiences the core value of your app. It is arguably the most underused metric in mobile analytics, and improving it often lifts retention and revenue more than any acquisition campaign.

Define your activation event

Activation is specific to each app. For a messaging app, it might be sending a first message to a real contact. For a banking app, linking an account and viewing a balance. For a meditation app, completing a first session. For a marketplace, making or receiving a first offer.

The best way to choose is to look at your data. Compare users who are still active after 30 days with those who left, and look for early actions that the retained group took far more often. The action that best separates the two groups, within a short time of installing, is a strong candidate. Be cautious about cause and effect: the action may simply indicate users who were already more motivated. Test it by changing onboarding to encourage the action and checking whether retention actually improves.

Activation rate and time to value

Activation rate is the percentage of new users who complete the activation event within a set window, such as the first day or first seven days. Time to value is how long it takes them to get there. Shortening that time, by removing unnecessary sign-up steps, asking for permissions only when needed or pre-filling sensible defaults, often has a direct effect on how many users stay.

Onboarding funnel drop-off

Break onboarding into steps, such as app opened, account created, permissions granted, profile completed and first core action, and measure the drop-off between each. A sharp fall at one step is a clear signal. A common example is asking for notification or location permission before users understand why the app needs it.

Engagement metrics: measuring use that reflects value

Engagement tells you how often and how deeply people use your app once they are on board. The main risk here is confusing activity with value.

Active users and stickiness

Daily, weekly and monthly active users (DAU, WAU and MAU) count unique users who did something meaningful in a period. The word "meaningful" matters. Counting anyone who opened the app, including people who tapped a notification and immediately closed it, inflates the figure. Define an active user by a real action where you can.

Stickiness is commonly measured as DAU divided by MAU. A ratio of 0.25 means the average monthly user is active on roughly a quarter of days, or about one day a week. Social and messaging apps often aim for very high ratios, while many useful apps are naturally used less often. A travel booking app or a home insurance app should not expect daily use, and pushing for it can harm the experience. For less frequent apps, WAU/MAU or a measure based on your natural usage cycle is more meaningful.

Frequency and depth of core actions

Rather than session length, which can rise because users are struggling, look at how often users complete core actions. Orders per active customer per month, workouts per week or documents created per user all reflect value delivered. Plot the distribution as well as the average. A small group of power users can hide the fact that most people barely use the app.

Feature adoption

Feature adoption measures the share of active users who use a particular feature within a period. It is especially useful after a release, to check whether a new feature is being found and used, and over time, to identify features that few people use and that could be simplified or removed. Combine it with retention data: features whose users retain much better than average are good candidates for more prominent placement in onboarding.

Engagement metrics are most useful when they are read alongside retention. Rising engagement among a shrinking group of users is not growth.

Retention: the metric that decides whether an app grows

If you track only one group of metrics properly, make it retention. It tells you whether users find enough value to keep coming back, and it determines how much every other investment is worth. Acquisition spent on users who leave within a week is largely wasted. Improvements in engagement or monetisation matter far more when they apply to users who stay.

The business case is long established. Research by Frederick Reichheld of Bain & Company, widely cited since, found that increasing customer retention by five percentage points could increase profits by 25 to 95 percent, depending on the industry. The figures came from service businesses rather than apps, but the underlying logic, that keeping customers is far cheaper than replacing them, applies strongly to mobile.

Why retention is hard

Most apps lose the majority of their new users quickly. Industry benchmark reports from mobile measurement companies such as Adjust and AppsFlyer have consistently shown average day-one retention in the region of a quarter of new users, falling to single digits by day 30, with large variations by category and platform. A widely shared analysis published by growth advisor Andrew Chen, based on data from the analytics company Quettra, found that the average app lost most of its daily active users within the first three days after install.

These benchmarks are useful for perspective, but not as targets. Your own retention trend, and how it compares across user groups, is far more important than an industry average that mixes games, utilities and shopping apps.

Measure retention in cohorts

A cohort is a group of users who started in the same period, for example everyone who installed during a given week. Cohort retention shows the percentage of each group still active after one day, seven days, 30 days and so on. Laid out as a table or heat map, it shows whether newer cohorts retain better than older ones. That tells you whether product changes are working, in a way an overall active user count cannot.

It also helps to choose the right type of retention. Classic or "N-day" retention counts users active on exactly a given day. Range or "bracket" retention counts users active at any point within a period, such as week four, which suits apps that are not used daily. Pick one definition and keep it consistent.

Look for the curve to flatten

The shape of the retention curve matters more than any single point. Almost every curve drops steeply at first. What you want to see is the curve flattening at some level above zero, meaning a core group of users has found lasting value. Many product teams treat a flattening retention curve as one of the clearest signs of product-market fit. A curve that keeps sloping towards zero suggests that users are trying the app and drifting away, and that more acquisition will not fix the problem.

Segment retention by acquisition channel, device, country and whether users completed the activation event. The differences often point directly to what needs to change.

Monetisation metrics: connecting usage to revenue

How you measure monetisation depends on how your app makes money, whether through subscriptions, in-app purchases, advertising, transactions or indirectly by supporting a wider business. A few metrics apply almost everywhere.

Average revenue per user and per paying user

Average revenue per user (ARPU) divides total revenue in a period by active users in that period. Average revenue per paying user (ARPPU) divides it only by those who paid. Watching both shows whether growth comes from more people paying or from existing payers paying more. Calculate them for a consistent period, usually a month, and note whether you are using revenue before or after app store commission, because the difference is substantial.

Conversion to paid

For subscription and freemium apps, the share of users who start paying, and how long it takes, is central. Track trial start rate, trial-to-paid conversion and the time from install to first payment. Small changes to paywall design, trial length or the moment the offer appears can have large effects, so this is a good area for controlled experiments.

Churn and subscription retention

Subscription churn is the share of paying subscribers who cancel or fail to renew in a period. Separate voluntary churn, where users choose to cancel, from involuntary churn, caused by failed payments. Involuntary churn is often fixable with billing retry and grace period features, which both Apple and Google offer for subscriptions.

Lifetime value and its ratio to acquisition cost

Customer lifetime value (LTV) estimates the total revenue, or ideally gross profit, a user generates over their relationship with your app. A simple version multiplies ARPU by the average lifetime in months, but because lifetimes are uncertain for young apps, many teams use LTV at a fixed horizon, such as revenue per user within 90 or 180 days of install.

LTV only becomes useful when compared with acquisition cost. A ratio of LTV to CAC of around three to one is a common rule of thumb for a healthy business, with payback, the time it takes to recover acquisition cost, also watched closely. Treat these as guides rather than laws. A business with strong cash reserves may accept slower payback to grow faster, while a bootstrapped business may need payback within a few months.

When the app supports another business

Many businesses run apps that do not earn money directly, such as a retailer's shopping app, a bank's mobile app or a utility's account app. Here, monetisation metrics should capture the value the app creates elsewhere: share of orders placed through the app, average order value of app users compared with web users, reduction in call centre contacts, or retention of app users compared with non-users. Be careful with comparisons between app users and non-users, because loyal customers are more likely to download an app in the first place. Comparing the same customers before and after they adopt the app is more reliable.

App quality and performance metrics

Technical quality is easy to treat as an engineering concern, separate from growth. In practice, crashes, freezes and slow screens are among the fastest ways to lose users, and they also affect how visible your app is in the stores.

Crash-free users and sessions

Crash-free users is the percentage of users who did not experience a crash in a period. Crash-free sessions is the equivalent for sessions. Tools such as Firebase Crashlytics, Sentry and the stores' own consoles report these. Many mature apps aim for crash-free rates well above 99 percent, but the right target depends on the complexity of the app and its user base.

Google Play's Android vitals thresholds

Google Play is explicit about how quality affects visibility. Through Android vitals in the Play Console, it reports a user-perceived crash rate and a user-perceived ANR ("application not responding") rate. Google has set bad behaviour thresholds for these: an overall user-perceived crash rate of 1.09 percent and an ANR rate of 0.47 percent, with stricter per-device thresholds. Apps that exceed them may be less discoverable on Google Play and can show warnings to users on affected devices. Check the current thresholds in Google's documentation, but this is a clear case where a technical metric directly affects acquisition.

Startup time and responsiveness

How long the app takes to open, particularly from a cold start, and how quickly key screens load both shape first impressions. Android vitals reports slow startup, and Xcode Organizer provides launch time and hang rate data for iOS apps. Track the slowest users, not just the average, because performance on older devices and poor connections is often much worse.

Ratings and reviews

Store ratings combine perceptions of quality and value, and they influence conversion on your store page. Track your average rating for recent versions rather than the lifetime figure, and read reviews for recurring themes. A sudden drop in rating after a release is often the quickest signal that something has gone wrong. Both stores allow you to prompt users for a rating inside the app through their official review APIs, within limits.

For apps with significant traffic, tying quality metrics to business outcomes is persuasive. For example, compare the retention of users who experienced a crash in their first week with those who did not. The gap usually makes the case for stability work better than any engineering argument. (Internal link suggestion: an article on mobile app performance optimisation or app maintenance and support.)

Matching metrics to your type of app

The same metric can mean very different things depending on the app. A daily habit app and a once-a-year tax app should not be judged by the same engagement standard. The table below suggests where to focus for common types of app.

App type

Example North Star

Metrics that deserve extra weight

E-commerce or retail

Weekly orders placed in app

Conversion rate, average order value, repeat purchase rate

Subscription content or fitness

Weekly active subscribers completing core sessions

Trial-to-paid conversion, subscriber churn, session frequency

Marketplace or on-demand

Completed transactions per week

Liquidity (requests matched), supply and demand retention, time to match

B2B or field service

Tasks completed through the app per week

Activation by account, seat usage, workflow completion time

Companion app for an existing business

Share of customer interactions handled in app

Adoption among existing customers, support contacts avoided, retention uplift

Utility or infrequent-use app

Successful completions per active user

Task success rate, time to complete, rating, retention over the natural usage cycle

Use the table as a starting point rather than a rule. The most reliable way to choose is to ask what behaviour, repeated over time, creates value for your users and revenue for your business, and then measure that behaviour as directly as you can.

Building a measurement setup you can trust

The best metric framework is useless if the underlying data is incomplete or inconsistent. Most analytics problems trace back to tracking that was added piece by piece, by different people, without a shared plan.

Write a tracking plan first

A tracking plan is a document, often a simple spreadsheet, listing every event the app records, when it fires, the properties attached to it and which metric it supports. For example, an event called order_completed might carry properties for order value, currency, number of items and payment method. Agree on naming conventions, such as lowercase words separated by underscores, and stick to them across iOS, Android and web. Inconsistent names, such as "Purchase", "purchase_complete" and "order_done" for the same action, are one of the most common reasons reports disagree.

Start with the events needed for your North Star and input metrics, and add others only when there is a clear question to answer. Tracking everything "just in case" creates cost, clutter and privacy risk.

Choose tools that fit your stage

Most apps use a combination of tools. Google Analytics for Firebase is free and widely used for event tracking. Product analytics platforms such as Amplitude, Mixpanel and PostHog specialise in funnels, cohorts and retention analysis. Mobile measurement partners such as AppsFlyer, Adjust and Branch handle attribution for marketing campaigns. Crash reporting tools cover stability, and App Store Connect and the Google Play Console provide store-level data that no third-party tool can fully replace.

For an early-stage app, one product analytics tool, crash reporting and the store consoles are usually enough. Add attribution tools when paid acquisition becomes a significant spend.

Build privacy in from the start

Analytics data is often personal data. Under laws such as the UK GDPR and the EU GDPR, you need a lawful basis for collecting it and must explain it clearly in your privacy notice, and in many cases you need consent before using non-essential tracking. Both app stores also require you to disclose data collection: Apple through App Privacy details on the App Store, and Google through the Data safety section on Google Play. These disclosures must cover third-party SDKs too, so review what each analytics tool collects.

Good practice is to collect only what you need, avoid sending names, email addresses or other directly identifying information to analytics tools, set sensible retention periods and give users meaningful choices. This protects users and also protects data quality, because opt-outs handled properly are easier to account for than tracking that is later found to be non-compliant.

Check the data regularly

Before every significant release, test that key events still fire correctly on both platforms. Compare analytics figures with source systems now and then, for example orders in your analytics tool against orders in your back-end database. Small discrepancies are normal, but a sudden gap usually means something has broken.

If you are planning a new app or a significant rebuild, it is much easier to design analytics into the product than to retrofit it later. Asking your development team or partner for a tracking plan alongside the technical specification is a simple way to make sure the app launches with the data you need. (Internal link suggestion: a mobile app development services page or a guide to planning a mobile app project.)

Common app analytics mistakes

Celebrating downloads while retention falls. A spike in installs from a campaign or a store feature can hide the fact that each new cohort is retaining worse than the last. Always read acquisition alongside cohort retention.

Reporting averages without distributions. Average session length or revenue per user can be driven by a small group of heavy users. Look at medians and percentiles, and segment by user type, before drawing conclusions.

Changing definitions quietly. If the definition of an active user or a retained user changes, historical comparisons break. Document every metric definition and note any change on dashboards.

Treating correlation as cause. Users who turn on notifications or use a particular feature may retain better because they were already more engaged. Use controlled experiments, such as A/B tests, before investing heavily on the strength of a correlation.

Ignoring platform differences. iOS and Android users often behave differently, and tracking can differ between the two builds. Compare platforms separately before combining them.

Running too few, too short experiments. An A/B test stopped after two days, or run on a small number of users, can produce misleading results. Decide the sample size and duration in advance, and include a full weekly cycle where usage varies by day.

Building dashboards nobody uses. A dashboard with forty charts is rarely read. A short weekly review of the North Star and its input metrics, with a named owner for each, drives far more action.