Ad revenue attribution guide

Premium

For:

Marketers

Last update: September 21, 2023 01:56

At a glance: Attribute ad revenue to complete the LTV performance view.

Ad revenue attribution

Ads display in the app on banners, offer walls, interstitials, etc., and generate ad revenue.
Ad revenue, combined with in-app purchases, and subscription revenue provide you with the complete LTV picture of the user. By matching user LTV with media spend campaign, ROI is determined and available for further analysis in the platform.

Attributed ad revenue data:

Is acquired from the mediation and/or ad monetization networks via server APIs or by embedded reporting SDK in the app (including iOS 14).
Is attributed to the media source that originally brought the user. For example:
- User sees an ad from Network A and downloads your app.
- Ad displays inside the app.
- Ad revenue is attributed to Network A (responsible for the user acquisition), no matter who published the ad.
Reporting granularity depends on the monetization network integration and ad revenue attribution type.

Integration types for ad revenue attribution

Ad revenue attribution supports different granularity methods. The granularity is monetization network dependent.

Ad revenue attribution integration type	Description
Aggregate level via S2S API	AppsFlyer gets the revenue daily broken down by geo. The effective revenue per action (eRPA) is derived by dividing the revenue by the number of instances of a trigger event. The trigger events are either app open or specific in-app events set in the app. If you're using a mediation network, make sure to disable ad revenue integrations for monetization partners that are mediated via the mediation network before enabling the ad revenue integration with the mediation network. Failure to do so results in duplicate data.
Device-level via S2S API	The mediation or monetization network reports the revenue by user at the device level. Not all networks support device-level granularity. This revenue is attributed to the media source that brought the user. Meaning AppsFlyer ad revenue attribution adheres to the attribution rules found in the platform, including retargeting attribution rules. If you're using a mediation network, make sure to disable ad revenue integrations for monetization partners that are mediated via the mediation network before enabling the ad revenue integration with the mediation network. Failure to do so results in duplicate data. Device-level via S2S API includes 100% of ad revenue and has the greatest data accuracy of the ad revenue integration types. Data is available in raw data reports. We don't send postbacks of device-level data to integrated partners.
Impression-level via SDK	Impression-level refers to how AppsFlyer receives the data. Data may end up being reported at other granularity levels (such as device level). The mediation or monetization network reports the revenue by user at the impression level. Not all networks support impression-level granularity. This revenue is attributed to the media source that brought the user. Meaning AppsFlyer ad revenue attribution adheres to the attribution rules found in the platform, including retargeting attribution rules. If you're using a mediation network, make sure to disable ad revenue integrations for monetization partners that are mediated via the mediation network before enabling the ad revenue integration with the mediation network. Failure to do so results in duplicate data. Impression-level via SDK has the best data freshness of all ad revenue integration types. Supports SKAN.
Impression-level (via SDK) with device-level (via S2S API)	Allows impression-level data that arrives via SDK to be attributed and reported on Day X, and be switched with device-level data that arrives via API on Day 1 and on. Enables data freshness to accuracy. Meaning, you get the benefit of data freshness for Day X with the data accuracy for Days X+1 and on. Supports SKAN.

Implementation

The following sections describe the types of ad revenue attribution available, as well as the workflows and steps necessary for implementation and maintenance.

Connect to ad revenue integrated partners

Before you begin:

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

To enable ad revenue integration with the ad revenue network:

In AppsFlyer, go to ROI360 > Revenue Settings > Ad revenue.
In Ad revenue integration, click New ad revenue integration.
Select an add revenue partner and click Next.
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 network 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.
  - Impression-level via SDK with aggregate level via S2S API.
  - Impression-level (via SDK) with device-level (via S2S API)
  - Note: If you're using a mediation network, make sure to disable ad revenue integrations for monetization partners that are mediated via the mediation network before enabling the ad revenue integration with the mediation network. Failure to do so results in duplicate data.
Complete the API credentials, or login, as required by the integrated partner. This is not relevant for SDK integrations.
Click Save.
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.
If there is no Test Connection button, you have completed the procedure.
AppsFlyer collects data from the partner multiple times per day.

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

View, edit, and delete ad revenue integrated partners

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

In AppsFlyer, go to Integration > Revenue > Ad revenue.
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.
Hover over the integration and click Edit or Delete as needed.

Deduplicate cross-referenced ad revenue

Partial duplication of ad revenue data may occur when an app uses two mediation platforms, both of which are associated with the same monetization network. 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 networks.

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

In AppsFlyer, go to ROI360 > Revenue Settings > Ad Revenue.
In General Settings, click Deduplicate ad revenue when two mediation partners cross-reference each other. Note: Don't deduplicate 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.

