Banner Refresh Interval Optimization for Mobile Apps: The Operator's Framework

For mobile app banners, the refresh interval is a secondary variable. The primary variable is whether refresh is triggered by visibility (banner is on screen) or by a timer (regardless of screen position). Visibility-based refresh produces fewer but higher-quality impressions; time-based refresh on an off-screen banner produces impressions that advertisers do not pay for at premium rates. AdMob enforces a 30-second minimum interval; GAM for mobile allows 30-120 seconds. The practical optimum for most mobile apps is 45-60 seconds with visibility-gating enabled, not the fastest rate the platform allows. Faster is not better once viewability per impression drops faster than impression count rises.

The math: refresh interval trades viewability for impression count

Most operators treat the refresh interval as a configuration they set once and forget. The interval compounds silently across every session, every user, every day. The mechanism that makes it consequential is specific: each refresh cycle produces one impression, but that impression is only valuable to advertisers if it is viewable. The IAB defines a viewable display impression as 50% of pixels visible for at least 1 continuous second. In practice, premium DSP buyers apply a more demanding threshold, often requiring 1-2 seconds of confirmed viewing time before crediting an impression. When your refresh interval generates impressions against a banner the user cannot see, those impressions enter your reporting as filled but they enter demand-side models as low-quality.

The concrete math: if your banner position is typically visible for 45 seconds before a screen transition or scroll, a 30-second refresh generates roughly 1.5 impressions per viewing window at approximately 75-80% viewability. The banner is on screen for both refresh cycles. A 15-second refresh (not permitted under AdMob policy, but common in older third-party implementations) generates roughly 3 impressions per viewing window at approximately 40-50% viewability. The first impression is fully viewed; subsequent ones compete with user navigation and screen transitions. The 30-second interval produces approximately 1.5 viewable impressions. The 15-second interval produces 1.5-1.8 viewable impressions. Nearly identical viewable yield, at twice the request volume, with materially lower viewability per impression.

The inflection point is the operative concept. There is an interval below which each additional refresh cycle produces fewer incremental viewable impressions than it produces additional requests. Below that inflection, impression count rises while viewable impression count flattens or falls, and eCPM begins to compress. Where the inflection sits depends on app category (session dwell behavior varies), format (anchor banners have structurally higher viewability than inline banners), and how long the banner has already been on screen.

The Unwind Media case study is the clearest empirical illustration available. Switching from time-based to engagement-triggered refresh reduced bid requests by 20% and increased viewability by 14%, with paid impressions increasing 5%. Fewer requests, higher quality per request, net revenue up. This is not a theoretical argument. It is what happens when you stop generating impressions no one is paying for.

The right question is not "how often should I refresh?" It is "how often can I refresh while maintaining viewability above the threshold where advertiser demand stays healthy?" That is a different question, and it has a specific answer for each format and each app's session behavior profile.

Google's 30-second minimum (and why it exists)

AdMob's custom refresh interval is configurable from 30 to 150 seconds via the AdMob UI. The option to set anything below 30 seconds does not exist in the standard interface. Google's recommended default is the "Google-optimized rate," which uses historical data for your ad unit to determine the best refresh frequency automatically.

The 30-second floor exists because of how viewability is measured. At a 30-second interval, a banner that is on screen for the full cycle has a high probability of meeting the IAB viewability threshold and the more stringent 1-2 second confirmation that many DSP buyers apply. Below 30 seconds, the probability of meeting advertiser viewability standards on every cycle falls, and the value of each impression decreases proportionally.

Google Ad Manager for mobile app inventory supports 30-120 seconds, with a documented default of 60 seconds when refresh is enabled. GAM's documentation explicitly recommends that ads persist for 60 seconds or longer depending on app functionality.

One piece of AdMob SDK behavior that most operators do not know about: when refresh is configured through the AdMob UI (the only supported method for standard AdMob banner ad units), the Google Mobile Ads SDK for Android enforces a visibility gate. Auto-refresh fires only when the banner is visible on screen. The SDK will not refresh an ad that is not visible. If you configured your AdMob banners through the UI and have not added a supplementary timer at the app layer, you are already running visibility-gated refresh without knowing it.

