How to Measure App Success: The KPIs That Actually Matter

An app with 40,000 downloads and 600 monthly active users is a failed app with a good marketing budget. An app with 4,000 downloads and 2,100 monthly active users who transact weekly is a working business asset. The download number is the one that gets quoted in meetings, and it is the least informative number available.

This guide sets out how a Nigerian business should measure a mobile app across its whole lifecycle: what to instrument before launch, which numbers to review weekly versus monthly, how retention curves should be read, which technical metrics quietly destroy a good product, and how device and data realities in Nigeria change the interpretation of standard benchmarks.

What app success means, and why downloads are not it

An app is successful when a defined group of users performs a defined action often enough to justify the cost of building and running it. That sentence contains three variables you must fix before launch: who the users are, what the action is, and how often is enough.

For a retail app the action might be "places an order at least once a month". For a logistics app it might be "a driver completes a delivery confirmation on every trip". For an internal operations app it might be "field officers submit reports the same day rather than at week's end". Each produces a different metric set.

Downloads fail as a success measure for three reasons:

• They measure intent, not value. Someone tapping install has committed nothing.
• They are easy to buy. Paid installs can be acquired cheaply and almost never retain.
• They are cumulative. A download from eighteen months ago still counts in your total even if the user deleted the app the same day.

The honest version of a download report is a retention cohort. Everything else is a press release.

The app success funnel: install, activate, retain, transact

Measure your app as a four-stage funnel. Most apps lose the majority of users at the second stage, and most teams spend their money on the first.

Stage 1 — Install. The user downloads the app. Measure store listing views, install conversion rate from the store page, and cost per install if you are running ads.

Stage 2 — Activation. The user reaches the first moment of value: account created, first search completed, first item added, first report submitted. Define activation as a single event and measure the share of installs that reach it within 24 hours.

Stage 3 — Retention. The user comes back. Measure day-1, day-7 and day-30 retention by weekly cohort.

Stage 4 — Transaction or core action. The user does the thing the app exists for. Measure frequency per active user, not just totals.

Where Nigerian apps usually lose people

The core app KPIs and how to calculate them

Keep the list short. These nine cover almost every business app.

Add cost per install and cost per activated user if you are spending on acquisition. The gap between those two numbers is usually the most revealing figure in any app marketing review.

The 40–80 word version for your board pack

App health is the product of three ratios: how many installers become activated users, how many activated users are still active thirty days later, and how much value each active user produces per month. Improve any one of those ratios and every downstream number improves with it. Downloads sit outside this chain entirely.

Retention: the metric that decides whether the app survives

Retention is the only metric that compounds. An app with weak retention needs constant paid acquisition simply to stand still, which means marketing spend becomes a permanent operating cost rather than an investment.

Read retention as a curve, not a single number:

• A curve that drops and flattens is healthy. A flat tail means a core group has found real value. The height of the flat part is your true addressable base.
• A curve that drops to near zero means the app has no repeat use case. More marketing will not fix this. Either the product needs a reason to return, or the business should have built a mobile website instead.
• A curve that rises after a dip usually means notifications, a restock, or a seasonal cycle is pulling users back. Identify the trigger and make it deliberate.

Always measure retention by cohort, meaning the group of users who installed in the same week. Aggregate retention across all users mixes new and old behaviour and hides deterioration after a bad release.

How often should you review retention?

Weekly for the first three months after launch, then monthly. Retention problems are cheapest to fix in the first quarter, while the team still remembers the code and the product decisions are still reversible.

Technical health metrics that quietly kill good apps

Business owners rarely look at these, and they are frequently the reason an otherwise sensible app fails.

• Crash-free session rate. Track it per app version and per device model. A crash affecting one popular budget Android model can quietly remove a large slice of your users.
• Cold start time. How long from tap to usable screen. Anything above a few seconds on a mid-range device will cost you activation.
• App size. Larger apps see more abandoned installs and more uninstalls when storage runs low.
• Failed network request rate. Measure API errors and timeouts. On intermittent connections this number is far higher than teams assume.
• Screen load times for the three most used screens. Not the average across all screens, which hides the problem.
• Permission grant rate. If most users decline notification permission, your retention plan needs rethinking.
• Update adoption rate. If users stay on old versions, your fixes are not reaching them; consider forcing updates for critical releases.

