Ad network mediation setup in a mobile app

Why ad network mediation fails to drive revenue

In an app, most often a single network is connected — the one whose manager was first to send access. While traffic is small, that is enough: block fill rates are close to 100%, and revenue from impressions grows along with the audience.

But as soon as some impressions go to geos with low demand or to older devices, the single source stops buying inventory, and impression revenue starts to drop out of nowhere. The losses are unnoticeable: reports show growth, while revenue per active user falls.

The second common mistake is manual ad rotation. Priorities are set once and never revised: a network with worse bids continues to take top positions, while a more profitable partner gets the remainder.

No one compares how much the same impression would have earned in an auction, so the decision on source order is made by intuition, not data.

The third is fill-rate gaps across part of the audience. Ad network mediation is not broken down by segment: different formats, placements and traffic types go into a common flow, and where one source does not serve ads, the second is not even requested.

In logs this shows up as empty responses that no one analyzes, while the share of unsold inventory accumulates for months.

The root cause is one: mediation setup is reduced to inserting keys, without priorities, timeouts and regular bid revision. Below we break down how to address this.

What a unified in-app auction delivers

The auction model replaces a sequential waterfall: the app sends one request, networks respond with bids simultaneously, and the impression goes to the winner.

In a waterfall, the next source was connected only after the previous one refused, so some requests ended with an empty response, and a chain of timeouts stretched screen loading.

In a unified auction, the mediator makes the decision — based on the actual bid, not on manually set priorities.

Impression fill rate grows: all connected networks compete, and the request is filled where the waterfall previously went to the end of the list. Revenue per active user rises not through impression volume but through the price of each one — it is determined by the winner's bid.

At the same time, the share of empty impressions and the time to render an ad block fall: instead of a chain of sequential calls, one is executed.

Automatic rotation redistributes traffic according to actual segment results: a network that pays better for the audience of a specific platform or country gets a larger share of requests without manual reconfiguration.

Before switching, we take a baseline snapshot and compare fill rate, revenue per active user and distribution across networks on comparable traffic — otherwise growth can easily be attributed to seasonality.

Technically, this relies on the platform's auction mechanism: Google AdMob aggregates bids from competing networks in a single mediator call and returns a ready ad.

Frequency caps and category filters continue to work on top of the auction — control over what the user sees remains with the app.

Comparison of approaches: mediation vs direct deals

The connection scheme determines who decides and how quickly which ad to show in each impression. A waterfall goes through networks sequentially: until the top one responds with a refusal, the others wait, and some requests are lost to timeouts.

An auction requests bids in parallel and returns the best one within the allocated window — fill grows without manually rearranging priorities.

Direct deals with partners provide fixed terms and control over formats, but each network is a separate integration, its own reporting and manual priority edits when terms change.

A hybrid connection scheme splits traffic: guaranteed impressions go through direct priorities, the remainder goes to the auction.

We compare connection schemes using measurements on real traffic: fill rate, response latency, bid variance by hour.

How setup proceeds: stages of engineering work

Mediation decides which network gets the impression each time a screen opens — a mistake in priority or wait time results in missed impressions. We follow a fixed order: every change is measurable and reversible, and we decide on full rollout based on numbers.

1. Ad inventory audit. We compile ad placement points, formats and networks into a table and reconcile them with actual statistics: where an impression is not filled, where a format interferes with the screen scenario. The result is an inventory map and a list of networks to enable or disable.
2. Priority scheme. We define network order, maximum response wait time, behavior when there is no fill, and impression limits. The scheme is agreed before code — edits here do not require a rebuild.
3. Setup and build. We connect network adapters and app IDs, define rules for rewarded formats, build a release on current mediation library branches and run checks for impression regressions.
4. Test traffic. We release to part of the audience, splitting it into control and test groups by comparable cohorts: then the difference in impressions is explained by mediation, not seasonality.
5. Revenue measurement before and after. We compare revenue per active user, fill rate and impressions per session in both groups and check that growth was not bought by a drop in retention.
6. Handover of control. We provide a dashboard broken down by networks and formats, a change policy and configuration documentation: from there, your team changes priorities and limits itself.

Each stage leaves a trace: it is clear what exactly drove revenue growth and how to restore previous settings if metrics decline.

Documentation, access and rotation rules

Mediation setup does not end when the app stops losing impressions on an empty network response.

Everything we configured in the dashboards must remain with your team in a working and reproducible form — otherwise, a change of priorities or analytics contractor turns into archaeology through chat history. Below is the list of what we hand over to you.

• Transferred configurations — export of mediation groups: network adapters, placement keys, test and production IDs, source weights. They are stored in the repository alongside the app code, not only in network dashboards.
• Connection scheme — adapter initialization order, first impression point, behavior when there is no fill and when the network drops. A diagram plus a description of which code branch is responsible for which scenario.
• Rotation rules — waterfall tiers, minimum bid threshold, impression frequency cap per user, separate sets for first launch and returning users. For real-time auction — a separate rule set.
• Access roles — who logs into network and aggregator dashboards, separate accounts for development and production, mandatory two-factor authentication, financial sections restricted to two responsible persons.
• Revenue reporting — reconciliation of aggregator accruals with network dashboards, breakdown by geo, format and source, reconciliation frequency and owner responsible for discrepancies.
• Update policy and rollback — how network adapters are updated when new versions are released, the procedure for testing on test traffic and storage of the previous configuration set so that rotation can be restored with a single edit.

Case study: impression revenue grew after rebuilding the scheme

The project is an app with a mixed audience: some users subscribe without ads, while the rest stay on a freemium model.

The first mediation scheme was built "by default": the main network AdMob was fixed at the top priority, bids were set manually and not revised, and the backup network was connected only on an explicit response error.

Inventory sat idle — revenue was lost not on impression volume but on the scheme for distributing them.

Initial state

Fill rate held around 62%, and the share of empty impressions during low-demand hours reached 28%: every fourth request went nowhere.

Revenue per active user fluctuated from release to release — some requests were processed under old rules, and the gap between estimated and actual revenue reached 15%.

The biggest losses came from late responses: the main network responded longer than the allotted time, and the backup was not connected at that moment.

Resulting state

We rebuilt the chain: a cascade with network priorities, parallel requests to backup networks and separate rules for the subscription audience so that impressions were not suppressed at the request stage.

Bids were switched to recalculation based on actual data, and disabling a problematic network became manageable — without releasing a new build.

Fill rate grew to 89%, empty impressions fell to 9%, and revenue per active user added about 40% on the same traffic.

The gap between estimate and actual dropped to 3%, and late responses disappeared as a class of failures: the request goes to the backup network before the wait time expires.

What to do if multiple sources are already connected?

If sources are already connected, the task is not what to add, but how to rebuild the configuration without dropping revenue.

Mediation stores state not in the app code but in remote configuration: priorities, shares, response wait time and network polling order come from the server.

Therefore, migration without stopping monetization is done by rolling out to part of the audience, not by releasing a new version to the app store.

Two working scenarios

Testing on part of the traffic is a mandatory step in both cases. We give the new scheme 5–10% of the audience, fixed by device ID, and compare fill rate, response time, failure rate and revenue per user with the control group.

If the gap is within normal fluctuations, we expand the share; if even one metric declines, we restore the previous configuration.

We keep the backup source connected at all times, rather than enabling it in an emergency: then, if the main network fails, the impression goes to it within a single request, without an empty block in the interface.

Rollback is a configuration change on the server, without a rebuild or re-moderation. This way, switching takes days, not release cycles, and monetization does not fail at any step.

Technical questions asked before starting

Before starting, the engineering part comes down to four questions: how the mediation layer coexists with already signed agreements, what happens if a source fails, what the app requirements are and how long the transition takes. Below are answers to what most often comes up in an estimate call.

Implementation risks lie not in the mediation layer itself but in the rollout order.

Therefore, we first raise a copy of the environment, run the source chain on test traffic, and only then enable it in shares — with the ability to return to the previous impression scheme with one setting.

What happens if a source does not serve an ad or responds slowly?

The request goes to the next one in the queue until the impression is filled or the list is exhausted. Each source has its own timeout and retry rule, so a slow partner does not block the screen or leave an empty space.

What are the app requirements and how long does the transition take?

Requirements are minimal: a current app branch, access to a test build and to network dashboards on the client side.

The transition proceeds in stages — layer integration, testing on real traffic, gradual enablement for the entire audience; rollback is done with a reverse setting.

Let's discuss the task and come back with an estimate and plan

So that the scope estimate and work plan are based on facts, not assumptions, we start with source data. Below is the minimum set that is sent for task discussion; we request the rest during the review.

• Current ad network mediation scheme: which networks are connected, how priority is structured, where frequency and impression order rules are set.
• Working access to ad network and aggregator dashboards — not demo accounts, so that real bids, fill rate and reports can be seen.
• Statistics export for a full cycle: revenue by network, share of unfilled impressions, data lag between the dashboard and the aggregator.
• Layout of ad blocks in the app: formats, screens, how impressions intersect with key user actions.
• List of known failures: fill-rate drops, reporting discrepancies, complaints about frequency, app store platform restrictions.
• Build constraints: minimum supported platform versions, composition of ad libraries, app update deadlines.
• Link to a test build and contact of the person responsible for ad inventory — so that approvals do not stretch for weeks.

We review this within a few days and come back with an estimate: scope of work, order of stages, what we change in network priorities, what we check on a test slice. We fix the plan so that each stage can be rolled back to the previous configuration without stopping impressions.