CLAUDE LABJP
FORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as OctoberFORK — Claude Code 2.1.212 changes what /fork does: it copies your conversation into a new background session with its own row in claude agents, so you can keep working. The old in-session subagent is now /subtaskLIMITS — WebSearch calls are now capped at 200 per session by default, and subagent spawns get the same 200 ceiling, so a runaway search or delegation loop stops on its ownMCPBG — MCP tool calls running past two minutes now move to the background automatically, keeping the session usable. Tune the threshold with CLAUDE_CODE_MCP_AUTO_BACKGROUND_MSPLANFIX — Fixed plan mode auto-running file-modifying Bash commands such as touch and rm without a permission prompt or an SDK canUseTool callbackSONNET5 — Claude Sonnet 5 is running on introductory pricing of $2 per million input tokens and $10 per million output. After August 31 it moves to $3 and $15IPO — Bankers are reportedly lining up investor meetings for Anthropic ahead of a possible public listing as soon as October
Articles/Cowork
Cowork/2026-06-03Intermediate

Rebalancing Interstitial Frequency in a Wallpaper App: Three Weeks of Trading Revenue Against Retention

I spent three weeks tuning only the interstitial frequency in a wallpaper app, watching where AdMob eCPM and next-day retention meet. Here is the quiet, unglamorous adjustment that actually moved things, with Claude in Chrome reading the dashboards alongside me each morning.

AdMob12interstitialfrequency-capindie-developer6monetization21

"Show one more ad and this month's revenue will go up." I have proven that to myself many times. But a few days later, the share of people who reopen the app the next morning quietly slips. Between short-term revenue and being used for the long run, I have spent years looking for the right place to draw the line. For the last three weeks I narrowed the whole question down to one knob — the display frequency of interstitials (full-screen ads) in a wallpaper app — and measured exactly where that line sits. Here is the record, offered as a reference for anyone wrestling with the same trade-off.

I have been building iOS and Android apps on my own since 2014, mostly wallpaper and calming apps, with around 50 million downloads across them. AdMob interstitials are my main source of revenue, which is exactly why "when and how often to show them" is the most delicate dial I own. It touches both the money and the feel of the app at the same time.

Why I touched frequency, not price

For a long time, "ad tuning" for me meant the price side: raising fill rate, revisiting floor prices, reordering mediation priority. Each of those helped. But at some point the numbers plateaued, and it became clear that chasing unit price further would buy me very little.

What remained was the dial I was most afraid to touch: frequency. Frequency is tempting because raising it visibly increases short-term revenue. Push it too far, though, and the experience becomes "open the app, see an ad; view one wallpaper, see an ad," and uninstalls creep up. The scary part is that this damage does not show up in same-day revenue — it shows up days later, lagging, in retention. Tune it by feel and you will misread it every time.

I split three weeks into three stages

Changing everything at once makes it impossible to know what worked, so I changed exactly one condition per week.

The first week I left the existing setup untouched to capture a baseline: show one interstitial after a set number of wallpapers viewed, with no cooldown and no cap. I recorded next-day retention and revenue per daily active user (ARPDAU) as the yardstick I would measure everything else against.

In week two I stopped the ad on launch, so the very first wallpaper is always shown without an ad. The goal was to protect the first moment after opening.

In week three I added a minimum cooldown (no next ad until a certain number of seconds has passed since the last one) and a per-session cap on the number of interstitials. Even when someone swipes through wallpapers continuously, an ad will not appear sooner than the interval allows.

The shape of the adjustment (wallpaper app interstitial)
- Baseline week: show every N views (no cooldown, no cap)
- Week 2: never show on launch (protect the first moment)
- Week 3: add minimum cooldown seconds + per-session cap
Metrics watched: next-day retention / ARPDAU / impressions per session

The numbers themselves are specific to my app, so I will describe the direction things moved rather than exact values. In week two, next-day retention recovered slightly and ARPDAU barely dropped. In week three, impressions per session fell noticeably, yet the dip in ARPDAU was far smaller than I expected, and retention recovered another step. The biggest takeaway: cutting impressions does not cut revenue by the same amount.

Cooldown and cap look similar but play different roles. A cooldown is a brake against firing ads back-to-back, protecting people who burst through wallpapers in a short window. A cap is a ceiling against showing too many in one session, which matters most for people who stay a long time. Only with both in place did extreme experiences stop appearing for heavy and light users alike.

I made Claude in Chrome the "reconciler"

The most tedious part of this kind of tuning is that the evidence lives in different places. Ad revenue is in AdMob; retention and session behavior in GA4; uninstalls and rating shifts in Google Play Console and App Store Connect. Opening four dashboards every morning and reconciling them in my head quietly drains focus.

There is one detour worth flagging. I removed the full-screen ad on launch to protect the first moment, but a separate App Open Ad I had configured was still firing — so "an ad the instant you open" quietly came back. Watching only interstitials, I missed that App Open is a separate channel. When you measure frequency, count how many ads a user touches per day across ad formats, not within one format. I learned that the painful way in week two.

So for these three weeks I had Claude in Chrome open each dashboard in turn every morning and summarize, in a paragraph, how retention and ARPDAU moved versus yesterday, and whether the change in impressions and the change in retention pointed the same way. I kept the final judgment for myself; what I handed off was the fetch-and-line-up work before the decision.

What I am careful about is not delegating the judgment itself. Retention can fall for reasons other than ad frequency — the week's update, or the quality of new installs. So I treat the summary as a list of "candidate observations," and I always check with my own eyes whether the week I changed frequency and the metric that moved line up in time. As a reconciler it is genuinely dependable, but the person who carries the responsibility at the end is the maker.

What settled in over three weeks

Both of my grandfathers were temple carpenters, and I grew up taking for granted the idea that anything people touch should be handled with care. Remeasuring ad frequency kept returning me to that feeling. A user's attention is not something to seize roughly, again and again — it is the time of someone who deserves to be treated with care.

On the practical side, care did not betray me either. Even when I lowered frequency rather than greedily raising it, more people kept the app around, and the total impressions those people generate held steadier. Protecting "they will open it again next week" compounds better than maximizing a single day's revenue. Obvious, perhaps — but I was half in doubt myself until the numbers confirmed it.

What I will try next

Next I will stop applying one frequency to everyone and instead vary it gently by launch count or days of use: lighter for newcomers, standard for people who already open it daily. The measurement stays the same — change one condition per week and check that retention and ARPDAU move in agreement.

Frequency tuning is not a flashy lever, but it quietly underpins the revenue base of an indie operation. I hope this becomes a small foothold for anyone weighing revenue against feel in the same way. Thank you for reading.

Share

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

Cowork2026-06-04
Where the human still has to press the button — lessons from delegating ad ops to Cowork
From actually delegating repetitive ad operations — AdMob bidding-partner sign-ups and floor tuning — to Cowork, here is the boundary I found between what AI can fully own and the single moves a human still has to make by hand.
Cowork2026-05-29
Three Weeks of Letting Claude in Chrome Tune My AdMob Mediation Priorities
I let Claude in Chrome handle the reordering of AdMob mediation priorities for three weeks. Here is how I set the threshold, the three prompt changes that actually mattered, the numbers, and the parts I deliberately kept under human control.
Cowork2026-05-28
Folding AdMob and Crashlytics into One Morning Check via Cowork Scheduled Tasks — Two-Week Notes
I had been checking AdMob fill rates and Crashlytics surges in two separate dashboards each morning. I folded them into a single Cowork scheduled task. Here are my two-week notes, with the numbers and the friction I ran into.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →