App Open Ads: When They Pay Off and When They Hurt Retention

App open ads lifted Supercent's ARPDAU 7%. For the wrong app, they tank retention. Here is the operator framework for when to add them and when to skip.

App open ads are net positive in apps with infrequent, single-purpose opens: utility apps, hyper-casual games with a natural loading window, tools. They hurt retention in apps users open five or more times per day, including news, social, content, and productivity apps where every open is a micro-decision about whether to stay. The decision hinges on opens per day, session frequency, and whether the format is shown on warm starts (it should not be, without a cooldown). Gross revenue lift is not the right metric. Cohort ARPDAU at D7 and D30 is.

What an app open ad actually is (cold start, warm start, and the full-screen takeover)

App open is a full-screen interstitial format triggered at the app-open moment. If you already know the difference between a cold start and a warm start, this section will still matter to you because most implementations treat them identically, and that is where the retention damage starts.

A cold start is a fresh process launch. The app was not in memory; the user tapped the icon from the home screen or app switcher and the OS is loading the application. There is an inherent delay between tap and usable app state. A warm start is a resume. The process was still in memory, the activity restores, and the user lands directly in the app content they left. No loading transition. Instant.

The cold start loading window is why app open ads have a defensible UX case in some apps. The user is already waiting. An ad that fills that dead time is not adding friction; it is monetizing time that would otherwise be blank. A warm start has no loading window. Showing a full-screen ad on every warm start puts a barrier in front of a user who expected to land immediately in active content. The friction profile is categorically different, and the retention cost reflects that.

AdMob's own documentation contains one under-cited signal: "apps with frequent opens (more than once every four hours) see the best performance." Read that in reverse. Apps where users open more than four times per day are outside the target performance zone for this format. The guidance is phrased as a positive, but it is the closest Google's documentation comes to telling you when not to add app open ads.

One more detail worth naming: AdMob offers a high-engagement variant that delays the close button to five seconds instead of the standard two. On paper, higher engagement time sounds like higher CPM. In practice, applying a five-second forced-view to every app open on a frequency-sensitive app means users are blocked for five seconds each time they try to access the app. That is a UX cost that does not show up in the revenue dashboard until it shows up in the retention curve.

The Supercent case study, read honestly

Supercent ran a two-week A/B test on their flagship hyper-casual title "Hit & Run," covering half their global installed base. App open ads increased ARPDAU by 7%. No negative impact on retention or crash rates was reported. The result is real.

Here is what made it real.

"Hit & Run" is a hyper-casual game with a natural two-to-three-second loading window between splash screen and game initiation. That window gave app open ads a clean display moment with no added delay. The user base was already ad-conditioned: over 90% of Supercent's revenue came from in-app advertising. These are users who expect interstitial-format ads as part of the product experience. And the implementation was careful. Supercent built a dedicated loading screen specifically to give the ad a clean window. Their initial show rate was 11%, which they identified as too low, and they adjusted to over 40% by solving the loading timing.

What the case study does not disclose: no D7 or D30 retention delta between test and control cohorts. "No negative impact on retention" was noted but not quantified. Additionally, the ARPDAU lift overlapped with concurrent bidding improvements and ARO (App Return On Investment) Google Ads campaigns running during the same period. Isolating the app open contribution from those concurrent changes is not possible from the public data.

The honest read: the 7% ARPDAU lift is reproducible under the right conditions. Those conditions include a hyper-casual category, a user base that derives most of its value from ad experiences, a natural loading window built into the product, and a careful implementation. Take any of those conditions away and the result does not transfer.

A social app, a news reader, a productivity tool, or any app where users open more than three to four times per day is not in the Supercent condition. The case study does not say that. Vendor documentation does not say that. This article does.

App categories where app open ads work

The question is not whether the format can fill. It can. The question is whether showing a full-screen ad at the app-open moment is structurally compatible with how your users use the app. That is a session-frequency and user-intent question, not an eCPM question.

Hyper-casual and casual games with loading windows. The loading state creates a natural display window. The ad fills dead time rather than interrupting active content. This is the Supercent condition. If your game has a defined loading screen of two seconds or more and the user base is ad-primary, app open ads are structurally suited to it.

