Ads

A typical free Android app earns roughly $0.50–$3.00 per 1,000 daily active users per day from in-app advertising, which works out to about $15–$90 per 1,000 DAU per month. The spread is enormous because earnings are the product of three numbers: how many ad impressions each user sees, what advertisers pay for that audience, and what share of requests actually get filled. A casual game in the United States showing rewarded video can clear $5 per 1,000 DAU per day; the same game in a low-CPM market showing only banners may make $0.10. Ad income also ramps — a brand-new app earns very little in month one because ad networks need install volume and retention data before they bid seriously on its inventory.

eCPM is effective cost per mille — the ad revenue an app earns per 1,000 ad impressions. The formula is eCPM = (total ad revenue ÷ total impressions) × 1000. If an app served 240,000 impressions last month and earned $720, its eCPM is $3.00. eCPM is the single most useful monetization number because it normalises across formats, countries and networks: it lets you compare a rewarded-video placement against a banner, or US traffic against Indian traffic, on one scale. Watch eCPM per placement, not just per app — one badly positioned banner can drag the whole average down while looking fine in aggregate.

Rewarded video earns the most per impression, interstitials are second, and banners are the lowest. Rough 2026 global averages: rewarded video $8–$20 eCPM, interstitial $4–$12, native $2–$6, banner $0.20–$1.50. Rewarded wins because the user opts in and watches to completion, so advertisers pay for genuine attention. Banners earn least per impression but fire constantly, so they still contribute real volume. The best-earning apps do not pick one — they run rewarded video at natural opt-in moments, an interstitial on a session or level boundary, and reserve banners for screens where a full-screen ad would break the flow.

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.

Indian traffic typically earns $0.30–$1.50 eCPM on banners and $1–$4 on interstitials, with rewarded video reaching $2–$6. That is roughly a quarter to a tenth of United States rates, because eCPM tracks what local advertisers will pay to reach that audience. Two practical consequences: an India-first app needs far more daily active users to hit the same revenue as a US-first one, and format mix matters more — leaning on rewarded video instead of banners can double effective earnings on the same user base. Payments from Google are made in local currency once the account passes the $100 payment threshold.

No — past a point, extra ads reduce total revenue by driving users away. Ad income is impressions multiplied by eCPM, but impressions depend on retention, and aggressive ad load is one of the top reasons users uninstall. Google Play also enforces this directly: ads that interrupt without warning, appear outside the app, or cover content are policy violations that get an app removed. The pattern that actually earns is fewer, better-placed ads at natural breaks — a session boundary, a level end, an opt-in reward — measured on revenue per daily active user over 30 days rather than impressions per session.

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.

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”.

CPM is what an advertiser pays per 1,000 impressions, eCPM is what the publisher actually earns per 1,000 impressions after fill and mediation, and RPM is revenue per 1,000 sessions or users rather than per impression. They are easy to confuse because all three are “per thousand” numbers. CPM is a buy-side price and includes the network's cut. eCPM is the sell-side reality and is the number to optimise: eCPM = (revenue ÷ impressions) × 1000. RPM changes the denominator to something user-shaped, which makes it better for judging whether an ad layout is working, because it captures the case where more ads per session raise impressions while driving users away. A practical habit: optimise eCPM to judge a placement, and RPM or revenue per daily active user to judge the whole app.

Roughly 1,500 to 3,500 daily active users for a US-heavy audience, and 15,000 to 50,000 for an India-heavy one. The arithmetic is simple: monthly ad revenue is approximately daily active users × ARPDAU × 30, where ARPDAU is average revenue per daily active user. Typical ARPDAU for a modestly monetised app runs about $0.01–$0.02 on Indian traffic and $0.10–$0.30 on United States traffic, with well-tuned games reaching higher. So $1,000 a month needs about 1,700 daily users at $0.02 ARPDAU, or 33,000 at $0.001. Two conclusions fall out of that: geography changes the answer by an order of magnitude, and raising ARPDAU through format mix and placement is usually cheaper than buying ten times the users.

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.

Apps aimed at children may only use ad SDKs Google has certified for families, must not show interest-based or remarketing ads, and must keep ads clearly separated from app content. If your app targets children, or targets both children and adults, it falls under the Designed for Families requirements, and the ad rules are stricter than the general policy in four specific ways: only self-certified ad SDKs from Google's published list may serve, ads must be non-personalised, interstitials that are disruptive or appear before a child can understand them are prohibited, and the app must correctly set its target audience and child-directed treatment flags in both Play Console and AdMob. The commercial consequence matters: non-personalised inventory earns materially less, so a children's app typically has a lower ceiling on eCPM and is better served by a monetisation mix that does not depend on ads alone.

