Knowing What the App Does, and How It Pays
Two halves of the same question. Measurement tells you whether people keep the app and where they stop; monetisation decides whether that is a business. Both are far cheaper to design in than to bolt on afterwards.
Analytics Added Later Only Measures Later
The most expensive version of this work is the one that starts three months after launch, when everyone wants to know why people left and there is no record of anything they did.
A plan before the code
A short written list: the events, what each one means, the properties it carries, and the question it exists to answer. If an event has no question attached, it does not go in. This document takes an afternoon and saves months of arguing about what a number meant.
Names you can live with
One convention, applied everywhere, chosen once. Renaming events after launch splits your history in two, and merging them back is tedious work that produces a number nobody quite trusts afterwards.
Events get tested too
An event that fires twice, or fires on a screen that was never opened, is worse than no event at all because it is believed. They go through QA with the same seriousness as a feature, on real devices, before a release.
Collect less on purpose
Everything you record has to be declared on both stores, defended if anyone asks, and deleted when someone requests it. Fewer, better events make that straightforward. See security and privacy.
Offline sessions still count
Mobile analytics has to queue events on the device and send them when a connection returns, or your data quietly over-represents people with good signal and under-represents everyone on a train.
Version and device on everything
Nearly every interesting mobile question turns out to be about a version, an OS release or a class of handset. Without those properties attached, a strange drop in a chart is unexplainable.
The Events That Earn Their Place
Most apps need somewhere around a dozen, not two hundred. These are the ones that change decisions.
First open
The start of every curve, split by where the install came from and which version they landed on. Everything else is measured relative to this.
Activation
The moment the app became useful: the account connected, the first item added, the first result produced. Define it explicitly, because it is the number that predicts retention.
The core action
The thing the app exists to do, counted every time it happens. If you can only keep one event, keep this one.
Repeat use
Second session, then second week. A single visit means almost nothing; coming back is the whole product in one signal.
Paywall seen
Who reached it, from which screen, and on which day of their life in the app. Without this, purchase numbers have no denominator.
Purchase and renewal
Started, completed, failed, refunded, cancelled. Failures matter as much as successes and are routinely left untracked.
Permission decisions
Prompted, allowed, denied. A feature that quietly depends on a permission most people decline is a product problem hiding in plain sight.
Errors people feel
Failed logins, failed uploads, empty results, timeouts. None of these are crashes, and they are usually the reason somebody left.
Funnels Tell You Where. Retention Tells You Whether.
A funnel finds the step that loses people. A retention curve answers the more uncomfortable question of whether anyone wanted the app at all.
Activation
61%
Paywall reach
38%
Trial to paid
44%
Crash-free
99.5%
Illustrative panel showing the shape of the numbers we set up, with invented figures. It is not data from any real client app, and the values are not benchmarks — a healthy curve for a daily habit app looks nothing like a healthy curve for one people need twice a year.
What the three numbers mean
Day one is mostly about the first ninety seconds. People who never come back tomorrow usually never got to the point — the sign-up was too long, the permission prompt arrived too early, or the empty state explained nothing.
Day seven is about whether the app found a place in someone's week. This is where onboarding stops being the explanation and the product has to be the explanation.
Day thirty is the honest one. If the curve has flattened by then, you have a real set of users to build on and marketing is worth spending on. If it is still falling steadily towards zero, more installs simply refill a leaking bucket, and that is a product conversation rather than a growth one.
Alongside all of it sits the crash-free rate, because a curve that drops on one OS version or one class of handset is usually a stability problem wearing a product costume. That link is covered in testing and QA.
Where Each Install Came From: the Honest Version
Mobile attribution used to work roughly the way web analytics does. It does not any more, and a plan built on the old assumptions will produce confident numbers that are simply wrong.
What changed
- The per-device identifier that joined an advert to an install now requires explicit permission on iOS, and most people decline
- What replaced it reports in aggregate, with deliberate delay and coarse detail
- Results are withheld entirely below certain volumes, which hits small apps hardest
- Android is moving in the same direction, on its own timetable
- There is no cookie, no cross-app view, and no reliable path from a web page to an install
What still works
- Blended cost per install: total spend divided by total installs, unglamorous and hard to fool
- Holdout and regional tests, where you switch a channel off somewhere and watch what happens
- Before and after comparisons around a campaign, with the seasonality acknowledged
- A single question in onboarding asking where people heard about you, which is imprecise but directionally useful
- The store consoles, which report their own search and browse traffic independently of any advertising
The practical consequence: budget for channels you can test, not for a dashboard that claims to trace every install to a click. Anyone promising the latter is describing how mobile worked several years ago.
Four Ways an App Makes Money, and Who They Suit
Most apps end up with one primary model and at most one secondary. Running three at once mainly confuses the people you are asking to pay.
Subscription
Recurring payment for continuing value. Suits anything used repeatedly, anything with ongoing costs behind it, and anything that keeps improving. It is the strongest model available on mobile and the least forgiving, because every month the user gets to decide again.
One-off purchase
Pay once, own it. Honest, easy to explain, and increasingly rare because it funds no ongoing work. It still fits tools with a finished shape, single-purpose utilities and content someone buys once, and it avoids the churn treadmill entirely.
Freemium
A genuinely useful free tier with a paid layer above it. Works when the free version has a natural ceiling people run into by succeeding — more projects, more storage, more collaborators. Fails when the free tier is a demo dressed up as a product.
Advertising
Revenue from attention, which means it needs a lot of sessions from a lot of people. Suits games, content and daily habits. For most business and service apps it earns very little while costing you speed, battery, data declarations and control of your own screen.
Missing from this list on purpose: charging upfront for the download. It is a hard sell for an unknown app in a store full of free ones, and it gives people no way to try before they decide.
When to Ask for Money
The timing of the ask matters more than the price on the button. Too early and nobody knows why they would pay; too late and paying feels like a punishment for liking the app.
Tie it to a moment of value
The first result produced, the first document saved, the second session. A paywall that appears immediately after something worked is a completely different proposition from one that appears immediately after install.
Show one plan clearly
Three tiers and an annual toggle is a decision people postpone on a phone screen. A recommended option, a clear price, a clear renewal date and one secondary choice converts better than a pricing table borrowed from a website.
Say what happens next
Price, billing period, renewal date and how to cancel, before the purchase. Both stores require this and it is also simply what a person needs to know. Vague trial wording is a common rejection and a reliable source of refunds.
Trials for slow-burn value
If the point of the app takes more than a session to feel, a trial earns its keep. If the value is instant, a trial mostly delays the decision and adds a cancellation step.
Remind before you charge
A reminder near the end of a trial costs you a few cancellations and saves you chargebacks, angry reviews and store attention. It is also the difference between a customer and someone who felt tricked.
Restore purchases, always
New phone, reinstalled app, second device. If people cannot recover what they paid for in one tap, you get a support ticket and a one-star review, and on iOS the missing control is a rejection in its own right.
The Platform Takes a Cut, and It Changes Your Maths
Digital goods and services consumed inside an app go through the store payment system, and the store keeps a share of every transaction. That is not a detail to discover after pricing is set.
- Both stores take a meaningful percentage of in-app revenue, with reduced tiers for smaller developers and for longer-running subscriptions
- Rates, tiers and the rules around alternative payments change, and vary by region, so we confirm the current position rather than quoting a number that will age
- Physical goods and real-world services — delivery, bookings, tickets to a real event — use an ordinary payment processor with no store commission
- Which side of that line your product sits on is a scoping decision, because getting it wrong is one of the fastest routes to a rejection
- Payouts arrive on the platform schedule, net of commission, tax and currency conversion, which is a cash-flow fact worth modelling
- Refunds are granted by the store, not by you, so a refund rate belongs in the model from the start
What this means in practice
Price against what you keep, not what the customer pays. An app that needs a certain revenue per user has to clear the commission, the refund rate and the cost of serving that user before anything reaches you.
It also changes what is worth building. A model that only works at very high volume is a riskier bet on mobile than one that works with a few thousand committed subscribers, because the store keeps its share either way.
We work this through during scoping, with your numbers, before a paywall is designed — see how we price projects and the cost estimator.
When Advertising Is the Wrong Model
Ads look like free money because there is nothing to sell. They are not free, and the cost lands on the user experience you just paid to build.
Where ads do fit — a game, a content app, something opened several times a day — they fit well, and we build them in properly with frequency caps and a paid option to remove them. We just will not recommend them because they sound easier than asking for money.
The Pages Either Side of This One
App Store Optimisation
Getting the installs whose retention and revenue you are then measuring.
Learn moreBackend & APIs
Where subscription state, receipt validation and your event pipeline actually live.
Learn moreSupport Plans
Monthly reporting on the numbers above, and the work that follows from them.
Learn moreAnalytics and Money Questions
What should we actually measure in the first version?
Far less than most dashboards suggest. For a first release we instrument the moment someone finishes onboarding, the moment they complete the core action the app exists for, whether they come back the next day and the following week, the steps of any funnel that ends in money, and the errors that stop people finishing something. That is usually somewhere around ten to fifteen events. Tracking every tap produces a dashboard nobody opens and a privacy declaration that is harder to defend, and it makes the events that matter harder to find rather than easier.
What is a good day-seven retention number?
There is no honest universal figure, and anyone who quotes one without asking what your app does is selling something. A daily habit app, a weekly delivery app and a tool people need twice a year have completely different shapes, and a good number for one would be a disaster for another. What is useful is the curve rather than the point: whether it flattens at all, and where. A curve that flattens means you have a group of people who genuinely kept the app, and that group is what you grow. A curve that keeps falling towards zero means acquiring more users just refills a leaking bucket.
Can you tell us which advert brought in each install?
Not the way web analytics does, and it is better to know that before you plan a budget around it. Platform privacy changes have removed the per-device identifier that used to join an advert to an install for most users, and what replaced it is deliberately aggregated, delayed and withheld below certain volumes. On iOS this depends on whether people agree to tracking at all, and most do not. So we build the measurement plan around what still works: comparing periods when a campaign ran with periods when it did not, holdout and regional tests, blended cost per install across all spend, and a simple question in onboarding asking where people heard about you.
Where should the paywall go?
After the user has felt something work, and before they have got the whole thing for nothing. A paywall on first launch converts a small number of people who already knew they wanted it and turns away everyone who was curious. A paywall that never appears until month three trains people to expect a free product. The placement that works is tied to a moment of value: the first result produced, the first document saved, the second session. It is also one of the few things genuinely worth testing, because the right answer varies by app and is rarely the one anyone guessed.
Should we offer a free trial?
Usually, for a subscription, if the value takes more than one session to become obvious. A trial converts curiosity into a habit and gives you a strong signal early. What matters is the honesty of the mechanics: state the price, the length and the renewal date before anyone starts, make cancelling easy to find, and send a reminder before the charge lands. Trials that rely on people forgetting produce refunds, chargebacks, one-star reviews and store scrutiny, and they poison the retention data you were trying to gather.
Can we just make money from ads instead of charging?
Only if you have a lot of users who open the app very often, and most apps do not. Advertising revenue is roughly a function of sessions and attention, so it suits daily-habit products, games and content apps, and it suits almost nothing else. It also has costs people underestimate: ad SDKs collect data you then have to declare, they add weight and battery drain, they slow your interface, and they hand part of your user experience to a network you do not control. For a business tool or a paid service, one small subscription from a user who values the app usually beats months of impressions from one who does not.
Work Out the Numbers Before the Build
Tell us what the app does and how you expect it to earn. You get back an event plan, a monetisation recommendation and the honest version of what you will be able to measure.