Utility apps with single-purpose sessions. Calculator, unit converter, translator, barcode scanner, PDF reader. Users open for one task and close. Open frequency is typically one to two times per day. There is a clear start and end to each session, and the open moment is a recognizable transition rather than a reflex behavior. A full-screen ad at that transition reads as "this is how the app works," not as an obstacle.

Archival and reference tools. Recipe apps, travel reference guides, DIY instruction sets. These apps are opened infrequently but produce extended sessions when used. Low open frequency and defined task intent make the format workable.

The common thread across these categories: the user opens the app for a specific purpose, the session has a defined structure, and the open frequency is below three to four times per day per active user. The open moment is a transition. An ad at a transition is interpretable. An ad that interrupts a reflex behavior is not.

The eCPM reality. AdMob claims app open eCPMs can reach "up to 70%" of interstitial eCPMs. Tested results from non-gaming apps at scale, based on GameBizConsulting's published data, land at 13-39% of interstitial eCPMs. That is the actual range to model from for initial projections. Anything above 30% of your interstitial eCPM is a favorable outcome. Plan for the floor, not the ceiling.

A mediation note relevant to AdMob Mediation vs AppLovin MAX: true app open ad support is limited. AdMob and Pangle support the format natively. AppLovin MAX does not offer a native app open ad unit. MAX offers an interstitial-at-app-start, which is functionally similar but is categorized differently in reporting and fills from different demand. These are not equivalent configurations for eCPM comparison or reporting purposes.

App categories where app open ads hurt

The structural incompatibility in high-frequency-open apps is this: when the format shows on every open, it becomes a tax on opening. For apps where opening is habitual or impulsive, that tax compounds. Users do not make a conscious trade-off decision each time they see the ad. They accumulate friction. At some point, they stop opening.

Social and communication apps. Users open these five to fifteen times per day, often to check a single notification. A full-screen ad on every open means multiple ad views per day per active user. The sessions are short, which means the revenue per open is low. The cumulative UX cost is high.

News and content apps. High open frequency plus immediate content intent. The user is not arriving at a loading transition. They are arriving to consume content. An ad that delays that access at the moment of highest intent produces a disproportionate frustration response relative to the revenue the ad generates.

Productivity and task management. These apps are often opened in response to a specific trigger: a reminder notification, a calendar alert, a deadline. The user is in action mode when they open. A full-screen interstitial at that moment is not background noise; it is an interruption of an active intention.

Shopping and commerce apps. High-intent opens. A user tapping into a shopping app during a purchase consideration is the worst moment to show a barrier. Even a short one. Bounce risk before the intended action is a conversion cost that does not appear in the ad revenue line.

Mid-core and hardcore games on warm start. These users carry active game state from session to session. A warm start resumes them inside that state. An app open ad on warm start in this context is not a loading-screen ad. It is a mid-session interruption dressed as an app-launch event.

The open frequency threshold. Apps averaging more than four opens per DAU per day are structurally outside the performance zone AdMob's own documentation identifies. That is a specific, measurable number you can pull from your analytics today. Check it before adding the format.

The first-session problem. Default SDK implementations show app open ads to all users from the first open. For a new user who has not yet seen any value from the app, the first experience of the product being a full-screen ad barrier is not a monetization moment. It is an onboarding failure. Implement a session count or days-since-install gate before the format shows to any user. Three sessions or three days installed is a defensible starting threshold.

The frequency cap and cooldown period that matter

"Every cold start" is not a frequency policy. It is the absence of one. Most SDK implementations will show an app open ad on every qualifying open unless you explicitly configure a cooldown. The default is the wrong starting point for almost every app.

The cold start cooldown, by category.

For utility apps with one to two opens per day: every cold start is defensible if warm starts are suppressed. The open frequency is low enough that per-session shows are not cumulative irritants.

For casual games with two to four opens per day: a two-hour cooldown is a reasonable starting point. It prevents multiple same-day shows without eliminating revenue on a meaningful share of opens.

For apps approaching the four-opens-per-day threshold: a four-hour cooldown minimum. Below that, the format shows multiple times per day on your median active user.

For apps above four opens per day: either skip the format entirely, or set a hard cap of once per 24 hours and run a retention holdback test before treating that configuration as stable.

