How it works
A developer calls the SDK with an event name and optional parameters, for example revenue, currency or an item ID, at the point in the code where the action happens. Events can also be sent from your backend, which suits actions that happen outside the app, such as a subscription renewal. The measurement platform links each event to the user's install and its source, includes it in cohort reports and forwards selected events to ad networks as postbacks.
Why it matters for an app team
Installs alone say little about quality. Events show which campaigns bring users who register, pay or come back, and they are the signal ad networks need to optimise towards those users instead of towards cheap installs.
In practice
Example with made-up numbers: two campaigns each bring 1,000 installs. In the first, 300 users complete registration and 40 make a purchase. In the second, 500 register but only 10 purchase. Which one is better depends on the event you care about, which is why it has to be measured.
Common confusion
More events are not better. A short list with stable names that match what each ad network expects is more useful than dozens of loosely named ones. Revenue sent from both the SDK and the backend for the same purchase is counted twice unless one of the two sources is switched off.