A subscription app is ready for paid acquisition when it can learn something from the spend, and ready to scale paid acquisition when it can make money from it. Those are two different bars. To buy paid traffic for learning, you need a stable app, onboarding you can measure step by step, events that reach Meta correctly, a few distinct creative concepts and a capped budget you can afford to lose. To scale for profit you also need measured install-to-trial and trial-to-paid rates, first renewals on real cohorts, a net value per payer after store fees, enough budget to optimise for trials or purchases, and the cash to wait for cohorts to mature. The checklist below scores both.
Most readiness advice treats this as a single yes or no, which is why founders either spend too early and conclude "paid doesn't work for us", or wait for certainty that only paid traffic can give them. Separating the two questions fixes both mistakes. It also changes what you should expect a first test to tell you, which is the part most teams get wrong.
Key takeaways
- Paid traffic for learning and paid traffic for profitable scale need different evidence. Score them separately.
- Three checks are non-negotiable even for a learning test: stability, step-by-step onboarding tracking, and events that reach Meta.
- A small test measures the top of the funnel well, the middle roughly and renewal not at all. Plan it around the question it can answer.
- Scale waits for net value per payer. Without it there is no maximum CPI, and without a maximum CPI there is no way to know whether a campaign is working.
- Readiness is not fixed. Most of the checklist can be improved while a learning test runs.
Paid traffic for learning versus paid traffic for scale
Paid traffic for learning is spend whose purpose is information: which promise makes the right people install, where they drop out of onboarding, whether they start trials at a rate close to your organic users. It is judged on what it teaches you, has a fixed budget set in advance, and is not expected to pay back.
Paid traffic for profitable scale is spend whose purpose is revenue. It is judged on whether each cohort earns back what it cost within a window you can fund, and its budget rises only while that holds.
The confusion between the two does real damage. A team that runs a learning test and judges it on return on ad spend will almost always conclude that paid acquisition failed, because a test that size was never going to show a return in the time they gave it. A team that scales without the evidence in the right-hand column of the checklist is spending on a number it has never measured.
A learning budget is research spend, judged on the questions it answers. A scaling budget is investment, judged on cohort payback. Mixing up the two is the most common reason subscription apps decide too early that paid acquisition does not work for them.
The 12-point readiness checklist
Each check has two bars. The middle column is what you need before buying paid traffic to learn. The right-hand column is what you need before scaling it for profit. The sections after the table explain the checks that most often trip teams up.
| # | Check | Enough to buy learning traffic | Needed before scaling for profit |
|---|---|---|---|
| 1 | People who found the app on their own come back | You can name who the app is for, and some unpaid users return without being prompted. | Organic subscribers renew past their first billing cycle at a rate you can build a business on. |
| 2 | The app is stable | No crashes on the path from first open to paywall. On Android, below Google Play's bad behaviour threshold. | Stable on the devices and countries your ads will reach, not just the ones your team owns. |
| 3 | Onboarding is tracked step by step | Every screen from first open to paywall logs an event, so you can see where paid users stop. | You know the drop-off at each step and have improved the worst one at least once. |
| 4 | Install-to-trial is measured | Measured on organic users, at any level. | Near your category median and holding on paid traffic, not only organic. |
| 5 | Trial-to-paid is measured | You have seen some trials convert. | Stable across several monthly cohorts, read at least five weeks after the trials started. |
| 6 | The paywall and price are deliberate | Live, with a chosen price, plan mix and trial length. | At least one price, plan or paywall test completed and the winner kept. |
| 7 | First renewal is measured | Not required. | Known for your main plan on enough subscribers to trust, from paid users as well as organic. |
| 8 | You know what a payer is worth, net | A rough estimate is enough. | Measured, after store commission and refunds, and turned into a maximum CPI and CAC. |
| 9 | Events reach Meta correctly | Install, Start Trial and Subscribe arrive in Events Manager, checked against a test purchase. | Cohort revenue from your own revenue data, reconciled with what Meta reports. |
| 10 | The budget can read a test | A capped amount, tied to one written question. | Enough for about 50 optimisation events a week per ad set on a trial or purchase event. |
| 11 | There is runway for the cash lag | The learning budget is money you can afford to lose. | Cash to fund at least two months of media before payouts and cohorts catch up. |
| 12 | Creative supply exists | Three to five genuinely different concepts, not one ad in five colours. | A pipeline producing new concepts faster than your winners tire. |
The product checks (1 to 3)
1. Do people who found the app on their own come back?
Organic users are the cleanest test of the product, because no ad promised them anything. If they return and some of them pay, paid users have somewhere to go. If they do not, better ads will pull more people into the same leak. For learning traffic, the bar is low: you can say who the app is for and see a core of people using it unprompted. For scale, you want organic subscribers surviving their first renewal, because that is the number that sets what an install is worth.
2. Is the app stable on the devices your ads will reach?
Paid traffic reaches phones your team has never tested on. Google publishes hard numbers here: its Android vitals documentation sets a bad behaviour threshold of 1.09% for the user-perceived crash rate averaged across devices, and 8% on any single phone model, and says staying under them helps your app's visibility on Google Play. Apple does not publish an equivalent threshold, so on iOS the practical test is whether crashes show up on the path from first open to paywall. A crash there wastes the install, and the cost of that install is now yours.
3. Can you see where paid users stop?
This is the check we would never waive, even for a small test. If onboarding is not tracked screen by screen, a poor result tells you nothing about why. Was the ad attracting the wrong people, or did the right people quit on screen four? Without step-level events you cannot tell an ad problem from a product problem, and every paid pound spent before then teaches less than it should. Our explainer on install-to-trial conversion covers how to read that drop-off against published benchmarks.
The funnel checks (4 to 7)
These are the rates that turn an install into revenue. Before comparing yours with anyone else's, check the definition, because the two most-quoted reports measure different things. RevenueCat's State of Subscription Apps 2026, built on more than 115,000 apps, defines download-to-trial as the share of installs that start a free trial within 30 days of download, for apps that use trials, and trial-to-paid as the share of trial starts that convert to a paid subscription. Its medians for download-to-trial include 9.1% for Business, 6.9% for Health & Fitness, 6.5% for Education and 4.4% for Gaming. For trial-to-paid, Health & Fitness sits at a 37.7% median, Gaming at 25.0% and Photo & Video at 22.2%.
For a learning test you only need to have measured these, at any level. For scale you want them near your category median and, crucially, holding on paid users. Organic users often convert better than paid ones, so a rate measured only on organic traffic is a ceiling, not a forecast. Our guides to trial-to-paid benchmarks and download-to-paid benchmarks break these down by category, region and trial length.
Read trial-to-paid late enough
Timing matters as much as the rate. RevenueCat finds that 50.6% of paid conversions happen on the day of install, but 19.2% arrive in week six or later. Both figures are shares of the conversions that eventually happen, not of installs. A trial-to-paid rate read two weeks after a test ends will understate the final figure, which is why the scale bar in the table asks for cohorts read at least five weeks after the trials started.
The paywall should be a decision, not a default
Before scaling, the price, plan mix, trial length and paywall model should each be something you chose and tested, not something set at launch and never revisited. Changing them later resets every benchmark you have built. Our comparison of hard paywalls and freemium for paid acquisition and our guide to weekly, monthly and annual plans cover the two choices with the biggest effect on what you can pay for an install.
What a learning budget can and cannot tell you
This is the part most teams skip, and it decides whether a first test is worth running. A test budget buys a fixed number of installs, and each stage of the funnel narrows the sample. The further down the funnel, the less precisely you can measure.
Take a hypothetical app. These are illustrative round numbers, not benchmarks and not client data. It spends £8,000 at a £2.50 cost per install, which buys 3,200 installs. Six per cent start a trial, giving 192 trials, and 35% of those convert, giving about 67 payers. The table shows how precisely each rate is measured, using a standard 95% margin of error for a proportion.
| Stage | Sample | Measured rate | Plausible true range | Verdict |
|---|---|---|---|---|
| Install-to-trial | 3,200 installs | 6% (192 trials) | about 5.2% to 6.8% | Usable |
| Trial-to-paid | 192 trials | 35% (about 67 payers) | about 28% to 42% | Rough |
| First renewal | about 67 payers | 50% (hypothetical) | about 38% to 62%, and not before the first billing cycle ends | Not readable yet |
Install-to-trial comes out within about one percentage point, which is enough to compare against your organic rate and your category median. Trial-to-paid is uncertain by around seven points either way, which on a 35% rate is a fifth of its value: enough to spot a disaster, not enough to set a CPI target. Renewal cannot be read at all for weeks, and on annual plans not for a year.
A paid learning test measures the top of a subscription funnel well, the middle roughly and renewal not at all. Design it around the questions it can answer, and do not ask it to prove lifetime value.
That shapes what a first test should be for. Good questions for a learning budget: which of three or four promises gets the right people to install, whether paid users start trials at a rate close to organic ones, which onboarding step loses them, and whether one country or audience behaves very differently. Bad questions: what your lifetime value is, and whether the app has product-market fit. Those need time and volume a test budget does not buy.
It also explains why optimising a small test for purchases rarely works. Meta's documentation on optimising app ads for app events lists Start Trial and Subscribe among the standard events you can optimise for, so your ads reach people "most likely to take the action you specify, not just the ones most likely to install your app". The catch is volume: ad sets need enough of that event each week to leave the learning phase, which we cover in our explainer on the Meta Ads learning phase. A test producing 67 payers over several weeks cannot feed a purchase-optimised campaign. Learning tests usually run on installs or trials, and the scale bar in check 10 is where that changes.
The economics checks (8, 10 and 11)
Scale needs a ceiling, and the ceiling comes from net value per payer. Net means after the store's share and refunds. Apple's subscription terms pay developers in the UK and US 70% of a subscription price in its first year and 85% after a subscriber has a year of paid service, and members of its Small Business Program receive 85% throughout. Google Play's rate on auto-renewing subscriptions is 15%. Divide net value per payer by the number of installs it takes to produce one payer and you have a maximum cost per install. Our guide to break-even CPI for a subscription app works through it.
Budget and runway are the other two. For scale, the useful bar is whether the budget can buy enough of your optimisation event for ad sets to stabilise, which Meta puts at about 50 results in the week after the last significant edit. At a trial or purchase event, that is a much larger number than most founders expect, and our guide to how much ad spend an app needs turns cost per event into the number of creative tests a budget can read. Runway matters because subscription revenue arrives late. Cohorts keep converting for weeks, and the stores pay out weeks after the sale, so even a campaign that pays back on day one needs working capital. Our guide to CAC payback for subscription apps sets out the cash timing.
The machine checks (9 and 12)
Measurement. Before spending anything, make a test purchase and confirm that install, Start Trial and Subscribe arrive in Events Manager with the right values. It takes an afternoon, and a broken event can make a whole test unreadable. For scale, report revenue by cohort from your own subscription data and compare it with what Meta claims, because the two will not match, especially on iOS. Our post on SKAdNetwork postback delays explains why.
Creative. A learning test needs three to five concepts that make genuinely different promises to genuinely different people, because the main thing it is testing is the message. Five versions of one idea test colour, not demand. Scale needs a pipeline: new concepts arriving faster than winners tire. Our creative refresh calculator gives a rough read on how much output a given spend level needs.
How to read your score
- Any of checks 2, 3 or 9 fails: do not spend yet. These are cheap to fix and a test without them cannot be read.
- Learning column passes, scale column has gaps: run paid traffic for learning. Write down the question, set the budget in advance, optimise for installs or trials, and judge it on what it teaches you rather than its return.
- Everything passes except creative supply: the bottleneck is creative, and more budget will only wear out the ads you have faster.
- All twelve pass: scaling is defensible. The remaining question is who runs it, which we cover in when a mobile app should hire a Meta Ads agency.
Readiness is not fixed
The checklist is a snapshot, and the most useful thing about a learning test is that it improves the score while it runs. Paid users expose onboarding steps your organic users never struggled with, and the messages that win tell you which promise the onboarding should keep. Our Steps & Beasts case study is an example: the published result is a 1112% revenue increase and 118% more active subscriptions, and the case study credits an onboarding overhaul that lifted install-to-subscriber conversion alongside heavy creative testing. The paid programme and the product fixes moved together.
The reverse also holds. An app that passed every check last year can fail check 4 after a new onboarding flow, or check 12 after its best concept fatigues. Re-score before any large budget increase.
Where we fit
We work with apps that are past the learning stage, or close to it: our pricing page sets a £3,000 minimum monthly ad spend, because below that a creative test cannot be read reliably. Our Meta Ads service combines creative strategy, production and campaign management, so checks 9, 10 and 12 are covered by one team. We do not offer app store optimisation or lifecycle marketing, so if your gaps are in checks 1, 6 or 7, fix those first or bring in someone who specialises in them. If you are not sure which side of the line you are on, see how we work with consumer and subscription apps, and for how acquisition fits into the wider funnel, start with our subscription app marketing strategy guide.
Frequently asked questions
When should a subscription app start paid acquisition?
Earlier than most founders think for learning, and later than most think for scale. Once the app is stable, every onboarding step is tracked and your install, trial and purchase events reach Meta, a capped learning budget can answer specific questions about messages, audiences and the top of your funnel. Spending to grow profitably should wait until install-to-trial, trial-to-paid, first renewals and net value per payer have been measured on real cohorts, and you have the cash and creative supply to keep going.
Can paid ads help a subscription app find product-market fit?
They can help you find who the app is for and which promise makes them try it, which is part of the job. They cannot prove that people stay. A small paid test produces too few payers, too recently, to read renewal, and paid users can behave differently from people who found the app on their own. Treat paid traffic as a research tool before product-market fit, not as evidence of it.
How much should a subscription app spend on a paid learning test?
Size it from the question rather than the calendar. Decide which rate you want to measure and how precisely, then work back to the installs or trials needed. In our hypothetical example, around 3,200 installs measure install-to-trial to within about one percentage point, but the same test leaves trial-to-paid uncertain by roughly seven points either way. Spend no more than you would be comfortable treating as research cost.
What install-to-trial rate should an app have before scaling paid ads?
There is no universal threshold. RevenueCat's State of Subscription Apps 2026 reports median download-to-trial rates, measured within 30 days of download for trial-based apps, of 9.1% in Business, 6.9% in Health & Fitness, 6.5% in Education and 4.4% in Gaming. Being near your category median is a reasonable bar for scale. What matters more is that the rate holds on paid traffic, not just on organic users.
Do I need retention data before running ads for a subscription app?
Not before running a learning test, but yes before scaling. You cannot know how much an install is worth without knowing how many subscribers survive their first renewal, and that sets the most you can pay to acquire one. Organic cohorts are usually the first place to measure it.
The short version
Ask two questions, not one. Can paid traffic teach you something? That needs a stable app, onboarding tracked screen by screen, events that reach Meta, a handful of distinct concepts and a budget you can treat as research. Can paid traffic make you money? That also needs measured trial and paid conversion on paid users, first renewals, net value per payer, enough budget to optimise deeper than installs, the cash to wait for cohorts and a creative pipeline that outpaces fatigue. Run the first kind of test as soon as the three basics are in place, expect it to measure the top of the funnel rather than lifetime value, and scale only when the second column is complete.