Use impression-level ad revenue

Impression-level ad revenue is best used for more granular revenue data and for LTV calculation. Consider using impression-level ad revenue if you:

• Need more granular LTV data
• Calculate LTV or return on ad spend (ROAS) on your own
• Use an internal system or third-party tool for data analysis and/or ROAS calculation
• Have developer resources to implement impression-level ad revenue

Otherwise, you can use the cohort report.

Impression-level ad revenue is supported out of the box by a number of measurement and analytics companies. You can check the list of supported companies for Android, iOS, and Unity. If your company isn’t supported yet, you might be able to pass the impression-level ad revenue data directly to your third-party SDK.

Impression-level ad revenue provides you with total revenue and impressions. Total revenue is the sum of ad_value from all impression-level ad revenue events (also called paid events in the SDK API).

Based on what you collect from the SDK, you can view this data by ad source, ad unit, ad format, or more.

The total impressions is the number of LTV pingback events. Make sure to include any events with zero ad_value to prevent underreporting.

Some discrepancy is expected with impression-level ad revenue for AdMob and third party networks. Depending on your calculation, the comparison of the impression-level ad revenue data to your AdMob reports or another data source may vary.

Make sure you’re not filtering out any events when collecting impression-level ad revenue data and calculating LTV.

If you’re finding a discrepancy on values with estimated precision, this can be caused by:

• Floor changes and eCPM fluctuations: Since values with estimated precision are calculated using an average based on historical data, ad unit floor changes or other CPM fluctuations can cause overestimation or underestimation.
• New ad source instances: If optimization is enabled, AdMob may take up to 5 days to generate data for a new ad source instance. In the meantime, publisher provided precision will be used.

If there's a discrepancy on values with publisher-provided precision, this can be caused by a mismatch between the manual eCPM and the third-party ad unit floor.

If you use manual eCPM in the mediation waterfall, this eCPM value is used to calculate the impression-level ad revenue data. If this eCPM is used for ordering waterfall ad source instances or does not match the third-party ad unit floor, this can cause discrepancy, since the manual eCPM doesn't reflect the actual CPMs the third-party delivers.

You can add the waterfall ad source credentials so AdMob can estimate the eCPM and reduce discrepancies.

AdMob may apply invalid traffic filtering after the impression has served. In those cases, you might notice discrepancies between what's shown in AdMob reporting and the data that was captured via the impression-level ad revenue data API before the filter was applied.

You can check the list of supported companies for Android, iOS, and Unity. If your company isn’t supported yet, you might still be able to pass the impression-level ad revenue data directly to your third-party SDK.

If AdMob doesn't have enough data to calculate the revenue for a bidding ad source, it will report a value of $0. It will also report Unknown for the precision level. This can happen if the ad source is an AdMob campaign.

If you’re getting null for an ad source using our mediation adapter callback, it's likely due to an ad loading error:

• iOS: Null if no ad was returned
• Android: Null if the ad failed to load