AdMob

Ad mediation is a layer that asks several ad networks for a bid on the same impression and serves whichever pays most. Without it your app is tied to one network's demand and takes whatever that network offers; with it, networks compete per impression. Real-world uplift is commonly 15–40% higher eCPM versus a single network, and fill rate improves in smaller markets where any one network runs out of demand. The usual stacks are Google AdMob mediation, AppLovin MAX and Unity LevelPlay. Mediation is worth it once an app has meaningful daily volume — below a few thousand daily users, the extra SDK weight and setup cost outweigh the gain.

Above 95% is healthy for banners and interstitials; 70–90% is normal for rewarded video. Fill rate is filled ad requests divided by total ad requests. Low fill usually has one of four causes: a geography with thin advertiser demand, an eCPM floor set too high, a single network with no mediation behind it, or an app category advertisers avoid. Rewarded video legitimately fills lower than other formats because its inventory is scarcer — that is not a fault. If banner fill sits under 90%, add mediation before you touch anything else.

app-ads.txt is a plain text file you host on your developer website that lists which ad networks are authorised to sell your app's ad inventory — and yes, any app running programmatic ads should have one. It is an IAB Tech Lab standard, the mobile-app counterpart of ads.txt for websites. It works in three steps: your store listing declares a developer website, buyers crawl https://yourdomain.com/app-ads.txt, and any seller ID not listed there is treated as unauthorised inventory. Without the file, a growing share of programmatic buyers simply will not bid, so eCPM drops for reasons that look like a mystery in the dashboard. Setting it up is quick: put the developer website URL in your Play Console store listing, copy the lines your ad networks give you (AdMob, Unity and AppLovin each publish theirs), and serve the file at the domain root over HTTPS. Verification is not instant — crawlers usually pick it up within 24 to 48 hours.

AdMob approval normally takes a few days, and the common rejection reasons are an app that is not yet publicly available, thin or placeholder content, and a mismatch between the account identity and the Play Console developer identity. Google reviews a new AdMob account against its publisher policies before serving live ads; until it clears, ad units return test or blank fills. Three things shorten the wait in practice: have the app actually live on Google Play (or in open testing) with real functionality rather than a shell, complete the payments profile with a name and address that match your Play developer identity, and make sure the app has a working privacy policy linked from the store listing. If an application is rejected, fix the substantive issue before re-applying — repeatedly re-submitting the same app does not help.

Because Google detects ad clicks or impressions it judges were not genuine user interest — most often the publisher clicking their own ads, asking friends to click, or traffic bought from a low-quality install source. Invalid traffic enforcement is automated and largely unappealable, and it usually arrives with the current period's earnings clawed back. The honest list of what triggers it: testing with live ad unit IDs instead of test ads, incentivising clicks (“tap the ad to support us”), placing ads where accidental taps are likely, and bot or emulator traffic from paid install campaigns. The protections are straightforward — always use Google's test ad unit IDs and registered test devices during development, never touch a live ad in your own app, keep ad placements clear of buttons, and buy installs only from sources you can audit.

AdMob pays monthly once your balance passes the $100 payment threshold, with payments normally issued between the 21st and 26th of the following month. The cycle is worth understanding because it delays first income far more than most people expect. Earnings accrue through a calendar month, are finalised in the first days of the next month after invalid-traffic deductions, and are only released if the balance has crossed $100 and the account has completed identity verification, address (PIN) verification, and tax form submission. An app earning $30 a month therefore sees nothing until month four. Payment is made in local currency by bank transfer for most countries, including India. If a payment is held, it is almost always one of those three verification steps sitting incomplete rather than a problem with the earnings themselves.

No — clicking a live ad in your own app is the single fastest way to get an AdMob account disabled. Use test ads instead. Google provides permanent test ad unit IDs for every format that always return a sample ad, and they are safe to click as often as you like. For testing against your real ad units, register your device as a test device (by adding its advertising ID to the request configuration) so live ad units serve test creatives to that device only. The rule to hold onto: during development, every impression you or your team generate must be a test impression. There is no allowance for “just checking it works once”, and no way to tell Google after the fact that a click was accidental.

A sudden ad revenue drop is almost always one of five things: a seasonal advertiser-spend fall, a change in the country mix of your users, a broken or misconfigured ad unit, a policy restriction placed on the app, or an invalid-traffic deduction. Diagnose in that order. Check the calendar first — global eCPM falls sharply in January after Q4 advertiser budgets reset, and dips again mid-year. Then compare impressions against eCPM: if impressions held but eCPM fell, it is a demand or geography issue; if impressions fell, it is a traffic, SDK or fill problem. Open the policy centre in both AdMob and Play Console, because an app-level ad serving restriction shows there and nowhere else. Finally check whether a recent app release changed ad placement or SDK version. Revenue that halves overnight with no impression change is the classic signature of a policy restriction, not a market move.