What changes when you measure apps in Nigeria

Standard app benchmarks are drawn from markets with different devices, data costs and payment behaviour. Five adjustments matter.

Android dominates, and the low end matters most. Your performance testing and crash monitoring should be weighted towards budget and mid-range Android devices, not the flagship phone on the product manager's desk. Segment retention by device tier; a gap there is a technical problem, not a product problem.

Storage pressure causes uninstalls that have nothing to do with your product. Phones fill up, and rarely used apps are deleted first. Keeping the app small and giving users a genuine weekly reason to open it is a direct defence.

Data cost shapes session behaviour. Users may open the app on Wi-Fi and abandon it on mobile data. Measure session length and completion rate by connection type if your analytics tool supports it, and cache aggressively so a returning user is not re-downloading images.

OTP and verification are a real funnel stage. SMS delivery is not guaranteed or instant. Track the share of users who request an OTP but never complete verification; in many Nigerian apps this is the single largest activation leak.

Payment success is a measurable KPI, not a background detail. Track attempted versus successful payments by method. Cards, bank transfer and USSD behave differently, and your payment provider's dashboard will show the split. An app with a 3-in-10 payment failure rate has a revenue problem masquerading as a conversion problem.

Referral happens on WhatsApp. Much of Nigerian app growth is word of mouth in group chats. Use a share link with a trackable parameter so organic referral is visible rather than lumped into "direct".

How to set up app measurement before launch

Instrumentation added after launch is always incomplete, because you cannot retroactively collect data on the users who already left.

1. Write the success sentence. Who, what action, how often.
2. Define the activation event. One event. Write it down and do not change it for six months.
3. List 15 to 25 events worth tracking. Screen views for key screens, sign-up started and completed, search performed, item added, checkout started, payment attempted, payment succeeded, notification opened.
4. Choose an analytics tool and install it in development first. Verify every event fires correctly on a real device before the build goes to the stores.
5. Add crash reporting. Non-negotiable. Configure alerting so a spike after a release reaches someone the same day.
6. Tag acquisition sources. Use store campaign parameters and trackable referral links so you can tell paid installs from organic.
7. Connect app data to your business records. Link a user ID to the customer record in your CRM or order database. Without this you cannot measure revenue per user.
8. Build the dashboard before launch. If the first version of the report is produced two months after launch, the launch cohort is already lost.
9. Set alert thresholds. Crash-free rate below a set level, payment failure above a set level, day-1 retention below a set level.

Pre-launch measurement checklist

• Activation event defined and agreed by product and business owners
• All key events firing and verified on a physical Android device
• Crash reporting live with alerting configured
• Store listing analytics accessible to the team
• Acquisition sources tagged
• Payment attempt and success tracked separately
• User ID linked between app and business database
• Privacy notice and consent handling reviewed against the Nigeria Data Protection Act 2023
• Weekly review meeting scheduled for the first twelve weeks

What app analytics and measurement cost

Indicative 2026 figures; verify current vendor pricing and store fees before budgeting.

App maintenance overall typically runs at 15% to 25% of the original build cost per year, and measurement work usually sits inside that budget rather than beside it.

Example (hypothetical): a Lagos pharmacy chain's ordering app

Illustrative scenario, not a client result.

A pharmacy chain with nine branches built an ordering app for roughly ₦7,000,000. After four months the board saw 11,300 downloads and considered the project a success. The operations director asked for a proper measurement review.

What the numbers showed:

• Install-to-activation was 22%. Most users never completed sign-up.
• The OTP step accounted for the majority of that loss: 41% of users who requested a code never entered one.
• Day-30 retention for the launch cohorts was 7%, with the curve falling to near zero rather than flattening.
• Monthly active users were 780 against 11,300 downloads.
• Crash-free session rate was 94% overall, but 81% on two common budget Android models.
• Payment success was 68%, with most failures on card attempts.