The warm start cooldown is not optional. Cross Field's frequency-cap adjustment (published in GameBizConsulting's data) reduced show frequency to 50% of opens and produced over 30% ARPU improvement. That result is evidence that the default "every open" trigger is wrong for most apps, and that a properly configured cooldown makes the format more profitable, not less.

The correct warm start logic: store a timestamp of the last app open ad show. On every foreground event, whether cold or warm start, check the elapsed time since that timestamp. Show only if the elapsed time exceeds the configured cooldown. Reset the timer on every show. This is not default SDK behavior. You need to add the cooldown logic yourself.

Warm start handling: the implementation detail that determines retention impact

This section is about the specific implementation behavior that turns a reasonable format into a retention problem. Warm start mishandling is the most common cause of negative retention outcomes from app open ads.

Both iOS and Android give you deterministic lifecycle callbacks that distinguish cold starts from warm starts. On Android, ActivityLifecycleCallbacks tracks onStart() and onStop() transitions. On iOS, UIApplicationDelegate and SceneDelegate provide applicationWillEnterForeground callbacks. These are platform-provided and unambiguous.

AdMob's official app open implementation uses an AppLifecycleObserver (Android) or SceneDelegate method (iOS) to detect foreground transitions and load or show the ad. The sample code does not include a cooldown check. It shows the ad on every foreground transition, cold start and warm start alike, unless you add the cooldown logic. This is the implementation most publishers deploy, because it is the implementation Google's documentation shows.

The correct behavior requires four additions:

  1. Store the timestamp of the last app open ad show. Not the last load. The last show. The distinction matters when loads fail.
  2. On every foreground transition, check the elapsed time since the last show against your configured cooldown threshold.
  3. Call show() only if the cooldown has passed.
  4. Reset the timestamp on every show.

There is also an SDK race condition to know about. App open ads must be loaded before they can be shown. If the load request fires on the foreground transition event but the user reaches the main app screen before the load completes, the ad should not be shown retroactively mid-session. The correct pattern is background preloading: load the ad in advance, show it on the next qualifying foreground transition if it is ready. Do not hold up app content display waiting for an ad load to complete.

On the splash screen interaction: if your app has a splash screen with a defined minimum display time (common in games), the app open ad can display within that window without adding delay. If the app has no splash screen, do not show an app open ad immediately on cold start with no loading buffer. The user will see a full-screen ad before they see any app content, which reads as interference rather than monetization.

AdMob's own guidance is explicit on this point: "display ads only before the app screen fully loads." Warm starts do not have a loading window. That single sentence is the clearest first-principles argument for suppressing app open ads on warm starts by default.

The broader UX balance question that app open ads fit into is covered in Balancing Ad Revenue and User Experience on Mobile Apps. The warm start decision is the app open specific version of that general trade-off.

The retention cost benchmark by category

There is no published, vendor-neutral dataset on app open ads' specific retention impact by category. The Supercent case study reports "no negative impact" for hyper-casual but provides no retention delta between test and control cohorts. GameBizConsulting's published data covers eCPM performance, not retention. The operator community has anecdotal reports of retention drops from high-frequency-open apps but no controlled study results.

What is known from adjacent interstitial format research is directionally consistent: interstitials at high frequency are associated with lower D1 and D7 retention in games. The direction is consistent across multiple published studies and platform guidance. The magnitude varies by category, but the pattern holds.

App open ads are full-screen interstitials applied to the highest-frequency moment in the session structure: every open. Their retention cost profile is structurally similar to mid-session interstitials, concentrated at a specific moment rather than distributed across a session.

The useful frame is not "does this specific format hurt retention" as an abstract question. It is: how many additional full-screen interruptions per day does this format add to my app, and what does that additional load do to my D7 and D30 curves?

By open frequency.

Apps averaging one to two opens per DAU per day: app open ads add one to two full-screen interruptions per day. With proper cold-start-only triggering and a cooldown on warm starts, the incremental interruption load is low. Retention impact is minimal for compatible categories.

Apps averaging three to five opens per DAU per day: without a cooldown, app open ads add three to five full-screen interruptions per day. Even with a four-hour cooldown, the format will show once to twice per day per active user. That is 30 to 60 additional full-screen interruptions per month per active user, on top of whatever mid-session interstitials are already running.