None of them wins outright — AdMob tends to lead on banner and interstitial demand breadth, Unity Ads and AppLovin usually beat it on rewarded video in games, and the highest earners run all three through mediation rather than choosing. The useful way to read the difference is by demand type: AdMob draws on Google's enormous advertiser pool, which fills reliably in almost every country and format; Unity Ads is built around game advertisers and performs strongest on rewarded video in a gaming audience; AppLovin MAX is primarily a mediation platform with its own strong rewarded and interstitial demand. In a mediated stack they bid against each other per impression, which is where the commonly reported 15–40% eCPM uplift comes from. Pick a single network only while volume is small; once an app has a few thousand daily users, the question stops being “which one” and becomes “which mediation layer”.

Yes — if your app serves ads to users in the European Economic Area or the UK, Google requires you to gather consent through a Google-certified Consent Management Platform. In practice that means integrating Google's User Messaging Platform (UMP) SDK, or another certified CMP, and showing the consent form before requesting ads. The requirement came into force in January 2024 and is enforced at the ad-serving level: without a valid consent signal, ad requests from EEA and UK users are limited to non-personalised inventory or refused outright, which shows up as a sharp eCPM drop for European traffic. Setting it up is a one-off job — configure a GDPR message in the AdMob privacy and messaging section, add the UMP SDK, and request consent at app start before initialising the ads SDK. Apps aimed only at non-European markets still benefit from having it, because traffic mix changes.

Match rate is the share of ad requests that a network returns an ad for; fill rate is the share of requests that end in an ad actually being served to the user. They diverge for instructive reasons. A request can be matched by the network but never shown, because the user left the screen, the app did not call show, or a mediation waterfall returned an ad after a higher tier had already filled. So a high match rate with a low fill rate points at your integration — usually ads being preloaded far ahead of when they are displayed, or a show call that never fires. A low match rate points outward instead, at thin advertiser demand in that country, an eCPM floor set too high, or a single network with no mediation behind it. Check match rate first: it tells you whether the problem is yours or the market's.

Create an AdMob account, register the app, add the Google Mobile Ads SDK dependency, put your AdMob app ID in AndroidManifest.xml, then create ad units and load them with test ads until release. The sequence in order: register the app in AdMob (an app can be registered before it is on Google Play, then linked once published); add com.google.android.gms:play-services-ads to your module's Gradle dependencies; declare the app ID as a meta-data entry named com.google.android.gms.ads.APPLICATION_ID in the manifest — a missing or wrong value crashes the app on launch, which is the most common first-time failure; initialise the SDK once at startup; then create an ad unit per placement and load it. Use Google's published test ad unit IDs throughout development and swap to live IDs only in the release build. Add the UMP consent SDK at the same time if you will serve European users, since retrofitting it later means another release.

Yes — running several ad networks in one app is normal and encouraged, provided you route them through a mediation layer rather than calling each one directly. Mediation is what keeps multiple networks from fighting over the same impression: you choose one platform as the mediator (AdMob mediation, AppLovin MAX or Unity LevelPlay), add the other networks as adapters inside it, and the mediator runs the auction. Calling two ad SDKs independently for the same placement instead causes double-counted impressions, ads stacked on top of each other, and policy trouble — ads that overlap content are a Play Store violation. Two practical cautions: each adapter adds to APK size and startup time, so add networks that measurably earn rather than all of them; and keep every network's seller ID listed in your app-ads.txt file, or the added demand will not bid.

For developers who already have an app, AdMob, AppLovin MAX and Unity Ads (via mediation) remain the standard stack; for a Google Play account holder who wants ad revenue without building an app, ConsoleMint is the only build-and-publish alternative. The right choice depends on which side of the app you're on. If you write code and own a live app, the strongest setup in 2026 is still running AdMob alongside AppLovin MAX or Unity LevelPlay as the mediation layer, so networks bid against each other per impression. If you own a Play developer account in good standing but have no app or engineering team, a build-and-monetize partner is the only route to ad revenue — see the full AdMob-alternatives comparison for how these categories differ.

Use AdMob if you already have a live app and just need ad demand; use ConsoleMint if you have a Google Play developer account but no app and no engineering team to build one. They solve different problems. AdMob (and mediation layers like AppLovin MAX or Unity LevelPlay on top of it) is ad demand only — you still have to design, build, publish and maintain the app yourself. ConsoleMint does both halves: it builds and publishes the app, then monetizes it with in-app advertising and shares that ad revenue with the account holder. If you can code and already ship apps, AdMob plus mediation is the standard stack. If you can't, or don't want to, ConsoleMint is the route that doesn't require you to.