Ad revenue attribution guide

At a glance: By attributing ad revenue, app owners complete the LTV performance view.


Ad revenue attribution

Ad revenue is generated by displaying ads on rewarded videos, offer walls, interstitials, and banners in an app. To display ads, ad monetization network SDKs are integrated into the app. Having done so you are able to serve ads to your app users and generate ad revenue.

Ad revenue combined with in-app and subscription revenue completes the app user LTV picture. By matching user LTV with media spend the campaign ROI is determined and is available in the Dashboard.

Ad revenue is reported using either API or SDK to SDK integration between AppsFlyer and the monetization network. The revenue is attributed to the media source that brought the user. Ad revenue can be broken down by user geo and monetization network. 

Data freshness: Ad revenue data is pulled daily at 14:00 UTC for the previous day. The data displays in the dashboard on the next day. (Processing begins at midnight UTC.) For example, an ad displays on Monday. The revenue data is pulled from the ad networks on Tuesday at 14:00 UTC. Processing begins  Wednesday (midnight) 00:00 UTC. The data is available in the Dashboard on Wednesday from 16:00 UTC. Note: The revenue displays under Tuesday.

Ad revenue display timeline


Ad revenue attribution supports different granularity methods. 

  • Aggregate granularity using API : AppsFlyer gets the revenue daily broken down by geo. The effective revenue per action (eRPA) is derived by dividing the revenue with the number of instances of a trigger event. The trigger events are either app open or specific in-app events set in the app. 
  • User-level granularity using API or SDK: (best practice): AppsFlyer gets the revenue at the user level. This enables attributing the revenue to the original UA source. Not all monetization networks support this method.  Note: If you're using a mediation network make sure to disable ad revenue APIs for partners that mediate via the mediation network before enabling the user-level granularity API.  

Add revenue API principles of operation

  • The API puls the ad revenue daily at 1400 UTC. 
  • Historical data is never pulled. Only the previous day's data.

API Ad revenue attribution workflows

To implement API ad revenue attribution, follow one of the granularity method workflows in the following table. 

Ad revenue attribution workflows
Step Aggregate granularity  User-level granularity 
1 Not Applicable

In the app implement:

  • Ad monetization networks' SDK.
  • AppsFlyer in-app events.

In the app implement:

  • Ad monetization network's SDK in the app
3 Connect to the add monetization network partner in AppsFlyer 

Connect to a user-level ad monetization network:

4 Generate and attribute ad revenue Generate and attribute ad revenue


Aggregate granularity using app open or in-app events

Aggregate granularity implementation:

  • The network reports by integration the total revenue per day broken down by geo. 
  • Appsflyer derives the effective revenue per action (eRPA) by dividing the ad revenue with the number of instances of a trigger event.
  • For each instance of the trigger event, AppsFlyer creates a _monetized event, that includes the eRPA. For example, ad_matched_monetized.
  • Using eRPA revenue is attributed to media sources.
  • You can use one of the following event types: 
    • Unique monetization in-app event requires modifications to the app. 
    • af_app_open_event which is available by default,
  • Don't report ad revenue in in-app events. Doing so causes ad revenue to be duplicated in the Dashboard because AppsFlyer gets the revenue data from the monetization network by integration. 
Aggregate ad revenue using events
Event method How implemented Considerations

Unique monetization in-app event 

  • An in-app event is set at the time of ad display 
  • This provides a distinct count of user actions which enables superior eRPA calculations 
  • This can be further refined by having a different in-app event for each monetization network doing so enables you to break the revenue down by monetization network
    See the table that follows for a full discussion. 
  • Requires the developer to modify the app
  • Revenue can be broken down by monetization network in the Dashboard

af_app_open event

  • The af_app_open event is sent by the Appsflyer SDK by default
  • It is triggered by each user session 
  • No app modification required
  • Quick to implement 
  • eRPA values are significantly distorted unless you show only one app per session
  • No breakdown of revenue by monetization network
  • The event pertains to all users who launch the app and you have no indication of the user's willingness to watch ads
Comparison of in-app event methods
Method Pros Cons Considerations
Use the same event for all networks. For example, ad_watched. This automatically generates the ad_watched_monetized event containing the monetization details Simplest to implement No quality information, like the number of clicks and ad revenue per network
  • Best suited if the main goal is to find source/campaigns that get users with the greatest tendency to click on ads. 
  • It is not suited to comparing the performance of monetization networks.

