Setting Up Ads in Your Mobile Game for the First Time: A Decision Framework

Start with rewarded video if your game has any natural pause or goal moment. Add interstitials at level transitions if the genre supports it. Skip banner ads in most game categories. Use AdMob as your first and only network until you are earning at least $50-100 per day. Before you write a line of code: decide if your game targets users under 13, create your app-ads.txt file, and understand the difference between test ad units and production ad units. Most first-timer AdMob account problems trace back to one of those three things being handled out of order.

Should you add ads at all? The IAP-first vs ads-first decision

The first question is not which SDK to install. It is whether ads are the right primary revenue model for your game.

Free-to-play games run on two basic models. IAP-first games treat ads as secondary or absent. The main revenue comes from in-app purchases: virtual currency, cosmetics, premium content, progression unlocks. Ads-first games make impressions the primary revenue stream. Every player generates revenue, whether they ever spend a dollar or not.

Most indie developers default to ads-first, and the logic is straightforward. IAP conversion rates across free-to-play games average 1.6-2%, sitting at the low end for hyper-casual titles. That means 98% or more of your players will never buy anything. Ads monetize that majority. IAP-first only makes sense if your game has a real monetizable economy: progression currency, unlockable content, something a player would pay to accelerate or access.

The decision logic:

If your game has progression, a currency economy, or gating mechanics, consider IAP-first or a hybrid setup. The hybrid model (ads plus IAP) is growing fast. AdMob reports hybrid monetization is up over 50% year-over-year. Ads handle the non-payers. IAP handles the engaged, high-value players. Both run simultaneously.

If your game is casual or hyper-casual (short sessions, no economy, tap-to-play, arcade, puzzle), ads-first is the right model. These games cannot sustain meaningful IAP conversion. The other 98% of players are your revenue.

If your game has significant depth (RPG, strategy, sim), IAP is likely the higher revenue ceiling. Ads as a secondary layer on these games require careful design. Interstitials in depth-first genres create more friction against paying behavior than they do in casual games.

One more thing to set expectations before you go further: a new game with 100 daily active users running a basic AdMob setup should expect somewhere between $1-10 per day at launch. ARPDAU (average ad revenue per daily active user) for hyper-casual games runs $0.02-0.05. Casual games with a clean mediation setup run $0.08-0.25. The point of setting up ads correctly on day one is not to generate meaningful revenue immediately. It is to have a clean, policy-compliant stack ready when your daily active user count grows.

Which network first: AdMob is the default for a reason

For a first-time mobile game setup, start with AdMob as a standalone network. Here is why it is the correct default.

AdMob has the largest demand pool of any mobile ad network. Fill rate (the percentage of ad requests that actually return an ad to show) is the primary reason. A first-time game with a global audience and no geo-specific bias will see the highest fill rates on AdMob. Low fill rate means empty placements and missing revenue.

AdMob's documentation is the most complete of any mobile ad SDK. Engine-specific integration guides exist for Unity, Flutter, native Android, native iOS, Godot, GDevelop, and GameMaker. The debugging tools (test mode, ad inspector) are mature and well-documented. The account setup is straightforward for a developer who has never run a network before.

AdMob does not charge to use. Revenue is taken as a share of the auction clearing price.

When AdMob is not the right first choice:

Your game targets exclusively Chinese users. Google Play and AdMob are not available on most Android devices in China. Pangle (ByteDance) is the relevant network in that market.

Your game is built in Unity and you already have a LevelPlay (formerly ironSource) integration in place. LevelPlay is a mediation SDK, not just a standalone demand source. It aggregates multiple networks. If the Unity project already has LevelPlay integrated, that may shorten the setup path. LevelPlay plus AdMob as a network is a reasonable alternative starting point for Unity-native games specifically.

What to avoid regardless of which network you choose: do not register for five networks on day one. Each additional SDK increases binary size, initialization time, and the surface area for implementation errors. A first-time setup needs one network, one integration, and clean traffic. When you are ready to evaluate adding a second demand source, see how AdMob and AppLovin MAX compare. For now, pick one and run it cleanly.

Before you start integration, run your AdMob setup through the checker. It flags common configuration problems on new accounts before they become policy issues.