Advertising earns a small amount from almost every user; in-app purchases earn a large amount from a very small minority — and for most non-game utility apps, advertising is the more reliable of the two. The reason is conversion: typical in-app purchase conversion on a free app is around 1–3% of users, and in many utility categories well under 1%, so purchase revenue depends on a handful of paying users you may not have. Advertising monetises the other 97% at a low but predictable rate. The strongest apps combine them deliberately: ads as the default revenue floor, plus a paid “remove ads” or premium tier for the minority who dislike them, which converts precisely the users whose ad revenue you lose. Games are the exception where purchases can dominate, because the reward loop creates genuine willingness to pay.

ARPDAU is average revenue per daily active user — total daily revenue divided by daily active users — and the fastest ways to raise it are format mix, mediation and placement, in that order. It is the cleanest single measure of how well an app monetises, because it is independent of how many users you have. Improving it has a reliable sequence: add rewarded video at natural opt-in moments, since it carries several times a banner's eCPM; turn on mediation so networks compete per impression; move interstitials to genuine session or level boundaries where they do not interrupt a task; then tune eCPM floors by country rather than globally. Measure over a 30-day window, not a day — an aggressive change can lift ARPDAU for a week while quietly cutting retention, which reduces total revenue even as the per-user number improves.

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.

An app monetization company places ads inside an app and turns those ad impressions into a revenue stream for whoever owns the app or the account it is published under. Most of the category — AdMob, Unity Ads, AppLovin, ironSource, Liftoff — only supplies the ad demand and mediation: a developer builds an app, integrates the SDK, and the network fills ad slots and pays out a share of what advertisers bid. A smaller group of companies, including ConsoleMint, do both halves: they build and publish the app themselves, then run the same ad-monetization stack on top of it and share the resulting ad revenue with the publishing partner whose Google Play account distributes the app. The difference matters if you don't want to write code — a pure ad network still requires you to have an app; a build-and-monetize company does not.

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.

A standard ad network keeps a mediation/platform cut and pays the rest to whoever owns the ad units, typically 60–80% to the publisher depending on the network and format. That share arrives from day one of live traffic, so a brand-new app with no installs earns close to nothing at first — the split is real but there is nothing yet to split. ConsoleMint's revenue-share model is structured differently because it is also the one paying for the app to be built and maintained: it pays a fixed monthly payout during the app's ramp-up months (while installs and ad revenue are still small), then converts to a performance-based share of ad revenue as the app matures, reviewed roughly every 45 days. The publishing partner is never asked to fund or wait out the ramp-up period unpaid.

There is no single benchmark because it depends entirely on country mix and ad format, but a rough planning range is $1–$5 of monthly ad revenue per 1,000 active installs for a US-heavy audience, and a fraction of that for India-heavy traffic. Revenue per install is a noisier metric than eCPM because it bundles retention, session frequency and ad format together — an install that opens the app once contributes almost nothing, while a daily active user with rewarded video exposure can be worth many times an average install. Use it only as a directional planning number, and track eCPM and ARPDAU for the metrics that actually diagnose a monetization problem.

Either hire a developer to integrate an ad SDK and mediation for you, or work with a company that already owns and monetizes an app catalogue and shares the resulting ad revenue with account holders. If you have an existing app and just want the ad integration done, a freelance Android developer can add AdMob or a mediation SDK in a few days. If you don't have an app at all and don't want to commission one, the alternative is a build-and-monetize partner: the company builds an app that already runs the ad stack, publishes it through your Google Play account, and pays you from the ad revenue it generates — no code required on your side at any point.

Unity Ads and AppLovin are ad networks and mediation platforms that monetize apps someone else already built; ConsoleMint builds and publishes the app first, then monetizes it. Unity Ads and AppLovin MAX sit inside an app's codebase as an SDK, competing for ad impressions and paying out a share of that ad spend — but only once an app exists and is live. ConsoleMint's differentiator is that it owns the product work end to end: design, build, Play Store submission, ongoing maintenance and policy compliance, on top of running the ad stack. A developer with a finished app wants Unity Ads or AppLovin; an account holder with no app wants ConsoleMint.