AdFailed code=3 msg=No fill.

[Sdoong]

Hello,

I'm reposting this question with a shorter summary because no one has responded to my previous post.

My app is being released in Spain, so I display a GDPR consent dialog and load AdMob banner ads only after the user gives their consent. When I use a test ad unit ID, everything works fine and the ads are displayed correctly.

However, when I use my actual AdMob ad unit ID in the published app, I get an error: AdFailed code=3 msg=No fill, and no banner ads are shown.

From what I’ve found online, this error usually occurs when there’s no ad inventory available to fill the request — not necessarily due to a coding issue. To try to solve the problem, I added Meta Audience Network and Unity Ads through AdMob Mediation, but I’m still getting the same error.

I did see an ad successfully just once after implementation, which makes me think this isn't a coding issue. But if it could still be related to the code, I would appreciate any suggestions to resolve it.

Also, I’ve read that if an app doesn’t have enough active users, AdMob may determine that it’s not worth serving ads, resulting in this same "No fill" error. Is that true?

If I gain more users, will ads eventually start showing?

[Mobile Ads SDK Forum Advisor]

Hi,

Thank you for contacting the Mobile Ads SDK Support team.

It is always recommended to use the latest versions of the SDK. I have executed our Google Sample project with the provided details  and I am consistently encountering a “No Fill” response from our end. While testing ads through Unity Ads mediation, the logs indicates the following error:

“Placement 5906700 could not be found(Error Code : 203)”

On the other hand, I have checked your account and the Meta mediation appears to be correctly configured.

The best way to get more information about your issue is the AdMob Help Center. You can also utilize the AdMob Communities for additional support. 

If you have any questions about usage of the Google Mobile Ads SDK, please feel free to reach out. 

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               
[2025-07-28 07:21:28Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01swvBK:ref" (ADR-00320750)

[Sdoong]

Hello,

Following your suggestions, I updated the AdMob SDK to the latest version (24.5.0) and removed the Meta mediation network for now.

However, I'm still seeing the error AdFailed code=3 msg=No fill.

I had previously contacted the AdMob Help Center, but I haven’t received any clear response so far.

I came across some posts mentioning that for apps with low daily active users, AdMob might not serve ads consistently to avoid wasting inventory. Could this be the reason?

Occasionally, an ad does appear, so I don’t think the issue is with my ad implementation code.

Would removing the Unity Ads mediation (which was previously causing issues) help resolve this?

Thank you.

2025년 7월 28일 월요일 오전 9시 22분 26초 UTC+2에 Mobile Ads SDK Forum Advisor님이 작성:

[Mobile Ads SDK Forum Advisor]

Hi,
Kindly note that this forum provides technical assistance specifically for Mobile Ads SDK code implementation.
As we mentioned earlier, for issues related to ad serving behavior AdFailed code=3 (No fill) — we recommend reaching out to the AdMob Help Center  and AdMob Communities for additional support.. They are better equipped to assist with account-level or inventory-related concerns.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-07-29 13:26:21Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01swvBK:ref" (ADR-00320750)

[Ge]

Hello everyone,

I'm hoping to get some insight from the community on a persistent and blocking issue with AdMob test ads. We have exhausted all client-side debugging and have strong evidence that points to a server-side account configuration problem.

The Core Problem

1. All test ad requests (using Google's test ad unit IDs) are consistently failing with Error Code 3 (No Fill).

2. The ResponseInfo object returned in the onAdFailedToLoad() callback for these failed requests is always null. This suggests the request fails before an ad auction even begins.

3. Critically, live ads for the same ad units serve perfectly fine. Our AdMob account is several years old and fully verified.

Exhaustive Investigation & Key Findings

We have performed every client-side test and fix we can think of. Our conclusion is that this is not a client-side implementation error.

1. Correct Test Configuration: Our test devices are correctly registered in the AdMob dashboard. We also configure them in code using MobileAds.setRequestConfiguration() with the correct test device IDs. We are exclusively using Google's public test ad unit IDs for all test requests.

2. Ad Inspector Confirms "No Fill": The Ad Inspector tool launches correctly and analyzes the ad request, but it confirms the result is "No Fill" and shows that zero ad networks participated in the auction.

3. Contradictory "Ghost" Mediation Logs: The verbose logs show a major contradiction. During the Google Mobile Ads SDK initialization, the logs indicate that it is detecting and attempting to initialize old mediation adapters (specifically Vungle and AppLovin). These adapters are failing to initialize, which is expected because we have never integrated them. We briefly used Unity mediation, but it has been completely removed from both the AdMob UI (all mediation groups deleted) and our project's dependencies and files.

4. Exhaustive Cleaning Failed: We have performed every possible cleaning step, including:

   • Deleting all mediation groups from the AdMob UI.

   • Clearing all Gradle caches (.gradle folder), build folders, and IDE caches.

   • Manually searching the entire project for any lingering files or references to old adapters.

   • The "ghost" adapters still appear in the initialization logs.

5. Definitive Final Test Protocol: To eliminate all doubt, we ran a final test with:

   • Verbose debug logging enabled on a physical Android test device.

   • The device's Advertising ID confirmed as a "Test device" in the AdMob dashboard.

   • Using only Google's official test ad unit IDs.

The results of this definitive test were identical to all previous tests and proved the client-side is working correctly:

• The network request is successfully sent and received by the AdMob server: Ads: GMA Debug CONTENT {"timestamp":...,"event":"onNetworkResponse",..."params":{"firstline":{"code":200}}} Ads: GMA Debug CONTENT {"timestamp":...,"event":"onNetworkResponseBody",..."params":{"body":"..."}}

• The log confirms the device is correctly identified as a test device: Ads: This request is sent from a test device.

• Despite this, the final result is still Error Code 3: No Fill.

Our Core Questions for the Community

Given this evidence, we are not looking for standard client-side suggestions (e.g., "check your ad unit ID"). We would be grateful for any insight into these specific questions:

1. Has anyone experienced a situation where correctly configured test ad requests fail with a null ResponseInfo, while live ads work fine? This points to a failure before the auction.

2. What could cause the Google Mobile Ads SDK to log initialization attempts for "ghost" mediation adapters that do not exist in the project or the AdMob UI? Could this be a stuck configuration on AdMob's backend?

We believe this is a server-side account issue that is beyond our control to fix. Any help, similar experiences, or suggestions on how to escalate this would be greatly appreciated.

Thank you.

[Mobile Ads SDK Forum Advisor]

Hi,
I will check with the wider team and get back to you. In the meantime, your patience is appreciated.

Thanks,
 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-10-13 18:35:29Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01swvBK:ref" (ADR-00320750)

[Mobile Ads SDK Forum Advisor]

Hi,

The issue has been resolved. Kindly check and confirm the results. 

Thanks,

 

Mobile Ads SDK Team

Feedback
How was our support today?

               

[2025-12-02 06:17:04Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01swvBK:ref" (ADR-00320750)