In-app events, postbacks and ROAS
Installs tell you who arrived, and in-app events tell you who was worth paying for.
In short: In-app events such as sign-ups and purchases are tied to the campaign that drove the install, then sent back to ad networks as postbacks so their algorithms can optimise. Grouping users by install date into cohorts and dividing their revenue by spend gives return on ad spend (ROAS), the number most budget decisions rest on.
What is an in-app event?
An in-app event is a recorded action a user takes inside the app after installing, such as completing sign-up, finishing a level, adding to basket or making a purchase, which an attribution system links back to the campaign that drove the install.
Events turn attribution from a count of installs into a measure of quality. Two campaigns with the same cost per install can produce very different numbers of paying users.
Types of event
- Activation events: sign-up, onboarding complete, first key action.
- Engagement events: level reached, lesson finished, content viewed.
- Revenue events: purchase, subscription start, renewal, with an amount and a currency.
- Re-engagement events: actions after a returning user taps a deep link.
Events can be sent from the app's SDK or from your server. Server-side sending is useful for revenue confirmed by a payment provider, but sending the same event from both places without a shared de-duplication key will double-count it.
What is a postback?
A postback is a server-to-server message that reports an install or in-app event to an ad network or partner, so it can credit its campaigns and optimise delivery. MMPs send postbacks to networks and partners; Apple sends SKAdNetwork postbacks to ad networks.
Postbacks matter for two reasons:
- Optimisation: a network that only hears about installs will find people who install. A network that hears about purchases can find people who buy.
- Partner reporting: affiliates and smaller networks often rely entirely on postbacks to see their results.
Sending revenue signals rather than installs alone is how teams move optimisation towards quality users. In an MMP such as Linkrunner, for example, postbacks to Meta, Google and TikTok can carry revenue signals, not only installs.
Platform limits on events
- Meta's Aggregated Event Measurement limits each app to 8 prioritised conversion events for iOS 14 and later campaigns.
- Google Ads counts in-app conversions within 90 days of the ad interaction by default.
- A Google conversion action set to count "Every" will record more conversions than a third party counting "One".
- SKAdNetwork carries only a conversion value from 0 to 63 in the first window, and low, medium or high afterwards. See the iOS ATT and SKAN chapter.
Revenue tracking
Revenue events need an amount, a currency code and a clear rule about which purchases count.
- Always send a currency code. Mismatched currency codes are a platform-stated cause of revenue differences.
- Decide whether revenue is gross or net of store fees and taxes, and use the same rule everywhere.
- Decide how refunds are handled.
- Google Play excludes failed purchases, so its numbers may differ from your own server.
What is a cohort?
A cohort is a group of users who share a starting point, usually the same install date or install week, and whose behaviour is tracked over the same number of days since that start. Cohorts let you compare like with like: users from last week against users from this week, each at day 7.
Without cohorts, revenue in a calendar month mixes users who installed yesterday with users who installed a year ago. That makes it hard to judge whether a campaign is getting better or worse.
How is ROAS calculated?
ROAS is revenue from users attributed to a campaign divided by what was spent on that campaign, usually measured at a fixed number of days after install. A ROAS of 1.0, or 100%, means the campaign has earned back its cost.
| Term | Meaning |
|---|---|
| Spend | Money paid to the ad network for the campaign |
| Cost per install (CPI) | Spend divided by attributed installs |
| Cost per action (CPA) | Spend divided by a chosen event, such as sign-ups |
| Day-7 ROAS | Revenue from the cohort in its first 7 days, divided by spend |
| Payback period | Days until cumulative cohort revenue equals spend |
A worked example
A grocery app spends ₹2 lakh on a Meta campaign in the first week of the month. The MMP attributes 10k installs to it, so the CPI is ₹20.
The app tracks revenue for that install cohort:
- By day 7, the cohort has spent ₹60k, so day-7 ROAS is 0.3, or 30%.
- By day 30, cumulative revenue is ₹1.6 lakh, so day-30 ROAS is 0.8.
- By day 60, cumulative revenue passes ₹2 lakh, so payback takes just under two months.
A second campaign with a higher CPI of ₹30 reaches day-30 ROAS of 1.1. It costs more per install, but its users pay back faster, so it deserves more budget. Without events and cohorts, the cheaper campaign would look like the winner.
These figures are illustrative, not benchmarks.
Why ROAS differs between tools
The same campaign can show different ROAS in Meta, Google and the MMP, for the reasons covered in earlier chapters:
- different attribution windows for installs and for events;
- self-attributing networks claiming overlapping installs;
- reporting on interaction day versus event day;
- time zones and currency handling;
- modelled conversions on iOS;
- events not mapped, or mapped under different names.
General practice is to use the MMP's de-duplicated ROAS for budget splits across networks, and each network's own figure for optimising inside it. See self-attributing networks and attribution windows for the detail.
Retention alongside ROAS
ROAS only measures revenue. For apps that earn through subscriptions renewing later, or through ads shown to active users, retention is the earlier signal.
- Day-1 retention: the share of a cohort that opens the app again the day after install.
- Day-7 and day-30 retention: the same measure a week and a month later.
- Event rates: the share of a cohort that completes a key event, such as sign-up or first purchase, by a given day.
A campaign with strong day-7 retention but little revenue so far may still pay back later. A campaign with weak retention rarely recovers, however cheap its installs.
Setting up events well
- Start with five to ten events that map to real business stages, not every button tap.
- Name them once and keep the names stable.
- Send revenue with currency, and decide on gross or net.
- Map each event to the matching standard event in each ad network.
- Check postback delivery logs after any change.
- Watch for duplicates when events come from both the SDK and the server.
Questions on this chapter
What is the difference between an event and a postback?
An event is the action itself, recorded by the app or server. A postback is the message that reports that event, or an install, to an ad network or partner.
Why should I send revenue events to ad networks?
Networks optimise towards whatever signal they receive. Sending purchases or revenue lets them look for people likely to pay, not just people likely to install.
What is a good ROAS?
It depends on your margins and how long you can wait for payback. A day-7 ROAS well below 1.0 can still be healthy if users keep paying for months.
Why does my revenue differ between the MMP and Google Ads?
Common reasons include different windows, currency codes, counting settings and failed purchases. Google recommends reconciling counts first rather than values.
What is cohort analysis used for?
It compares groups of users who started at the same time over the same number of days. This shows whether newer campaigns bring better or worse users than older ones.
What is mobile app attribution?
Mobile app attribution is the process of crediting each app install and in-app event to the ad, link or channel that drove it. It tells you which campaigns bring users, so you can move budget to the ones that work.