AppLovin MAX handles this differently. MAX banners do not auto-refresh on a fixed interval by default. The publisher or mediation configuration defines refresh behavior. Publishers using MAX who add a timer-based refresh in application code (a common pattern in older implementations) bypass the visibility check that AdMob's SDK enforces. This is one of the primary sources of accidental time-based refresh on off-screen banners in production apps. For the broader comparison of how AdMob and MAX handle banner configuration, see AdMob Mediation vs AppLovin MAX.

The compliance line applies across platforms. A refresh interval below 30 seconds is not configurable in AdMob and violates Google's ad serving policies. For AppLovin and other networks, check each network's specific refresh policy documentation before setting any interval below 30 seconds. Meta Audience Network has historically flagged apps with excessively fast banner refresh as a policy concern. Meta does not publish a specific minimum in their public documentation, but the practical floor based on common operator experience is 30 seconds.

The transparency obligation matters too. Google's policy for refresh requires that refresh behavior be transparent to demand partners. Undeclared or opaque refresh is treated as invalid traffic in some enforcement contexts.

The viewability-impression tradeoff (when faster refresh lowers revenue)

The mechanism most operators encounter when they shorten their refresh interval and their eCPM drops is not obvious from the reporting. You see fewer bids or lower clearing prices. You do not see a line item that says "viewability penalty." The cause is on the demand side.

Demand-side platforms track viewability performance per publisher, per placement, in real time. When your viewability rate for a given ad unit falls below 60-70%, buyers begin to apply bid discounts or deprioritize the placement in their targeting models. eCPM falls gradually, not in a single event. The compressed eCPM is the symptom. The degraded viewability score is the cause.

The direction of the tradeoff for a typical inline banner in a casual game where screen transitions occur every 60-90 seconds:

30 seconds: Approx Impressions/Minute: 2 · Viewability (typical inline banner): ~75-80% · Viewable Impressions/Minute: ~1.5-1.6 · eCPM direction: Baseline

45 seconds: Approx Impressions/Minute: 1.3 · Viewability (typical inline banner): ~80-85% · Viewable Impressions/Minute: ~1.1-1.1 · eCPM direction: Lower impressions, higher eCPM per impression

60 seconds: Approx Impressions/Minute: 1 · Viewability (typical inline banner): ~85-90% · Viewable Impressions/Minute: ~0.85-0.9 · eCPM direction: Fewer impressions, highest eCPM per impression

90 seconds: Approx Impressions/Minute: 0.67 · Viewability (typical inline banner): ~88-92% · Viewable Impressions/Minute: ~0.59-0.62 · eCPM direction: Fewest impressions, highest absolute eCPM

These are illustrative ranges for this specific app category and placement type. Actual numbers vary. Do not use these as direct benchmarks. Use them to understand the direction of the tradeoff, then calibrate with your own app's data.

The correct optimization target is viewable impressions per session multiplied by eCPM per viewable impression. Not raw impression count. A 30-second interval that produces 6 impressions per session at 70% viewability yields 4.2 viewable impressions. Extend to 45 seconds and you produce 4 impressions at 82% viewability: 3.3 viewable impressions. The 30-second interval still wins on viewable impression count, but eCPM per impression is higher at 45 seconds. Whether total revenue is higher depends on your specific demand mix. There is no universal answer. The calculation is yours to run.

The scenario where longer works better: utility apps, news apps, productivity tools where users spend extended time on single screens. These apps have high dwell time on the banner position. Longer intervals produce fewer requests against the same viewable exposure, which means higher viewability per impression and higher eCPM. A 60-second or 90-second interval can produce equal or higher net revenue than 30 seconds when the eCPM lift is real and viewable impression count is nearly identical.

