The AdMob consent bug that meant no ad ever loaded

By David26 May 20263 min read

The first update to Word Search and Bible Word Search was approved, the listings were live, and the AdMob dashboard said nothing at all. No requests, no impressions. I spent a while blaming a quiet launch before I opened the game on an emulator and looked for the banner. It wasn't there. It wasn't there on my phone either.

What went wrong

Google's User Messaging Platform (UMP) is the SDK that shows the GDPR consent form in Europe and the US state privacy messages. Before you can request ads, you ask UMP for consent info. My code did that, and if the call threw, it treated the error as fatal and never started the ads SDK.

The call did throw: "no form(s) configured". I had never published a GDPR message in AdMob's Privacy & messaging section for these apps. And this is the part that surprised me: without a published consent message, UMP fails for everyone, not just players in Europe. An Australian or American player hit the same error, so the ads never started for anyone.

It got through my own testing because my smoke test was "install it, play a puzzle, looks good". Nobody checked that an ad actually appeared.

The fix

Two parts, both shipped the same day:

Configuration. I published two shared consent messages in AdMob, one for GDPR (Europe) and one for US states, and ticked every app into both. New apps take up to an hour to get their form, so a check run straight after publishing still fails. Wait, then check again.
Code. A consent error is now logged and the game carries on. UMP's canRequestAds decides whether ads load, not whether the consent call threw.

Then I installed both builds fresh on an emulator and watched the log: consent status NOT_REQUIRED, canRequestAds: true, an ad unit loaded, and a banner on screen.

Loaded isn't shown

There's a quieter version of this failure, and it's the reason "ads must actually show" is one of my rules. An ad can load perfectly and still never appear, because the game's cadence is so cautious that players rarely reach a moment where one is allowed. Your fill rate looks great and your revenue is zero.

That's the rule I now treat as the first law of ad-funded games:

Loaded but unshown ads are the most expensive bug you can have. Measure the show rate, not the fill rate.

The check that prevents it now

Every release now goes through an automated ad smoke test before it can be uploaded. It does a fresh debug install on an emulator and passes only if the log shows UMP returning "canRequestAds":true and at least one ad unit reporting a loaded ad. A second check fails if any of my games is missing from either consent message. That caught Sovereign later: it was in an old English-only GDPR message and in no US-states message, so US players never got their privacy notice.

An app can belong to only one GDPR message. Publishing silently wouldn't complete until I deleted an old "Untitled European regulations message" that still held one of the apps.
Renaming a published message doesn't stick. The names are labels only, so don't rely on them.
The editor can show success when nothing was saved. Reload the page and read it back after every change.
An app that isn't linked to its Play listing yet gets limited ad serving. Link it as soon as the listing is public, then expect app-ads.txt verification to take about two days. Don't debug it before then.

What "0 requests" really means

A footnote, because I nearly drew the wrong conclusion twice. A week after the fix, AdMob still showed tiny request counts, and I assumed ads were broken again. They weren't. Analytics showed about eight real first opens per word game that week. Zero requests can mean zero players. Before calling the ads broken, compare AdMob requests with your daily actives. The real bottleneck was installs, which is what most of the rest of this blog is about.