This is a decision tree, not a format comparison. You have a specific game. The question is which format to implement first.

Step 1: Does your game have any of the following?

A level-fail or run-end moment
A resource or currency the player runs out of
A power-up or extra-life mechanic

If yes, start with rewarded video. The player opts in to watch an ad in exchange for a meaningful reward. This is the only format where players often choose to engage with the ad rather than tolerate it. Rewarded video has the highest eCPM (effective revenue per 1,000 impressions) of any standard mobile ad format. It monetizes without retention risk when the reward is real.

If no, or you are not sure, go to Step 2.

Step 2: Does your game have natural break points between distinct sessions of play?
Examples: level complete screen, game over screen, chapter end, race finish.

If yes, add interstitials at those break points. Interstitials on transition screens are less disruptive than interstitials during active play. Do not show them at every single break point. Start with a frequency cap of no more than one interstitial per 3-5 minutes of play, triggered only at the transition screen, never during active gameplay.

If no (the game is a continuous experience with no discrete session end), do not use interstitials. A continuous sandbox or simulation game has no safe moment for a full-screen interruption. Consider banner or native instead.

Banner ads: usually skip in games

Banner ads work in apps where users browse or read while the banner is present. In most games, a banner competes with the UI, clutters the visual design, and generates low eCPM relative to the screen real estate it consumes. Hyper-casual games with minimal UI can run a persistent bottom banner at low UX cost. Most other game genres are better served by rewarded plus interstitial only.

The exception: if your game has a lobby, menu, or idle waiting screen where the player is not in active gameplay, a banner there is defensible. Not in the gameplay view.

App open ads: add later, not first

App open ads are a full-screen format that shows when the user opens the app. They can work in specific contexts (hyper-casual games with a natural loading screen) but require careful implementation to avoid hurting return rates. Do not add them as part of a first-time setup. Add them after rewarded and interstitial are running cleanly and you have data on your open frequency. Read when app open ads pay off and when they hurt retention before you get there.

eCPM context (rough benchmarks, not guarantees):

Rewarded video: commonly $10-50 per 1,000 completions in tier-1 markets
Interstitial: typically $3-15 per 1,000 impressions in tier-1 markets for a new account
Banner: typically $0.30-1.00 per 1,000 impressions

A new game with 50 daily users in a mixed geo audience will not hit tier-1 benchmarks on day one. These ranges are steady-state targets, not launch numbers.

COPPA and audience configuration: resolve this before SDK integration

This is a decision most tutorials bury after setup. It belongs before SDK integration, because getting it wrong before launch creates a compliance problem that is hard to fix retroactively.

COPPA is a US law that restricts how apps can collect data from and show behavioral ads to users under 13. Google Play and the App Store both have audience-targeting settings that developers must configure. AdMob has a separate ads content rating and "directed to children" setting.

The practical question: does your game primarily appeal to users under 13? Signs that it might include cartoon characters, bright primary colors, simple one-touch mechanics, animal characters, toy or fantasy themes with childlike aesthetics, or a Play Store category of "Games for Kids."

If yes, or if you are not sure:

On Google Play, set the app's target age group in the Family Policy section of the Play Console before launch.

On AdMob, set "Directed to children" as Yes for your app, or configure a child-directed treatment tag at the request level. This restricts the types of ads served. No personalized or behavioral advertising can be shown to child-directed content.

On the App Store, configure the age rating correctly and use App Store Connect content description fields to declare child-directed content.

Failure to configure this correctly is not a theoretical risk. Google Play has removed games from the store for targeting under-13 users with behavioral advertising. The sequencing rule: decide your audience configuration before you configure any ad unit. The ad unit type and personalization settings follow from this decision.

For European users: if your game reaches players in the European Economic Area, you need a User Messaging Platform (UMP) consent flow before showing personalized ads. AdMob provides a UMP SDK that generates the appropriate consent dialog. This is separate from COPPA and is also a pre-SDK-initialization decision.

The minimum viable setup: one ad unit, one placement, one SDK

Name the minimum viable setup before you integrate anything: one ad unit type (rewarded video, or interstitial if rewarded does not fit your game), one placement (the natural break point from the format decision tree above), and a single SDK.

