ROI360 ad revenue attribution guide

Data accuracy and freshness are dependent on the ad revenue attribution integration type, as explained in the following table.

Note: SDK integration types require developer assistance to implement. S2S integration types require you to have the correct network credentials.

Before you begin:

• Request that the ad revenue integrated partner provide you API credentials.

To enable ad revenue integration with the ad revenue network:

1. In AppsFlyer, from the side menu, select Settings > Revenue Settings > Ad revenue.
2. In Ad revenue integration, click New ad revenue integration.
3. Select an add revenue partner and click Next.
   
4. Select the type of ad revenue data you want to receive. Note: Not all ad networks provide all the options listed below.
   • Attributed revenue. Meaning revenue based on the user acquisition source. Attributed revenue reports can be either:
     • Aggregate level via S2S API.
       • Select the event on which to base the ad revenue. For example, if you choose the event af_app_opened, then the total ad revenue is divided between all app-opened events, which gives you the ad revenue per app open. 
     • Device-level via S2S API. 
       • Note: If you're enabling the device-level ad revenue API of a mediation platform you must disable the ad revenue integrations of the monetization networks that it mediates. Failure to do so results in duplicate data.
     • Impression-level via SDK.
       • Tell your app developers to integrate the AppsFlyer ad revenue SDK API.
     • Impression-level (via SDK) with device-level (via S2S API).
       • Tell your app developers to integrate the AppsFlyer ad revenue SDK API.
     • Note: If you're using a mediation platform, make sure to disable ad revenue integrations for monetization partners that are mediated via the mediation platform before enabling the ad revenue integration with the mediation platform. Failure to do so results in duplicate data.
5. Complete the API credentials, or login, as required by the integrated partner. This is not relevant for SDK integrations.
6. Click Save.
7. If the Test Connection button displays, as in the image above, click Test Connection.
   • If API key verified displays, you have successfully completed the procedure. 
   • If any other message displays, see Ad revenue API status and testing and repeat the procedure.
8. If there is no Test Connection button, you have completed the procedure. 
   AppsFlyer collects data from the partner multiple times per day.
9. [Optional ]QA and compare the ad revenue data you see in AppsFlyer to the ad revenue data you see in your mediation partner and UA partner dashboards. Learn more
10. [Optional] Share ad revenue data to your UA partners via UA signals and ad revenue event postbacks.

Note: If you change from one integration type to another, the change takes effect at 12 AM UTC the following day. 

To view, edit, or delete ad revenue network integrations:

1. In AppsFlyer, from the side menu, select Settings > Revenue Settings > Ad revenue and select your app.
   A list of all your partner integrations displays, along with information about the product and integration type, integration status, and the ad revenue event names.
2. Hover over the integration and click Edit or Delete as needed.

When an app uses two mediation platforms with API integration types (aggregate level or device-level), both of which are associated with the same monetization network, partial duplication of ad revenue data may occur. In such cases, each mediation platform reports all the ad revenue generated by their associated monetization network, regardless of whether that revenue was generated while being mediated by only one of the platforms.

To help avoid partial duplication of revenue data when two mediation platforms cross-reference each other:

1. If available, use impression-level integrations via SDK. 
   • There isn’t duplication if both mediation platforms use impression-level integrations via SDK.
   • If you have multiple integrations, and one of them is SDK, we recommend also making your other integrations via SDK.
2. For integrations via API, deduplicate the ad revenue: 
   1. In AppsFlyer, from the side menu, select Settings > Revenue Settings > Ad revenue.
   2. In General Settings, check the box Deduplicate ad revenue when two mediation partners cross-reference each other. Note: Don't check the box if the 2 mediation platforms:
      • Mediate different ad formats. For example, when platform 1 shows Banner and Interstitial, and platform 2 shows AppOpen and Native ads.
      • Have impression-level integrations via SDK.

Aggregate granularity for ad revenue works as follows:

• The integrated network reports 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.
• AppsFlyer creates a _monetized event, that includes the total eRPA for each attributed device. 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_opened event which is available by default.
• Don't report ad revenue amounts in in-app events in parallel to an ad revenue integration. 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

Comparison of in-app event methods

• The operational status of ad revenue integration is available as follows:
  • Cost and ad revenue integration status dashboard: Centralized list of partners for whom ad revenue integration is enabled for one or more apps housed in your account. 
  • Some partners enable you to test the API connection. Where available, a Test connection button displays.
  • To verify that the API connection is operational:
  • Click Test connection. 
    The message API key verified displays. If this is not the case, follow the corrective action guidance in the table that follows. 

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

Note: There may be discrepancies between the ad revenue data in different dashboards and reports. Learn more. 

Ad revenue attribution is available as follows:

• LTV-based:
  • Dashboards being: Overview, events
  • LTV reports
  • Cohort dashboard and reports
  • Master API
• Activity-based:
  • Dashboard: Activity
  • Ad revenue raw data

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. 

Ad revenue raw data reports contain data provided by monetization networks having device-level or impression-level integration with AppsFlyer. 

Principles of ad revenue raw data

• Data is aggregated by the number of unique impressions per user. Unique impressions are derived from the combination of ad monetization network, ad unit, and placement. 
• Impression-level raw data is:
  • Aggregated to device-level and available in device-level reports.
  • Available as in impression-level reports in Data Locker.
  • Raw data freshness is identical to that of device-level ad revenue in the Activity dashboard.

Data characteristics and fields

The fields in ad revenue reports are populated:

• By the ad revenue event itself and listed in the table that follows. These fields are divided into:
  • Specific: Fields specific to ad revenue. For example, impressions and placement. Note! The fields populated differ by monetization partner, as shown in the Fields by network table in this section.
  • Context: Fields having a similar meaning in other raw data reports. For example, event name, event value, currency. 
• As a result of attributing the event to the media source that brought the user. Meaning these fields are copied from the conversion event that brought the user. For example, media source and campaign. These fields are not listed in the table that follows. 

Fields populated by ad revenue

Fields by network

Data freshness depends on the integration type and the reporting method. 

For S2S API integrations, the earliest that data becomes available is:

• Dashboards and reports (via Data Locker) starting at Day X+1, 8 AM UTC, approximately 4 times per day, every 6 hours. And days 2, 3, 7, and 14, once per day.

For impression-level SDK integrations, the earliest that data becomes available is:

• Dashboards and reports (via Data Locker) best case scenario, starting at Day X from 5 AM UTC, updated approximately 6 times per day, every 4 hours.
• Impression level raw data reports (via Data Locker) at Day X from 1 AM UTC, updated hourly.

For impression-level (via SDK) with device-level (via S2S API), you get data freshness for Day X with the data accuracy for Days X+1, as follows:

• For impression-level data that arrives via SDK:
  • Dashboards and reports (via Data Locker) best case scenario, starting at Day X from 5 AM UTC, updated approximately 6 times per day, every 4 hours.
  • Impression level raw data reports (via Data Locker) at Day X from 1 AM UTC, updated hourly.
• For device-level data that arrives via S2S API:
  • Dashboards and reports (via Data Locker) starting at Day X+1, 8 AM UTC, approximately 4 times per day, every 6 hours. And days 2, 3, 7, and 14, once per day.

Note: When changing the integration type, data received via the previous integration type for dates in the past will not be backfilled by the new integration type. For example, if on day X the integration type was changed from SDK to S2S, the data will be pulled from day X+1 onwards and not be pulled for days preceding day X.

• Migrating does not impact historical ad revenue data. This data remains unchanged.
• Ad revenue data is pulled once a day at 1400 UTC using the granularity options selected at that time.
• Device-level granularity does not require you to define in-app events (like you do for aggregate-level reporting). You can continue sending these events, but they don't impact the device-level granularity reporting in AppsFlyer.