The scenario where shorter can work: hyper-casual games with very short round structures (10-20 seconds) where the banner is consistently on screen through the entire round. The available viewing window is short by design. A 30-second interval in this context maximizes capture of the viewing window without materially degrading viewability.

For the broader relationship between session-level ad frequency and user retention, see Balancing Ad Revenue and User Experience on Mobile Apps. Refresh interval is one component of that system, not a standalone lever.

Visibility-based refresh vs time-based refresh (the bigger lever)

The interval number is not the primary refresh variable. The refresh trigger condition is.

Time-based refresh fires on a wall-clock interval regardless of whether the banner is currently visible on screen, regardless of whether the user is actively using the app, and regardless of whether the ad has had any meaningful viewing time. An ad that refreshes while the user's phone is face-down, while a modal is covering the banner, or while the user has scrolled the banner off screen generates a bid request and fills an impression. That impression has near-zero viewability. As advertiser measurement tools improve, buyers will purchase less of this inventory.

Visibility-based refresh fires only when the banner is confirmed visible, passing an on-screen threshold check. The impression is served when it has a reasonable probability of being seen. Viewability rates are materially higher. Bid requests are fewer but each request is for a higher-quality impression. eCPM holds.

The AdMob default behavior is a point worth repeating: when refresh is configured through the AdMob UI, the SDK automatically enforces visibility-gating. Most operators who configure AdMob banners through the UI are already getting visibility-based behavior. The risk is in implementations that add a supplementary timer at the app layer, which can fire refresh requests independently of the SDK's visibility check.

For AppLovin MAX and custom refresh implementations: publishers using MAX with a manual timer-based refresh in application code are running time-based refresh without visibility gating unless they have explicitly implemented the check. The fix is to use MAX's built-in refresh behavior or to add an active-visibility check in the app layer before triggering the refresh timer.

The practical operator check: open your app, navigate to a screen where the banner is below the fold or off-screen, and use the mediation reporting in real time or a test device with verbose SDK logging to confirm whether refresh requests are firing. If requests are firing while the banner is off-screen, you are running time-based refresh. If they are not, you have visibility-gating in place.

Engagement-based refresh is the more advanced mode, and it is the ceiling of refresh optimization rather than a starting point. The most sophisticated implementations trigger refresh based on user engagement signals rather than just on-screen visibility. A banner is visible but the user has been scrolling continuously past it with no meaningful pause. An engagement-based approach delays refresh until there is a measurable pause in scroll velocity or a screen dwell event. On mobile, the equivalent triggers on app-foreground events, scroll stops, or screen-transition events rather than a raw timer. Few mobile operators implement this today.

The revenue impact difference between visibility-based and time-based refresh is typically larger than the difference between a 30-second and 60-second interval. Fix the trigger condition before adjusting the number. For viewability considerations specific to anchor and sticky placements where visibility is structurally high by design, see Sticky and Anchor Ads Implementation Guide.

App category benchmarks (utility, casual game, news, social)

Refresh interval is not a universal number. The optimal interval is a function of how long the banner position is typically visible before the user navigates, scrolls, or transitions. App category is the primary predictor of that behavior.

Utility apps (weather, productivity, tools, calculators): Users spend extended time on single screens. The banner may be visible for 2-5 minutes during a task. Screen transition frequency is low. Recommended starting interval: 60-90 seconds. Viewability will be high because users are stationary on screen. A 30-second interval in a utility app is unlikely to cause viewability problems, but it is unlikely to produce proportionally more revenue either, because demand-side buyers are already satisfied with your viewability score and the additional impressions generate incrementally lower bids. Start at 60 seconds with visibility gating. If eCPM holds and viewability is high, testing 45 seconds is a reasonable next step.

Casual games (puzzle, match-3, runner): Screen transitions are frequent. The banner may be visible for 30-60 seconds between level transitions, then obscured during scoring screens and menus. Recommended starting interval: 45-60 seconds with visibility gating. At 30 seconds, refresh may fire during transitions when the banner is partially obscured, degrading viewability. At 60 seconds, you may miss refresh cycles during long sessions where the user plays through multiple levels with the banner consistently on screen. Priority: confirm visibility gating is active before adjusting the interval. A 60-second visibility-based refresh may produce higher revenue than a 30-second time-based refresh in a game with 45-second average level duration.