Why minimum viable first: each additional ad unit, placement, and SDK increases the surface area for implementation errors. A first-time developer who sets up rewarded plus interstitial plus banner plus two networks simultaneously has four times the debugging surface when something breaks. AdMob's account review process reviews apps before ads start serving. If the first integration is clean and passes review, adding more units later is incremental. If the first integration has policy issues, fixing it is harder with multiple units active.

Revenue from one well-placed rewarded video placement in a game with healthy DAU will outperform revenue from three poorly configured placements. Format quality matters more than format quantity at this stage.

What one placement looks like in practice:

For rewarded video: one game moment (level-fail offer, extra-life offer, currency top-up) with a clearly meaningful reward in the game economy.

For interstitial: one trigger (game over screen, level complete screen) with a frequency cap. Start at no more than one interstitial per 3-5 minutes of play, at the transition screen only.

Integration basics without being a tutorial: add the AdMob SDK via your engine's package manager, or via Gradle on Android and CocoaPods or Swift Package Manager on iOS. Initialize the SDK once at app start inside the MobileAds.initialize() callback. Use test ad unit IDs during development. Create production ad unit IDs in the AdMob console before release. More on that distinction in the section below.

Before integration, check your SDK version. Outdated SDK versions are a common source of fill rate problems and policy flags on new accounts.

App-ads.txt and store metadata before going live

App-ads.txt is a file that tells buyers which ad networks are authorized to sell ads in your game. Without it, some buyers refuse to bid on your inventory, which reduces both fill rate and eCPMs. It is not an edge case. Low fill rate on a new game frequently has a missing or misconfigured app-ads.txt as a contributing cause.

How to create it: generate the app-ads.txt entries from your AdMob console (Account > App-ads.txt). Host the file at yourdomain.com/app-ads.txt if you have a developer website, and declare that developer website in your App Store and Play Store developer profile. If you do not have a developer website, the practical path is a minimal one-page site with app-ads.txt at the root. A single static page is sufficient.

Play Store metadata: make sure your content rating, app description, and screenshots accurately represent the game. AdMob's review process cross-checks the AdMob account against the Play Store listing. Discrepancies (an app description that says it has no ads while AdMob shows it as monetized) create review friction.

App Store metadata: the App Store requires apps to disclose in-app advertising in the app description or privacy label. Third-party advertising must be declared before the app goes live with ads.

Why this matters before launch rather than after: demand quality is lower for apps without app-ads.txt, which means lower eCPMs from day one. Doing it after launch creates a gap period where inventory is running without full demand access. Set it up before the first impression.

Test ad units vs production: never ship test ads accidentally

This is the most common cause of policy problems on new AdMob accounts. The scenario: a developer integrates AdMob using Google's sample code (which includes test ad unit IDs), forgets to replace them with production ad unit IDs, submits the app, and either generates zero revenue because test ads do not pay, or triggers an AdMob policy review because interaction patterns with test ads do not match legitimate user behavior.

What test ad unit IDs are: Google provides hardcoded test IDs that return placeholder ads during development. These are safe to click while testing. They are specifically designed so developers can interact with ads without generating invalid traffic signals. The test IDs are constant and listed in AdMob's documentation.

What production ad unit IDs are: each ad placement in your game needs a unique production ID created in your AdMob account. These IDs are linked to your account, your app, and the specific placement. Revenue requires production IDs.

The checklist before submitting to the store:

Every ad unit in the app code uses a production ID (no test ID strings present)
Test mode is disabled in the SDK initialization code
AdMob's ad inspector and test device configuration are not hardcoded in production builds

Check for test-ad issues in your AdMob setup before you submit. It takes a few minutes and catches the configuration mistakes that take weeks to recover from.

AdMob's review team flags new accounts showing patterns inconsistent with legitimate user behavior. A flagged account goes into a review hold that can delay revenue for weeks. The hold is easier to avoid than to recover from. For a full picture of how AdMob's approval process works and what causes rejections, the Google AdMob Approval Guide covers the review process in detail.

The first-week diagnostic

Once your game is live with ads, four metrics are worth checking in the first seven days.

