Putting AdMob Bidding into Production for a Rork App — Five Networks Bidding in Parallel, eCPM Trends, and Daily Operations

Configuring Bidding in the AdMob Console — The Pitfalls That Cost Me Days

This is where most of the practical learning happened. Below are the three pitfalls that absorbed the most time during my migration.

Pitfall 1: Enabling Bidding in AdMob Is Not Enough

In the AdMob console you create a new Mediation Group, pick the bidding-capable networks, and save. The screen confirms "Bidding enabled." But until you complete the mapping inside each network's own management console — minting a bidding-specific ID and pasting it back into AdMob — no actual bid requests reach those networks.

I lost two days on AppLovin, three days on Meta Audience Network, and a day on Pangle this way. Each network's flow is slightly different, and each one has a setting that looks connected but isn't until you paste the right bidding ID into AdMob.

Pitfall 2: Adapter Versions Are Strict

Bidding support is gated by adapter major version. AppLovin SDK 11.x is waterfall-only; 12.x is where bidding starts. Each network has its own breakpoint. I grep Podfile.lock and android/app/build.gradle to confirm versions before flipping bidding on.

Three of my five adapters needed updates as part of the migration. Adapter updates sometimes change how ad unit IDs are passed in at initialization time, so I treated each one as a small refactor rather than a version bump.

// android/app/src/main/java/.../MainApplication.kt (excerpt)
override fun onCreate() {
  super.onCreate()
  MobileAds.initialize(this) { status ->
    status.adapterStatusMap.forEach { (adapter, state) ->
      Log.i("AdMobInit", "$adapter: ${state.initializationState}")
    }
  }
}

If even one adapter is in a state other than READY, that network drops out of the auction completely. I now make a habit of checking the Logcat output at startup before shipping any release.

Pitfall 3: Test Devices Cannot Reproduce Bidding

The AdMob test ad unit IDs never reflect bidding behavior — they always return test creatives. To validate bidding you have to use production ad units, but you cannot let your own developer device serve real impressions in production without risking ad spam.

My workflow is to enroll a handful of beta testers through TestFlight and Google Play Internal Testing, then watch the "Bidding report" section in the AdMob console for each ad unit. When I see "impressions through bidding > 0," I consider the migration successful for that app.

Three Weeks of Production Numbers — eCPM, Fill Rate, and Latency

Across five wallpaper apps that I migrated in waves over three weeks, the weighted-average comparison against the prior waterfall configuration looks like this. Numbers move app by app, but the direction has been consistent.

The biggest mover was interstitial eCPM. During hours where my Japanese audience is concentrated, interstitial eCPM peaked at +35% above the waterfall baseline. The story behind that number is that Meta Audience Network surprisingly often submits very strong bids in Japan, and under waterfall it was sitting behind AppLovin and rarely getting served. With bidding it competes head-on every impression.

Fill rate improvements sound modest as percentages, but five percentage points of interstitial fill across millions of impressions per month adds up to real money. Latency dropping was the result I least expected. I assumed parallel requests would be slower than sequential ones, but the waterfall path's tail latency was dragged down by "network 1 timed out, try network 2," which the bidding model bounds with a single auction window.

It was also worth looking at how the wins actually split. Averaged across three weeks of interstitial traffic, the share of auctions each network won came out roughly like this.

The row that mattered most to me was the last one, not the first. A few percent looks like something you could drop, but the hours Liftoff wins are clustered where the other four go quiet. A network can be small in aggregate and still be the thing keeping your fill rate from falling through the floor at 3 a.m. Not judging a network by its share alone is a habit I picked up somewhere around the fourth migration.

Separating "No Bid" from "No Fill" — Not Arriving vs. Not Winning

Bidding changed how I debug. Under waterfall there were two states: a network filled, or it didn't. Under bidding, three separate things sit side by side. The bid never arrives. The bid arrives but loses on price. The bid wins and then the creative fails to load. Confuse them and you will spend your afternoon fixing the wrong layer.

What makes it harder is that the vocabulary doesn't line up across dashboards — what one network calls "no bid" another labels "unfilled." Watching six apps at once, I gave up on reading each dashboard on its own terms and folded them into a single table first.

I labeled the second row "normal" for a reason. On day one of the migration, Liftoff's win share sat around 3% and I spent half a day bouncing between consoles convinced I had misconfigured something. Bid responses were in fact coming back roughly nine times out of ten — Liftoff was just bidding less than the other four. Participating and winning are different questions under bidding, and the fix was to always read bid rate and win rate as two separate numbers rather than one health indicator.

