A banner loads immediately when you use Google’s demo ad unit. You replace that ID with your own AdMob unit, open the same screen on the same phone, and the load callback returns No fill.
That result does not prove the test ad was misleading, and it does not automatically prove your integration is broken. It means the app successfully reached one controlled test path, while the request using your own ad unit entered a longer chain that also depends on account status, app approval, ad-unit configuration, request eligibility, mediation setup, and available demand.
The practical answer is to stop treating “test ads work” and “real ads fill” as the same test. Diagnose three layers in order:
- Integration: Can the app initialize the SDK, send the intended request, receive a callback, and render the format?
- Eligibility: Is this publisher, app, ad unit, and request allowed and ready to receive ads?
- Inventory: Did an eligible source actually return an ad for this request under the current auction and settings?
A no-fill response is an outcome at the end of a request. It is not a single root cause and has no single guaranteed fix.
What a working test ad proves—and what it does not
Google provides demo ad units that point to known test creatives. Those units are not associated with your AdMob account. Google also lets you mark a device as a test device and request test ads with your own ad unit IDs. Both methods are safer than interacting with live ads during development, but they answer different questions. See Google’s Next-Gen test ads guide.
| Observation | What it supports | What remains unproven |
|---|---|---|
| A Google demo ad loads | The app can reach enough of the SDK, network, callback, and rendering path to show that format on that device | Your account, app, own ad unit, policy status, mediation setup, and live demand |
| A Google demo ad fails | There is still an integration, device, SDK, request, connectivity, or service problem to isolate | There is no reason yet to blame live inventory |
| Your own ad unit loads on a registered test device | Stronger evidence that your app/ad-unit configuration is recognized in a production-shaped test path | A live auction will return an ad to every user or every request |
| Production reports show requests but few matched requests | Requests are reaching reporting, but many are not returning ads | Whether the cause is eligibility, filters, floors, limited demand, or a specific source |
| Matched requests are healthy but impressions are low | Ads are being returned | Whether the app is actually presenting those returned ads at the intended moment |
The first row is the source of most confusion. A demo unit is deliberately designed to make integration testing predictable. It bypasses the question you are ultimately asking in production: “Is there an eligible ad for this publisher, app, format, user, and request right now?”
“No fill” in a bug report is a result bucket, not a diagnosis
Teams often use “no fill” to describe the whole class of live ad requests that did not produce an ad. The exact SDK result is narrower. In the current Android GMA Next-Gen SDK, LoadAdError.ErrorCode.NO_FILL means the request succeeded but no ad was returned because no inventory was available. The same enum separately identifies an invalid request, network error, missing or unsupported mediation adapter, timeout, and other failures. See the Next-Gen error-code reference.
Google’s onboarding messages add another layer of specificity. A failed request can name an unapproved account or app, a format mismatch, an eCPM floor, or publisher data that has not propagated yet. That is why a copied “error 3” from a legacy SDK or wrapper is not enough evidence by itself. Record the SDK generation and preserve the complete failure output rather than translating every failure into “no demand.” Google’s Next-Gen ad load errors guide and common onboarding messages should be read together.
The fields also vary by SDK. Current Android Next-Gen exposes an error enum, message, ResponseInfo, and the full object through toString(). Other platforms and wrappers may additionally expose a domain or underlying cause. Capture what the running build actually provides:
- UTC timestamp, app version, platform, device or emulator, and network type;
- SDK generation and exact version, plus mediation adapter versions where relevant;
- app ID, ad unit ID with sensitive portions masked in shared documents, ad format, requested size, and placement;
- error enum or code, full message, complete
LoadAdErrorstring,ResponseInfo, and any domain or underlying cause exposed by that SDK; - whether the device was registered for testing and whether the request was made in context;
- account status, app readiness status, app-ads.txt status, and Policy Center status at the time;
- Ad Inspector’s request result for each bidding or waterfall source.
ResponseInfo is available for failed requests as well as successful ones, and its source-response list can expose which mediation sources were attempted, their latency, and their errors. Google documents the fields in Retrieve information about the ad response.
Run the diagnostic in the right order
1. Reproduce with the official demo unit
Use the Google demo unit for the exact format you are testing. For example, Google currently lists ca-app-pub-3940256099942544/6300978111 for a fixed-size Android banner. Do not publish a build with the demo ID, and do not substitute a production ID merely to see whether clicking works.
At this article’s September 9, 2026 source check, Google listed GMA Next-Gen SDK 1.4.0 as the latest Android version. Treat that as a dated maintenance snapshot, not a forever recommendation: record the exact SDK generation and version in every diagnostic.
If the demo ad does not load, stay in the integration branch. Check the basics before touching account settings:
- the SDK initializes before the request;
- the build uses a currently supported SDK and the documentation for the same SDK generation;
- the requested format, size, and lifecycle match the implementation;
- the device has connectivity and the failure callback is actually logged;
- the ID has not been truncated, copied with extra characters, or paired with the wrong format;
- a mediation adapter is not missing when the placement depends on it.
Current Next-Gen error codes distinguish an invalid request, network failure, missing or unsupported adapter, timeout, and NO_FILL; Google’s onboarding messages separately identify account, app, format, floor, and propagation conditions. That is why “demo failed” should lead to the complete error record, not to a theory about advertiser demand.
2. Test your own unit on a registered test device
Once the demo unit loads, configure a registered test device and run your own ad unit in the real placement. This tests more of the production-shaped configuration without asking you to interact with a live ad. For devices added through the AdMob UI, Google says test serving typically begins within 15 minutes but can take up to 24 hours. Confirm the test state instead of assuming registration was immediate.
Google notes that mediated ads may not show a “Test Ad” label, so test mode must also be handled according to each mediation network’s instructions. Never click an ad unless you have verified that it is a test ad for the source that served it. Google also says test requests, impressions, and clicks do not appear in account reports, so production reporting must be evaluated separately.
Prefer an in-context Ad Inspector test: navigate to the actual screen, trigger the real request, then inspect it. Google says out-of-context tests do not carry all the parameters used by the app UI, including child-directed treatment, custom targeting, network extras, and differing sizes. That makes out-of-context testing useful for isolation, but weaker as evidence about the placement the user actually sees. See Test ad units in Ad Inspector.
At this point, there are three meaningful outcomes:
- The own unit loads as a test ad. Integration and basic unit recognition look healthy. Continue to readiness and production reports; live fill is still not guaranteed.
- The own unit returns a specific configuration or onboarding message. Follow that message before changing auction settings.
- The request ends without fill. Inspect account/app eligibility and then the sources called in the request. Do not restart the entire SDK integration from zero just because the demo and own-unit outcomes differ.
3. Check eligibility before interpreting the auction
A production-shaped request cannot answer the inventory question cleanly until the publisher and app are eligible to serve.
Start with four visible states:
- Account approval and verification. Google says first-time account review typically takes up to 24 hours, though rare cases can take up to two weeks. Incomplete or unverifiable account, payment, phone, or duplicate-account information can block approval.
- App readiness. A new app must be published, listed in a supported store, linked correctly in AdMob, and reviewed before it can fully serve. Google’s app readiness guide distinguishes
Getting ready,Requires review,Needs attention, andReady; reviews typically take two to three days but can take longer, and serving may be limited during review. - App authorization. Google’s app-ads.txt verification guide says apps cannot fully serve until required app-ads.txt verification and the readiness review are complete. For a newly configured app, check the verification status rather than assuming the file was discovered. Google currently exempts apps listed only in third-party stores from this verification requirement.
- Policy and serving limits. Check the Policy Center for app-level or account-level restrictions. Scope matters: Google says some account-assessment limits affect the AdMob Network and third-party bidding but not third-party waterfall sources, while an app-readiness limit can apply to all demand for that app. See Ad serving limits.
These are not four versions of “wait a few days.” They are different states with different actions. Waiting is appropriate only when the current status and message say a review or propagation is in progress.
Google’s onboarding guide, readiness guide, and low match-rate guide give distinct timing signals:
- a newly created ad unit that returns “Publisher data not found” may need up to one hour to propagate;
- account verification usually takes up to 24 hours, with rare cases up to two weeks;
- app readiness review usually takes two to three days, but can take longer;
- a new app or ad unit may receive less Google demand for up to one week while traffic quality is evaluated.
Do not add those durations together into a universal delay. Record which condition actually applies.
4. Inspect the auction and mediation sources
When the app is Ready, required authorization is verified (or explicitly not required), the Policy Center is clear, and the own-unit request still ends without fill, you have finally reached the inventory branch.
Open Ad Inspector’s SDK request log. It shows the sources called until an ad filled or the waterfall ended without a fill, along with source-level errors and latency. Bidding results distinguish a source that won, a source with an integration issue, a source that returned no ad, and a source that submitted a bid but lost. The Ad Inspector troubleshooting guide also lets you share the request and response for support.
Then examine settings that deliberately narrow eligibility:
- Manual eCPM floors. A floor excludes AdMob Network and bidding ads below the threshold. Google explicitly warns that a higher floor is likely to reduce fill and match rate; it does not apply in the same way to third-party waterfall sources. See About AdMob eCPM floors.
- Blocking controls and maximum content rating. Blocking categories removes bids from competition, and a narrower content rating can reduce the eligible audience and demand.
- Children and family treatment. Age-appropriate demand can be smaller, and legal or platform restrictions can narrow the auction.
- Mediation configuration. “No ad returned” is not the same as “adapter failed to initialize.” Diagnose the source that reported the issue instead of collapsing both into “AdMob no fill.”
Google’s low match-rate guide groups these checks alongside policy enforcement, implementation changes, crashes, and report patterns. None of them guarantees a fill after one toggle. The goal is to remove a proven blocker or run a controlled comparison, not to promise that demand exists.
A filled diagnostic record: the Orbit Notes banner
The following is an original fictional teaching example, not a report from a live publisher account. It shows how one team can move through the three layers without guessing.
| Step | Recorded evidence | Branch result | Next action |
|---|---|---|---|
| 1 | Google fixed-banner demo unit loads on Android build 4.2.0 | Integration: pass | Keep the working request/render path unchanged |
| 2 | Own banner unit loads with test treatment on a registered test device | Own-unit test: pass | Do not treat this as evidence that a live auction will fill |
| 3 | Account approved; app status Ready; app-ads.txt verified; Policy Center clear |
Eligibility: pass | Move to production request evidence rather than repeating app review |
| 4 | A representative production failure records NO_FILL with the message No ads meet eCPM floor |
Specific live-request signal | Preserve the complete error and ResponseInfo; inspect the unit’s floor |
| 5 | Ad Inspector shows no missing adapter; the unit uses a fictional manual floor of $18.00 | Plausible controlled variable, not a universal benchmark | Lower, disable, or use Google-optimized all-prices as one controlled comparison |
| 6 | Seven-day report: 10,000 requests, 6,400 matched requests, 5,120 impressions | 64% match rate; 80% show rate | Track whether match rate changes; investigate presentation separately only if show rate is the weak metric |
The diagnostic does not conclude that $18 is always too high. It concludes that the actual error message and the recorded unit setting point to a testable variable. If lowering the floor does not improve matched requests, the team returns to source-level evidence instead of inventing a new certainty.
Use the packaged AdMob no-fill diagnostic log to load this filled example, change the states, calculate the two rates, and export the resulting record. It is a local teaching tool and does not connect to AdMob or validate a live account.
Download the filled Orbit Notes CSV record for a portable version of the example.
Use match rate and show rate to avoid the wrong fix
AdMob’s reporting language is useful here. According to Google’s reports glossary, requests are counted even when no ad is returned. Match rate is matched requests / requests, while show rate is impressions / matched requests.
For Orbit Notes:
- Match rate = 6,400 / 10,000 = 64%
- Show rate = 5,120 / 6,400 = 80%
Those two numbers describe different failures.
| Pattern | More likely branch | What to inspect next |
|---|---|---|
| Requests exist, but match rate is low | Eligibility, restrictive settings, auction demand, or source configuration | App/policy status, floors, blocking, content rating, Ad Inspector source results, country/format/date segments |
| Match rate is reasonable, but show rate is low | App presentation flow after an ad was returned | Lifecycle, preload timing, placement logic, navigation, rendering, and whether the loaded ad is discarded |
| Both fall suddenly after a release | Could cross integration and inventory layers | Compare app version, SDK/adapters, request errors, placement changes, and report segments |
| One test device fails while aggregate reports are stable | Local request or device context | In-context request log, exact device/build/network, then compare another registered test device |
There is no universal “good” match rate in this article because demand varies with app, market, format, restrictions, and time. The useful comparison is your own segmented baseline and the point where the metric changed.
Five debugging mistakes that prolong no fill
Treating the demo creative as proof of monetization
A controlled test creative proves a technical path, not advertiser availability or publisher eligibility. Mark the integration layer as passed, then move on.
Reading only the numeric error code
The error enum or code, full message, complete object string, ResponseInfo, and per-source results belong to the same evidence record. Preserve what your SDK exposes before searching for a fix.
Waiting without naming the state
“New account,” “new ad unit,” “app in review,” and “new inventory under traffic evaluation” are different conditions. A screenshot of the current status and the full error message is more useful than the sentence “I waited three days.”
Changing several controls at once
If you change the floor, blocking categories, mediation order, SDK, placement, and ad unit ID together, a later fill does not tell you what changed the outcome. Keep a short experiment log and change one meaningful variable at a time.
Interacting with live ads during development
Use Google demo units or registered test devices. Google warns that clicking live ads during development can create invalid activity risk, and mediated networks require their own test-mode handling.
The support packet that makes escalation useful
Escalate after you can show where the branch stopped. A useful packet contains:
- a single UTC timestamp and reproducible screen path;
- app package, store URL, app version, platform, SDK generation/version, and adapter versions;
- masked app and ad unit IDs, format, size, and placement;
- the full load error object and
ResponseInfo, not just a screenshot of “No fill”; - Ad Inspector’s exported request and response plus source-level results;
- account approval, app readiness, app-ads.txt, and Policy Center states;
- a report slice with requests, matched requests, impressions, match rate, and show rate, segmented by the smallest useful combination of app, ad unit, format, country, date, and app version;
- the one controlled change already tested and its before/after observation.
Before escalating a sudden cross-app failure, check the official Google Ads Status Dashboard for publisher products. A platform incident can save you from making unnecessary production changes, but the dashboard is only evidence for the time you checked it.
The decision to make after test ads work
When a demo ad loads and your own unit does not, do not ask, “Why is AdMob broken?” Ask, “Which additional gate did the second request encounter?”
First, prove the integration with the official demo unit. Second, inspect your own unit on a registered test device and capture the complete request evidence. Third, verify account, app, authorization, and policy status. Only then interpret the auction, floors, filters, mediation sources, and production match rate.
That sequence will not manufacture demand, and it should not promise a fill for every request. It does something more useful: it stops a working integration from being rebuilt to solve an eligibility problem, and it stops an inventory problem from being mislabeled as an SDK bug.
Sources
- Enable test ads — Google for Developers (last updated September 3, 2026)
- GMA Next-Gen SDK — Google for Developers (last updated September 3, 2026)
- Ad load errors — Google for Developers (last updated September 3, 2026)
- LoadAdError.ErrorCode — Google for Developers (last updated July 28, 2026)
- Retrieve information about the ad response — Google for Developers (accessed September 9, 2026)
- Test ad units — Google for Developers (last updated September 3, 2026)
- Troubleshoot ad units — Google for Developers (last updated September 3, 2026)
- Resolve common onboarding issues — Google AdMob Help (accessed September 9, 2026)
- About app readiness — Google AdMob Help (accessed September 9, 2026)
- Verify your app with app-ads.txt — Google AdMob Help (accessed September 9, 2026)
- Ad serving limits — Google AdMob Help (accessed September 9, 2026)
- About AdMob eCPM floors — Google AdMob Help (accessed September 9, 2026)
- Common reasons for low match rate — Google AdMob Help (accessed September 9, 2026)
- Reports glossary — Google AdMob Help (accessed September 9, 2026)
- Google Ads Status Dashboard — Publisher products (accessed September 9, 2026)