Apps averaging five or more opens per DAU per day: the format should not be added without a hard cap of once per 24 hours maximum and a cohort retention holdback test before any scaling decision. The additional interruption load at this open frequency is too high relative to the eCPMs the format generates.

How to measure this for your own app. Run a cohort comparison: users who received at least one app open ad in their first seven days versus users who did not, using a proper A/B holdback. Compare D7 and D30 retention rates. A difference of more than three to five percentage points at D7 is a signal worth investigating before scaling. If the test cohort has materially lower D30 retention, the format is taking future ARPDAU and converting it into near-term ad revenue. Most apps should not make that trade.

Post-ATT attribution complicates downstream LTV measurement on iOS. The SKAdNetwork 4.0 Conversion Value Setup article covers how to structure the attribution window to catch the retention impact in the right measurement period.

Decision framework: add, test, or skip

This is a framework with explicit criteria. The four variables that determine the outcome are: opens per DAU per day, app category, revenue mix, and user lifecycle stage.

Add with standard configuration.

All of the following must be true:

  • Opens per DAU per day: 1-3
  • App category: utility app, hyper-casual game, casual game with a loading window, archival or reference tool
  • Revenue mix: ad-primary (50% or more of revenue from ads)
  • User base: established (not a new launch where retention data is not yet stable)

Standard configuration for these apps: cold start trigger, warm start blocked until four-hour cooldown has passed, onboarding gate (three or more sessions or three or more days installed), standard two-second close delay (not the high-engagement five-second variant).

Test with holdback before scaling.

Any one of the following is enough to require a holdback test:

  • Opens per DAU per day: 3-5
  • App category: mid-core games, casual content apps, lifestyle apps
  • Revenue mix: hybrid (both IAP and ads are material revenue contributors)
  • User base: launched less than 90 days ago, or D7 retention is currently below 20%

Test configuration: 20-30% of traffic in the test group, cold start only, four-hour cooldown on warm starts, onboarding gate in place. Measure D7 and D30 cohort retention against holdback before any decision to scale. Do not scale until cohort data is clean at D30.

Do not add (or remove if already added).

Any one of the following is a stop condition:

  • Opens per DAU per day: 5 or more
  • App category: social, news, communication, productivity, task management, shopping or commerce
  • Revenue mix: IAP-primary (app open eCPMs at 13-39% of interstitial do not justify retention risk for IAP-primary apps)
  • D7 retention currently below 15% (fragile retention does not tolerate additional full-screen interruptions at the open moment)

The overriding condition, regardless of category. If your A/B test shows a D7 retention delta of more than five percentage points between the app-open cohort and the holdback, remove the format. Gross revenue from the ad unit does not compensate for accelerated churn at that retention cost.

If you are not sure which category your app falls into, or if you have already added app open ads and suspect they are affecting retention, a structured audit of your cohort data will answer that faster than a longer test period. That is the kind of structured engagement that starts with the free initial conversation at /contact.

Implementation gotchas

The five errors below are not in vendor documentation. They are the implementation failures that show up in production and are hard to diagnose from a reporting dashboard alone.

The SDK initialization race condition.

App open ads require the AdMob (or mediation) SDK to be initialized before a load request can be made. Initialization takes time. If the load request fires before initialization completes, the load silently fails. The symptom: low fill rates on first sessions but not a zero fill rate. New users see no app open ad on their first cold start. It is inconsistent behavior that does not appear as an obvious error. The fix: initiate the first app open ad load inside the onComplete callback of MobileAds.initialize(), not at application start unconditionally.

Check your SDK version compatibility first. The Mediation SDK Checker will surface known adapter conflicts and initialization timing issues before you debug them manually.

The splash screen timing mismatch.

If the app open ad shows during a splash screen, the splash screen and the ad must share the same display window. If the splash screen dismisses before the ad is ready, the app content is already visible when the ad appears. The user sees a full-screen ad interrupt active content, not a loading-screen ad. The behavioral impact is categorically different. Use a splash screen minimum display time of two to three seconds, and ensure the app open ad is displayed within that window or suppressed entirely on that open.

The warm start handler in the wrong lifecycle method.

