The event with the strongest connection to revenue is an obvious place to start. It is not automatically the best signal to use today.
A first payment might take weeks to arrive. A registration might happen immediately but say little about whether someone will pay. A trial start might be a useful compromise, provided it means a real trial and you can show what usually happens next.
Your job is to choose a signal the campaign can use, then judge the people it brings in against the business outcome you actually need. Those are related decisions, but they are not identical.
Start with the outcome, then work backward
Write the commercial outcome as precisely as you can. “Subscriptions” is too loose if it combines free trials, first payments, and renewals. “New customers making their first successful payment” gives you something clearer to measure.
Draw the journey leading to it:
Install → registration completed → trial started → first successful payment → retained paying customer
Your app may have a different sequence. Keep only milestones that change what you know about a person’s progress. A tutorial completion can be useful if it reflects meaningful setup; it is less useful if everyone receives the event automatically on opening the app.
Then separate the event you want to optimize toward from the outcome you will use to evaluate the campaign. For example, you might optimize toward trial starts while evaluating cost per first payer and subsequent refunds. Calling trial starts the optimization goal does not make them revenue.
TikTok’s current App Event Optimization setup lets advertisers select an in-app event as the optimization goal. Its supported-events list also shows which events can be used for App Event Optimization and which are supported only for app retargeting. Check your actual app, campaign setup, and available choices before designing a transition around an event. TikTok’s AEO setup guide and supported in-app events
Check what each event really means
An event name is a label. The implementation determines what it tells you.
For every candidate, ask the product or tracking owner to confirm:
- What exact action triggers it?
- Does it fire when the action is attempted or when it succeeds?
- Can one person generate it more than once?
- Does it include existing customers as well as new ones?
- What makes the revenue amount and currency correct, if it carries value?
- Is the event arriving through the intended measurement path and mapped to the expected partner event?
An attempted checkout is not a completed payment. A repeated app open is not a new activated user. If the same purchase is sent by two integrations, do not assume a shared name makes those copies count once.
AppsFlyer treats the event name, its parameters, and the mapping sent to each partner as distinct parts of an implementation. Use that distinction when reviewing your own setup: seeing a familiar label in a dashboard is not a complete event audit. AppsFlyer’s in-app events overview
Build a short definition card. For a first-payment event, it might say: “Emit after the first successful charge; exclude trial initiation and renewals; verify duplicate handling in the supported integration.” That is much more useful than “track purchases.”
Compare signals without inventing a score
Assess each candidate on four questions.
Volume: How many eligible events does your existing, comparable activity suggest you could observe within the spending limit? Use a range. Historical volume is evidence, not a delivery promise. TikTok’s AEO setup guide gives a useful reference point: it recommends a daily budget of at least 20 times your historical cost per event for upper- and mid-funnel events, and at least 10 times for lower-funnel events.
Delay: How long does the action take, and when does it become available in the report you use? A quick app action can still have delayed reporting. On iOS, privacy-preserving attribution through SKAdNetwork and AdAttributionKit can delay and coarsen later events, so check how your candidate event appears in those postbacks before relying on it.
Reliability: Is the definition stable? Are you confident the event arrives and is counted as intended? A frequent but unreliable event is not a useful shortcut.
Relevance: How strongly does reaching the event predict the business outcome, after allowing the same observation time? Check by acquisition source and product context. A relationship observed among organic users may not hold for paid traffic.
You do not need an artificial score out of ten. Write “keep,” “test,” or “reject,” with the evidence behind it. Reject a broken event until repaired. Keep a working signal when the alternative cannot yet support a meaningful evaluation. Test a better candidate when the expected learning justifies the exposure.
Work through a trial-based example
Here is a hypothetical app, using invented numbers rather than campaign results. A completed acquisition cohort contains 1,000 installs, 300 registrations, 120 trial starters, and 24 first payers by the agreed review age. Each milestone counts unique people once.
That gives you:
- 30% install-to-registration conversion: 300 ÷ 1,000
- 40% registration-to-trial conversion: 120 ÷ 300
- 20% trial-to-first-payment conversion: 24 ÷ 120
Suppose the trial lasts 14 days. Registration is an earlier, more frequent signal, while first payment is closer to the commercial outcome but arrives later and less often. Trial start sits between them.
The event-choice matrix for this fictional case could read:
- Install: keep as a delivery reference; reject as the preferred business signal if stronger, reliable alternatives are feasible.
- Registration: keep as a fallback; test only if it reflects genuine intent and later quality remains acceptable.
- Trial start: test as the candidate signal; it is more frequent than payment, but must retain a downstream payment guardrail.
- First payment: retain as the evaluation outcome; consider an optimization test when the available volume, delay, and budget make that test feasible.
None of those cohort ratios predicts what a new optimization strategy will produce. If delivery finds people who love free trials but rarely pay, trial volume could rise while economics worsen. That possibility is exactly why the downstream guardrail belongs in the plan.
Change one important thing and protect the comparison
State the transition as a question: “Does optimizing for trial starts acquire first payers more efficiently than our current registration goal?”
Where the available setup and budget support a controlled comparison, keep creative, offer, geography, and other material settings consistent. If you cannot isolate the change, record the other changes and treat the result as directional. A before-and-after improvement is not proof that the event change caused it.
Define separate periods for acquiring users and observing their later outcomes. Do not end the evaluation on the final acquisition day if the new users still need time to finish their trials.
Set a total exposure limit and a quality condition before starting. For example, the decision might depend on cost per first payer at a completed cohort age, with refunds and retention checked separately. Choose the actual limits from your economics; there is no universal event count or waiting period that makes the decision safe.
Finish with a small decision record: selected event, exact definition, why it is usable, what downstream result must hold, and when you will revisit it. A good optimization goal is a testable choice, not a permanent declaration that one event is best.