Aggregate granularity using app open or in-app events

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

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_opened event	The af_app_opened 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,

ad_watch_vungle.

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 an in-app event per network.

Ad revenue API status and testing

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.

Status	Meaning	Remarks/action required
API key verified	The connection is live and can pull data. Data is pulled once a day.	None
Invalid credentials	One or more of the credentials provided is incorrect.	Get the correct credentials from the ad revenue partner
Missing configuration details	One or more of the credential fields is incomplete	Retrieve the credentials in the ad revenue partner's dashboard or reach out to the partner and request the credentials.

Ad revenue data

Ad revenue data is available via AppsFlyer dashboards and raw data reports.

Ad revenue aggregate 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 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.

Examples

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:

Meta 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:

User

UA network

fb_
ad_view

chartboost_
ad_view

admob_
ad_view

applovin_
ad_view

is_ad_view

Total

Network A

2017-12-31

2018-01-01

2018-01-02

2018-01-03

2018-01-04

Network B

2017-12-31

2018-01-02

2018-01-04

Organic

2017-12-31

2018-01-01

2018-01-02

Looking at the data, we can now summarize the revenue collected per user, per day (and per in-app event):

User	2018-01-01	2018-01-02	2018-01-03	2018-01-04	Total LTV
A	$1	$1	$1	$1	$4
B		$1		$1	$2
C	$1	$1			$2
Total	$2	$3	$1	$2	$8

Understanding the Reports:

As mentioned, ad revenue is tied to user LTV. Therefore, 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 a report with two different date selections:

Aggregate Report : Dates Selected: 2017-12-31-2018-01-05

Network	LTV Revenue
Organic	$2
Network A	$4
Network B	$2
Network C	$2

In this case, the cohort is users who installed the app from 2017-12-31 until the current day, 2018-01-05. All the revenue generated by those users is tied back to the acquiring source and represented under the user’s LTV.

Ad revenue raw data

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.

Report	Export data page	Pull API	Data Locker
Attributed ad revenue (non-organic)	✓	✓	✓*
Organic ad revenue	✓	✓	✓*
Retargeting ad revenue	✓	✓	✓*
Impression-level raw data	-	-	✓
* Versioned report is also available, updated multiple times per day, with data aggregated at the device level. Non-versioned Data Locker reports are daily.

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

api_name	Field name	Field type	Description
event_time	Event time	Context	The date the revenue is attributed to
event_name	Event name	Context	Default is set to af_ad_revenue Can also be a custom event
event_revenue	Event Revenue Currency	Context	Amount of revenue using event revenue currency A zero value indicates impressions without revenue
event_revenue_currency	Event Currency	Context	Event revenue currency
event_revenue_XXX	Event Revenue XXX	Context	In the export page: Revenue converted to the app-specific currency In Data Locker always USD In Pull API according to the currency of the Pull.
country	Country	Context	Install country of the install conversion
ad_unit	Ad unit	Specific	Type of ad
segment	Segment	Specific	Ad placement name
monetization_network	Monetization Network	Specific	Network sending the ad
impressions	Impressions	Specific	Number of times that the user saw the ad
mediation_network	Mediation Network	Specific	Mediation network reporting the event to AppsFlyer

Fields by network

Display name	Admob	ironSource	AppLovin MAX	Appodeal	Fyber
Ad unit	✓	✓	✓	✓	✓
Segment	-	(1)	-	-	-
Placement	-	✓	✓	✓	✓
Monetization Network	✓	✓	-	✓	-
Impressions	-	-	✓	✓	-
Mediation Network	-	✓	✓	✓	-
(1) The advertiser needs to configure this in ironSource

Ad revenue raw data sample report

Data freshness

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 For ROI360 subscribers, 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 For ROI360 subscribers, Days 2, 3, 7, and 14, once per day.

For legacy integrations (pre-ROI360), data freshness is Day X+1, 5 PM UTC at the earliest.

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.

Ad Revenue Data Locker reports

Name

Freshness

Report Sections

Daily Ad Revenue (aggregated at device-level)

The ad revenue for a particular day (day X) is reported on the following day (X+1), at 8 PM UTC.

For instance, Ad revenue from May 1st will be reported on May 2nd.

The report includes Attributed, Organic, and Retargeting AdRevenue sections.

Versioned Daily Ad Revenue Report (aggregated at device-level)

The daily report consists of:

In-day versions created every 4 hours during the day of revenue (day X). The in-day data is collected by the SDK ROI connector.
Full-day versions created on day 2,3,7, and 13, based on data originating from S2S API reports.

