Ad Refresh Strategies: How Often Is Too Often

What's Actually Happening Inside That Ad Slot

Ad refresh, at the code level, is just a new ad request fired into a slot that already exists on the page, without a full page reload. The div stays put, the surrounding content doesn't move, but the ad server call runs again and a new creative gets swapped in. That's it mechanically. No navigation event fires, no new pageview registers in most analytics setups unless you've wired it that way deliberately, and the user's scroll position and reading state are untouched.

This is different from what happens on an infinite-scroll site where new ad units get injected as fresh content loads in — that's technically a new impression on a new slot, not a refresh of an existing one, even though publishers often lump the two together in conversation. It matters because Google's policy language treats them somewhat differently, and I've seen ad ops teams get confused auditing their own implementation because they didn't separate the two mechanisms in their tagging.

Under the hood, most refresh implementations either call googletag.pubads().refresh() for GAM-served slots or re-trigger a Prebid.js auction cycle followed by that same GAM refresh call for header bidding setups. Either way, the slot's targeting parameters usually get updated too — you're not just re-serving the same request, you're often passing a fresh key-value or incrementing a refresh count that downstream demand can use to bid differently.

Why This Exists: The Static Ad Problem

The economic case for refresh comes down to one observation: a visitor who spends 5 minutes on a long-form article page looks at the exact same banner the entire time unless something changes it. That's a wasted opportunity on any site with real dwell time. A news site with a 45-second average session gets almost nothing from refresh. A recipe site, a forum thread, or a long guide with an 8-minute average session is leaving real money on the table with static units.

I've run this comparison across a handful of publisher accounts with session lengths above 4 minutes: adding a single interaction-gated refresh cycle to a mid-page unit typically lifted total ad revenue per session by 15-25%, mostly because it converted otherwise-idle screen time into additional monetized impressions. On a site with 90-second average sessions, the same change moved the needle by low single digits — not nothing, but not worth the engineering time either.

The mistake I see constantly is publishers treating refresh as a blanket RPM booster to bolt onto every template regardless of content type. It's a tool for long-dwell pages specifically. If most of your traffic bounces off a page in under a minute, refresh isn't your lever — your unit placement and broader page UX probably matter a lot more to your bottom line than anything refresh-related.

What Google Actually Requires, Not What Forums Claim

There's a lot of outdated and honestly wrong information floating around about refresh policy. The core requirement, as Google has communicated it through Ad Manager and AdSense policy channels, is that a refreshed ad impression needs to be tied to a genuine user action or a meaningful content change — not to the passage of time alone. That's the line that separates a compliant implementation from one that reads as an attempt to inflate impression counts artificially.

In practice, the accepted patterns are: refreshing when a user returns to a tab after switching away and back (using the Page Visibility API), refreshing when new content loads via infinite scroll or pagination, refreshing after a user interaction like clicking to expand a section or advancing a slideshow, and refreshing tied to substantial content changes such as navigating within a single-page app without a full reload. What's explicitly not acceptable is a fixed interval timer that fires regardless of whether the user is even still looking at the screen.

Enforcement here isn't theoretical. I've had two client accounts receive policy warnings in the past year specifically flagged for refresh behavior — both were running blind 15-second timers inherited from an old plugin nobody had audited. Neither got suspended, but both had to prove remediation within a set window, and that's a stressful conversation to have with a client when it was entirely avoidable. If you haven't reviewed your refresh logic since Google's last enforcement pass, it's worth checking against the current policy guidance before you assume your setup is still fine.

Why The 30-Second Timer Is A Trap, Not A Shortcut

Blind interval refresh — fire every 30 seconds, no questions asked — is the single most common implementation mistake I find when auditing a new account. It's tempting because it's the easiest thing to code: one setInterval call and you're done. But it creates three separate problems that compound on each other over time.

First, it refreshes ads for users who've scrolled away, switched tabs, or are on a slow connection and haven't even seen the first creative render yet — pure waste that drags down your overall viewability rate. Second, it's the exact pattern Google's invalid traffic detection is tuned to catch, because genuine user engagement doesn't happen on a fixed clock. Third, and this surprises people, it often hurts revenue even when it doesn't trigger enforcement, because demand partners see the pattern in bid request data and start discounting bids on that inventory or dropping out of the auction entirely.

I'll say the unpopular thing here: most of the refresh plugins sold as plug-and-play solutions still default to timer-based logic because it's simpler to build and demo. If a vendor pitches you refresh and can't explain exactly what user action triggers each request, that's a red flag worth pushing back on before you sign anything.

Triggers That Actually Hold Up To Scrutiny

Event-driven refresh means tying the ad request to something a real, present user actually did. This is more engineering work than a timer, but it's the difference between a defensible implementation and one you'll have to rip out after a policy warning.

The patterns I implement most often across publisher sites fall into a fairly narrow set, and combining two or three of them usually covers most of a site's engaged traffic without overreaching.

