The Conversion Event Your Ads Should Optimize On, and When to Switch It

The temptation, when you turn on a campaign, is to optimize it for the event closest to money: a paid subscription, a converted trial. That's the event that actually matters to your business, so that's the one to chase. Right?

Usually wrong, at least at first. The ad networks' optimizers are predictive models, and a predictive model needs a minimum number of examples to be worth anything. Meta wants roughly 50 optimization events per ad set per week to exit its learning phase; below that an ad set goes "learning limited", delivery gets volatile, and your cost per result spikes. A new subscription app isn't doing 50 paid conversions per ad set per week. It's doing a handful a month across everything. And those conversions land days after the click, so even the volume you do have arrives too late to steer today's spend.

So you don't start on "subscribe". You start on the deepest event you can feed enough of, let the optimizer learn on that, and climb toward "subscribe" as you scale. This post is the ladder, when to climb each rung, and a trick for warming up a new ad network so it doesn't start cold.

Why you can't just optimize on "subscribe" on day one

The learning phase is the whole reason. When an ad set starts (or when you change something material, including the optimization event), the network throws delivery wide and watches what converts, building a model of who to show the ad to. It exits that phase once it has enough conversions to be confident, roughly 50 per ad set per week on Meta and TikTok. Until then, performance is noisy by design.

Now do the math on a deep event. If "subscribe" happens 40 times a month across your whole account, no single ad set is getting 50 a week, so nothing ever exits the learning phase. You're asking the model to predict from a sample of almost nothing, and it shows: CPAs swing, delivery stalls, you blame the creative. Worse, the conversion is slow. A trial-to-paid window of 3 to 30 days means today's spend is being judged against subscriptions that won't be known for weeks. The optimizer is steering with a map that's a month out of date.

Volume isn't the only thing that matters; a clean, concentrated 50 conversions beats a noisy 50 from wildly different audiences. But you still need the 50. A deep, rare, slow event gives you neither.

The conversion-event ladder

The rule is simple: optimize on the deepest event you can fill with enough conversions per ad set per week to exit the learning phase. Start as low on the ladder as you have to. Climb as soon as you can.

• Install (or first open). Maximum volume, minimum signal. The networks will gladly find you cheap installs that never open the app again. Use it only at the very start, on a brand-new campaign with nothing else to go on, and get off it fast. Google App Campaigns calls this target-CPI; treat it as the floor, not a destination.
• Trial started (or registration, signup, qualified trial). The sweet spot for most new subscription apps. There's usually enough of it to clear the threshold per ad set per week, it fires inside the first session so it can steer today's spend, and it correlates with intent far better than "install". Send the qualified version if you can: the trial that survived its first couple of hours, not the one that cancelled on the spot, so you're not training the optimizer on the same-session-cancel cohort. (More on why that matters in our piece on the 1-hour trial.)
• Subscribe (or converted trial). The event you actually care about. Move here once you have the volume: roughly 30 to 50+ of these per ad set per week on Meta and TikTok, or ~30 to 50+ a day on Google App Campaigns before you switch it to target-CPA. Below that, "learning limited" costs you more in volatility than the better signal buys you.
• Value or LTV. The top of the ladder. Once you're consistently doing ~30+ purchases a week with several distinct values, move to value-based bidding (Meta's value optimization, Google's target-ROAS) and send the purchase value. Eventually, a modeled LTV. Now the optimizer is chasing revenue, not conversion count.

Starting shallow isn't settling

Two things make the shallow-first approach better than it sounds.

First, the model you train on trial-starts isn't thrown away when you graduate. The network has learned a great deal about who your converting-ish users look like; switching the optimization event to "subscribe" later is a refinement, not a restart. You're handing the optimizer a warm start, not a blank one.

Second, you don't have to choose. Once you have any subscription volume at all, run a deep-event campaign alongside the shallow one: the deep campaign stays small and feeds in cleaner signal while the shallow campaign carries the scale. As the deep one builds volume, you shift budget toward it.

Warm a new ad network before you spend on it

Here's the move most teams miss. You've been running Meta. Now you want to add TikTok. The instinct is to wire up TikTok's Events API on launch day, the day you allocate the first budget. Don't. Wire it up weeks earlier, and start sending it your conversion stream, the same trial-starts and subscribes you're already tracking, including the ones that came from Meta and from organic.

By the time you actually spend on TikTok, its integration isn't cold. The event is configured, the value mapping is set, your iOS event priorities are sorted, and there's a backlog of real conversions for the optimizer to anchor on, instead of it meeting your business for the first time with your first $500. Same logic for Google App Campaigns, Apple Search Ads, Applovin: the conversion feed is cheap to turn on and expensive to turn on late. Turn it on the day you think you might use the channel, not the day you do.

And: don't fire twenty events at the networks

Most apps instrument dozens of in-app events, for product analytics, for the data team, for the backlog of "we might want this someday". The ad networks don't need them, and they don't optimize better for having them. They optimize best on one or two events at a time. Pick your ladder, install → trial-started → subscribe → value, and send those.

Extra events don't add signal; they add clutter. On iOS, Meta's Aggregated Event Measurement lets you prioritize a handful of events per domain. Spend those slots on the ladder, not on "viewed_screen_3". More events sent to the ad networks is not more signal. The right events, sent server-side, deduplicated, and at the rung you've actually reached, are the signal.

Where SignalSeal fits

This is the plumbing. You instrument your events once and send them to SignalSeal, or pipe revenue events in from RevenueCat and Superwall, and we fan the conversion event you choose out to Meta's Conversions API, Google Ads, and TikTok's Events API, server-side, with the qualified-trial logic, the deduplication, the hashing, and the consent flags handled. When you decide to climb the ladder, switch the optimization event, add purchase value, add a new network, that's a setting, not an integration project. And warming up a new channel's feed weeks before you spend is one toggle.

What we deliberately don't do: a fraud suite, an audience builder or CDP, multi-touch attribution modeling, product analytics. If your growth is paid ads on the big networks, this is the whole product.

The short version: you can't optimize toward the event that matters most until you have enough of it, and at the start you don't. So start on the deepest event that has the volume, give the optimizer a clean signal to learn on, and climb toward "subscribe" and then revenue as you scale, switching the event only when you've clearly outgrown the last one. And turn on every channel's conversion feed early, before you spend, so nothing has to learn your business from scratch.