In other words, the version set of a daily report includes the following versions:

00:00 — 04:00 on day X.
00:00 — 08:00 on day X [SDK ROI connector]
00:00 — 12:00 on day X [SDK ROI connector]
00:00 — 24:00 on day X [ SDK ROI connector]
00:00 — 24:00 on day x+1 [S2S]
00:00 — 24:00 on day x+2 [S2S]
00:00 — 24:00 on day x+6 [S2S]
00:00 until 24:00 on day x+13 [S2S]

Each report version includes Attributed, Organic, and Retargeting AdRevenue sections.

Impression level Ad Revenue report (impression-level)

The impression level ad revenue records are written to a separate file every hour.

Additional information

Migrating from aggregate to device-level granularity

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.

UA signals for ad networks

Note

You may want to work with ad networks that can receive UA signals. This means that ad networks responsible for user acquisition can receive data from mediation networks regarding ad revenue and use it to optimize their customers' UA campaigns.

To give signals to UA ad networks, mediation partners must have either impression-level or device-level integration.

To learn what the partner needs to do to receive the report, see here.
To learn what the advertiser needs to do to grant the partner permission for the report, see here.

List of mediation partners that can send UA signals to UA ad networks:

Applovin Max
Google AdMob
Appodeal
Chartboost
Fyber
Tapdaq
Topon
Unity
Unity LevelPlay mediation (formerly ironSource)
Admost
Tradplusad
Yandex

List of UA ad networks that can receive UA signals:

AdAction
Adamobi
Adjoe
Adonco
Adshow
Appier
Apprainbow
Aura from Unity
Betop
Bidswave
Brandscale
Chameleostudios
Chartboost
Datawave
DLab
Ecomonline
Etusdigital
Foregon
GNA Company
Happimobi
Hybrid
Inflecto
Irismedia
Lambadapp
Leadidadmonster
Lifestreet
Liftoff
Melodong
Mintegral
Mobrand
Moloco
Motive
Mpnd
Msla
Muvmobile
Nexamob
Nftdroper
Nsofmedia
Performadlive
Personalyrtb
Pitatroas
Rebornads
RTBhouse
Runfuns
Scmobi
Shalltry
Shareit
Smadex
Tapjoy
Targetmedia
Thepurpleline
TikTok for Business
Trademob
Truemoney
Unity Ads
Yandex
Yeahmobi
Z2A Digital
Zoyo

Permit ad networks to get ad revenue data

Before ad networks responsible for user acquisition can receive data from mediation networks, they must receive your permission.

Note: Before granting permission, contact the ad network to confirm that it has an ingestion flow and optimization logic in place to process your data.

To permit ad network to get aggregated revenue data:

Go to Configuration > Active integrations.
Select the integrated partner.
Go to the Integration tab.
Verify that Activate Partner is on. If not, data isn't shared.
Go to the Permissions tab.
Turn on Ad network permissions.
Turn on Access ad revenue raw data.
In Sending option, select whether to send data for ad revenue only from this partner (This partner only), or for ad revenue from all media sources (All media sourcesd, including organic).
Click Save Settings.
Contact the ad network to notify it that you have granted the permissions.
Make sure that the ad network enabled the report in their Data Locker and configured its output settings

Ad revenue event postbacks for ad networks

You can configure ad revenue postbacks for ad networks. This means that ad networks responsible for user acquisition can receive data from mediation networks regarding ad revenue and use it to optimize their customers' UA campaigns.

To send postbacks to UA ad networks, you must have an impression-level integration via SDK with the mediation network. AppsFlyer automatically generates an af_ad_revenue event per impression. These events can be selected from the list of events to be sent via in-app event postback to the UA ad network.

To set up ad revenue event postbacks:

Search for and select your partner, either from the marketplace or from the Configuration > Active Integrations page.
In the Integration tab, scroll down and turn on In-app event postbacks.
Select the AppsFlyer event af_ad_revenue.

Map it to the UA ad network event as follows:

UA ad network	Event to map af_ad_revenue to	Screenshot
ironSource	adRevenue
Unity Ads	ad_revenue
Moloco	No mapping needed
Mintegral	No mapping needed
Smadex	No mapping needed
Meta Ads	fb_mobile_purchase

Click Save integration.

List of mediation partners that can send impression-level ad revenue events to UA ad networks:

Applovin Max
Google AdMob
Appodeal
Chartboost
Fyber
Tapdaq
Topon
Unity
ironSource
Admost
Tradplusad
Yandex

List of UA ad networks that can receive ad revenue event postbacks:

ironSource
Unity Ads
Moloco
Mintegral
Meta Ads
Smadex

FAQ

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: This total ad revenue is LTV data, meaning it's the entire revenue generated by a monetizing network for your app from users who installed during the specified date range.

Is ad revenue available in the activity page?

Yes. 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

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.

How is device-level ad revenue attributed if a user has an app version without the AppsFlyer SDK?

Ad revenue is attributed as organic.

Is there a discrepancy between ad revenue data in different dashboards and reports?

There can be discrepancies between ad revenue data in the Overview dashboard and raw data reports, and in the Activity or Cohort dashboards. This is because:

Ad revenue data in Cohort and Activity dashboards, as well as data via Master API and Cohort API is updated retroactively; in the Overview dashboard, and via raw data export and Pull API, it is not.
Data is sometimes displayed in the Activity and Cohort dashboards before the Overview dashboard.
Dashboards include events marked as af_ad_revenue and _monetized, while raw data only includes af_ad_revenue events.

Traits and limitations

Trait	Remarks
Limitations	Ad revenue events are not available to: Push API Retargeting dashboard Device-level granularity limitations: The af_ad_revenue event is not available for cohorts in Pivot and Master API. The event is available in Cohort analytics. Discrepancies can occur when implementing Meta ads in-app bid revenue. The count of unique users triggering an af_ad_revenue event is not supported in AppsFlyer dashboards.
Ad network access	Can't access Cohort reports
Agency access	Agencies: Can't access the ad revenue configurations. Can see all the dashboards and data relevant to them.
Agency transparency	Not supported
Time zone	Ad revenue displays in AppsFlyer dashboards and reports in UTC timezone only. Meaning, if data is reported at 2 PM UTC+2, in AppsFlyer it displays as 2 PM UTC. processed daily. This is because AppsFlyer needs to normalize the data collected from multiple sources and partners, most of which report their data in UTC.
Currency	In AppsFlyer: Dashboard displays the advertiser's app-specific currency. Raw data reports display the original currency and also convert it to the advertiser's app-specific currency.
Data type	Both organic and non-organic data are supported
Data freshness	Ad revenue
Historical/retroactive data	Data is pulled and available from the day of the integration. This means historical data is not available before the date of the integration (day 0). Ad revenue data received via S2S API for a specific day is updated on days 1, 2, and 3. Ad revenue data in Cohort and Activity dashboards, as well as data via Master API, Cohort API is updated retroactively; in the Overview dashboard, and via raw data export and Pull API, it is not. If you have the advanced revenue package, data is also updated in Data Locker.
Account user access	Supported
SKAN	Supported by impression-level ad revenue SDK connectors.
Geo/country	In Cohort dashboard, when geo is unknown (N/A), the N/A data doesn't display when aggregating by geo.
In-app event postbacks	Postbacks to partners are for data relating to in-app events attributed to that partner; they don't include data relating to other media sources.

List of Ad revenue integrated partners

Partner	Credential parameters required	Data granularity
AdColony	API key App ID	Aggregate level with geo
Admost	Network app ID Token	Device-level with geo
AppLovin	Report Key App Package Name	Aggregate level with geo
AppLovin MAX	Report Key App Package Name	Device-level with geo Impression level (via SDK)
Appodeal	Application key API key User ID	Aggregate level with geo Device-level
Bytedance Ads - China traffic	Secure key App ID Account ID	Aggregate level with geo
Chartboost	User ID User Signature App ID	Aggregate level with geo
Meta ads	Login to Meta ads	Aggregate level with geo
Fyber	Client secret API ID Client ID	Device-level with geo Impression level (via SDK)
Google Marketing Platform -DV360/CM (DoubleClick)	Login to Google Marketing Platform - DV360/CM	Aggregate level with geo
Google Admob	AdMob app ID	Aggregate level with geo Impression level (via SDK)
Google Ads	API Authentication by OAuth	Aggregate level with geo
IronSource	Secret Key User Name App ID	Aggregate level with geo Device-level Impression level (via SDK)
Mintegral	App ID Secret Key API Key	Aggregate level with geo
Tapjoy	App ID Marketing API key	Device-level with geo
TikTok for Business	Secure Key App ID Account ID	Aggregate level with geo
TopOn	Network app ID Publisher key	Device-level with geo
Tradplus mediation	API key Network app ID	Device-level with geo
Unity Ads	API Key App ID	Aggregate level with geo Impression level (via SDK)
Voodoo Ads	Bundle ID Access token	Aggregate level with geo
Vungle	API Key App ID	Aggregate level with geo
Yandex	N/A	Impression level (via SDK)