Three changes followed: browsing without an account, a second OTP delivery route with a voice fallback, and bank transfer plus USSD added at checkout. The team also fixed the crash affecting the two device models.

Within the next two quarters the meaningful movement was in activation and monthly actives, not downloads. That is the point. The chain stopped reporting downloads to the board and reported three numbers instead: activated users, monthly active users, and orders per active user.

The monthly app scorecard

Mistakes to avoid

• Reporting cumulative downloads. It is a number that can only go up, which makes it useless as a management signal.
• Measuring aggregate retention instead of cohorts. Aggregate retention hides the effect of a bad release for months.
• Defining activation loosely. "Opened the app twice" is not activation. Pick the event that represents real value.
• Instrumenting after launch. You permanently lose the data on your earliest users, who are usually your most informative ones.
• Ignoring store reviews as data. Recurring complaints in Play Store reviews are free, specific bug reports.
• Treating notifications as a retention strategy. Notifications bring users back to an app that already has value. They cannot create value.
• Comparing your numbers to foreign benchmarks. Device mix, data costs and payment methods differ enough to make most imported benchmarks misleading.
• Building an app when a mobile website was the right answer. If the use case is infrequent, retention will never form, and no amount of measurement will change that.

Conclusion

Measuring an app well is mostly a matter of refusing to be impressed by the wrong number. Downloads are marketing output. Activation, retention and core actions per user are business outcomes, and they are the only ones that tell you whether to invest more, fix something specific, or stop.

Decide your activation event before launch, instrument the funnel properly, read retention by cohort, and watch crash rates on the budget Android devices your customers actually carry. Review weekly for a quarter, then monthly. If the curve flattens and core actions per user hold steady, you have a real product. If it does not, the answer is a product change, not a bigger marketing budget.

If you are planning an app build and want measurement designed in from the start, or you have a live app whose numbers do not add up, Linestech can help specify the event tracking, fix the funnel leaks and set up reporting your management team can act on.

Frequently asked questions

What is a realistic retention rate for a Nigerian business app?

There is no dependable published figure to quote, and specific percentages offered without a source should be treated carefully. Judge your app against its own weekly cohorts instead. The more useful question is the shape of the curve: if day-30 retention flattens rather than falling to zero, you have a core of genuine users to build on.

How many events should we track in an app?

Between 15 and 25 well-chosen events covers most business apps. Tracking 200 events produces dashboards nobody reads and slows the app down. Start with the funnel stages, the core action, payment attempts and errors, then add events only when a specific question arises.

Should I measure an internal staff app the same way?

Partly. Installs and store metrics are irrelevant, but activation, daily active users as a share of staff, task completion rate and error rate all apply. The business KPI becomes process time saved or data quality improved rather than revenue.

Why do my monthly active users keep falling even though downloads rise?

Because new installs are replacing departing users rather than adding to them. This is the classic signature of weak retention. Stop increasing acquisition spend until day-7 and day-30 retention improve, otherwise you are paying to fill a leaking bucket.

How do I measure whether the app reduced costs rather than increased sales?

Define the manual process the app replaced, measure its cost before launch in hours and naira, then measure the same process after. Track adoption alongside it, since a cost saving only materialises if staff actually stop using the old method.

Do app store ratings affect success?

They affect install conversion from the store listing, which is a measurable funnel stage. Track your store listing view-to-install rate before and after a run of poor reviews. Respond to reviews, since visible responses influence how new visitors read the listing.

When should we decide an app has failed?

After two honest improvement cycles, usually six to nine months. If activation and day-30 retention have not moved after fixing onboarding, performance and payments, the problem is the use case rather than the execution. Redirect the budget to a mobile-optimised web experience or to the workflow the business actually needs.

Can I measure app success without a developer?

You can read the numbers without one, but you cannot collect them correctly without engineering work. Event instrumentation, crash reporting and user ID linking all have to be built into the app. Specify them in the development contract rather than requesting them later.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Act 2023 — NDPC
• Apple Developer Program
• Google Play Console
• Firebase documentation
• Baymard Institute e-commerce UX research