AdMob Mediation for Indie Apps: Setup, Testing and Revenue

AdMob mediation routes each eligible ad request across multiple demand sources so they compete for, or are sequenced toward, the impression. Google’s mediation guide describes two mechanisms: real-time bidding and an eCPM-ordered waterfall; a group can use both.

In bidding, participating sources submit prices in a server-side auction. In a waterfall, AdMob calls sources in order using configured or optimised eCPM values until one fills. The winning ad still needs to load and render, so auction price is only one part of realised revenue.

• Request: The app asks the Google Mobile Ads SDK for one format and ad unit in a defined context. Consent, geography and eligibility shape the candidate set.
• Auction: Bidding sources respond in parallel where supported. The highest eligible bid competes with AdMob demand.
• Waterfall: Configured sources are attempted in sequence if needed. Latency grows when slow sources repeatedly fail.
• Impression: Revenue exists only when an eligible creative actually renders. Track show rate after match rate.

Decision rule: Optimise the complete request-to-impression path rather than celebrating a high bid or isolated eCPM.

The part that surprises most first-time integrators is latency. Each waterfall step is a sequential network call, so a six-tier waterfall can spend several seconds before an ad renders, and users leaving during that window cost more than the impression was worth. Set an explicit timeout per tier and a total budget for the request, then measure fill against time-to-fill rather than fill alone. AdMob's mediation overview describes the request path; the practical discipline is deciding in advance how long an ad is allowed to take before you show the app instead.

Instrument the request path before adding partners, or you cannot tell a demand problem from a latency problem. Serving limits produce similar symptoms from a different cause.

Use mediation when advertising is already a meaningful revenue stream and another source can add genuine demand coverage without overwhelming the team. A new app with a few hundred daily impressions should usually improve placement quality, consent and retention before integrating several networks.

Mediation has fixed operational cost: SDK integration, privacy disclosures, partner accounts, payment reconciliation, creative-quality review and upgrade work. At low volume, revenue variance can look like uplift while the extra complexity is permanent. Estimate incremental net revenue, not theoretical auction density.

• Volume: Count eligible requests by country and format, not total sessions. Partners need enough comparable traffic to evaluate.
• Concentration: Check whether one geography, platform or placement creates most revenue. Add demand where the gap actually exists.
• Capacity: Name who owns adapter updates, policy changes and discrepancies. No owner means silent decay.
• User cost: Baseline latency, crash-free users and retention before changing the stack. You need a counterfactual.

Decision rule: Proceed when a specific partner has credible coverage for a valuable cohort and the plausible monthly uplift exceeds integration and ongoing ownership cost.

Run the arithmetic before the integration, because mediation has a fixed cost that small inventories do not repay. Estimate the uplift you expect — a realistic band for a second network is single-digit to low-double-digit percentage on eCPM, not a multiple — and multiply it by current ad revenue. Compare that against SDK maintenance, review risk, added crash surface and the engineering weeks involved. AdMob's optimisation documentation is worth reading before committing, because much of the available uplift comes from configuration rather than from adding networks.

Below roughly a few thousand daily impressions, tuning formats and placements usually pays better than mediation. Blending ads with other revenue may move the number further.

Start with two or three partners chosen for geographic demand, format fit, payment reliability and maintained adapter support—not a logo checklist. AdMob publishes source setup instructions and partner-specific requirements; read them before opening accounts or shipping SDKs.

A partner strong in US rewarded video may add little to Indian banner inventory. Ask for evidence at the country-format level, verify minimum payout and tax paperwork, and confirm whether the source supports bidding, waterfall or both. Prefer a reversible first integration.

• Demand fit: Request recent country-and-format coverage rather than a global eCPM claim. Your inventory mix decides relevance.
• Technical fit: Check adapter versions, SDK footprint, platform support and release cadence. Abandoned adapters create security and build risk.
• Commercial fit: Review payment threshold, terms, currency, deductions and reporting access. Gross estimates are not cash received.
• Policy fit: Assess creative controls, child-directed treatment, consent signals and data use. Your app remains accountable for the stack.

Decision rule: Rank partners with a weighted scorecard and integrate the highest-confidence source alone before adding the next.

Choose partners by whether they actually buy your inventory, which is a question about geography and format rather than brand recognition. A network with strong demand in North America adds little to an app whose users are largely in India or Indonesia; a network strong in rewarded video adds little to a banner-only app. Ask each prospective partner for fill and eCPM in your top three markets for your specific format before integrating. AdMob's partner documentation lists the supported adapters, which constrains the shortlist more than most teams expect.

Check policy fit too: one partner's creative standards can jeopardise the whole app. Platform comparison covers the wider landscape.

Create separate groups for each platform and format, then add geographic segmentation only where demand economics or policy treatment materially differ. Google explains that groups target combinations of format, platform, app, ad unit and country, with priority resolving overlaps.

A small number of mutually understandable groups is safer than a maze. Name each group so another operator can identify platform, format, market tier and purpose. Avoid duplicated ad units across overlapping groups unless priority behaviour is deliberate and documented.