On Android, ActivityLifecycleCallbacks.onStart() fires on both cold starts and warm starts. Many implementations put the show logic in onStart(), which means the ad shows on every foreground transition including warm starts. The correct approach on Android is to track foreground and background state using ProcessLifecycleOwner, and trigger the ad show only on foreground entries that correspond to a user-initiated open, with cooldown gating applied.

The high-engagement variant applied without a retention holdback.

The five-second close-delay variant is designed for high-CPM inventory with low open frequency. Using it as the default on a frequency-sensitive app means habitual openers are blocked for five seconds per open before they can access the app. Test the five-second variant specifically against a retention holdback. Do not apply it as the default and check revenue only.

No onboarding exclusion.

The default SDK implementation shows app open ads to all users from the first session. There is no built-in gate. A new user's first experience being a full-screen ad before they have seen any value from the app is not a monetization moment from their perspective. It is an unearned barrier. Implement a session count or days-since-install gate before any show logic is invoked.

Measuring app open ads' true impact (the cohort framing)

The wrong measurement is looking at gross revenue lift in the AdMob reporting dashboard after adding app open ads. Revenue from the new ad unit is visible within days. The retention cost shows up in D7 and D30 cohort curves one to four weeks later. Publishers who measure only the revenue side conclude the format is working. Publishers who measure the cohort see the full picture.

The right measurement is net ARPDAU on a cohorted basis. Not "what did I earn from app open ads this week" but "what is the ARPDAU of users who received app open ads at D7 and D30, compared to a holdback cohort that did not receive them?"

If net ARPDAU is higher in the app-open cohort: the format is net positive. Ad revenue from app open exceeds the retention-weighted revenue lost to churn.

If net ARPDAU is flat or lower: the format is converting future user sessions into near-term ad revenue. That trade benefits the current month's numbers. It costs long-term user value.

How to run the cohort test in AdMob.

Create a mediation group A/B test in AdMob. App open ads enabled in the test group, excluded in the holdback. Set holdback size at 20-30% of traffic. Run for a minimum of 45 days: 14 days of exposure plus 30 days of cohort follow-up. Export cohort data from Firebase or Google Analytics for Firebase to compare D7 and D30 retention rates between groups. Evaluate net ARPDAU, not just ad revenue. If the app has IAP, include estimated IAP revenue by cohort in the net ARPDAU calculation.

The LTV frame for D30+ retention apps.

For apps where meaningful revenue extends past 30 days, a three to five percent retention drop at D30 from app open ads represents more lost future ARPDAU than the weekly app open revenue adds. The breakeven point depends on your average user LTV duration. Apps with 90-day or longer meaningful retention should be conservative with this format. The math on that breakeven needs to be run on your actual cohort data, not on industry averages.

What to watch in reporting.

Fill rate by session type: low fill rates on warm starts typically indicate the warm start handler is not suppressing shows correctly. The ad is being requested but there is no loading window for it to fill.

eCPM by time of day and geography: app open eCPMs are sensitive to both. US morning and evening opens tend to see higher eCPMs. Tier-2 and tier-3 geos will land in the 13-39% of interstitial range rather than the upper end.

Per-user daily show frequency: if this metric is above two shows per day per DAU, the cooldown configuration is not working as intended.

The measurement approach differs between mediators. AdMob Mediation vs AppLovin MAX covers the reporting differences that affect how you interpret cohort data across platforms. For the broader mediation stack context that app open ads exist within, see Mediation Waterfall vs In-App Bidding.

Use the AdMob Approval Checker to confirm your AdMob configuration is clean before running the A/B test. A misconfigured mediation setup will produce noisy cohort data.

If your app has meaningful D30-plus retention, running the net ARPDAU analysis on your specific cohort data before scaling app open ads is worth doing before the test window closes, not after. That is the kind of structured engagement that starts with the free 30-minute call.

Frequently Asked Questions

Do app open ads hurt user retention?

They can, and the risk is category-specific. In utility apps, hyper-casual games, and apps with 1-3 opens per day, properly implemented app open ads (cold start only, warm starts suppressed, 4-hour cooldown) show minimal retention impact in published testing. In apps with 5 or more opens per day, including social apps, news readers, productivity tools, and communication apps, app open ads add multiple daily full-screen interruptions at the highest-friction moment in the session. The retention cost in those categories is real. The only way to confirm which situation your app is in is to run a properly structured A/B test with a holdback cohort and measure D7 and D30 retention, not just gross revenue.

