Designing AdMob App Open Ad Frequency Without Hurting Retention — Operational Notes from Wallpaper Apps

Rewriting Rork's Generated Foundation

Rork can scaffold a basic App Open Ad loader when prompted, but to satisfy the rules above the generated code needs explicit state on top. I started with a minimal Expo + React Native hook in TypeScript.

// hooks/useAppOpenAd.ts
import { useEffect, useRef, useState } from "react";
import { AppState, AppStateStatus } from "react-native";
import { AppOpenAd, AdEventType, TestIds } from "react-native-google-mobile-ads";
import { useRemoteConfig } from "./useRemoteConfig";
import { useSession } from "./useSession";
 
type AdState = "idle" | "loading" | "loaded" | "showing" | "error";
 
export function useAppOpenAd() {
  const { minInterval, coldStartSkip } = useRemoteConfig();
  const { lastShownAt, lastDismissedExternalAt, sessionStartedAt } = useSession();
  const [state, setState] = useState<AdState>("idle");
  const adRef = useRef<AppOpenAd | null>(null);
 
  // Initial load
  useEffect(() => {
    const ad = AppOpenAd.createForAdRequest(
      __DEV__ ? TestIds.APP_OPEN : "ca-app-pub-XXXXXXXX/YYYYYYYY",
      { requestNonPersonalizedAdsOnly: false, keywords: ["wallpaper", "lifestyle"] }
    );
    adRef.current = ad;
    ad.addAdEventListener(AdEventType.LOADED, () => setState("loaded"));
    ad.addAdEventListener(AdEventType.ERROR, () => setState("error"));
    ad.load();
    setState("loading");
  }, []);
 
  // Decide to show on foreground
  useEffect(() => {
    const sub = AppState.addEventListener("change", (s: AppStateStatus) => {
      if (s !== "active") return;
      if (!adRef.current || state !== "loaded") return;
 
      // Rule 1: skip the first cold start
      if (coldStartSkip && Date.now() - sessionStartedAt < 3000) return;
      // Rule 2: minimum interval
      if (Date.now() - lastShownAt < minInterval * 1000) return;
      // Rule 3: skip after returning from external modal UI
      if (Date.now() - lastDismissedExternalAt < 5000) return;
 
      adRef.current.show();
      setState("showing");
    });
    return () => sub.remove();
  }, [state, minInterval, coldStartSkip, lastShownAt, lastDismissedExternalAt]);
 
  return { state };
}

The point is to consolidate every time-based check inside this hook and to make minInterval and coldStartSkip arrive from Remote Config. From day one I want to be able to retune frequency in production without shipping a new binary.

Splitting Frequency by Cohort with Remote Config

Frequency design rarely lands at the right value on the first try. I use Firebase Remote Config to deliver per-cohort values and observe an A/B split. Here is the configuration I currently run for the Beautiful HD Wallpapers family.

// hooks/useRemoteConfig.ts
import remoteConfig from "@react-native-firebase/remote-config";
import { useEffect, useState } from "react";
 
const DEFAULTS = {
  app_open_min_interval_sec: 120,
  app_open_cold_start_skip: true,
  app_open_modal_skip_window_ms: 5000,
  app_open_enabled: true,
};
 
export function useRemoteConfig() {
  const [config, setConfig] = useState(DEFAULTS);
  useEffect(() => {
    (async () => {
      await remoteConfig().setDefaults(DEFAULTS);
      await remoteConfig().setConfigSettings({ minimumFetchIntervalMillis: 3600 * 1000 });
      await remoteConfig().fetchAndActivate();
      setConfig({
        app_open_min_interval_sec: remoteConfig().getNumber("app_open_min_interval_sec"),
        app_open_cold_start_skip: remoteConfig().getBoolean("app_open_cold_start_skip"),
        app_open_modal_skip_window_ms: remoteConfig().getNumber("app_open_modal_skip_window_ms"),
        app_open_enabled: remoteConfig().getBoolean("app_open_enabled"),
      });
    })();
  }, []);
  return {
    minInterval: config.app_open_min_interval_sec,
    coldStartSkip: config.app_open_cold_start_skip,
    enabled: config.app_open_enabled,
  };
}

On the Firebase Console side, I split conditions into "Cohort A (user-ID-suffix 0–4)" and "Cohort B (suffix 5–9)" and serve app_open_min_interval_sec as 60 for A and 180 for B. After three to five days, I cross-check the ad KPIs against D1 retention and converge toward the winning cohort's value.

A note on minimumFetchIntervalMillis: making it too short bumps into Remote Config rate limits. I keep it at one hour (3600 * 1000) by default. For emergency rollbacks I keep a separate path that does an explicit fetch followed by activate at launch.

Putting Modal Suppression on the Session Layer