News and media apps: Users scroll through feeds and articles. The banner is visible when reading but scrolled off screen at the top or deep in an article. Recommended starting interval: 60 seconds with visibility gating. News users have variable on-screen banner exposure; longer intervals reduce the probability of off-screen refresh. The anchor banner exception: if the banner is implemented as a bottom anchor (consistently visible regardless of scroll position), the interval can be shortened to 45 seconds because viewability is structurally high. Standard inline banners in article feeds should use longer intervals.

Social and community apps: Feed scrolling means the banner is visible briefly as the user scrolls past. Social sessions are interaction-driven, not dwell-driven. Recommended starting interval: 60-90 seconds. Faster intervals in a feed-scroll context produce impressions during scroll-past moments with minimal actual view time. The quality argument for longer intervals is strong here. Apps with very long sessions (30 minutes or more) can sustain lower eCPM per impression across more impressions; shorter-session apps should prioritize impression quality over count.

Hyper-casual games: Very short rounds (10-20 seconds), high ad density tolerance, banner persistent through rounds. The banner is often the only format other than interstitials. Banner eCPM is a meaningful revenue component at scale. Recommended starting interval: 30-45 seconds. The round structure means the banner is consistently visible during gameplay and briefly obscured during round end/start transitions. A 30-second interval captures approximately one refresh per round in a typical hyper-casual title. Visibility gating is still the correct mode.

The compliance line (AdMob, AppLovin, IAB)

The compliance constraints are reference information, not alarm signals. Here is what the rules are and what happens when they are violated.

AdMob policy: Custom refresh intervals are supported in the 30-150 second range via the AdMob UI. Below 30 seconds is not configurable. Google also prohibits publishers from using code-level mechanisms to trigger banner refresh outside the AdMob system (for example, destroying and recreating the banner ad view on a fast timer to simulate sub-30-second refresh). The violation is not purely a policy technicality. Sub-30-second refresh via app-layer workarounds generates inventory quality signals that affect eCPM directly.

Google Ad Manager (GAM) for mobile app: Refresh intervals of 30-120 seconds are supported. Publishers using GAM as the ad server alongside mediation must declare their refresh behavior to Ad Exchange. Failing to declare constitutes a policy violation. GAM's default is no refresh; 60 seconds is the auto-populated value when refresh is enabled.

AppLovin MAX: AppLovin does not publish a specific minimum refresh interval the way AdMob does. However, AppLovin's demand partners, including Google's buy-side, apply their own viewability standards to inventory transacted through MAX. Running sub-30-second refresh on MAX inventory will depress eCPM from Google demand and other premium DSPs regardless of whether MAX has an explicit policy violation. See Mediation Waterfall vs In-App Bidding for context on how demand-side pricing interacts with mediation configuration.

IAB viewability standards: The MRC and IAB define a viewable display impression as 50% of pixels visible for at least 1 continuous second. Ad tech buyers using MRC-accredited viewability measurement (DV, IAS, MOAT) will credit only impressions that meet this threshold. Fast refresh on off-screen banners does not meet this threshold and generates measured viewability scores that reduce buyer confidence in your inventory.

The practical operator summary: do not go below 30 seconds. Do not refresh off-screen. Make sure your mediation configuration reflects the refresh interval and mode you are actually running, not a default. For publishers who want to check their current AdMob configuration, the AdMob Approval Checker provides a structured audit view.

A/B testing methodology for refresh interval

Ad load A/B testing is the area where the most operator errors occur, and refresh interval testing has a specific set of failure modes that are worth naming before you design a test.

