How do you set up app events tracking that campaigns can actually optimize on?

Why do events decide how your campaigns perform?

Modern app campaigns on Meta, Google, TikTok and Snapchat are optimization machines pointed at whatever event you feed them. Optimize to installs and they find the humans most likely to install — including the ones who never open the app again. Optimize to trial starts or purchases and they hunt for payers. The event taxonomy is therefore not an analytics chore; it is the steering wheel of your entire acquisition budget.

Bad taxonomies fail quietly. A purchase event without revenue makes ROAS unknowable. A registration event that fires on screen view instead of completion teaches the algorithm to buy lookers, not doers. Duplicate purchase events — the classic being client and server both reporting the same transaction without a shared transaction ID — double your reported revenue and hide losing campaigns behind inflated returns. Each of these is invisible until you audit for it.

Which app events should you track? The core eight

Most apps need fewer, better events than they think. Eight cover the growth funnel for nearly every category:

• first_open — automatic in most SDKs; your install baseline.
• sign_up — account created, fired on completion, with a method parameter (phone, Apple, Google).
• onboarding_complete — the user got through setup; the first quality gate paid traffic must pass.
• activation — your app's aha moment: first scan, first lesson, first search, first listing saved. Define it once, from retention data.
• content_view or product_view — the browsing signal, with a category or item parameter for later segmentation and retargeting.
• add_to_cart or trial_start — the intent event; the strongest pre-revenue signal ad networks can optimize on.
• purchase or subscribe — with revenue, currency, and a transaction_id for deduplication, ideally verified server-side.
• renewal or repeat_purchase — the loyalty signal that separates buyers from customers, and the honest input to LTV.

What naming conventions keep analytics sane?

Naming feels trivial until the day three tools disagree and nobody remembers which event is real. The rules that hold:

• snake_case everywhere, one grammatical pattern — object_action (trial_start) or verb_object — chosen once and never mixed.
• Parameters, not name variants: one level_complete event with a level parameter, never level_1_complete, level_2_complete and forty siblings.
• The same event name in the app code, the MMP, GA4 and every ad network mapping — renaming per tool is how numbers stop matching.
• One tracking plan sheet as the single source of truth: event name, trigger definition, parameters, destinations, owner, date added. Version it.
• No orphan events: if nobody can say what decision an event feeds, it does not go in. Dozens of unused events are how real signals drown.

How do you wire events through your MMP to the ad networks?

For paid campaigns, your MMP — Adjust or AppsFlyer — is the source of truth, because it is the only place attribution and cost meet. Implement events once in the app, forward them through the MMP, and map each to the corresponding optimization event in every network: Meta app events, Google conversions, TikTok and Snap equivalents. One taxonomy, many destinations — never a separate hand-built setup per channel.

Send purchase revenue with currency on every event, and pass a transaction ID so networks and the MMP deduplicate correctly — the most common inflation bug in app accounts is the same purchase counted twice. On iOS, your SKAdNetwork conversion values must be derived from the same taxonomy, so the events you optimize on remain measurable even for opted-out users. And verify end to end before spending: trigger each event on a test device and confirm it lands, once, with the right parameters, in the MMP and in each network.

How do you set up conversion events for campaigns?

Every campaign faces the depth-versus-volume tradeoff: deeper events describe better users but fire less often, and delivery algorithms need steady weekly volume to learn — as a working floor, an event that cannot produce a few dozen conversions per week per campaign is too deep to optimize on yet.

So graduate as you grow. A new app starts on install or sign_up optimization while volume builds. Once trial_start or add_to_cart fires reliably at volume, move campaigns there — quality jumps, and cost per install usually rises while cost per customer falls. At scale, purchase or value-based optimization is the end state. Revisit quarterly: staying on install optimization long after you have purchase volume is one of the most expensive default settings in app marketing.

How do you build funnels in GA4 and your MMP?

The eight events chain into one funnel: first_open → onboarding_complete → activation → intent → purchase → repeat. Build it twice — in GA4 for product analysis across all users, and in the MMP segmented by channel and campaign for paid decisions. The two views answer different questions: GA4 tells you where the product leaks; the MMP tells you which money buys users that survive the leaks.

Review weekly and act on the largest drop-off, not all of them. And set volume alerts on your core events — a sudden drop after a release usually means a broken SDK call, and every week it goes unnoticed, your campaigns are optimizing on corrupted signal and your reports understate reality.