Fill rate by ad unit. Fill rate is the percentage of ad requests that return an ad. A fill rate below 80% in a new game is worth investigating. Common causes: app-ads.txt not configured (see above), targeting set too narrow, or the AdMob account still in review.

Impressions per DAU. This is how many ad impressions each daily active user is seeing. If it is very low (below 0.5 per DAU for rewarded, below 1-2 for interstitial), the placement trigger is not firing correctly, or the SDK is failing to preload ads. If it is very high (above 6-8 per DAU for interstitial), the frequency cap is not set correctly.

eCPM trend. Do not read eCPM in the first week as meaningful. AdMob's demand optimization takes 2-4 weeks to learn your inventory and calibrate bids. Week-one eCPM is the lowest it will typically be. This is normal. The most common first-timer mistake is panicking at low week-one eCPMs, adding more networks, and resetting the calibration process from scratch.

D7 retention. Are players returning on day 7? For a casual game, D7 retention in the 15-25% range is a reasonable baseline. A noticeable drop after you enable ads (with no other explanation such as an app update or acquisition source change) is worth investigating. The usual cause is interstitial timing or frequency.

The calibration period: the first 14-30 days of an ad setup is when demand sources are learning your inventory. eCPMs will be lower than their eventual steady-state. Fill rate may fluctuate. Do not make configuration changes based on week-one data unless something is clearly broken (zero fill, SDK crash, a visible retention cliff). Wait for 14 days of stable data before drawing conclusions.

If the first week shows fill rate below 50%, eCPMs near zero despite real traffic, or a clear D7 retention drop, those are worth investigating rather than waiting out. That is the kind of quick diagnostic the free 30-minute call is designed for.

When to add a second network

The answer is: not during the calibration period, and not below roughly $50-100 per day in ad revenue on your current setup.

Below that threshold, the configuration and debugging overhead of running multiple network SDKs costs more in developer time than the incremental revenue from adding demand competition. Adding a second network before the first one is calibrated means you cannot isolate problems. If impressions drop or fill collapses after adding network B, you cannot tell whether the cause is network B's integration, an SDK conflict, or a policy flag on your account. Single-SDK diagnostics are much simpler.

What "adding a second network" actually means: you are moving from a single-SDK setup to a mediation setup. Mediation is the layer that manages multiple ad networks and routes each impression to whichever network bids highest (in-app bidding) or ranks highest in a configured priority stack (waterfall). For a first-timer who started with AdMob, the two most common next steps are:

AdMob mediation: AdMob's own mediation product, which lets you add Pangle, AppLovin, Meta Audience Network, and others as demand sources within the existing AdMob SDK. Lowest additional integration complexity if AdMob is already your primary SDK.

AppLovin MAX: a separate mediation SDK that can include AdMob as a network via adapter. MAX has a larger demand-source footprint in gaming and is the mediation platform of choice for many indie and casual game publishers.

Before you evaluate mediation, wait for 14 or more days of clean data, a fill rate above 80% on the primary network, and a stabilizing eCPM trend.

When you are ready for that comparison, see how AppLovin MAX and Unity LevelPlay compare for indie games. For the mechanics of how mediation routes impressions, see waterfall vs in-app bidding before you configure one.

The specific gotchas indie developers hit

These are named problems with named fixes, not general warnings.

AdMob account not approved before launch

AdMob requires your app to be live in a store before the account review is complete and ads start serving. Developers who integrate AdMob, submit to the store, and expect ads on day one of launch frequently find the account is still in review. The approval process typically takes 1-3 days after the app is live and traffic is detected. The practical fix: submit the app 5-7 days before your intended launch-with-ads date, let it accumulate some organic installs, and confirm the account is approved before you start promoting heavily.

Low fill because the app is not live yet

AdMob fill rate is near zero for apps that are not yet published. If you are testing on a development build before the app goes live, fill will be low or absent even with production IDs, because AdMob's demand side does not know the app exists yet. Use test ad unit IDs during development. Switch to production IDs only after the app is published. The Google AdMob Approval Guide covers the approval sequence in detail.

ATT prompt timing on iOS