The implementation that took the longest was the modal return suppression. The photo library, share sheet, in-app purchase sheet, camera, and OAuth web view are all routes where the user voluntarily leaves the app. Showing an App Open Ad when they return feels jarring because their intent was always to come back.

I chose to handle this on the session layer rather than the ad layer. The ad-side decision becomes trivially simple if it only needs one piece of session data: "when was the most recent external UI dismissed?"

// hooks/useSession.ts
import { create } from "zustand";
 
interface SessionState {
  sessionStartedAt: number;
  lastShownAt: number;
  lastDismissedExternalAt: number;
  markExternalShown: () => void;
  markAdShown: () => void;
}
 
export const useSession = create<SessionState>((set) => ({
  sessionStartedAt: Date.now(),
  lastShownAt: 0,
  lastDismissedExternalAt: 0,
  markExternalShown: () => set({ lastDismissedExternalAt: Date.now() }),
  markAdShown: () => set({ lastShownAt: Date.now() }),
}));

Callers mark the external UI before opening it.

import * as ImagePicker from "expo-image-picker";
import { useSession } from "./hooks/useSession";
 
export async function pickWallpaper() {
  const { markExternalShown } = useSession.getState();
  markExternalShown();
  return await ImagePicker.launchImageLibraryAsync({ mediaTypes: ImagePicker.MediaTypeOptions.Images });
}

Once this structure was in place, adding new external modals later only required one line — markExternalShown() immediately before the call. Rork-generated screens that grow new modal flows do not regress the ad-side logic, since the responsibilities are cleanly separated.

Three Weeks of Measured Movement

Below are actual numbers from three weeks of running Cohort A (min_interval 60s) versus Cohort B (min_interval 180s). My naive expectation was that A would print more impressions and capture more revenue. The results were not what I expected.

• Cohort A: impressions +27%, CTR -0.3pt, eCPM -8%, D1 retention -2.1pt, ARPDAU -3%
• Cohort B: impressions -6%, CTR +0.1pt, eCPM +12%, D1 retention roughly flat, ARPDAU +18%

Cohort A printed more impressions but lost on eCPM and retention. My read is that the ad networks detected the over-exposure through declining CTR and reduced their bids. After this three-week experiment, I converged on Cohort B's 180-second interval in production. The takeaway is counterintuitive on its face but consistent across the apps in my 50-million-download portfolio: lowering ad frequency can raise ARPDAU when the platform values longer-term engagement.

Delegating Daily Dashboard Review to Claude in Chrome

With this many parameters, manually opening AdMob and Firebase every morning accumulates real time cost. Alongside this update I switched daily trend review over to Claude in Chrome.

Concretely, I ask Claude in Chrome to do three things every morning.

1. Open the AdMob dashboard and pull per-app App Open Ad eCPM, fill rate, and CTR into a table
2. Cross-reference Firebase Console App Open Ad impression events with the previous day's values
3. Check whether today's app_open_min_interval_sec Remote Config value aligns with the CTR trend, and flag inconsistencies

The system only posts to Slack when CTR drops 0.3 points or more day over day. On normal days, no manual check happens. My role is to refine the prompt on days when an alert fires. After 12 years in the indie app business, one thing I have noticed is that watching ad KPIs daily dulls pattern recognition. Personally, the more days in a row I stare at AdMob, the worse my detection becomes. Delegating routine trend monitoring to AI and keeping my own attention for judgment calls fits my temperament better.

When I Accidentally Disabled the Cold-Start Skip

Soon after the rollout, one variant accidentally shipped with app_open_cold_start_skip = false. The cause was a misassigned condition in Remote Config — I had moved a variant into the wrong cohort. Within half a day, we lost roughly one star on store rating, and reviews showed up with "ad the moment I opened it" and "I get it, but I doubt I'll open it again." Then we looked at the Firebase value.

Two lessons stuck with me. First, Remote Config conditions need labels that any human can read at a glance. Naming a condition cohort_AB is the kind of abstraction that fools even its author later. Second, the risk of running an ad on cold start does not average out — for a user who opens the app once a day, the first launch's ad experience is the app's first impression. A small impression-count gain is easily wiped out by store rating damage.

My Current Priority Order

Putting the threads together, here is the priority order I think about when designing App Open Ad frequency.

1. Protect the very first cold start
2. Handle modal returns on the session layer
3. Keep the minimum interval inside a 90–180 second band, tuned through Remote Config
4. Track CTR, D1 retention, and ARPDAU together as three signals
5. Delegate dashboard reading to AI; keep human attention for judgment

The 50 million downloads that have supported my indie business were carried by ad revenue, which is why I refuse to be casual about wearing users down with ads. App Open Ads can be a kind format that captures real eCPM, or a quiet drag on retention, depending on how they are designed. The investment in careful design is, in my experience, more than repaid.

If you operate on the same format, I would love to hear how you have shaped your own Remote Config keys.