(best practice) Each network is allocated a unique event for ad watching. Example: ad_watch_admob,


Full visibility and ability to compare the monetizing networks in the dashboard in addition to the raw data. Ad revenue isn't accumulated under a single event. The number of events is equivalent to the number of networks Enables comparison of monetizing networks in the dashboard. Ad revenue is separated by network using 

User-level granularity with Ad revenue API

User-level granularity implementation:

This method is the best practice. It provides the greatest level of granularity and ad revenue is attributed without the need to modify the app. Ad revenue is accurately attributed to the UA source. 

User-level data used for ad revenue attribution is not available in reports/postbacks.


If you are enabling the user-level ad revenue API of a mediation network you must disable the ad revenue APIs of  the monetization networks that it mediates.

User-level granularity (best practice)
Method How implemented Considerations

User-level data using Ad revenue API

  • Configure the integrated partner parameters in the Dashboard. Note: There is no need to implement in-app events. 
  • Data displays in the dashboard with the af_ad_revenue event


Migrating from aggregate granularity to user-level granularity implementation notes

  • Migrating does not impact historical ad revenue data. This data remains unchanged.
  • User-level granularity does not need in-app events. You can continue sending these events they don't impact the user level granularity reporting in AppsFlyer. 
  • Ad revenue data is pulled once a data at 1400 UTC using the granularity options selected at that time.
  • If you have implemented in-app events, to identify ad viewing activity, these continue to operate. They do not impact the operation of user-level granularity. 

Connecting to ad revenue integrated partners

Before you begin:

  • Prepare the app
  • Request that the ad revenue integrated partner provide you API credentials.
  • If you are implementing User-level revenue attribution with a revenue mediation partner: Disable active ad revenue integrations with partners that report the revenue via the mediation partner. 

To enable ad revenue integration with the ad revenue network:

  1. In Appsflyer, go to Configuration > Integrated Partners.
    The Integrated Partner window opens. 
  2. Select a partner. Tip: Select Active and Ad revenue to display your existing partners having Ad revenue capabilities. 
  3. Select the integrated partner.
    The integrated partner's configuration window opens.
  4. Go to Ad Revenue tab, enable Get Ad Revenue Data.
    The API credentials fields are displayed. 
  5. Some partners offer both user-level and aggregate granularity integrations. Select one. 
  6. Complete the API credentials as provided by the integrated partner. 
  7. If you selected Aggregate granularity, complete the app trigger in-app event that represents the ad monetization trigger. This event is usually sent for each ad impression. For example, ad watched or video watches
  8. Click Save Ad revenue.

Implementing ad revenue mediation platforms

App owners may contract with one or more ad monetization networks, either directly or via ad revenue mediation platforms Examples: IronSource, Admob, DoubleClick (DFP). 

If you implement a mediation platform's SDK in the app, this may cause duplicate reporting of revenue. To avoid duplication use the flow chart that follows to identify the appropriate way to integrate monetizing networks and mediation platforms.

AppsFlyer requires these platforms to integrate with it to perform ad monetization recording. You can check if the ad monetization platform you use is integrated with AppsFlyer. 

Admob and Applovin can act as mediation platforms but in AppsFlyer they only report ad revenue generated via Admob or Applovin respectively.

Viewing ad revenue data

Ad revenue shows the quality of users from different sources over time. As users continue launching the app and engaging with ads, their LTV continues to increase. 

Ad revenue attribution information is available in:

  • LTV:
    • Overview dashboard, Aggregated Performance Report table
    • Events dashboard
    • Cohort 
    • Master API: LTV
  • Activity: Master API: Activity 

Overview dashboard - aggregated performance report

In the Overview dashboard:

  • Values including revenue are LTV See LTV vs. activity data.
  • The Revenue column includes all revenue including ad revenue and in-app purchases
  • Drill-down into the advertising hierarchy (media source, campaign, ad set, geo) to view the monetized events in the report.
Events dashboard

In the Activity dashboard:

  • Values including revenue are activity date based. See LTV vs. activity data.
  • The Average Actions per User, indicates the tendency of users to engage with the ads presented in the app. 

Traits and Limitations

  • Traits:
    • App-specific time-zone: supported
    • App-specific currency: supported
    • Agencies: Agencies are not able to access the ad revenue configurations
    • Organic: supported
    • Non-organic: supported
    • Pulling historical data: Data is updated for the current day
  • Limitations:
    • Ad revenue events are not available in the following:
      • Raw Data reports
      • In-app event postbacks 
      • Push API
      • Retargeting dashboard
    • Additional limitations for user-level granularity:
      • The af_ad_revenue event is not available for cohorts in Pivot and Master API. 
      • The event is available in Cohort analytics.