What is a reasonable cooldown for app open ads?

The right cooldown depends on your app's session frequency. For apps with 1-2 opens per DAU per day, a 2-4 hour cooldown is defensible. For apps approaching 4 opens per day, the cooldown should be at least 4 hours, keeping total daily shows near or below one per DAU. For apps above 4 opens per day, a 24-hour cooldown (once per day maximum) is a more appropriate starting point, and even that requires a retention holdback test before scaling. The important point: cooldown applies to warm starts as well as cold starts. Resetting the timer only on cold starts and showing freely on warm starts defeats the purpose of the frequency policy.

Should I show app open ads on warm starts?

No, as a default behavior. A warm start is an app resume. The user is returning to active content without a loading transition. Showing a full-screen ad on every warm start is structurally different from showing one during a loading screen. AdMob's own implementation guidance says to display app open ads only before the app screen fully loads, and warm starts do not have a loading window by definition. The practical implementation: store a timestamp of the last show, check on every foreground event (cold and warm), and show only if the elapsed time exceeds your configured cooldown. The default SDK code does not do this; you need to add the cooldown logic yourself.

Which app categories should NOT use app open ads?

Social apps, news and content readers, communication apps, productivity tools, task management apps, and shopping apps should not use app open ads as a default monetization strategy. The common factor: these apps are opened frequently (5 or more times per day by active users) and the app-open moment is a high-intent action, not a loading transition. A full-screen ad at that moment competes with the user's reason for opening the app. App open eCPMs typically land at 13-39% of interstitial eCPMs in these categories, which does not compensate for the retention cost. If you are in one of these categories and want to test the format, use a holdback cohort of at least 20% and measure D30 retention before committing to full rollout.

How do I A/B test whether app open ads are net positive for my app?

Set up a mediation group A/B test in AdMob with app open ads enabled in the test group and excluded in the holdback. Keep the holdback at 20-30% of traffic. Run the test for a minimum of 45 days: 14 days of exposure plus 30 days of cohort follow-up. Measure D7 and D30 retention rates for both groups using Firebase or Google Analytics for Firebase. Compare net ARPDAU, including both ad revenue and IAP revenue if applicable, rather than just ad revenue. A retention delta of more than 5 percentage points at D7 is a stop signal. If net ARPDAU is flat or lower in the app-open group despite higher ad revenue, the format is converting future LTV into near-term revenue, a trade most apps should not make.

Why do my app open ads not fill?

Low fill on app open ads is commonly caused by three things. First, the ad was requested during a warm start without a loading window: the SDK starts a load but the app resumes before the load completes, resulting in a non-fill. Fix this by preloading the ad in advance, not reactively on the foreground event. Second, eCPM floors set too high in the mediation configuration: app open eCPMs run at 13-39% of interstitial levels, and floors set to interstitial benchmarks will clear most of the available demand. Third, SDK initialization timing: if the ad load request fires before MobileAds.initialize() completes, the load silently fails. Always initiate the first app open ad load in the SDK initialization callback, not in parallel with it. Mediation note: only AdMob and Pangle support native app open ad units. AppLovin MAX's app-start interstitial is a different unit type and fills from different demand.

The bottom line

App open ads are not categorically good or bad. They are a full-screen format triggered at the highest-stakes moment in a user's session: the decision to open the app. Whether that trade-off is net positive depends entirely on how often your users open, what they open for, and whether your implementation protects the moments that should not be interrupted.

The format has a legitimate place in the right app. Hyper-casual games with loading windows, utility apps with single-purpose sessions, reference tools with infrequent opens. In those contexts, with cold-start-only triggering, proper warm start suppression, and an onboarding gate, app open ads add revenue without meaningful retention cost.

In any app where opening is habitual or high-frequency, the format is a tax on the behavior that drives your retention curve. The eCPMs, at 13-39% of interstitial levels, do not cover that cost.

Run the cohort test with a proper holdback. Measure net ARPDAU at D7 and D30, not gross revenue. If the numbers are clean, scale. If they are not, the format is not your answer.

If you want to work through that analysis for your specific app, that is what the free 30-minute call is for.