Across my two wallpaper apps on iOS and Android, I now run more than 50 AdMob mediation groups. BW iOS has 28, BW Android 14, UKI iOS 16, UKI Android 6. One mediation per app multiplied into this many after App Tracking Transparency (ATT) ON/OFF splits and regional splits piled on.
I am Masaki Hirokawa. I've been building iOS and Android apps as an indie developer since 2014, with about 50 million cumulative downloads in the catalogue. The manual time I was spending each morning on AdMob reports and floor-value tweaks was creeping up, so over the last month I drew a line between what an agent can run and what I refuse to delegate. This article is the playbook from that month, written in a shape you can replicate.
If you are an indie dev with 10+ mediation groups, the tweaks are eating non-trivial time, and you'd like to put an agent in the loop without losing revenue, this is for you.
Why the group count exploded
Before the agent discussion, a quick map of how I ended up at 50+. Modern AdMob mediation practice splits groups along three axes: ATT ON/OFF × top countries × format (INT/BNR/RWD/RWI/AOA). For BW iOS interstitials, the split looks like:
- BW-INT-iOS-JP-ATT-ON / OFF
- BW-INT-iOS-TW-ATT-ON / OFF
- BW-INT-iOS-US-ATT-ON / OFF
- BW-INT-iOS-IT-ATT-ON / OFF
- BW-INT-iOS-DE-ATT-ON / OFF
- BW-INT-iOS-HK-ATT-ON / OFF
- BW-INT-iOS-ROW-ATT-ON / OFF
7 regions × 2 ATT values = 14 groups for one format on one platform. Add BNR / RWD / RWI / AOA and you cross 30 per platform, 60+ across both OS. Realized eCPM ranges from $1 to $34 across groups, each with its own optimal floor.
A "floor" here is the minimum eCPM across the full bidding + waterfall stack. Raise the floor and unit price climbs but match rate falls. Lower it and the inverse. My rule of thumb: floor = realized eCPM × 50–60%; revisit when the floor-to-eCPM ratio crosses 65%.
Tasks I now hand off — the four I let an agent run
After a month of experiments, the four tasks I trust an agent with are:
The first is match-rate monitoring. The agent opens the AdMob report at a 30-day window and aggregates impressions, match rate, and estimated revenue per group. I issue this style of instruction:
On the AdMob report:
1. Window: last 30 days
2. Dimensions: app + mediation group
3. Metrics: impressions, match rate, estimated revenue
4. Filter: groups with matchrate < 80% only
5. Output: group name / current floor / realized eCPM /
floor-to-eCPM ratio / recommended actionThe agent pulls the data via API or CSV export and returns a table. I read the table and decide "keep JP, adjust ROW." Aggregation dropped from 30 minutes to 3 minutes.
The second is floor-to-eCPM ratio checks. Trivial math, but the place where humans make small errors at scale:
def evaluate_floor(group_name, current_floor, ecpm_30d, matchrate):
"""Score the relationship between floor and realized eCPM."""
ratio = current_floor / ecpm_30d
if matchrate < 0.80:
if ratio > 0.65:
return f"{group_name}: ratio={ratio:.2%} — candidate to lower (matchrate {matchrate:.0%})"
return f"{group_name}: ratio={ratio:.2%} — likely demand shortage (floor not the cause)"
if ratio > 0.65:
return f"{group_name}: ratio={ratio:.2%} — ratio high but matchrate OK, hold"
return f"{group_name}: healthy"
# Expected output:
# BW-INT-AND-JP: ratio high but matchrate OK, hold
# BW-INT-AND-DE: ratio=88.96% — candidate to lower (matchrate 56%)The third is operations-log updates. Every floor change gets appended to admob-mediation-unified.md with date, group ID, before → after, and reason. I describe the change verbally; the agent files the entry. The asset is being able to ask future-me, "why did I lower JP floor from $15 to $12 on 2026-05-17?" and getting an answer in 5 seconds.
The fourth is applying the "half rule" for AppLovin MAX. When AppLovin MAX joins a waterfall already running Unity Ads, I set AppLovin's manual eCPM to half of Unity's. Unity at $8.50 → AppLovin $4.25; Unity at $5.00 → $2.50. Computing 20 groups by hand will produce at least one error.
Read the Unity floor column below. Compute the AppLovinMax waterfall
floor at half. Output a paste-ready number-only list for AdMob's edit
screen. For BNR groups, ignore the Unity value and output a fixed $0.15.
| Group ID | Unity floor (waterfall) |
| BW-INT-AND-JP (8292611016) | $8.50 |
| BW-INT-AND-KO (5982272500) | $5.00 |
| ... |The output goes directly into AdMob's edit screen. Ten groups in under a minute, and the error rate of manual arithmetic disappears.
What I refuse to hand over — four domains I keep
The other side of the line. These cases satisfy at least one of "directly affects revenue," "data alone is insufficient," or "embedded business logic."
The first is setting absolute floor values. Even if the agent proposes "lower JP from $15 to $10.50," the final approval is mine. Floor decisions track not only realized eCPM but also seasonal ad demand (year-end retail, spring fresh starts) and the wave of specific networks (Meta, AdMob Network). Data alone won't surface those.
The second is wholesale stopping or restarting a network. On 2026-05-26 I paused AppLovin Bidding and Waterfall across all of my apps on INT/RWD/RWI. The trigger was a CTR 13% × RPC $0.0092 × eCPM $1.21 anomaly on BW Android and an 11-year crash trend in App Store Connect showing a clear 2022 spike (when AppLovin was first integrated) across all five iOS apps. That kind of decision pulls from data, lived observation of test ads, and 11 years of memory. About $730/month of revenue went away. That's a call I make and own.
The third is interpreting anomalies. When match rate moves materially week-over-week, or one group's eCPM doubles overnight, attributing it to "network bidding logic change," "my own release timing," or "season" is hard for an agent. In my workflow, I lay Crashlytics, Play Console, App Store Connect, and AdMob reports side by side and reason; the context only lives in human heads here.
The fourth is adding or removing an ad SDK. Whether to integrate Mintegral, submit InMobi for review, or raise Meta's priority touches not just revenue but crash risk, UX, and apk footprint. If the agent says "Meta has higher average eCPM than AdMob Network," I don't promote Meta on that basis alone. Knowing Meta's quirks ("Code 1002 too frequently" frequency-cap behaviour) matters more than the average eCPM number.
How the handoff actually runs — a monthly review loop
I run a scheduled monthly review across all 50+ groups. The agent runs:
[Step 1] Data pull from AdMob report
- Window: last 30 days
- Impressions / match rate / estimated revenue / realized eCPM
for all 50+ groups
- Persist results as structured data (JSON / CSV)
[Step 2] Programmatic floor-to-eCPM evaluation
- Call evaluate_floor() on every group
- Bucket into "candidate to lower," "candidate to raise," "hold,"
"likely demand shortage"
[Step 3] Month-over-month diff
- Compare against last month's operations log
- Highlight groups where eCPM moved more than ±20%
[Step 4] Report generation
- Top 5 revenue contributors
- Bottom 5 match rates
- "Needs human judgment" list
- Mechanically applicable change candidatesI read the report in the morning with coffee, approve the subset I'm willing to commit, and tell the agent to "execute." The agent either calls APIs or drives the AdMob UI through a browser tool, then appends entries to admob-mediation-unified.md and we're done.
Before the agent ran this loop, it was 3–4 hours of manual work per month. Now under 30 minutes. The 3 hours go into app-side code maintenance and review replies — work agents can't (yet) do well.
A failure case I want to flag
Worth writing down, because the same trap might catch someone else.
The agent once proposed temporarily setting a group's floor to OFF to recover match rate. I approved it. The minimum eCPM disappeared across the entire bidding + waterfall stack, and overall eCPM caved. The AdMob spec is clear that Waterfall manual eCPM is not a substitute for the floor, but acting on an agent's proposal without re-reading the spec is easy to do.
After that I wrote a rules file (feedback_admob_ecpm_floor_warning.md) and started copy-pasting it into every agent instruction:
[Prohibited]
- Never set an INT group's floor to OFF
- Disabling the floor erases the minimum eCPM across bidding too
- Waterfall manual eCPM is NOT a substitute for the floorThe safer pattern: hand the agent both "what to do" and "what never to do," explicitly. The asymmetry matters more than you'd think.
Recent tuning, by way of example
A few real adjustments from the last month, labelled by agent involvement:
- 2026-05-17 (Android BW-INT) — 30-day eCPMs landed at JP $15.23, KO $8.64, TW $8.87, DE $5.62. Match rates JP 45% / KO 47% / TW 67% / DE 56%, all under 80%. The agent listed them as "floor too high" candidates → I approved → floors changed JP $15→$12, KO $10→$7, TW $10→$8, DE $10→$5
- 2026-05-24 (BW/UKI Android, all 20 groups) — Applied the half rule for AppLovin MAX. Agent computed → I pasted into AdMob's edit screen for 20 groups
- 2026-05-26 (All iOS/Android AppLovin INT/RWD/RWI pause) — Decision driven by crash evidence and CTR anomaly. Pausing was a manual click; the agent organised
applovin-stop-decision-2026-05-26.md
That last one is the right shape for large decisions: agent organises evidence, human pulls the trigger. Aggregation and reasoning go to the machine; the actual button push stays human.
Starting "half-agented" mediation operations
For someone bringing an agent into AdMob mediation today, here's the first-week order:
- Consolidate the existing mediation groups into a single operations log (
admob-mediation-unified.mdor equivalent) - Write the floor-to-eCPM evaluation function in Python, run it locally on your own data first
- Lock in one prompt for monthly match-rate monitoring, schedule it
- Write down a "prohibited" list and always include it in agent instructions
- Run the first month in "proposals only, human executes" mode
- Once a month runs cleanly, promote the low-risk tasks (operations log entries, half-rule arithmetic) to autonomous execution
Twelve years of running AdMob by myself has taught me that monetization tuning matters more for reproducibility than for raw speed. A lucky eCPM bump this month is meaningless if next month's path can't be reproduced. The point of bringing an agent in is to document your own judgment so anyone, including future-you, could run the same loop and get the same outcome. The time savings are a side effect.
Both of my grandfathers were temple carpenters. They never built without drawings. Mediation operations have the same shape — the drawing (operations log) comes first, and the agent's judgment stays inside the drawing. Let the agent draft the drawing itself, and one day revenue collapses.
Thanks for reading.