• Platform: Keep Android and iOS separate because adapters, consent and demand can differ. Never assume parity.
• Format: Separate banner, interstitial, rewarded and native inventory. User intent and economics are different.
• Market tier: Group countries only when they share observed demand behaviour. Do not create country groups from stereotypes.
• Priority: Document which group should win every overlap and why. Test with representative requests.

Decision rule: If the on-call owner cannot predict which group handles a sample request, simplify the structure before launch.

Keep the group structure as flat as it can be while still separating things that genuinely price differently. Every additional dimension multiplies the number of groups, and each group needs enough daily volume to produce a readable signal — split too finely and you are tuning noise for months. Start with platform and format, add market tier only where eCPM genuinely diverges, and resist per-country groups until volume justifies them. AdMob's mediation group documentation explains how eCPM values order the waterfall, which is the mechanism the whole structure depends on.

Name groups so a stranger can read the configuration. ARPU benchmarks give context for whether a tier is worth separating.

Use bidding for supported real-time competition and retain a short, evidence-based waterfall where it adds fill or specialised demand. Google’s bidding FAQ says a source may be used in bidding and waterfall and recommends both where available, subject to the partner’s setup.

Bidding reduces dependence on manually ordered historical averages. Waterfalls remain useful for sources or arrangements outside bidding, but every added call can cost time. Optimised eCPM also needs enough data, so do not treat the ordering as immediately perfect.

• Bidding role: Let eligible sources price the current impression rather than a historic average. Validate that consent and mapping allow responses.
• Waterfall role: Use a small sequence for incremental fill or direct arrangements. Remove sources that rarely render.
• Hybrid risk: Prevent duplicate or misconfigured instances from creating misleading reports. Follow partner mapping instructions exactly.
• Latency budget: Measure request duration at placement level and by connectivity. A timeout is a product cost.

Decision rule: Keep a source only if its incremental rendered revenue exceeds its latency, stability and operating cost in the measured cohort.

Bidding and waterfall answer different questions, and mixing them badly is the usual source of unexplained revenue drops. Bidding partners compete in real time on actual value; waterfall partners are ordered by a historical eCPM estimate that goes stale. A waterfall tier priced above what bidders actually pay will intercept traffic it should not win, so review those floors on a schedule rather than setting them once. AdMob's bidding documentation covers how the two interact. Keep the total latency budget fixed as you add tiers, or fill improves while revenue per session falls.

Move demand to bidding where the partner supports it — it removes the manual floor maintenance. Purchase revenue responds to different levers and should be measured separately.

Integrate one source at a time, pin compatible versions, validate consent propagation and test every lifecycle edge before exposing production traffic. A successful build proves compilation, not correct serving, privacy handling or resilience.

Use the AdMob and partner test modes on physical devices. Exercise cold start, background and foreground transitions, rotation, weak networks, no-fill, timeouts and frequency caps. Confirm test devices cannot accidentally produce live interactions and never ask team members to click production ads.

• Dependency plan: Record SDK and adapter versions plus their compatibility source. Upgrade deliberately, not through an unrelated build.
• Consent path: Verify the user choice reaches every partner before a request. Test deny, accept and unavailable states.
• Lifecycle safety: Do not show interstitials after the intended context has disappeared. Cancel or suppress stale callbacks.
• Failure behaviour: No-fill and timeout must return control without blocking the user. Advertising is an optional dependency.

Decision rule: A partner does not enter production until test requests, consent states, app lifecycle and no-fill behaviour pass on both supported platforms.

Treat each adapter as a third-party dependency with its own risk, because that is what it is. Pin versions, read the transitive dependency tree before merging, and check the minimum OS each adapter requires — one partner raising its floor can quietly drop support for a segment of your install base. Wrap initialisation so a partner SDK that fails or hangs cannot block app start, and make the no-fill path render the app normally rather than an empty container. AdMob's consent requirements have to be satisfied before any partner request, and consent must propagate to every adapter rather than to AdMob alone.

Test with consent denied as a first-class case, not an edge case. The compliance checklist covers the declarations this affects.

Run a controlled experiment that changes one mediation decision, protects user guardrails and measures net rendered revenue per eligible user. AdMob’s mediation A/B testing allows 1–50% traffic for Variant B, runs up to 90 days and needs at least 10,000 ad requests before it can determine a result.

The console result should be read with app telemetry because revenue alone can hide slower screens or retention damage. Choose an allocation that can generate a result while limiting risk, and run through weekday and weekend behaviour. Google recommends at least two weeks and changing one setting.

• Hypothesis: Name the source, order or configuration and the mechanism expected to improve value. Do not test a bundle of changes.
• Primary metric: Use estimated earnings or impression RPM with clear eligibility. Keep currency and timezone consistent.
• Guardrails: Watch show rate, latency, crashes, session depth and retention. A revenue lift can still lose users.
• Decision window: Set minimum duration and request count before launch. Do not stop on an exciting first day.