• Tab visibility change — refresh only fires when a user switches back to the tab after being away, using document.visibilityState, capped at one refresh per return
• Infinite scroll milestones — new ad slots load with new content batches rather than refreshing existing slots blindly
• Explicit interaction — refresh tied to a click, an accordion expand, a next-page click, or a slideshow advance
• Meaningful SPA route change — for single-page apps, refresh on virtual pageviews that represent genuine content navigation
• Minimum elapsed time plus confirmed viewability — even event-triggered refresh should respect a floor, typically 30 seconds since the last impression, so a burst of clicks doesn't spam requests

The Viewability Gate You Cannot Skip

Here's the requirement that trips up more implementations than the trigger logic itself: a slot generally should not refresh into a new impression unless the prior ad in that slot was actually viewable. That means meeting the standard viewability threshold — 50% of pixels in view for at least one continuous second for display, two seconds for video — before the countdown to the next eligible refresh even starts.

This matters because a slot sitting below the fold, never scrolled into view, technically "exists" on the page the whole session, but it never generated a viewable impression. If your refresh logic is keyed purely to time-on-page rather than to a viewability event firing first, you can end up refreshing units that were never seen at all, which is worse for revenue and worse for how demand partners score your inventory over time.

If you're not already instrumenting viewability at the slot level with something like the IntersectionObserver API feeding into your ad refresh logic, that's the first fix to make before you touch refresh timing at all. It's worth reading through the mechanics in our full breakdown of viewability if you haven't already, because refresh built on top of a shaky viewability foundation just compounds whatever measurement problems you already have.

Refresh And Header Bidding: The Auction Has To Run Twice, Three Times, Four Times

Every refresh cycle isn't just a new ad server call — if you're running header bidding, it means re-triggering the entire Prebid auction before that GAM call goes out. That's a new round of bid requests to every configured demand partner, a new auction timeout window to manage, and a new set of latency tradeoffs on every single refresh, not just the initial page load.

The practical complication is bidder participation drop-off. In accounts I've audited, bid density on refreshed impressions typically runs 20-35% lower than on the initial auction for the same slot, because some demand partners either throttle repeated requests from the same page view or simply have lower fill probability for a signal that reads as a mid-session re-request rather than a fresh visitor arrival. You're not getting the same competitive auction each time — you're getting a thinner one.

This is also where technical debt piles up fast. Every refresh needs its own auction timeout, its own targeting key updates, and its own cleanup of prior bid responses so stale creative doesn't render. I've seen sites where refresh was added without updating the Prebid config's auction ID handling, and it caused duplicate-counting issues in reporting that took weeks to untangle. If your header bidding wrapper wasn't built with refresh in mind from day one, budget real development time to retrofit it properly rather than bolting refresh calls on top of an existing setup.

The Risk/Reward Math For Your Specific Site

Refresh isn't a universal yes. I walk every client through the same basic framework before recommending it: what's your average session duration, how much of your traffic is on long-form or reference content versus quick-bounce pages, and how much engineering capacity do you have to build and maintain it correctly.

As a rough threshold, I don't recommend refresh at all for sites averaging under 90 seconds per session — the revenue upside is marginal and the compliance risk isn't worth it for a low return. Between 90 seconds and 3 minutes, a single conservative refresh cycle on one or two units, gated by visibility and interaction, tends to be worth testing. Above 4 minutes — think long recipes, forums, in-depth guides, tools with extended dwell time — refresh becomes one of the higher-leverage changes available to you, often outperforming layout tweaks in raw RPM impact.

• Under 90 seconds average session: skip refresh, focus elsewhere on the page
• 90 seconds to 3 minutes: test one gated refresh cycle on a single high-visibility unit
• 3 to 6 minutes: refresh two to three units with staggered, interaction-based triggers
• Above 6 minutes: refresh is likely underused on your site if you haven't implemented it yet
• Any tier: don't ship refresh without viewability gating already in place first

Measuring Whether It Actually Worked

The mistake I see even in well-intentioned rollouts is measuring refresh success by raw impression count instead of revenue per session. Impressions will go up almost by definition — that's the entire point of the feature — so a raw impression lift tells you nothing about whether you made a good decision. What you need is RPM per session and total session revenue, compared against a holdout group that didn't get refresh at all.

Run it as a proper A/B test if your ad server setup allows for it — a percentage of sessions get the refresh logic, a control group doesn't, and you compare over at least two full weeks to smooth out day-of-week variance. Watch fill rate and average CPM on the refreshed impressions specifically, not blended across the whole slot, because a drop in per-impression value can quietly offset the volume gain if the auction thinning effect described earlier is significant on your demand mix.

If you're not sure how to set up that kind of holdout test cleanly, or you want a second set of eyes on an existing refresh implementation before a policy review catches something first, that's exactly the kind of audit worth booking time for — you can reach out directly and I'll walk through your specific setup rather than guessing from general benchmarks.

Frequently Asked Questions