On this page
eCPM is revenue per thousand impressions. Fill rate describes a response outcome relative to a request population, whose exact definition depends on the reporting system. Neither metric alone tells you how much an app earns or whether the advertising experience is worthwhile.
The most useful revenue analysis follows the entire path from an eligible opportunity to a valid impression and finalized revenue. This article defines an explicit example funnel so denominators stay visible. Its numbers are arithmetic scenarios, not observed network performance.
This guide is for AI application developers reconciling advertising with model-serving costs. For general publisher metric definitions, see ADX's eCPM, CPM and RPM guide. We operate both publications; this article's distinct decision is whether the ad funnel supports completed AI tasks, rather than which publisher network pays most.
Define events before dividing them
A user session may contain an eligible placement opportunity. The app may issue an ad request, receive a usable response, load the creative and actually show it. Reporting may later adjust impressions or revenue. Those are separate events.
| Symbol | Definition used in this guide | Important boundary |
|---|---|---|
| O | Eligible placement opportunities | Excludes screens where the placement is not permitted |
| Q | Logical app ad requests | Count once per app opportunity, before partner fan-out |
| F | Requests returning a usable filled response | Does not mean a creative was shown |
| I | Recorded monetizable impressions under the reporting definition | Must use the platform's valid event semantics |
| R | Net revenue for that impression population and period | State provisional versus finalized status |
Some dashboards count partner requests, matches, loads or impressions differently. Map their definitions to your event ledger before comparing them. Never label a server response as an impression merely to make a ratio look stronger.
The formulas
eCPM = R / I × 1,000
request fill rate = F / Q
show rate in this model = I / F
request rate = Q / O
revenue per opportunity = R / OMultiply rates consistently and they reconcile:
R = O × (Q/O) × (F/Q) × (I/F) × (eCPM/1,000)This identity uses the same cohort, time window and compatible counts. If your counts refer to different periods or a request can produce multiple recorded impressions, adapt the model rather than forcing a false equality. Treat zero denominators as unavailable metrics, not zero performance.
Work through a complete example
Assume 100,000 eligible opportunities, 80,000 logical requests, 48,000 filled responses and 36,000 valid recorded impressions. Assume finalized net revenue of $72. These are invented inputs.
The request rate is 80%, fill is 60% and show rate is 75%. eCPM is $72 / 36,000 × 1,000 = $2. Revenue per eligible opportunity is $0.00072. The combined formula gives the same result: 100,000 × 0.8 × 0.6 × 0.75 × $2 / 1,000 = $72.
Now suppose a second assumed setup has a $3 eCPM but produces only 20,000 valid impressions from the same eligible opportunity population. It earns $60. The higher eCPM does not make the second setup more valuable on this revenue definition. You still need experience and operating-cost checks before choosing either setup.
A mediation request is not every partner request
One logical app request may cause several demand-source requests. If you count all partner requests in Q while using only one winning impression population in I, your apparent funnel changes. That is not necessarily an integration bug; it may be an inconsistent reporting boundary.
Keep identifiers for the logical opportunity, mediation request and partner attempts where the integration permits it. Deduplicate events using documented identifiers rather than assumptions about timestamps. When exact joining is unavailable, report the limitation and compare aggregates only at compatible boundaries.
See network, exchange and mediation differences for the architectural distinction. There is no universal rule that every provider uses identical fill terminology.
Segment before interpreting changes
Compare like-for-like format, country, device, app version, placement and consent state where it is appropriate and privacy-preserving. A change in traffic composition can change aggregate eCPM without any improvement in underlying demand.
For example, an invented app shifts traffic toward a higher-value placement while each placement's own eCPM stays unchanged. The overall eCPM can rise because the weights changed. That is a mix effect, not evidence that the SDK optimization increased auction prices.
Avoid overly granular segments that reveal individuals or produce unstable tiny samples. Establish a minimum useful aggregation policy and explain where data is insufficient. A one-day result from a small cohort rarely justifies a general revenue claim.
Distinguish gross, net and cash received
Record which fees, adjustments and revenue shares are included in R. Estimated in-product revenue, finalized partner revenue and bank receipts can differ because of reconciliation, settlement timing, deductions or currency conversion. Do not compare one provider's gross estimate with another's finalized net amount.
Keep a reconciliation sheet: reporting period, source statement, currency, impressions, estimated revenue, adjustments and final revenue. Preserve original figures and explain revisions. Payout timing is a cash-flow consideration separate from the economic value attributed to impressions.
Diagnose the stage that is failing
Low Q/O can result from intentional eligibility rules, consent state, disabled placements or a request bug. Low F/Q can reflect demand, configuration or failures. Low I/F can indicate a placement that loads too late, navigation away, rendering issues or inaccurate event handling. Investigate rather than assuming every decline comes from the network.
Track latency and failure class alongside each stage. A request that eventually fills after the user leaves does not improve the task experience. Verify lifecycle handling during backgrounding, orientation changes and screen destruction on the actual target runtime.
For ADX, check the runtime and rendering support documented for your integration. The event ledger should describe real client behavior; it must not manufacture a viewed impression from a successful server request.
Add product guardrails
Connect the funnel to accepted AI work. In a hypothetical extension of the $72 revenue example, suppose the same cohort completes 30,000 tasks at an effective variable cost of $0.004 per completed task, including retries. Task costs are $120 and contribution before other costs is −$48. Revenue per completed task is $0.0024. These assumptions are invented and do not predict an achievable eCPM or inference price.
If task volume doubles while valid ad impressions stay fixed, revenue does not double with it. Count repeated model calls and failed attempts in effective task cost. Separate a lower model bill, a higher ad show rate and a smaller free allowance as different experiments; changing all three at once prevents a useful diagnosis.
The metric formulas use the same principle as Google's reporting definitions: preserve the event denominator and revenue basis. The task-cost extension above is original arithmetic, not vendor reporting.
Advertising can increase revenue while reducing completed tasks, retention or trust. Define a useful-session measure and observe crashes, accidental interactions and complaints. For AI apps, track inference contribution as well: additional ad impressions do not automatically pay for additional model calls.
Use the AI app monetization model to connect revenue and task cost. If you experiment, keep cohort assignment and eligibility rules stable, document changes and report uncertainty rather than declaring a winner from an isolated eCPM peak.
Build a dashboard people can audit
Show counts next to rates, name each denominator and include the time zone and reporting status. Display unavailable values clearly. Link a metric to its event definition and known exclusions so another developer can reproduce the calculation.
Start by reconciling one placement for one fixed reporting period. Confirm that the funnel counts and revenue describe the same population. Once that is reliable, expand segmentation and experiments. A trustworthy denominator is more valuable than an impressive-looking percentage nobody can explain.