In AppsFlyer, installs are recorded automatically when the SDK reports the first app open. Everything after that — registrations, deposits, purchases, subscriptions — must be sent as in-app events, either from the SDK in the app or server-to-server from your backend. Purchase and payment events need a revenue value and a currency so AppsFlyer can calculate revenue and ROI, and partners can be paid on them.
Where to see installs
- Overview dashboard: installs by media source, campaign and date, split into organic and non-organic.
- Raw data / export reports: one row per install with media source, campaign, site ID, sub-parameters, install time and device data (availability depends on your plan).
- Cohort and retention reports: what those installs did later.
Check that the time zone matches the one your partners use for billing, or numbers will not reconcile at day boundaries.
Sending in-app events from the SDK
The app calls the SDK's event method with an event name and a map of values. AppsFlyer provides predefined names that partners recognise automatically:
| Business event | Event name | Typical values |
|---|---|---|
| Registration | af_complete_registration | method |
| First deposit / purchase | af_purchase | af_revenue, af_currency, af_content_id |
| Subscription | af_subscribe | af_revenue, af_currency |
| Add to cart | af_add_to_cart | af_price, af_content_id |
| Level achieved | af_level_achieved | af_level |
Revenue rules:
- Put the amount in
af_revenueand the ISO currency code inaf_currency(for exampleUSD,EUR,INR). - Send revenue only on events that represent money; AppsFlyer counts any event with
af_revenueas revenue. - Do not include currency symbols or thousands separators in the value.
- Decide whether revenue is gross or net of store fees and document it.
Sending events server-to-server
When the payment is confirmed on your backend — common for deposits, KYC approvals and web payments — send the event from your server using AppsFlyer's S2S in-app events API. The request identifies the app and the device's AppsFlyer ID, includes the event name and event values, and is authenticated with your key. AppsFlyer's developer documentation describes the current endpoint and required fields; the AppsFlyer ID (appsflyer_id) captured from the SDK is the key that ties the server event to the attributed user.
S2S events are more reliable for money events because they fire only when the payment is truly confirmed, not when the app thinks it was.
Validating store purchases
For Google Play and App Store purchases, AppsFlyer offers receipt validation (and a purchase connector product on some plans) so that only verified purchases are reported as revenue. This removes fake or test purchases from your data and from partner postbacks.
Sharing events with partners (postbacks)
- Open the partner's integration.
- In the in-app events section, map your event (
af_purchase) to the partner's event identifier. - Choose whether to send revenue values, and for which traffic — events from users attributed to that partner only, or all users (where the partner needs it for optimisation and your terms allow it).
- Save and test with a real event.
For CPA deals, the event you map is the event you pay on. Agree its name, attribution window and any value threshold in writing. See payout models.
How to check payment events
- Events report: filter by event name (
af_purchase) and media source to see counts and revenue. - Raw data — in-app events: one row per event, with revenue, currency, the attributed media source and campaign, and event time.
- Compare with your backend: reconcile counts and totals for a period. Differences point to missing S2S calls, test purchases or currency issues.
- Partner view: confirm that the partner received the same number of postbacks for its traffic.
Common problems
| Problem | Likely cause |
|---|---|
| Revenue looks 100× too high | Amount sent in cents instead of currency units |
| Revenue in wrong currency | af_currency missing; AppsFlyer used the app default |
| Events counted twice | Sent by both SDK and server without deduplication |
| Partner receives no events | Event not mapped, or mapped name mismatch |
| Events attributed as organic | Event sent with an ID that does not match the attributed install |
FAQ
How do I track purchase revenue in AppsFlyer?
Send an af_purchase event (or your own purchase event) with af_revenue and af_currency, from the SDK or server-to-server once the payment is confirmed.
What is the difference between SDK and S2S events?
SDK events are sent from the app on the user's device. S2S events are sent from your server, usually after a payment or approval is confirmed, and are more reliable for money events.
How can I see which partner brought paying users?
Use the events report or raw in-app event data filtered by af_purchase and grouped by media source and campaign.
Why does AppsFlyer revenue differ from my backend?
Common causes are currency conversion, test purchases, refunds, time-zone boundaries and events missing from S2S calls. Reconcile by event ID where possible.
Sources
- AppsFlyer Developer Hub — in-app events and S2S API (opens in a new tab)
- AppsFlyer Help Center — rich in-app events (opens in a new tab)
Published 25 October 2026 by the ClickSpero Editorial Team. Platform features, fees and policies change often — check the provider’s current terms before you rely on a number. Third-party names are trademarks of their owners; no endorsement is implied.