Yandex Mobile Ads integration: where an app loses revenue
Ad integration in an app is most often built simply: the request goes out when the screen opens. On an unstable network, the response does not arrive before the user moves on — the request was sent, no impression occurred, and it is reported as empty. The audience is the same, but revenue per user drops.
The second loss point is how the request reaches the auction. If formats are not matched to the screen size and context, some requests go there without competition, and some do not arrive at all: the slot remains empty or is filled with the cheapest option.
A separate case is an impression that is counted when the screen is no longer visible: the network does not accept it, while the app wastes traffic.
The third cause is settings configured once at launch. Frequency caps, the order of switching between networks, behavior when there is no fill, bid updates in Yandex Ads after an audience change — all of this affects mobile app monetization more than is commonly thought.
The gap between the number of requests and the number of counted impressions is the app's revenue loss — it is visible in reports even before changes. Below we break down how each of these points is closed and which metrics we consider confirmation of the result.
What correctly configured in-app advertising delivers
In-app impressions are a manageable resource, not a case of "turned it on and it works." Impression frequency per user, the set of formats (interstitial, rewarded, banner), and trigger points determine how many ad events each active user receives per session.
The rewarded format changes the logic: attention is exchanged for in-game value, and such an impression is not perceived as a nuisance.
Fill rate is maintained by mediation: the request goes to several sources with priorities and timeouts, and a fallback kicks in on an empty response.
Yandex Mobile Ads operates as one of the demand sources — its share of the traffic is set by weights, so a drop in one channel does not zero out in-app impressions.
Revenue from traffic grows without attracting a new audience: the same session produces more impressions at high bids, and the frequency cap does not burn out the user.
Interstitial and rewarded impressions are placed at events — level completion, return to menu — rather than in the middle of data entry or payment.
For retention, predictability matters more than quantity. Limiting impressions per hour, excluding the first session, and pausing after a failed action reduce irritation, while impressions per active user remain the same.
The result is visible in reports: fill rate stays at the target level, revenue from traffic and revenue per active user grow, and app uninstalls after ad sessions do not become more frequent. We compare these metrics by cohorts before and after revising the scheme.
Ad formats and ad network mediation modes
Ad format and network connection method are two independent decisions, and confusing them is costly.
Rewarded advertising relies on voluntary viewing and delivers the highest response, interstitial insertions monetize pauses between actions, and native blocks fit into the feed and do not break the layout.
The format is chosen for the scenario, but if there is only one network, the app quickly hits a ceiling: for part of the audience, no impression is found at all.
The ready-made formats of Yandex Mobile Ads cover the basic scenario with a single integration, and beyond that, ad network mediation is needed — the request goes to several sources, and the impression is taken by whoever offered the best terms.
| Option | When it fits | Limitations |
|---|---|---|
| One network | Fast launch, one format, predictable audience | Fill rate drops in narrow geos and during low-demand hours, and there is no fallback if the source fails |
| Ad network mediation | Several formats at once, high fill rate required | Priority rules and control over block load latency are needed |
| Priority auction | Mature traffic, there is room to manage bids | Revenue is harder to predict, per-source analytics is required |
A priority cascade is easier to debug and predictable in response time; a unified auction redistributes traffic more precisely but requires its own analytics.
We lock the scheme in the mediation configuration — formats are enabled one at a time and changed without rebuilding the app.
Implementation stages: from placement audit to handover of settings
Ad implementation in an app starts not with connecting a library, but with a monetization audit. We look at which screens the user passes through, where they linger, where they close the app, and compare this with already connected sources, including Yandex Mobile Ads.
The output of this stage is a placement scheme: how many blocks, on which screens, at what frequency, and how they yield to each other.
- Audit of scenarios and current monetization: screen map, session duration, drop-off points, list of active sources.
- Placement scheme: a format for each screen — banner, interstitial at natural pauses, rewarded on user action, native within content.
- Ad block setup: a separate identifier per format, source order in the chain, intervals between impressions, behavior when there is no fill.
- Impression testing on real builds: test devices, runs on weak internet and offline, fill rate by region, correct closing and return to the app.
- Calibration by metrics: impression-to-request ratio, impact on retention and session depth, frequency adjustment where drop-offs grow.
- Handover to the team: configurations, block list, documentation, and rules for changing frequencies without releasing a new app version.
Configured blocks, placement schemes, and documentation
Work with in-app advertising does not end with connecting Yandex Mobile Ads — the value remains in artifacts that outlive the release.
Without them, every next change starts with archaeology: where the block was placed, why it has exactly that interval, why a source was disabled when fill dropped. That is why we hand over a complete package to the client, not verbal agreements.
- Placement map — screen, position in the layout, block format, behavior on scroll, and lazy-loading logic.
- Block configurations — identifiers, binding to impression placements, source priority in mediation, conditions for enabling a backup source.
- Frequency rules — intervals between impressions, restrictions at session start, behavior on a weak network, and per-screen limit.
- Impression policy — what to do on an empty response, timeout, and initialization error, and when the block is hidden entirely.
- Developer instructions — how to add a new block, which checks to pass, how to switch a source without releasing a new build.
- Monetization documentation — which metrics we collect (impressions, fill, retention) and how decisions about moving blocks are made from them.
- Diagrams and acceptance checklist — initialization order, failure handling, procedure for rolling back the configuration to the previous working version.
The package lives next to the code, not in chat: the placement map is updated together with screens, frequency rules are moved into configuration, and instructions describe actions that do not require the integration author's involvement. A new engineer adds a block from the document without reconstructing the history of decisions.
Case study: how impression fill rate grew after improvements
The client is a service with a daily usage scenario: the user opens the app several times a day, but sessions are short.
Monetization relied on one Yandex Mobile Ads ad unit and one format that was triggered only when entering the feed — so fewer impressions were requested than there were transitions between screens.
What it was like
Impression fill rate stayed around 46%: some requests did not manage to get an ad within the allotted waiting time, and some arrived when the screen was already closing.
There were 2.8 impressions per active user per day, and drop-off on screens with ads reached 21% — more than half left in the first seconds after the insertion.
What we changed
We separated impressions by screens and scenarios: one format on transitions between sections, a second within the feed, and a third on demand, in exchange for bonus content.
We configured ad preloading, the request order when the primary source is unavailable, a per-user frequency cap, and a soft wait for the response so an empty response would not block the interface.
An impression no longer starts until the screen is rendered: the ad stopped overlapping buttons and provoking closure.
What the result was
Fill rate grew from 46% to 88%, impressions per active user from 2.8 to 7.4 per day, drop-off on screens with ads fell to 7%, and complaints about intrusiveness became almost three times fewer.
We compared with a control group where the impression order remained the same: metrics there did not move, so the increase in impressions was not attributed to seasonality.
How direct Yandex integration differs from network mediation
Direct ad connection is when the app calls a single network and gives it the entire slot. The path from request to creative is shorter, there are no intermediaries, and on traffic where the network competes for audience, revenue per impression is higher.
The flip side is that fill rate equals one network's inventory: in a rare geo, at night, or during an outage on its side, the block remains empty, and that impression is lost irreversibly.
Network mediation puts an arbiter layer between the app and advertisers.
Two mechanisms are at work: network priority — a queue where a network is called based on a known-in-advance revenue per impression, and impression auction — networks compete for each specific impression in real time.
The queue is easier to set up and more predictable; the auction squeezes more out of quality traffic but requires honest statistics: on bad data, it starts giving impressions to the cheapest networks.
The comparison of approaches comes down to the task. Where stable revenue and fill rate close to 95% on any device are needed, mediation wins: if one network did not deliver a creative, the next one by priority picks up the slot.
Where control over formats, predictability, and the maximum bid on your own traffic matter, direct connection wins.
In practice, we more often assemble a hybrid: the bulk of traffic is covered by a direct connection to Yandex Mobile Ads as the first-priority source, while mediation insures against fill failures.
To choose a configuration, we enable both options on comparable audience segments and look at fill rate, revenue per thousand impressions, and the share of blocks left without ads.
We rebuild priorities based on actual data, not network promises: a queue set approximately quietly loses revenue percentage points for no apparent reason.
Common technical questions about in-app advertising
The first question is usually about timelines. A test impression launches the same day on a test block identifier.
Production ones are enabled after account moderation and payment details are filled in — this takes several business days and does not depend on the code: if the app is already built, the delay almost always sits in the account settings.
The second is "the network is connected, but there are no impressions." Diagnostics proceed along the chain: the ad module initializes before the first screen, the request goes out with a valid identifier, the network response arrives and is logged, and the ad renders in the allocated area.
A break at any step produces an empty block without an error — that is why we log each stage separately instead of guessing at the cause.
The network is already connected, but there are almost no impressions — what do we check?
First we rule out integration errors: initialization timing, identifier validity, available space for the banner, behavior on orientation change and app minimization. If the code is clean, we look at the network's own settings — geography, content category, frequency caps. Beyond that, it is a matter of fill, not development.
Who is responsible for restrictions on the network side?
Fill rate, geography, anti-fraud, and moderation rules are set by the ad network Yandex, and we do not influence them.
Our area is a correct request, screen readiness, and transparent statistics: you see how many requests went out and at which step they were cut off, and with that you can already go to the network's support.
Advertising hurts the user experience — is that limited in any way?
We set the formats and frequency: interstitial ads only between screens, not over actions, an impression limit per user per session, and disabling on paid tiers. These are configurable parameters, not a one-time compromise — values change after launch without rebuilding the app.
Let's discuss the task and come back with an estimate and work plan
You can discuss the task at any stage — when the app is only being designed or already lives in the stores and needs an ad block. For the project estimate to be accurate rather than "by eye," engineers need a product description and access to the current code. Then we calculate timelines by stages, not as a single number for the entire scope.
What to send to start:
- a brief app description: platform, audience, and what stage the product is at — development, release, or support;
- screens and impression scenarios: between levels, after an action, in the feed, on pause;
- required formats — banner, interstitial, rewarded for viewing, native;
- access to the repository or build if the integration is going into an existing product;
- access to the ad network account and test identifiers for ad placements, if they have already been set up;
- metrics by which you will accept the work: fill rate, retention, impact on conversion.
Work starts after the plan and scope of the first iteration are agreed.
We assemble the plan in the order of actual integration: placement markup, connecting the ad network in test mode, testing on real devices and a weak network, then release and project handover with documentation for setting up new blocks.
This allows you to change frequency and scenarios without contacting us. Describe the task — we will come back with a project estimate, work plan, and timeline proposal.