Three users install an app on December 31, 2017. They are attributed as follows:

  • User A: Network A
  • User B: Network B
  • User C: Organic

The app is integrated with five different monetization platforms. Each platform uses a unique in-app event using the AppsFlyer SDK as follows:

  • Facebook Audience Network: fb_ad_view
  • Chartboost: chartboost_ad_view
  • Admob: admob_ad_view
  • Applovin: applovin_ad_view
  • IronSource: is_ad_view

After the install for a period of four days, the users are shown ads, as follows:


UA network








Network A












Network B

















If we look at the data we can summarize the revenue collected per day and the generated in-app events. This gives the eventual revenue per event which is then distributed to each user:

User LTV






Total LTV







B   $1   $1 $2
C $1 $1     $2
Total $2 $3 $1 $2 $8

Understanding the Reports:

As mentioned, ad revenue is tied to the user LTV. As a result, the time period you select in the Dashboard represents the cohort of installs for which the revenue is aggregated up until the current time and day. Let’s examine the report from two different date selection and understand the reporting.

Aggregate Report - Date Selected: 2018-12-31, current day 2018-01-05


LTV Revenue



Network A


Network B


Network C


In this case the cohort is the install date and the current day is 2018-01-05. All the revenue generated is tied back to the acquiring source and represented under the user’s LTV.


How can I get the total ad revenue from each platform?

  • Ad revenue attribution is linked and displays in relation to the user acquisition source.
  • This provides the LTV view of your ROI and KPIs.
  • To view the total revenue from each monetization platform use a different in-app event for each network and use the following procedure:
    1. In the Overview dashboard, go to the aggregated performance report table.
    2. Select up to four monetized events representing the platforms you want to query. 


    3. Download the report by, click Export CSV.

    4. Sum up the Revenue column of the requested platform's monetized event


    Note that this total ad revenue is LTV data, i.e. it's the entire revenue generated by a monetizing network for your app from users, who installed during the specified date range.

Is there ad revenue data in the activity page?


The Activity page reports on the combined revenue from in-app purchases and ad revenue. Note: Ad revenue data is sent to AppsFlyer on a daily basis, the day following the event. This means that in the Activity dashboard ad revenue data is assigned to the following day. 


On Monday midnight AppsFlyer gets a total ad revenue of $1000 for Monday for your gaming app - "Example App". While the AppsFlyer LTV data on the overview page shows the $1000 recorded for Monday, the activity page shows it for Tuesday (while its Monday data shows Sunday's ad revenue).

Do I need to activate the partner in the Integration tab?

  • If you engage with the partner for ad monetization (ad revenue) only: don't enable Activate Partner in the integration tab. 
  • Enable only Get Ad Revenue data in the Ad Revenue tab.

List of Ad revenue integrated partners

Partner Logo Credential parameters required Data granularity


  • API Key
  • App ID
Aggregate level with geo


  • Report Key
  • App Package Name
Aggregate level with geo

AppLovin MAX

  • Report Key
  • App Package Name
 User-level with geo


  •  Application key
  • API key
  • User ID
User-level with geo
Bytedance Ads - China traffic 
  • Secure key
  • App ID
  • Account ID
Aggregate level with geo
  • User ID
  • User Signature
  • App ID
Aggregate level with geo
Google Marketing Platform -DV360/CM (DoubleClick)
  • Login to Google Marketing Platform -DV360/CM
Aggregate level with geo
Facebook Facebook_Audience_Network.png
  • Login to Facebook
Aggregate level with geo
Google Ads
  • API Authentication by OAuth
Aggregate level with geo
  • Secret Key
  • User Name
  • App ID
  • Aggregate level with geo
  • User-level


  • App ID
  • Secret Key
  • API Key 
Aggregate level with geo

TikTok Ads 

  •  Secure Key
  • App ID
  • Account ID

Aggregate level with geo

Twitter (mopub)

  • API Key
  • Inventory Report ID
  • APP ID


Unity Ads

  • API Key
  • App ID
Aggregate level with geo
Voodoo Ads  voodoo.png
  •  Bundle ID
  • Access token
Aggregate level with geo


  • API Key
  • App ID
Aggregate level with geo
Was this article helpful?