Keeping the AdMob Waterfall While Adding Bidding: A Decision Record from Four Live Apps

Comparing the Two Methods from the Operator's Seat

I'll leave the mechanics to the official docs and list only what you touch in the console and what tends to break.

Bidding costs less effort, but it is also the method where you least notice that something has gone wrong. If you switch without per-network revenue in hand, you can never say afterward whether things improved.

That was the main reason I ran both. You need the yardstick first. Replace before it exists and no evidence for the decision remains.

ATT and Initialization Order: The First Trap That Empties Bids

On iOS, starting the ad SDK before the tracking-consent prompt can send requests without the identifier that bidding needs. In my apps, ATTrackingManager.requestTrackingAuthorization runs first, and MobileAds is initialized only after it completes.

import AppTrackingTransparency
import GoogleMobileAds
 
// Call when the app becomes active (the prompt won't appear while inactive)
func startAdsAfterTrackingPrompt() {
    ATTrackingManager.requestTrackingAuthorization { _ in
        // Regardless of the answer, start the SDK once the prompt has closed
        DispatchQueue.main.async {
            MobileAds.shared.start(completionHandler: nil)
        }
    }
}

Why write it this way? The answer can be allow or deny; either is fine. What matters is that the SDK reads identifiers after the user's choice is settled. When a user denies, ads still serve but bid prices fall. That is by design, not a defect.

Get this wrong and nothing visibly breaks. Ads keep appearing, and only the revenue quietly thins out.

The step before it: consent messaging for the EU and UK

The code above handles ATT only. If your app serves ads to users in the EU or UK, Google's UMP (User Messaging Platform) consent step comes first. The official docs describe the flow like this: update the consent information at every launch, present the form if one is required, and check canRequestAds before requesting any ad.

import GoogleMobileAds
import UserMessagingPlatform
import UIKit
 
// Update consent on every launch, show the form if needed, then go on to ATT → SDK start
func gatherConsentThenStartAds(from vc: UIViewController) {
    ConsentInformation.shared.requestConsentInfoUpdate(with: RequestParameters()) { error in
        // Don't stop on an update error: the previous consent state may still allow ads
        ConsentForm.loadAndPresentIfRequired(from: vc) { _ in
            guard ConsentInformation.shared.canRequestAds else { return }
            DispatchQueue.main.async {
                startAdsAfterTrackingPrompt()   // the ATT → MobileAds start shown above
            }
        }
    }
}

canRequestAds returns false until you have called the consent update at least once, so forgetting that call shows up as "no ads at all". That is easier to notice than a missing ATT step, but requests that fire while the consent form is still on screen still cost revenue.

You can also show the ATT prompt through AdMob's IDFA message instead. In that setup you need to avoid calling it twice, and the details vary by SDK version, so please check the official privacy and consent page just before you implement. One honest caveat: I wrote this Swift snippet from the official API names and flow, and I did not run it on a device for this article.

Three Fragile Spots on the Implementation Side

More mediation puts more load on the code that shows ads. Here are three places I revisited in the Android update.

First, the back-button ad gate. Written as nested ifs, the priority between ads disappears into the shape of the code. I made the gates parallel and independent, and expressed priority as list order.

interface AdGate {
    val name: String
    fun isEligible(): Boolean          // Display conditions (including the ad-free check)
    fun show(onDone: () -> Unit)
}
 
class BackPressGates(private val gates: List<AdGate>) {
    // Priority is the list order. Read this and you see the whole picture
    fun onBackPressed(proceed: () -> Unit) {
        val target = gates.firstOrNull { it.isEligible() }
        if (target == null) proceed() else target.show(proceed)
    }
}

Second, simultaneous full-screen surfaces. The paywall prompt, the review request, and the rewarded-ad invitation each work correctly alone. The moment they overlap, things break visually. I added one layer (ModalGate) that manages central modals in a single place, with a rule that only one shows at a time.

Third, the ad-free decision. Purchase-based and reward-based temporary ad removal both pass through a single combined check, isAdFree || isRewardAdFree. Multiple entry points to that decision mean more loopholes each time you add mediation. I wrote up that idea in the article on keeping billing state as a single source of truth.

Log Per-Network Revenue Before You Switch

This is the linchpin of running both. Every time an ad is shown, record which network it came from and how much it paid into Firebase.

import com.google.android.gms.ads.OnPaidEventListener
import com.google.android.gms.ads.rewarded.RewardedAd
import com.google.firebase.analytics.FirebaseAnalytics
import com.google.firebase.analytics.logEvent
 
// For each served ad, record the source network and its revenue
fun RewardedAd.trackPaidEvents(analytics: FirebaseAnalytics, placement: String) {
    onPaidEventListener = OnPaidEventListener { adValue ->
        val source = responseInfo.loadedAdapterResponseInfo?.adSourceName ?: "unknown"
        analytics.logEvent("ad_revenue_by_source") {
            param("ad_platform", "admob")
            param("ad_source", source)                 // Which network won
            param("ad_format", "rewarded")
            param("ad_unit_name", placement)
            param(FirebaseAnalytics.Param.VALUE, adValue.valueMicros / 1_000_000.0)
            param(FirebaseAnalytics.Param.CURRENCY, adValue.currencyCode)
        }
    }
}

I deliberately did not name the event ad_impression. According to the Firebase documentation, when AdMob is linked to Firebase, ad_impression is logged automatically, and the automatic version carries no value or currency in the default integration. Adding a manual event with the same name and a revenue value may count impressions twice. The docs don't address that duplication, so I can't state it as fact. For comparing networks, though, a separate event name saves you from doubting the numbers later. If you want to pass value to Google Ads, the situation differs: log ad_impression yourself in that case, and confirm the counts in DebugView first.

With ad_source recorded, you can line up "times bidding partners won," "times the waterfall side won," and "average price for each" over the same period and the same ad unit. The switching decision comes down to that one table.

Before and after a switch, I watch these five things.

I release in staged steps of 5% → 25% → 50% → 100%, and only move to the next step while Crash-free users stays at or above 99.7% and ANR stays below 0.20%. Even if revenue looks better, stability comes first.

What I Hand to Antigravity, and What I Don't

Work that went well with the agent:

• Implementing the delivery logging above and wiring it into existing code
• Structural cleanup such as making the ad gates parallel
• Handling test ad unit IDs (writing them in AGENTS.md helps avoid misusing production IDs)

What I did not hand over is anything in the console that affects revenue. Enabling partners and payment profiles (for each of Unity Ads, Liftoff, and InMobi) tie directly to money and rights, so I worked through them with my own eyes.

The agent speeds up implementation, but the responsibility for deciding what goes to bidding and what doesn't can't be handed off. That part stays with me.

For related implementation, you may also like AdMob integration in Flutter and Firebase project setup.

Your Next Step

Try giving yourself about four weeks of running both. During that time, do three things.

1. Record revenue with ad_source every time an ad is shown
2. Confirm the order is consent message → ATT prompt → SDK start
3. Roll out in stages while watching Crash-free users and ANR

It is not too late to decide what to keep and what to reduce once the yardstick is in place. Declining to rush a replacement is, in my experience, a perfectly valuable choice in operation. Looking back, the pause in front of the console may not have been indecision at all, but a sign that I was missing a yardstick.