In-app event

How it works

A developer adds a line of code at the point where the action happens. When a user completes a purchase, for example, the SDK sends an event with a name and a time. Most events can also carry extra fields: a value and currency, a product ID, a plan name.

Some events never pass through the app. A subscription renewal or a completed delivery is confirmed on a server, so it is sent from the server with the user's ID attached. Reports treat it the same way as an event sent by the SDK.

Tools usually offer a list of predefined event names for common actions, and let you define your own on some plans. The difference is explained under custom event versus standard event.

When it matters

Events are where app types diverge. The install is the same everywhere, and what follows is specific: a trial start for a subscription product, an order for a shop, a level for a game, an approved account for a finance app. The guide to attribution for fintech apps shows how much care the choice can take. If you are starting out, which in-app events to track first gives an order to work in.

More events are not always better. Each one adds work and, on plans billed by volume, cost.

How it relates to attribution

An attribution tool matches the install to an ad and then attaches every later event from that user to the same source. That link turns a raw count of purchases into purchases per campaign, and it feeds metrics such as ROAS and retention. Events can also be sent back to ad platforms so their delivery favours people likely to complete them.