Apple's App Tracking Transparency framework (ATT) requires a user-facing permission prompt before an app can access the device's advertising identifier (IDFA). AdMob uses IDFA for personalized ads on iOS. If you do not implement the ATT prompt, or if you implement it after the first impression rather than before it, you will serve non-personalized ads to all iOS users. This reduces eCPMs by 30-50% in tier-1 markets.

The correct sequence: show the ATT prompt before initializing the AdMob SDK for the first time. On first launch, before any ad request, show the ATT prompt, wait for the user's response, then initialize AdMob. Do not initialize AdMob first and request ATT permission later.

Rewarded ad not loading before the player needs it

Rewarded ads have a load time. If you only start loading the rewarded ad when the player taps "watch an ad," there will be a visible loading delay or no ad at all if the load fails in time. The correct implementation: preload the rewarded ad as soon as the previous one completes, or as soon as the scene where it might be needed loads. Keep a loaded ad ready. Do not request it reactively.

Frequency cap not implemented on interstitials

The AdMob SDK does not impose a frequency cap by default. Without explicit frequency cap logic in your code, interstitials will show as often as the SDK has a loaded ad available. A developer who adds interstitial on level complete without a timer or session limit can inadvertently show ads every 10-20 seconds in a fast-paced game. Implement a minimum interval (60-90 seconds between impressions) and a session cap (2-3 per session as a starting point for casual games) before shipping. For more on how this plays out at the operator level, see balancing ad revenue and user experience on mobile apps.

Account flagged for invalid traffic

AdMob's invalid traffic detection flags accounts showing patterns inconsistent with legitimate user behavior. Common first-timer triggers: clicking your own ads during testing (this is why test IDs exist), showing ads to emulators, or SDK misconfiguration generating rapid ad requests without impressions. An account flagged for invalid traffic enters a payment hold. Resolution typically takes 2-4 weeks of review. The fix: always use test ad unit IDs on development builds, never click your own production ads, and do not show ads to automated test devices.

Account flags and review holds are one of the messier situations to navigate on your own, because AdMob's communication during review is minimal. If your account is in a hold and you are not sure why, that is a good moment for a second set of eyes. The free 30-minute call is the right place to start.

Kids-directed content served behavioral ads

Games with child-directed content must be configured accordingly before launch. Developers who configure this after launch face a period of policy non-compliance that can result in app removal. This is harder to recover from than getting it right the first time. If there is any ambiguity about whether your game appeals to users under 13, configure it as child-directed before you go live.

What not to do

Do not maximize ad density from session one

A game with 200 daily users and a well-designed economy will generate more revenue over 12 months than the same game with triple the ad frequency and half the users churning by day 7. Interstitial density is the most common axis on which first-timers over-optimize. The instinct is understandable: revenue is low, so more ads should mean more revenue. The result is that retention drops, the daily active user count shrinks, and the impression pool contracts. You have not generated more revenue. You have moved it forward in time by burning your user base.

Do not copy another game's ad density without understanding their model

Hyper-casual titles with a million daily active users can run 6-8 interstitials per session because that model extracts value in the first 1-3 sessions before users churn anyway. An indie developer with 500 DAU and a game that depends on ongoing engagement applying that same density is destroying the user base that makes the revenue model work. Ad density parameters do not transfer across game types.

Do not add a second network before the first one is working

This is covered above. The temptation to chase higher eCPMs by adding more networks before the first is calibrated is the most common way first-timers create complex debugging situations that take weeks to untangle.

Do not treat week-one revenue as steady-state

The calibration period is real. eCPMs in weeks one and two will run 30-50% below where they settle in weeks four through eight as demand sources learn the inventory. Developers who see low week-one revenue, reconfigure the setup, and check again in week two have reset the calibration clock. The week-one number is not a signal about your setup's long-term performance. It is the baseline before learning begins.

Do not skip app-ads.txt because it seems like a backend detail

Lower demand quality from day one is the direct cost. There is no upside to deferring it.

Do not show interstitials before the player has experienced the game

The first session is when the player decides whether your game is worth their time. An interstitial before they have finished level one is a full-screen interruption before a positive value signal has been delivered. It is also the fastest path to one-star reviews on the store. Hold the first interstitial until the player has completed one full level or game cycle.

Frequently Asked Questions

