For weeks, the pattern looked the same. I would finish an afternoon meeting, open the AdMob dashboard, and only then realize the fill rate had been dropping since morning. Half a day of revenue is hard to claw back once it is gone, and the notes I write at that hour rarely capture what really happened. It was the kind of slow damage that I tolerated for too long.
I am Masaki Hirokawa, an artist and indie app developer. I have been making apps on my own since 2014, and the catalog has grown past 50 million cumulative downloads, mostly across wallpaper apps and gentle, healing-style apps. This post is about a small workflow change I tried for two weeks: letting Claude in Chrome read the AdMob report every morning so I could catch fill-rate drops before they cost me a full day.
Why I changed the routine
For a while, the AdMob dashboard was a place I visited when I felt like it. Right after a release, or after a floor-price change, I would check several times a day. Once things felt stable, I drifted down to two or three visits a week. That gap was exactly where the trouble lived. Fill rate could fall from the low 80s into the 60s for several hours before I noticed.
The trouble with noticing late is not just the lost revenue. Three things actually compound.
- Time zones make the damage spread. North American sessions go on while a misbehaving waterfall keeps serving suboptimal traffic.
- The diagnosis gets coarse. Network-level drops are easier to localize if you compare morning data and afternoon data separately, instead of treating the whole day as one block.
- The record is rough. By the evening, fixing things is rushed work, and I rarely write down why I made each decision.
Both of my grandfathers were temple carpenters, and the idea that "something built carefully will hold for decades" settled into me early. The same is true of code and operations. Skipping the daily inspection lets small problems quietly compound. Building the morning check into the schedule felt more honest to the work.
The setup
The current configuration is intentionally small. A Cowork scheduled task wakes Claude in Chrome at 07:10 JST. Claude opens the AdMob report URLs in sequence, exports filtered CSV per app and per network, and computes the gap against the same weekday in the prior week. If the difference for any network drops by more than my threshold — currently five percentage points — Claude posts a short summary into a private Slack channel. Anything quieter than that goes unreported.
The "say nothing if nothing is wrong" rule turned out to matter more than I expected. The first three days, I had Claude post a full summary every morning. By day three, the channel had become noise, and I started missing the lines that actually mattered. Once I switched to silence-as-no-news, I could trust the alert and react quickly when it arrived.
What the two weeks looked like
Between May 12 and May 24, Claude posted four real alerts. The breakdown:
- May 14 (Tue) — Liftoff fill rate down 12 points; a specific SDK build had stopped serving
- May 16 (Thu) — InMobi down 8 points; a geo filter had been left in the wrong state
- May 20 (Mon) — Unity Ads down 6 points; bidding logic appeared to have shifted overnight
- May 23 (Thu) — AppLovin MAX down 7 points; behavior right after an SDK update
In every case, I started looking at the issue before 10 a.m. JST. Under the old routine, I probably would have caught three or four of these later in the day, or missed one entirely. Across the four alerts, the rough revenue loss landed at around ¥18,400 — a recovery that scales to roughly ¥40,000 over a month.
That said, Claude only guessed the root cause correctly twice out of four. The numerical detection was reliable; the explanation was not. The remaining two cases needed me to bounce between AdMob and the partner consoles to figure out what had really happened. The lesson for me is clear: detection is something I can outsource, but the diagnosis still belongs with a human.
The friction I ran into
Two real frictions came with the convenience. The bigger one is session loss. AdMob asks for re-authentication every few days, and on those mornings, the scheduled task ran into a login screen and gave me nothing. I now set aside about ten minutes each Monday to open Chrome manually and sign back into AdMob, which has reduced — but not eliminated — the misses. If I were running this at a more serious scale, I would probably build a second account for redundancy or switch to a proper API integration.
The smaller friction is CSV export latency. When I ask for the full per-app, per-network breakdown, AdMob sometimes takes close to twenty seconds to assemble the file. Claude in Chrome cannot easily tell the difference between "the page is loading" and "the user is thinking." On a few days, the run looked frozen. I added an explicit timeout extension to the prompt, which calmed things down.
Trying the same thing with Claude Code
I also spent a morning testing whether Claude Code could do this through the AdMob API. The honest verdict is that it is doable but not worth it at my scale. Setting up the API keys, OAuth refresh, and report-grain configuration took the better part of half a day. With only four apps and four networks, checking the dashboard manually each morning is a five-minute job. I would gladly invest in the API path if I had ten or more apps, or several AdMob accounts. At an indie scale, Claude in Chrome started faster and stayed simpler.
Where I draw the line
After two weeks, the boundary is sharper.
- Delegated: fetching the report, comparing against the same weekday in the prior week, drafting the alert.
- Not delegated: the final call on cause, floor-price changes, the order of mediation networks.
- Shared: brainstorming candidate causes. Claude lists possibilities, and I pick by going through the AdMob, AppLovin, and Liftoff consoles myself.
When I was seventeen, an online mentor told me that "art is a natural language open to everyone." I have started applying that idea to how I use tools. Instead of trying to delegate every step, I keep the judgment with myself and ask the tool to assemble the materials for that judgment as quickly as it can. The morning fill-rate workflow is exactly that shape: the decision stays in my hands, only the gathering changes.
What I want to try next
Three threads to pull on next.
- Lower the alert threshold from −5 points to −3 points and see whether the noise stays bearable.
- Pull Crashlytics spikes into the same morning check, so revenue health and app stability show up in the same view.
- Once a month, ask Claude in Chrome to list every day in the last 30 that crossed the threshold, and look at the pattern over a longer window.
Five quiet minutes in the morning has bought back a surprising amount of confidence. When I come back from an afternoon meeting now, I know whether the day held its shape or not. If you are running your own apps and your own ad stack, I hope some of this is useful.