The fourth row is the one aggregate dashboards will never show you. Pangle's overall bid rate looked perfectly healthy in my account while Japan specifically sat at nearly zero for over a week. Inventory from other countries kept the average respectable, so nothing ever crossed an alert threshold. For the first week after a migration, it is worth building a country-split view for your top three or four markets and reading that instead of the summary.

In practice, working through it in this order got me to the answer fastest:

1. Check bid rate. Zero means the network's console, not your app. No amount of client-side work will move it.
2. Check win rate. Low on its own is normal — that's a price and inventory story, not a defect.
3. Compare match rate against show rate. A gap points at the adapter, which sends you back to the initialization logs.
4. Split by country. When the first three look fine but revenue still isn't moving, the reason is usually hiding here.

Estimated Revenue Will Not Match the Networks — Decide the Tolerance First

The first month-end after the migration is where I got stuck. AdMob's estimated revenue never matched the networks' own figures under waterfall either, but with five networks competing for the same impression, there are simply more places for the gap to come from. The gap itself isn't a defect — but treating every gap as an incident will eat your entire month-end.

So I drew the line in advance, separating discrepancies worth investigating from discrepancies that are just how the system works. This is the reference I use across the six apps.

As long as a gap fits inside those four explanations, I don't investigate. I only reach for the consoles when a monthly reconciliation lands in double-digit percentages. Before I had that rule, small daily discrepancies would catch my eye and stall the morning. What the operation actually needed wasn't a perfect match — it was a threshold for calling something abnormal.

One more trap specific to bidding: the same impression appears twice if you aren't careful. AdMob records one impression for "AppLovin won this auction," and AppLovin records one for serving it. Add the two dashboards together and your total impressions come out close to double the truth. Obvious in hindsight, and yet the first spreadsheet I built to consolidate five networks did exactly that. Under a bidding setup, AdMob is the single source of truth for impressions, and the network consoles are there for eCPM and delivery errors only. Splitting the roles that way is what finally made month-end quiet.

Delegating the Daily Round to Claude in Chrome

The economics are one story; the daily operations are another. With six apps in production, opening every AdMob console and every network's dashboard every morning is not realistic. AdMob has an API, but the network dashboards each require their own API setup, and standing all of that up myself for a six-app catalog is a full project on its own.

I have been doing my morning round through Claude in Chrome instead. What convinced me was an inversion I kept running into: the screens with no API tend to be exactly the ones holding numbers that only matter if you look at them daily. Each network's diagnostics page and its "no bid" breakdown live precisely there.

The prompt I send each morning looks roughly like this:

# Morning AdMob round

Visit each site in order and report the listed metrics in a single markdown table.
Add a "Notes" column for anything unusual.