Should I use AdMob, AppLovin MAX, or Unity Ads for my first mobile game?

For a first-time setup, start with AdMob as a standalone network. AdMob has the deepest demand pool for a global audience, the best documentation across all major game engines, and the most straightforward account setup for a new developer. AppLovin MAX is a mediation SDK, not just a network: it aggregates multiple demand sources including AdMob. It makes sense once you have clean traffic and are evaluating how to add competitive demand beyond your first network. Unity Ads (now part of Unity LevelPlay) is a strong option if you are building in Unity and LevelPlay is already integrated into your project. The evaluation between MAX and LevelPlay as mediation layers is a second-step decision, not a first-step one. Get one network running cleanly before comparing mediation platforms.

What ad format should I add first to my mobile game?

If your game has a natural break point where players pause (level fail, level complete, run end) and any mechanism where a resource or extra life would be useful, start with rewarded video. It is the only format where players often choose to engage with the ad rather than tolerate it. Rewarded video has the highest eCPM of any standard mobile ad format and the lowest retention cost when the reward is meaningful. If your game has no natural economy for rewarded video, add interstitials at transition screens with a frequency cap of one per 3-5 minutes. Skip banner ads in most game genres unless your game has an idle lobby or menu screen where a persistent banner is non-intrusive.

How do I know if my game can support ads?

Any free game can technically support ads. The question is which format and at what density. A game supports rewarded video if it has a moment where a player would trade 30 seconds for something useful in the game: an extra life, a resource, a power-up. A game supports interstitials if it has natural pause points between distinct units of play: levels, rounds, matches. A game should not run interstitials if it has no natural pause points. A continuous sandbox or live-event game where there is no discrete session end has no safe moment for a full-screen interruption. The format choice follows the game structure, not the other way around.

Will adding ads kill my game's retention?

Poorly implemented ads will. Well-implemented ads in the right format will not. The retention risk comes from three specific mistakes: showing interstitials before the player has experienced value (before level 1 is complete), showing interstitials too frequently without a time-based or session-based frequency cap, and showing full-screen ads on every app open rather than at natural in-game transitions. Rewarded video, when user-initiated with a meaningful reward, has the opposite effect. Users who watch rewarded video have higher return rates than users who do not, because the reward creates a positive loop between the ad and the gameplay. If your D7 retention drops after adding ads, check the timing of the first interstitial in a session and the total interstitial count per session.

When should I move from a single ad network to mediation?

When your current setup is clean and generating consistent revenue. The practical threshold: wait until you are past the 14-30 day calibration period, your fill rate is above 80%, and you are earning roughly $50-100 per day. Below that threshold, the debugging overhead of running multiple network SDKs costs more developer time than the incremental revenue from adding demand competition. When you are ready to evaluate mediation, the two most common choices for indie mobile game developers are AdMob mediation (lowest additional complexity if you started with AdMob) and AppLovin MAX (larger demand-source coverage in gaming). Do not add a second network during the calibration period. If fill rate collapses or eCPMs drop after adding a second SDK, diagnosing the cause is much harder with two networks active than with one.

Do I need to register for AdMob before submitting my game to the App Store or Play Store?

You can register for AdMob before submission, and you should. Creating your AdMob account and ad units before submission gives you production ad unit IDs to integrate into the code before the store review, and it starts the AdMob account review process in parallel with the store review. What you cannot do before submission: complete AdMob's full approval process for your specific app. AdMob requires the app to be live (or have a live URL) before the account review for that app closes and ads start serving. The practical sequence: create the AdMob account and ad units, integrate them using production IDs, submit to the stores, wait for store approval and go live, then expect a 1-3 day AdMob approval period before live ads start serving. Do not use test ad unit IDs in the production build that you submit to the store.

Setting it up right the first time

The sequence matters more than the speed. Most first-timer AdMob problems (policy holds, low fill, retention drops) are not caused by bad SDK choices or the wrong ad format. They are caused by doing steps out of order: integrating the SDK before deciding on the audience configuration, shipping test IDs in production, or adding a second network before the first one is calibrated.

The framework above covers the decisions in the order they need to be made. If you want to run through your specific game and setup before you go live, that is exactly what the free 30-minute call is for.