Decision rule: Adopt Variant B only when the revenue improvement survives the full window and no predefined user or stability guardrail fails.

Change one variable at a time and hold it long enough to read. Ad revenue is noisy on a small base, and weekday and weekend behaviour differ enough that a three-day test comparing a Thursday to a Sunday will mislead you. Run at least one full week per variant, use a geography or user-bucket split rather than a before-and-after comparison, and write the guardrails down first: session length, retention and crash rate all belong in the decision alongside eCPM. The Android mediation guide documents the test-ad configuration that keeps development traffic out of production reporting.

A revenue win that costs retention is a loss on a longer horizon. Retention benchmarks give you the comparison base.

Read requests, match rate, show rate, impressions, impression RPM, latency and user outcomes as one funnel. No single mediation metric explains revenue on its own, and eCPM is especially easy to misread without volume.

Requests describe opportunity; matched requests describe available ads; impressions describe what rendered; earnings divided by impressions produces an efficiency rate. A high rate on very few impressions may contribute almost nothing. Calculate revenue per eligible daily active user to connect the ad system to the product.

• Opportunity: Eligible users, requests and requests per user reveal placement volume. Exclude users who should not receive ads.
• Delivery: Match rate and show rate locate demand versus rendering loss. Investigate the transition between them.
• Value: Impressions, estimated earnings and impression RPM describe realised monetisation. Always display volume beside RPM.
• Product: Latency, crash-free users, retention and reviews show the cost side. Segment exposed and unexposed users.

Decision rule: Optimise revenue per eligible user subject to retention and quality guardrails, not maximum ads per session or maximum eCPM.

Watch the funnel rather than the headline, because a single eCPM figure hides where value leaks. Requests, fill rate, show rate, impressions and revenue each answer a different question, and the gap between fill and show is where broken placements and lifecycle bugs hide — an ad that fills and never displays earns nothing while looking healthy in the demand report. Track revenue per daily active user alongside eCPM, since eCPM can rise while total revenue falls if the waterfall is rejecting more requests. The iOS mediation guide covers the callbacks needed to measure the show step accurately.

Add session-level product metrics to the same dashboard. Ad experience is a measurable uninstall driver.

Reports disagree because platforms count different events on different clocks and apply their own currency, invalid-traffic and finalisation rules. A discrepancy is not automatically lost money or fraud; first reconcile definitions and time boundaries.

Compare a closed UTC date range, the same app and ad units, and the same serving relationship. Separate estimates from finalised payments. Confirm whether the partner view includes mediated and direct traffic, and whether AdMob is showing bidding, waterfall or both.

• Time: Align timezone, day boundary and reporting delay. Late events can move between dates.
• Scope: Match app, platform, format, ad unit, country and source instance. Saved filters often cause false gaps.
• Counting: Distinguish requests, bids, matched requests, impressions and clicks. Similar labels may use different triggers.
• Money: Align currency conversion, deductions, invalid traffic and estimated versus final revenue. Finance should use payable values.

Decision rule: Escalate only after documenting the exact metric, scope, time window, expected value and observed value on both sides.

Expect a discrepancy and define the tolerance you will accept rather than chasing exact agreement. Time zones and reporting windows account for much of it, deduplication and click filtering for more, and network deductions and currency conversion for the rest. Reconcile monthly against payment received rather than daily against dashboards, treat differences under roughly ten per cent as normal, and investigate anything larger or anything that trends in one direction. AdMob's reporting documentation specifies the counting definitions; ask each partner for theirs so you are comparing like with like.

Keep a monthly reconciliation sheet with payment evidence. Analytics discrepancies often share the same root causes.

Run a 45-minute weekly review for anomalies and a monthly decision review for partner and placement changes. Continuous console tweaking destroys baselines and turns normal auction variance into work.

Weekly operations should confirm delivery, policy status, adapter health and major movements. Monthly operations can evaluate source contribution, experiment outcomes and placement economics. Quarterly, audit every SDK, data disclosure, account and payment path.

• Weekly health: Check requests, show rate, revenue, latency, crashes and policy notifications against the prior four-week range. Annotate releases and campaigns.
• Monthly decisions: Review incremental source value and one experiment at a time. Remove dead complexity.
• Quarterly governance: Update adapters, consent mapping, privacy disclosures, tax and payment details. Verify account access and ownership.
• Incident lane: Define who can disable a source or placement and how. Keep the remote control tested.

Decision rule: Do not make a configuration change without an owner, hypothesis, observation window and rollback record.

Right-size the cadence to a team that has other work. A short weekly health check on fill, latency and revenue per user; a monthly session for floor and partner decisions; a quarterly review of adapter versions, policy changes and consent handling. The incident lane matters most: define in advance what a partner outage or a policy warning triggers, and who can disable a network without a release. Most small teams discover they cannot turn a partner off quickly, which is the wrong thing to learn during an incident. AdMob's optimisation guidance is a reasonable agenda for the monthly review.

Keep a one-page runbook with the disable path for each partner. Serving limits are the most common incident and have their own diagnosis path.