Optimise your Meta campaigns for the deepest event that passes three tests. It has to fire about 50 times a week in each ad set at a budget you can afford. It has to predict revenue, so that more of it means more paying subscribers. And it has to reach Meta quickly enough to learn from. For most subscription apps with a free trial, that event is the trial start. Installs make sense while in-app events are not tracked reliably or the budget is very small. Subscriptions or purchases make sense when users pay without a trial, or when paid volume is high and trial quality varies a lot between campaigns. No event is right for every app, and the right one changes as spend grows.
We have touched on this choice in our subscription app marketing strategy guide and in our Advantage+ app campaigns setup guide. This is the full version: what each option asks Meta to do, according to Meta's own documentation, the three tests applied with numbers, a decision table, and how to change events without throwing away what the account has learned.
Key takeaways
- The optimisation event tells Meta who to find. Optimise for installs and it finds installers; optimise for trials and it finds trialists. It will not find payers you never told it about.
- Deeper is better only when the event passes three tests: volume, predictiveness and latency.
- Each step down the funnel multiplies the spend needed to reach about 50 events a week. Subscriptions can need 30 to 40 times the budget of installs per ad set.
- Trial starts are the default for trial apps because most happen on install day. Check that trial-to-paid holds steady across campaigns before you trust them.
- Never switch events by editing a live ad set. Test the new event alongside the old one and compare matured cohorts.
What each optimisation event asks Meta to do
Meta's app ads documentation describes app event optimisation as showing install ads to "people most likely to take the action you specify, not just the ones most likely to install your app". The event you pick is the definition of a good outcome. Everything else in the delivery system, who sees the ad, where and at what bid, works backwards from it.
| Optimise for | Meta setting | Meta looks for | Strength | Weakness |
|---|---|---|---|---|
| Installs | App installs goal (APP_INSTALLS in the API) | People most likely to install | Most volume, fastest learning, lowest cost per result | Least connected to revenue |
| Trial starts | App event goal on the Start Trial standard event | People most likely to start a free trial | Fires on install day for most users, far more often than paid events | Some trialists never intended to pay |
| Subscriptions or purchases | App event goal on Subscribe or Purchase | People most likely to pay | Closest to revenue | Rarest event; on trial apps it arrives when the trial ends |
| Purchase value | Value goal (VALUE in the API), optionally with a minimum ROAS | The most total purchase value within the attribution window | Separates a weekly buyer from an annual one | Needs reliable purchase values and enough purchases; availability varies |
A few details from the documentation matter in practice. An ad set can optimise for only one app event at a time. Meta defines Start Trial as logged "at the start of a free trial" and Subscribe as logged "at the start of a paid subscription", so they are separate events and should never fire on the same moment. Custom app events can be used as the optimisation event within the app installs objective, and where a custom event matches a standard one, Meta recommends optimising "directly for your custom event". Meta's Advantage+ app campaign reference lists a value goal that "optimizes for maximum total purchase value within the specified attribution window", which can be paired with a minimum ROAS bid, while its general app ads page still describes value optimisation through the API as available "on a limited basis" to advertisers on an allow list. Check what your own account offers before planning around it.
Test one: volume, or can Meta learn on it?
Meta's Business Help Centre says an ad set usually leaves the learning phase after about 50 results in the week after its last significant edit, and an ad set that cannot get there shows as learning limited. Results means your optimisation event, so the threshold gets more expensive with every step down the funnel. Our guide to the Meta Ads learning phase covers what happens below it. The useful calculation is how many installs each event needs:
Weekly spend per ad set ≈ installs needed × CPI
Here it is for a hypothetical fitness app at £2.50 per install, with an install-to-trial rate of 7% and a trial-to-paid rate of 37.7%. Those two rates are the Health & Fitness medians in RevenueCat's State of Subscription Apps 2026 (6.9% of installs starting a trial within 30 days, rounded, and 37.7% of trial starts converting to paid), which covers more than 115,000 apps. They come from separate distributions, so multiplying them is an illustration rather than a benchmark.
| Event | Share of installs | Cost per event | Installs for 50 a week | Weekly spend per ad set |
|---|---|---|---|---|
| Install | Every install | £2.50 | 50 | £125 |
| Trial start | 7% of installs | about £36 | about 715 | about £1,790 |
| Paid subscription | 7% × 37.7% ≈ 2.6% of installs | about £95 | about 1,900 | about £4,740 |
Two things follow. First, the jump from trials to subscriptions is the expensive one: about £4,740 a week, or roughly £20,000 a month, for a single ad set before anything else is tested. Second, the table uses the funnel of the current campaign, and a deeper event usually changes that funnel, as the worked example below shows. Our guide to how much a subscription app should spend on Meta turns this into a monthly delivery floor, and our hard paywall vs freemium guide shows how much the floor moves with the paywall model.
If you fail the volume test, consolidate before you give up on the event. Fewer ad sets, fewer markets per campaign split out, and fewer parallel campaigns all concentrate events. Only when a consolidated ad set still cannot reach the threshold should you step back to a shallower event.
Test two: predictiveness, or does more of it mean more revenue?
A shallow event is only useful as a stand-in for revenue if the people who complete it pay at a fairly steady rate. If 35% of trial starts from one campaign convert and 15% from another, optimising for trial starts pays Meta to find both kinds of trialist equally, and it will happily lean towards whichever is cheaper.
RevenueCat's 2026 data gives a reason for caution. Among 3-day trials, 55.4% of all cancellations happen on day 0, the day the trial starts. For 7-day trials the figure is 39.8%, and 31.1% for 30-day trials. A cancellation does not remove the Start Trial event Meta already received, so a meaningful share of what the algorithm counts as success can be people who decided against paying within hours.
The check is simple and most accounts never run it: take trial-to-paid by campaign, and if you can, by creative concept, for cohorts whose trials have ended. If the rates sit close together, trial starts are a good stand-in and you can stop worrying. If they spread widely, the trial event is not doing its job, and you either need a deeper event or a creative and paywall fix so that the ads and the paywall attract the same person. Our trial-to-paid benchmarks show what a normal range looks like by category and trial length.
Test three: latency, or does the signal arrive in time?
An event Meta hears about late, or never, cannot steer delivery. Trial starts score well here. Adapty's State of In-App Subscriptions 2026, built on more than 16,000 apps, reports that 89.4% of trial starts happen on day 0, and RevenueCat puts Health & Fitness at 82.1%. The event lands almost as fast as the install.
Paid events depend on the model. Where users buy on the paywall without a trial, payment is a first-session event too: RevenueCat reports that 50.6% of all eventual paid conversions happen on day 0, a share of conversions rather than of installs. Where there is a trial, the paid event arrives when the trial ends. Meta's longest standard click-through attribution window is 7 days, so if your setup logs the conversion when a 14-day or 30-day trial converts, most of those subscriptions arrive after the window has closed. How your SDK or measurement partner logs trial conversions decides this, so check it before choosing Subscribe on a long trial.
iOS adds its own delay. Apple's SKAdNetwork reports conversions in windows of days 0 to 2, 3 to 7 and 8 to 35 after first launch, each with a random delay before the postback is sent, and Meta's Advantage+ app campaigns ask iOS 14+ campaigns to choose between Apple's SKAdNetwork and Meta's Aggregated Event Measurement. Our explainer on SKAdNetwork postback delays covers what that does to your reads. The practical point: on iOS, a deeper event is both rarer and later, which makes it harder to learn on than the same event on Android.
A worked example: which event wins depends on volume
Here are three hypothetical campaigns for the same app, each spending £5,000 a week in one ad set. The pattern is a common one: deeper optimisation raises the price of an install and improves what happens after it. These are illustrative numbers, not client data, and your own gaps between the three will differ.
| Setup (£5,000 a week) | CPI | Install-to-trial | Trial-to-paid | Installs | Optimisation events a week | Subscribers | Cost per subscriber |
|---|---|---|---|---|---|---|---|
| Optimise for installs | £1.80 | 4% | 30% | about 2,780 | 2,780 installs | about 33 | about £150 |
| Optimise for trial starts | £3.00 | 9% | 32% | about 1,670 | about 150 trials | about 48 | about £104 |
| Optimise for subscriptions | £4.20 | 10% | 40% | about 1,190 | about 48 subscriptions | about 48 | about £105 |
The install campaign has the best CPI and the worst cost per subscriber, which is why CPI on its own cannot settle this question, as we set out in our guide to CPI, CPA and CAC. The trial and subscription campaigns land at almost the same cost per subscriber on paper. The difference is that the trial campaign feeds Meta about 150 events a week and the subscription campaign about 48, just below the threshold. In practice that subscription ad set would sit in learning, swing from week to week and be fragile to every new ad. At £5,000 a week, trial starts are the better choice. At £15,000 a week the subscription campaign would produce about 140 paid events and the comparison would be worth running for real.
That is the general shape. The deeper event earns its place when two things are true at once: it clears the volume test, and the shallower event's downstream conversion is weak or unstable enough to leave money on the table.
Which event to choose: a decision table
| Your situation | Optimise for | Why |
|---|---|---|
| In-app events are missing, duplicated or untrusted | Installs, temporarily | A deeper event the system cannot see reliably teaches it the wrong thing. Fix tracking first. |
| Trial app, cannot reach about 50 trial starts a week per ad set even after consolidating | Installs, or a frequent custom event such as onboarding completed | Volume test fails for trials. A first-session custom event can sit between the two. |
| Trial app, 50+ trial starts a week, trial-to-paid steady across campaigns | Trial starts | Passes all three tests. This is where most trial-based subscription apps should sit. |
| Trial app, trial-to-paid varies widely by campaign or concept | Test subscriptions alongside trials | Trial starts are not predicting revenue, so the algorithm is being paid to find the wrong trialists. |
| No trial, users buy on the paywall | Subscribe or Purchase | The paid event happens in the first session, so it passes the latency test as well as a trial would. |
| Long trials, 14 days or more | Trial starts, judged on cohorts | If the paid event is logged when the trial converts, it can land outside Meta's 7-day click window. |
| Mixed weekly and annual prices, plenty of purchases, values tracked | Test value optimisation, if your account offers it | Volume of payers is not the same as value of payers when prices differ by a factor of ten. |
Two notes on the table. A custom event such as onboarding completed or paywall viewed is only worth optimising for if it happens in the first session and its completers start trials at a clearly higher rate than other installers. And value optimisation does not remove the volume problem. It needs purchases, with values attached, often enough to learn from.
When optimising for installs is the right call
Meta's documentation calls install optimisation "the recommended approach if your goal is to maximize the reach of your application". For a subscription app that is rarely the goal, but installs are still the honest choice in three situations: before in-app events are tracked and deduplicated properly, when the budget cannot reach 50 trial starts a week in even one consolidated ad set, and for a short burst of reach in a new market while you learn which creative earns attention there.
What changes is how you judge it. An install campaign should be read on cost per trial and cost per subscriber by install cohort, never on CPI, because CPI is the number it is built to push down. If that cost per subscriber is acceptable, cheap reach is fine. If it is not, the campaign is buying the wrong users efficiently, and the fix is more budget, fewer ad sets or a deeper event, not a better install price. Our guide to break-even CPI shows how to work out what an install is worth to you.
How to move to a deeper event without breaking the account
Meta lists a change of optimisation event as a significant edit, which puts the ad set back into learning. Switching the event on your best ad set is therefore a gamble with your most stable spend. The approach we use:
- Audit the events first. Start Trial fires once per user at trial start. Subscribe or Purchase fires only on payment, never at trial start, and never with a zero value. iOS and Android send the same event names, and the SDK and any measurement partner are not both reporting the same event to Meta.
- Run the new event alongside the old one. Launch a separate campaign or ad set on the deeper event with the same creative, and leave the existing one running.
- Fund it to the threshold. A test ad set that cannot reach about 50 events a week will look worse than it is. If you cannot fund it, you are not ready to test it.
- Judge on cohorts, not on Meta's CPA. Each campaign reports cost per its own event, so the platform figures are not comparable. Compare cost per subscriber by install cohort, after trials have ended and the iOS postback windows have closed.
- Move budget in steps. If the deeper event wins, shift spend over gradually rather than all at once, as we describe in our guide to scaling Meta Ads for a subscription app.
The same logic runs in reverse. If a subscription-optimised ad set spends most of its life learning limited after a budget cut, moving back to trial starts is not a step backwards. It is matching the event to the volume you can now afford.
Where we fit
Choosing the event is one decision we make on every account we run through our Meta Ads service, alongside the budget that can feed it and the creative that decides which trialists it finds. That last part matters more than most teams expect, because predictiveness is partly a creative problem: ads that promise what the paywall sells bring trialists who pay. Our Steps & Beasts case study shows a published 1112% revenue increase and 118% more active subscriptions from heavy creative testing alongside onboarding improvements. You can read how we work with consumer and subscription apps, and if your app is already spending on Meta, our pricing is published and you can apply to work with us.
Frequently asked questions
Should a subscription app optimise Meta Ads for installs, trials or purchases?
Optimise for the deepest event that passes three tests: it fires about 50 times a week per ad set at a budget you can afford, it predicts revenue, and it reaches Meta quickly enough to learn from. For most subscription apps with a free trial that is the trial start. Installs suit very small budgets or apps whose in-app events are not yet tracked reliably. Subscribe or purchase suits apps that sell without a trial, or trial apps with enough paid volume and trial-to-paid that varies a lot between campaigns.
How many conversions does Meta need to optimise for an app event?
Meta's Business Help Centre says an ad set usually leaves the learning phase after about 50 results in the week after its last significant edit. Results here means the event you optimise for, so an ad set optimising for trial starts needs about 50 trial starts a week, and one optimising for subscriptions needs about 50 subscriptions a week. Ad sets that cannot reach that level show as learning limited.
Is it bad to optimise a subscription app for installs?
Not always. Meta describes install optimisation as the recommended approach if your goal is to maximise the reach of your app. It is reasonable while in-app events are not tracked reliably, or when the budget cannot buy 50 deeper events a week even after consolidating ad sets. The risk is that installs are the event least connected to revenue, so cheap installs can bring users who never start a trial. Judge an install-optimised campaign on cost per subscriber by cohort, not on CPI.
What is the difference between Start Trial and Subscribe events on Meta?
In Meta's app events documentation, Start Trial is logged at the start of a free trial and Subscribe is logged at the start of a paid subscription. They are separate standard events, and an ad set can optimise for only one app event at a time. A common setup error is firing Subscribe when the free trial starts, which makes a subscription-optimised campaign behave like a trial-optimised one while reporting it as paid.
Does changing the optimisation event reset the learning phase?
Yes. Meta lists a change of optimisation event as a significant edit, which sends the ad set back into learning. That is why we test a new event in a separate campaign or ad set running alongside the existing one, with the same creative, and judge the two on matured cohort cost per subscriber rather than editing the live ad set.
The short version
Meta finds whoever you tell it to find, so the optimisation event is the most consequential setting in a subscription app account. Go as deep as volume, predictiveness and latency allow, and no deeper. For most trial apps today that means trial starts, with a regular check that trial-to-paid holds steady across campaigns. Revisit the choice whenever spend, the paywall or the trial length changes, and test any new event alongside the old one rather than in place of it.