1. AdMob Console (https://apps.admob.com)
   - Past 24h estimated earnings (per app)
   - Past 24h eCPM (banner / interstitial / rewarded, per app)
   - Bidding acceptance rate (Mediation > Optimization > Bidding analysis)

2. AppLovin Dashboard
   - Past 24h Revenue / Impressions / eCPM (per app)
   - Delivery error rate (Diagnostics)

3. Meta Audience Network
   - Past 24h Revenue / Impressions / eCPM
   - Watch for elevated "no bid" rates

4. Same for Unity Ads / Pangle / Liftoff.

## Alert rules
- Mark any app with eCPM down >25% day-over-day with "⚠️".
- Mark any app with fill rate under 80% with "🔻".
- If delivery error rate exceeds 5%, add a separate root-cause section.

Claude in Chrome opens each site, pulls the tables, and sends me a single consolidated digest. I read the report on my phone while the coffee brews. The state of six apps in production is in my hands before the day starts.

It is not fully autonomous yet. AppLovin sometimes logs me out daily; when that happens, Claude pauses partway through and asks for the 2FA code, which I provide. Even with that small interaction, the time savings versus visiting six dashboards manually are an order of magnitude.

Rollback Design — What I Always Have Ready Before Flipping the Switch

Bidding has clear upside, but it has one operational constraint: configuration lives per-app in the console, and if something goes wrong for a single app you need a way back. I do not flip an app to bidding without the following three pieces of fallback in place.

1. Preserve the previous mediation group. Instead of deleting the waterfall mediation group when I create the bidding one, I keep it and set its status to disabled. If bidding goes sideways, flipping the status back is one click and zero rebuilds.
2. Switch ad unit IDs through Firebase Remote Config. The app carries two sets of ad unit IDs — the bidding ones and the legacy ones — and reads which set to use from Remote Config. This means I can roll back an app without resubmitting to the stores.
3. Tag ad-related exceptions in Crashlytics. Each network's stack traces look different. I attach custom keys to ad-related exceptions so I can filter Crashlytics by network when something starts failing on a specific SDK.

The second item reads like one line and behaves like three. The ad unit IDs have to be resolved after fetchAndActivate() has settled — if you let that promise float, the session that runs on rollback day still requests against the old IDs. This is the shape I use in the wallpaper apps.

// hooks/useAdUnitIds.ts
import { useEffect, useState } from "react";
import remoteConfig from "@react-native-firebase/remote-config";
 
// Defaults point at the pre-migration set on purpose. A device that cannot
// reach Remote Config should fall back to serving, not to serving nothing.
const LEGACY = {
  banner: "ca-app-pub-XXXXXXXXXXXXXXXX/1111111111",
  interstitial: "ca-app-pub-XXXXXXXXXXXXXXXX/2222222222",
};
const BIDDING = {
  banner: "ca-app-pub-XXXXXXXXXXXXXXXX/3333333333",
  interstitial: "ca-app-pub-XXXXXXXXXXXXXXXX/4444444444",
};
 
export const useAdUnitIds = () => {
  const [ids, setIds] = useState(LEGACY);
  const [ready, setReady] = useState(false);
 
  useEffect(() => {
    const load = async () => {
      try {
        await remoteConfig().setDefaults({ ads_use_bidding: false });
        await remoteConfig().setConfigSettings({
          // Default is 12 hours. I ship 1 hour for the first migration week.
          minimumFetchIntervalMillis: 60 * 60 * 1000,
        });
        await remoteConfig().fetchAndActivate();
        const useBidding = remoteConfig().getValue("ads_use_bidding").asBoolean();
        setIds(useBidding ? BIDDING : LEGACY);
      } catch {
        // On failure we stay on LEGACY.
      } finally {
        setReady(true);
      }
    };
    void load();
  }, []);
 
  // No ad requests while ready is false.
  return { ids, ready };
};

The ready flag is the part I would not skip again. When the hook returned only ids, the very first request after launch went out against the old unit, and an app I had supposedly rolled back kept reporting a mix of both sets. It took me two evenings to find that, and the fix was four lines.

minimumFetchIntervalMillis defaults to 12 hours, and if you leave it there, a rollback you trigger in the morning starts reaching devices in the evening — which rather defeats the point of having a switch that needs no rebuild. I now ship the shortened interval as its own build during the migration week, and only flip bidding on the week after.

Ship the way back before you want to take it. Of everything in this rollback design, the timing of the build turned out to matter more than the steps themselves.

I have actually used the Remote Config switch once during the migration. One app showed unexpected eCPM movement for the first 48 hours and I rolled it back, investigated, fixed an adapter version mismatch, and re-enabled bidding two days later. Without that switch in place I would have been waiting on App Store review to ship a hotfix.

Should an Indie Developer Move to Bidding?

For solo developers considering the move, here are the three questions I would ask first.

The first is whether the mediation SDKs you currently use are on the bidding-capable adapter generation. Networks whose adapters have stopped getting major updates are not migration candidates; leave them in the waterfall residual.

The second is whether your traffic volume justifies the work. I would say that around 5,000–10,000 DAU is the threshold where bidding starts paying back the setup time. Below that, the number of bidders per auction is low enough that the eCPM gains tend not to be dramatic, and the operational overhead does not amortize.

The third is whether you can sustain daily monitoring. Bidding revenue is more sensitive to network health than waterfall revenue, because if one major bidder goes quiet the auction can soften noticeably. If you can wire up something like Claude in Chrome (or a custom API integration) for the daily round, you're fine. If not, a well-tuned waterfall might be the better operational fit even if the absolute eCPM is lower.

In my own apps, after three weeks of work and adjustment, I feel I should have done this migration sooner. Rork-generated apps come with the AdMob foundations already in place, which makes bidding migration easier than it would be on a hand-built codebase, not harder.

If you are still on waterfall, the most practical next step is to pick one app, confirm your SDK adapter versions support bidding, and walk through the console mapping with the three pitfalls above in mind. Once the first app is stable in production, the rest of your portfolio takes far less time per app.

I am still learning as I go. If any of this is useful to other indie developers monetizing through AdMob, I would be glad to hear about your numbers as well. Thanks very much for reading.