The contamination problem: a before-after comparison of refresh interval conflates the interval change with day-of-week variation in advertiser demand, weekly budget cycle effects (Monday-Tuesday demand is systematically higher than Friday-Saturday), any concurrent SDK or adapter changes, and seasonal eCPM patterns. None of these can be separated from the refresh interval effect in a before-after design. You change the interval on a Monday, compare to the prior week, see higher eCPM, and conclude the interval worked. The eCPM may have been higher regardless.

Proper A/B test design for refresh interval: split traffic at the user or session level, not at the date level. Assign users to test and control groups using a feature flag system. Firebase Remote Config is the standard tool for this in mobile. The control group runs at the current interval. The test group runs at the candidate interval. Maintain the split for at least 14 days to capture weekly demand variation in both groups simultaneously.

Change one variable: the refresh interval or the refresh trigger type (visibility vs time), not both simultaneously. Multiple concurrent changes make attribution impossible.

Sample size and measurement window: to detect a 5% difference in eCPM per session at 90% confidence, you need a minimum of 3,000-5,000 users per group with a 14-day window. Apps with lower daily active users should extend the window to 21-30 days rather than conclude at insufficient sample size. Day-of-week demand effects take at least two full weeks to average out.

Measure in this order:

1. Impressions per session for the specific ad unit. If impressions did not change as expected from the interval change, the configuration did not take effect. Confirm the setup before drawing any other conclusions.
2. Viewable impression rate. Did viewability change in the direction you expected from the interval change?
3. eCPM per impression. Did advertiser pricing change in response to viewability?
4. Revenue per session. Net effect: more impressions at lower eCPM vs fewer impressions at higher eCPM, which direction won?
5. Session length and D7 retention. Banner refresh changes are unlikely to produce measurable retention effects, but confirm there is no concurrent change driving a retention signal.

The key diagnostic: if impressions per session increased but revenue per session did not, the additional impressions are not producing proportional eCPM. Viewability fell faster than impression count rose. The interval is too short. If impressions per session decreased but revenue per session held, viewability and eCPM improved enough to compensate. The interval can potentially be extended further.

Before starting any refresh interval test, confirm your SDK and adapter versions are current and stable. An SDK or adapter change that happens in the same window as a refresh interval change contaminates the result just as badly as a day-of-week effect. Use the Mediation SDK Checker to confirm versions before running a change that takes four weeks to validate.

The most common mistake in refresh interval testing is running a before-after comparison and concluding the interval caused an eCPM shift that was actually driven by day-of-week demand variation or a concurrent SDK update. A properly controlled test requires a user-level split and a 14-day minimum window. If you are not sure whether your current interval is leaving revenue on the table, that is worth checking before you run a change that requires four weeks to evaluate. Book a free 30-minute call.

How to read the data (eCPM by interval, viewable impressions per session, retention signal)

Operators who run a refresh interval change often look at the wrong columns. Here is the measurement sequence that gives accurate read on a refresh change.

eCPM per ad unit, not account-level eCPM. Your account-level or app-level eCPM is diluted by rewarded video and interstitial pricing, which are unrelated to a banner refresh change. Pull the eCPM for the specific banner ad unit where you changed the interval. Account-level eCPM can be misleading in both directions.

Impressions per session for the specific ad unit. An interval reduction from 60 to 30 seconds should theoretically double impressions per session, all else equal. If impressions per session did not increase proportionally, visibility gating is limiting the refresh. The banner is not on screen for the full available interval window. This is diagnostic: it means the app's session behavior limits how much the interval reduction can deliver. Do not interpret it as a configuration error; interpret it as data about your app's actual on-screen dwell time.

Viewability rate at the ad unit level. AdMob provides viewability metrics per ad unit as visible impressions as a share of total impressions. GAM provides more granular active view data. If viewability fell alongside the interval reduction, the additional impressions are partially off-screen. If viewability held, the new interval is operating within the visibility-gated window.

Revenue per daily active user (ARPDAU) for banner only. This is the cleanest single metric for evaluating a refresh interval change. Calculate it as total banner revenue per day divided by daily active users. A successful interval reduction shows ARPDAU increasing. An interval reduction that hurt viewability and eCPM shows ARPDAU flat or decreasing despite more impressions. For how floor pricing interacts with eCPM per impression to determine clearing prices, see Floor Pricing Strategy for Mobile Apps 2026.

