How to Calculate Revenue for In-app Advertising: Our Proven Framework

If you’re an app developer or marketer who monetizes through in-app advertising (IAA), you probably already know the challenge: how do you calculate ad revenue accurately when the numbers don’t always add up?

One dashboard might show $50,000 in ad revenue, while another shows $48,000. Your ad mediation platform reports one figure, but your ad network and channel APIs report something completely different. When these discrepancies reach a certain range of 10-20%, how are you supposed to make a decision?…And, many follow-up questions arise: Which revenue insight is real? Where’s the revenue leak? 

In this guide, these questions and more are answered by in-house expert Anurag Mohan, Senior Customer Success Manager at Tenjin. He’ll walk us through our proven framework and share his knowledge on the following topics:

• Ad Attribution As The Foundation 
• Why Tenjin Includes More Than One Revenue Stream
• How To Calculate Revenue For Each IAA Source 
• The Key Differences In Calculation Methods And Why They Matter
• How To Use Your Revenue Insights Dashboard To Detect Invalid Ad Requests
• Best Practices For Mobile Invalid Ad Detection And Prevention
• How Dual-Source Tracking Improves Return On Ad Spend (ROAS)

Whether you’re analyzing revenue in your insights dashboard, troubleshooting API discrepancies, or defending against invalid ad requests, this framework will help you report with confidence and protect your bottom line. We’ll even share some real use cases to prove it. 

Ad Revenue Attribution Is The Foundation

IAA revenue calculation starts with a clear purpose: ad revenue attribution. By connecting earnings to campaigns, アドネットワーク, and creatives, you identify which channels deliver positive ROAS. This visibility allows you to eliminate waste, allocate budget to profitable sources, and scale user acquisition strategically.

In-app purchases? Straightforward. An MMP like Tenjin tracks the install, and all revenue data flows straight to you through your app.

But the big focus in this article is IAA and that’s because it works differently than in-app purchases (IAP). Advertisers don’t know how much ad revenue their acquired users generate. Publishers see impressions and earnings, but they can’t connect them to specific campaigns or networks.

This is where ad revenue attribution delivers value. But first, let’s understand the legwork for our IAA calculation. 

Why Tenjin Includes More Than One Revenue Stream

Most mobile measurement partners (MMPs) rely on a single ad revenue source. This one source contains data that is directly pulled from ad mediation platforms like AppLovin Max, or Unity LevelPlay. While this gives you a single view of your ad revenue, combining multiple ad revenue sources allows for deeper validation, better fraud detection, and more precise campaign optimization.

As a hybrid-friendly MMP, Tenjin thinks differently. Anurag explains:  

“Tenjin is uniquely the only MMP that gives this flexibility and this complete coverage of all of your ad revenue sources. So we’re the only ones who, on our dashboard, give you the option to look at the ad mediation revenue and also the revenue that’s coming from these reporting APIs.” 

We calculate the revenue for IAA by considering two sources: 

• Ad mediation revenue is captured directly from your mediation SDK at the impression level, in real-time. 
  

• Ad revenue via Channels API is aggregated from ad networks’ reporting APIs and allocated to your user acquisition campaigns based on sessions. 

By using two distinct ad revenue sources, ad mediation and channels APIs, there are more robust possibilities and perspectives. This includes the chance to dig deeper into the data and discover opportunities for campaign optimization and catch different types of invalid ad requests before it hurts. 

How to Calculate Revenue for IAA: We Think Twice

Understanding how to calculate revenue from each of our two sources for IAA is the foundation for navigating your ad revenue and insights dashboard correctly. Let’s take a quick look at how they both work: 

How to Calculate Ad Revenue via Mediation

1. Impression-level capture 

The Tenjin SDK fetches impression-level ad revenue (ILRD) directly from your mediation SDK in real-time. Each ad impression íncludes data about the a) revenue value b) user ID c) timestamp and d) placement details

2. User-level attribution

Since Tenjin has already tracked the user through the user acquisition funnel, we assign each impression’s revenue directly to that specific user. 

3. Campaign aggregation 

All impression-level revenue is then aggregated up to the campaign level, channel level, and ultimately the app level. 

“We are able to pull this ad impression and the ad revenue directly from the mediation SDK, and then because we have seen that user on the user acquisition side, we just allocate or assign that revenue to that user and aggregate it down to the campaign level and then the app level.”

How to Calculate Ad Revenue via Channels API 

1. Data collection

Tenjin calls the APIs of all your monetization channels (like Google AdMod, Unity Ads, ironSource, etc.) and pulls aggregated revenue data at the app, country, and date level. It is based on the number of sessions. 

2. Proportional allocation 

This aggregated revenue is then allocated to your user acquisition campaigns based on the number of sessions generated by each channel. 

“This revenue is your daily payouts, right? So this is the actual ad revenue that you made on that particular date—the money that actually came into your app because of the ads that the users saw.” 

Why report more than one IAA ad revenue source? 

If you look at Tenjin’s insights dashboard, we display both ad revenue sources side-by-side in the UA Report. But, we don’t report two sources of IAA to be redundant, there’s a strategy behind all of this. Here are the four main reasons why we decided to calculate revenue this way:

