Which in-app events to track first, and which can wait

The short answer: events that decide budget

An in-app event belongs in your MMP if you would move ad spend because of it. That test leaves most apps with the same small set.

The first value action depends on the app. For a fitness app it might be a completed workout. For a marketplace it might be a first search with results. Pick the one action that best separates people who stay from people who leave.

Why a short list works better

You can verify it

Each event has to be fired at the right moment, once, with the right name. Five events can be tested by hand on one phone before launch. Fifty cannot, and a wrongly fired purchase event will distort every revenue figure in your reports.

Some plans bill by event

Check how your MMP charges before you decide. On Airbridge Core, for example, one data point is one event collected for your app, so each event you add is counted towards the plan's included volume.^[1] Other providers bill by attributed conversion or by active user, where extra events do not change the bill in the same way. Estimating a monthly attribution bill shows how to work it out from your own numbers.

Ad platforms learn from one clear signal

The event you send back to an ad platform is the thing its bidding is designed to get more of. An event that happens rarely, or long after the install, gives it few examples at the start. Many teams start by optimising for an earlier event, such as a sign-up or trial start, and move to purchases when volume allows.

Name events so they survive

Use the standard event names your MMP provides wherever one fits. Standard events are usually easier to map to what each ad platform expects, while an event you define yourself may need extra mapping and may sit in a higher plan. On Airbridge, custom events are part of the Growth Plan.^[2] The difference is explained under custom event versus standard event.

Three habits prevent most rework:

• Send revenue with a currency and an amount on the event itself.
• Fire the event when the action is confirmed, for example once the payment has succeeded. A tapped button can still end in a failed payment.
• Write each event's name, trigger and owner in one shared document.

When to add more

Add an event when a question comes up that the current list cannot answer. If two campaigns bring the same number of sign-ups but one retains better, an event deeper in the funnel will show why. If you start a campaign to bring back lapsed users, you need the event that marks a return. Add one event at a time, test it, and release it.

What to do next

Write your four or five events on one page and give it to your developer with the pre-launch checklist. After launch, you will see these events as columns in your first report. The guide on reading a first attribution report explains how to read them.