Network-level eCPM decomposition. If you run mediation with multiple networks, pull eCPM per network for the banner ad unit. A refresh interval reduction that caused viewability to fall will produce eCPM drops preferentially in networks whose buyers apply stricter viewability standards (Google's buy-side demand, programmatic DSPs). Networks with lower viewability sensitivity may hold their eCPM. If you see a divergence where some networks held eCPM while others dropped, the cause is viewability-related, not demand-cycle variation.

Retention signal. Banner refresh interval changes are unlikely to produce measurable D7 retention effects. Unlike interstitial frequency changes, which can affect session-end behavior, banner refresh operates below the UX awareness threshold for most users. If D7 retention changes in the same window as a banner refresh change, the cause is almost certainly something else. Do not attribute a retention change to a banner refresh change without ruling out other concurrent app changes. For a structured audit of your AdMob configuration before or after a refresh change, use the AdMob Approval Checker.

Common refresh mistakes (and what each costs)

Most of these mistakes compound silently. The eCPM degradation from off-screen refresh or a loop-refresh implementation accumulates per impression, per session, per day. There is no alert and no dashboard notification. The only signal is gradual eCPM compression that looks like normal demand variation.

Mistake 1: Sub-30-second refresh via app-layer timer. The publisher implements a background timer in app code that destroys and recreates the banner ad view on a 15 or 20-second cycle to simulate fast refresh outside the SDK. This comes from web publisher forum advice applied to mobile without checking AdMob's SDK behavior or policy. What it costs: the SDK visibility check is bypassed or reset on each recreation, viewability collapses, and eCPM from premium demand sources falls sharply within days of rollout. The app may pass initial review but faces enforcement risk during account-level quality reviews. Fix: remove the app-layer timer. Configure refresh through the AdMob UI only (30-second minimum). Let the SDK manage the refresh lifecycle.

Mistake 2: Anchor banner refresh set too fast. Anchor banners (fixed position at the bottom or top of screen) are often treated as a special case where they are always visible so faster refresh is safe. The logic is partially correct: anchor banners do have high viewability. But the conclusion that faster refresh is therefore safe ignores the policy floor and ignores that very fast refresh on an anchor generates more impression requests than demand can clear at quality CPMs. An anchor refreshing every 10 seconds generates 6 impressions per minute. At $1.00 eCPM baseline, that is $0.006 per minute. An anchor refreshing every 45 seconds at $1.80 eCPM (higher because viewability is strong) generates 1.3 impressions per minute at $0.0023. The faster option loses. Fix: set anchor banner refresh at 45-60 seconds. Confirm via the metric sequence above before shortening. For the full implementation context for anchor and sticky placements, see Sticky and Anchor Ads Implementation Guide.

Mistake 3: Time-based refresh firing on off-screen banners. The refresh timer fires regardless of banner visibility. Custom refresh implementations at the app layer (common in MAX integrations or in apps migrated from SDK implementations without the AdMob visibility gate) fire the timer on the wall clock. What it costs: every off-screen impression degrades the viewability score for that ad unit. DSP bid models update on this data and apply discount pricing. eCPM falls gradually. Fix: add a visibility check before triggering any app-layer refresh. The check must confirm the ad view is within the viewport and the app is in the foreground before firing the request.

Mistake 4: Refresh-on-network-error in a tight loop. Some SDK implementations or custom mediation logic retry an ad request immediately on a no-fill or network error, creating a sub-second refresh loop. This is not a scheduled refresh. It is an error-handling loop that behaves like extremely fast refresh. What it costs: rapid-fire impression requests that are almost all unfilled count against impression limits and can generate invalid traffic signals. Networks may throttle or suspend the ad unit. Fix: implement exponential backoff on no-fill events. The first retry should wait at minimum 30 seconds. Subsequent retries should wait 60, 120, and then 300 seconds before treating the condition as a longer-term no-fill situation.

Mistake 5: One refresh interval applied to all banner formats. The same 30-second interval applied to a standard 320x50 banner, an MREC, an anchor banner, and an adaptive banner, without considering that these formats have different dwell-time behavior and different advertiser CPM expectations. One interval setting, applied globally, requires no per-unit configuration thought. What it costs: the MREC typically has higher viewability and commands higher eCPM than a standard banner. Refreshing the MREC at the same rate as a standard banner may deplete viewability faster than the format's demand depth justifies. Anchors can tolerate shorter intervals than inline banners. The format-level calibration is the correct configuration. Fix: configure refresh intervals per ad unit. Start with 30-45 seconds for anchors (consistently visible), 45-60 seconds for MRECs (high value, protect viewability), and 60 seconds for inline standard banners (variable visibility depending on scroll behavior).

Most of the mistakes above compound silently. If your banner eCPM has been drifting down without a clear cause, refresh configuration is one of the first things to audit. Book a free 30-minute call.

Format-by-format refresh guidance (banner, MREC, anchor, adaptive, sticky)

Each format has different structural visibility characteristics, different advertiser CPM expectations, and therefore a different optimal refresh strategy. This section is the reference table.

Standard banner (320x50 and variants). Structural visibility: variable. A top-of-screen banner in a utility app is visible throughout the session. A mid-content inline banner in a game is obscured during active gameplay and visible during menu states. Recommended interval: 60 seconds as the starting point, with visibility gating active. Confirm visibility gating first. The interval number matters less than ensuring off-screen refreshes are not occurring. eCPM sensitivity to interval changes is moderate. Standard banners have thin demand and CPMs in the $0.30-$1.50 range in Tier 1 markets. Viewability is a larger eCPM driver than the interval.

MREC / 300x250. Structural visibility: higher than standard banners in most implementations. MRECs are typically placed in high-dwell positions (end of article, between levels, at natural content pauses). Recommended interval: 45-60 seconds. The higher CPM of MRECs ($0.80-$2.50 in Tier 1 depending on app category) means the viewability argument is stronger. Protect each impression's quality. Do not place an MREC in a position where it will frequently be off-screen and then apply a fast refresh. The combination of a premium format and degraded viewability produces a worse eCPM outcome than a lower-CPM format with high viewability.

Anchor banner (persistent, bottom or top of screen). Structural visibility: high by design. The anchor is always in the same position and is visible unless covered by a modal, a keyboard, or an app-level overlay. Recommended interval: 30-45 seconds. The anchor's structural visibility advantage means the viewability cost of a shorter interval is lower than for other formats. A 30-second interval on a well-implemented anchor that is visible throughout the session is compliant with policy and maintains higher viewability than a 30-second interval on an inline banner. Watch for modals and keyboards. When a soft keyboard appears or a full-screen overlay covers the anchor, refresh should not fire. If your implementation fires refresh during keyboard-present states, that is effectively off-screen refresh.

Adaptive banner. Structural visibility: depends on implementation. An adaptive banner that fills the full screen width at a fixed position has similar visibility characteristics to an anchor. An adaptive banner placed inline in a scroll view has the same variable visibility as a standard inline banner. Recommended interval: follow the guidance for the functional placement type, not the technical format name. Adaptive anchor: 30-45 seconds. Adaptive inline: 60 seconds. Google recommends adaptive banners over fixed-size banners for fill rate and eCPM reasons. The refresh guidance follows from placement behavior, not format name. For the full implementation and optimization guidance for adaptive banners, see Adaptive Banner Ads.

Sticky banner (overlay on content rather than in the layout flow). Structural visibility: high. Sticky banners that overlay content are visible until explicitly dismissed. Recommended interval: 45-60 seconds for sticky banners on content screens. The overlay nature of sticky banners creates UX friction if ad load is perceived as high; faster refresh compounds that friction without proportional revenue gain. Sticky banners on gaming apps where the overlay persists between rounds can use 30-45 seconds given consistent visibility. Sticky banners that partially cover content (news, article reading) should use 60 seconds to minimize the compounded UX impact of a visible, frequently-changing overlay. For implementation and viewability optimization of persistent placements, see Sticky and Anchor Ads Implementation Guide.

For publishers evaluating whether mediation configuration is contributing to refresh behavior issues, see Mediation Waterfall vs In-App Bidding for how mediation stack structure affects how ad requests are handled.

Banner refresh is not a set-and-forget configuration. Visibility gating, format-specific intervals, and a valid test methodology are the difference between refresh that protects eCPM and refresh that erodes it impression by impression. If you want to run a refresh audit against your specific app's session data rather than against these benchmarks, that is what the free initial conversation is for. Book a free 30-minute call.

Frequently Asked Questions

What is the optimal banner refresh interval for a mobile app?

For most mobile apps, 45-60 seconds is the practical starting point, but the interval is secondary to whether refresh is visibility-gated (fires only when the banner is on screen) or time-based (fires on a clock regardless of visibility). An anchor banner with consistent on-screen presence can use 30-45 seconds. An inline banner in a casual game where screen transitions frequently obscure the placement should use 60 seconds or longer. There is no universal optimal number. The correct interval is the shortest interval at which viewability per impression remains above 70 percent, which is specific to your app's session behavior and placement type.

What is the minimum refresh interval AdMob allows?

AdMob's custom refresh interval is configurable from 30 to 150 seconds via the AdMob UI. Below 30 seconds is not configurable through the standard UI. AdMob's SDK also enforces visibility-gating: auto-refresh only fires when the banner is visible on screen, regardless of the interval configured. Google Ad Manager for mobile app inventory supports 30 to 120 seconds with a default of 60 seconds when refresh is enabled.

Does faster refresh always mean more revenue?

No. Faster refresh increases impression count but can decrease viewability per impression if refresh fires during off-screen or low-attention moments. Demand-side platforms track viewability at the publisher and placement level. When viewability falls below 60 to 70 percent, buyers apply bid discounts or reduce spend on the placement and eCPM drops. If eCPM falls faster than impression count rises, revenue per session decreases despite more impressions. The correct optimization target is viewable impressions per session multiplied by eCPM per viewable impression, not raw impression count.

Should I refresh banners when they are not visible to the user?

No. Refreshing off-screen banners generates impressions that have near-zero viewability. These impressions are measured by advertiser viewability tools and degrade the quality score for your placement in DSP bid models. Viewable-CPM buyers will price your inventory lower if your viewability rate falls. AdMob's standard implementation already prevents off-screen refresh when refresh is configured through the AdMob UI. If you have added a supplementary refresh timer at the app layer, which is common in custom AppLovin MAX integrations, confirm that timer includes a visibility check before firing.

What is the difference between visibility-based refresh and time-based refresh?

Time-based refresh fires on a wall-clock interval regardless of whether the banner is currently visible on screen. Visibility-based refresh fires only when the banner is confirmed on-screen and the app is in the foreground. Visibility-based refresh produces fewer but higher-quality impressions. AdMob's SDK enforces visibility-gating by default when refresh is configured through the UI. AppLovin MAX and custom implementations may use time-based refresh unless a visibility check is explicitly implemented in the app layer. The difference in revenue impact between the two modes is typically larger than the difference between a 30-second and 60-second interval.

How do I A/B test banner refresh intervals without breaking my eCPM data?

Split traffic at the user level using a feature flag system such as Firebase Remote Config. Assign users to test and control groups before the test starts and maintain the split for at least 14 days to average out day-of-week demand variation. Change one variable, either the refresh interval or the refresh trigger type, not both simultaneously. Measure in order: impressions per session first to confirm the change took effect, then viewability rate, then eCPM per impression, then revenue per session. A before-after comparison that changes the interval on a Monday and compares it to the prior week is contaminated by day-of-week demand cycles and is not a valid test.