広告収益アトリビューション

It may reveal your value, but there is not one simple answer for how to go about ad mediation. While there’s no universal solution, selecting the right attribution method is a priority since it dictates your evaluation framework for measuring all ad campaigns, creatives, ad networks, and sources. Your chosen method directly impacts the accuracy of key metrics like ROAS and LTV. 

Additionally, cross-referencing multiple attribution models enhances data accuracy and provides deeper performance analysis. 

Cross referencing and our featured split view is exactly why we’ve created IAA revenue in this manner. This split view allows you to track LTV and other campaign metrics by allocating value to individual sessions. Because our IAA has more than one ad revenue source, it means that we are also able to provide two types of LTV for ad revenue. 

Ad Mediation LTV 

Your mediation provider sends Tenjin the bid amount for each ad impression. Tenjin then totals this revenue per user and breaks it down by acquisition channel, campaign, and country. This is directly related to Ad Mediation revenue. 

Ad Revenue LTV

This approach estimates ad revenue using session data from the Tenjin SDK. Each session from the same user within the same channel, campaign, and country is assigned equal monetary value. This method is directly related to ad revenue via Channels API.  

Curious to learn how we calculate aggregate-based revenue LTV? Read our case studies with クアプス と ハイパーベアード to find out. 

In our ダッシュボード, you are able to compare the two different sources of ad revenue directly to IAP LTV, or in any combination you desire. 

Detecting Invalid Ad Requests

Another reason for using two types of streams in our IAA to account for any irregularities between the two. Large discrepancies may point to invalid ad requests. If there are large differences in Ad Mediation Revenue and Ad Revenue via Channels API, then this is often a signal of fraud detection. As Anurag warns:

 “There is a lot of fraud sometimes happening through user acquisition channels… If there’s an inflated number of ad impressions that a fraudulent user generated, your Ad Mediation Revenue is going to look inflated. But the Ad Revenue via Channels API… is not going to be inflated because that’s the actual revenue that you’ve made from these users.”

When fraudulent users enter your app through compromised user acquisition channels, they often generate artificially inflated ad impressions: 

• Ad Mediation Revenue (from SDK) will show inflated numbers because it’s capturing every impression, including fake ones
  

• Ad Revenue via Channels API (actual payouts) will show accurate, lower numbers because ad networks only pay for legitimate impressions

Invalid Ad Request Signals:

• Discrepancies exceeding 15-20% between the two sources

• Specific campaigns showing unusual spikes in Ad Mediation Revenue

• Revenue patterns that don’t align with user behavior metrics 

Differences in Calculation Logic

It’s important to understand that some discrepancy between the two measurements is normal and expected. “Both are accurate. They just use different logics for calculation,” Anurag clarifies. “So it’s not necessarily that one is more accurate than the other.” Rather, he reinforces that: 

“The idea is to give you access and insight into all the sources of ad revenue that exist.”

It’s normal to see some differences because there are two ways of calculation: session and impression-based. Another reason for discrepancies can be as simple as the timezone difference between mediation providers and the ad networks. Yet, another difference could be due to delayed API reporting or currency conversion timings. These all seem quite reasonable reasons for why there could be a difference within your data. 

The issue is when there are more abnormalities. For example, when these discrepancies between the data are 15-20% or above, then there should be an investigation into their validity. However, it might not always come down to fraud detection. Integration issues with the mediation SDK could be another reason why there are major differences between reported revenue types. Besides integration issues, missing ad network connections in API channels should also be checked. Moreover, there could also be issues with how sessions are recorded. 

Holistic Visibility for Revenue 

Sometimes ad networks may exist outside your ad mediation stack. The Channels API ensures you’re capturing all revenue resources for a more complete picture.

“A lot of times there might be ad networks that you’re using separately outside of the mediation provider that you have,” explains Anurag. “Like, your stack might not have that ad network in the mediation side. So it’s always another source that you have that you can use to look at where your ad revenue is coming from.”

Practical Takeaways

Accurate ad revenue calculation isn’t just about reconciling numbers. It’s also about protecting your profitability and making smarter growth decisions. 

By leveraging dual-source revenue tracking through both ad mediation and channels API, you gain the complete visibility needed to optimize ROAS, detect fraud before it drains your budget, and capture revenue from every monetization channel in your stack. 

When discrepancies arise, you now have a framework to investigate systematically rather than guess. Whether you’re scaling user acquisition, defending against invalid ad requests, or simply trying to understand where your revenue really comes from, this two-source approach gives you the confidence to act on your data.

• Dual-source revenue tracking gives you complete revenue visibility and a robust fraud-detection framework.

• Differences between the two sources are normal but actionable. When large discrepancies appear, it can indicate fraud, integration issues, or gaps in network connections.

• Ad Mediation Revenue is essential for real-time ROAS optimization due to its impression-level data and instant network callbacks.

• Ad Revenue via Channels API adds breadth by incorporating channels outside your mediation stack, improving revenue completeness and serving as a benchmarking metric.

Want to see this framework in action? Watch our team explain why our customers are huge fans of how we calculate revenue for in-app purchases: