Ad Refresh Strategies That Boost Revenue Without Triggering Policy Violations

A 120-second refresh running behind a ten-minute session turns one impression per slot into five. Auto-refresh multiplies sellable impressions without adding a single visitor, and it is also one of the few levers that ends in a policy notification when the paperwork and the code disagree. Google requires a declaration for every refresh trigger, treats a missing or incorrect declaration as a policy violation, and notifies publishers when it detects one. The strategy that survives enforcement has three parts: a qualifying trigger, an interval buyers will actually pay for, and a declaration that mirrors the page code exactly.

What Google requires, and where

Google publishes its declaration requirements for refreshing inventory under Inventory rules in Ad Manager, in the Publisher declarations section. The requirement follows industry transparency guidelines: buyers must see, before they bid, which portions of inventory refresh and how fast. For each refresh trigger, the publisher specifies the minimum time interval between ad refreshes, and the publisher defines the trigger both in the UI and on the page. Both artifacts must exist, and both must agree. The declarations apply to Open Auctions, Private Auctions, First Look and Open Bidding, so one declaration covers every sale type that moves through Ad Manager.

The enforcement position is explicit. Failing to declare refreshing inventory, or declaring it incorrectly, violates Google policy, and Google notifies publishers of detected violations. When a notification arrives, the fix routes through the same two places: the Publisher declarations UI and the page code. Correct one or both, then verify the two match before the next auction cycle.

The three triggers that qualify

Google recognizes three trigger types, and the common thread matters more than the list itself: the user asks for new content, the page genuinely changes its content, or the clock runs on an honest timer. Anything a publisher wires up purely to mint impressions fails the test.

• User action refreshes. New ads follow user-guided navigation such as infinite scroll or filtering. The user drives the change, so Google applies no minimum interval.
• Event-driven content changes. An event replaces both content and ads together, for example a live blog rolling to its next entry or a feed swapping its card set after a filter change. These triggers carry a 30 second minimum, and Google recommends 60 seconds for mobile apps.
• Time interval refreshes. The page reloads the slot on a fixed clock, such as every 120 seconds. The same 30 second minimum applies, and mobile apps should hold 60 seconds.

The exclusions cause more violations than the inclusions, because most of them look reasonable in a product ticket. General page activity, hovering, scrolling, gameplay clicks, small publisher updates made solely to generate new ads, events that fire under about 120 seconds, and new user comments do not qualify. Hovering and scrolling happen continuously, so a refresh wired to either runs as a near-constant reload loop. Gameplay clicks and comment arrivals hand the publisher new impressions without handing the user new content, which is the exact behavior the policy targets.

Interval arithmetic and the declaration floor

The clock has two floors. Event-triggered and time-based refreshes carry a 30 second minimum, and Google recommends 60 seconds for mobile apps. User action refreshes carry no minimum, because the user sets the pace. Treat the 30 second floor as a compliance line rather than a revenue recommendation: longer refresh intervals generally make inventory more desirable to buyers, and no serious valuation rewards a slot that reloads every 30 seconds.

The declaration needs its own arithmetic, and Google's worked example sets the pattern. When the exact interval is unavailable, declare one step below the actual rate: a slot that refreshes every 220 seconds takes a 180 second declaration, and a 240 second declaration would be a violation. The rule under the example: the declared interval must never exceed what the code actually does. When the interval varies, declare against the fastest cycle the code can produce, and note that a visibility-gated timer can only stretch the wall-clock interval, never shorten it.

Typical auto-refresh implementations reload an ad unit every 60 to 240 seconds, and that range is where testing should happen. CPM falls as the refresh rate rises and impressions climb, so revenue per session decides whether the configuration wins. Measure revenue per session across interval cells, for example 60 seconds against 180 seconds, before committing a template.

The declaration does not refresh anything

This distinction causes the most damage in practice. The declaration labels inventory for buyers; it does not control what the ads do on the page. The actual refresh executes in page code, in GPT through googletag.pubads().refresh(), and Google documents the mechanics in its guide to controlling ad loading in GPT. Two sources of truth therefore exist for every refresh: the UI declaration and the code path, and Google holds the account to both.

The failure modes all share a shape. A template update adds a call to googletag.pubads().refresh() with no slot argument, and the call reloads every defined slot on the page, including the ones nobody can see. An A/B test variant with refresh enabled wins its test and ships to full traffic without a matching declaration. A plugin quietly wires refresh into a sticky rail. The code refreshes, the declaration says nothing, and the account collects a violation. Search for refresh call sites on a schedule, not after the notification arrives.

What refresh does to header bidding

Header bidding decides whether a "new" impression is actually new. Auto-refresh scenarios typically reload an ad unit every 60 to 240 seconds, and Prebid can reconsider cached header bids for those refreshes up to their time-to-live, a mechanic the Prebid FAQ on refresh and caching covers in detail. The consequence follows directly: when the refresh cycle runs shorter than a cached bid's remaining time-to-live, the same creative can serve twice in one slot, and the advertiser burns frequency on a placement the user has already seen.

Three configurations cover the space, and each spends a different resource. Pick based on what the property can afford to lose: latency, price, or engineering time.

• Re-run the auction on each refresh event. A fresh round of header bidding returns new bids and new creatives, at the cost of browser work and added latency on every cycle.
• Reconsider cached bids inside their time-to-live. Cheap and fast, but the creative pool repeats, and repeat creatives erode the price of every cycle after the first.
• Label the cycles. Pass a refresh count or a refresh flag as a key-value, so demand partners can bid the first impression in a slot differently from the fourth or fifth.

The workable combination is the first option plus the third: a fresh auction on each cycle, with a key-value that tells buyers which cycle they are buying. Server-side demand absorbs part of the latency cost, because refresh events can reach additional seats without adding JavaScript to each cycle. At OnlyMedia, we integrate OpenRTB 2.6 seats and Prebid for both header and server-side demand, so one refresh event drives both paths through a single integration.

Designing refresh that buyers pay for

Refresh trades price for volume, and the trade has a shape. Five impressions per slot at a falling average CPM can outrun one impression at full price, but only up to the point where the impression gain stops covering the price decline. Later cycles sell below earlier ones, because buyers value the first view of a slot more than its fourth, so marginal revenue falls with each refresh. Four design rules follow from that curve.

• Refresh only slots in view. An off-screen reload burns an impression nobody sees and drags the slot's measured viewability down with it. Gate the timer on an intersection check so the clock runs while the slot sits on screen.
• Cap the cycles. Two or three refreshes per slot per session protect the price of every impression that came before them.
• Prefer the long end of the range. Longer intervals carry more dwell per impression, so test from the top down: 180 seconds before 60.
• Segment the inventory. Route refresh impressions into labeled deals buyers can price knowingly, and let the key-value separate cycle one from everything after it.

Buyers pay for transparency at every layer of the stack. We are an ad network, an SSP and an agency in one company, so the same refresh inventory reaches us as sellable impressions, as bid stream data, and as line items in advertiser plans, and the pattern repeats at each layer: buyers price what carries a label and discount what does not. Our curated programmatic demand network serves publishers above one million monthly pageviews and pays Net 30, CPM based, no chasing, no sliding terms.

Formats: where refresh belongs

The same trigger and interval rules govern display and video surfaces. Sticky and fixed slots are natural refresh candidates, because they hold position while the page moves. Interstitials between content sections qualify as event-driven content changes when the section swap moves content and ads together. Out-stream players that advance creatives behave like time-based refresh and should carry time-based declarations. App environments should hold the 60 second recommendation.

Our display and video ad formats cover every IAB display size plus in-stream, out-stream, interstitial and CTV video, and the declaration framework covers all of them. Video adds one constraint: fire refresh events at pod or creative boundaries, never mid-creative, because an abandoned impression helps nobody.

Monitoring: catch drift before Google does

Google notifies publishers of detected violations, so internal monitoring exists to find the drift first. Ad requests per pageview carries most of the weight: the ratio holds steady on a stable template and jumps the moment refresh calls enter a page. Our ten-minute reporting console with API access refreshes CPM, fill rate, ad requests, pageviews, revenue, countries, devices and video detail on that ten-minute cycle, so a refresh rollout shows in the ratio within the hour, by template and by geography.

The codebase carries the other half of the signal. Search for googletag.pubads().refresh and for wrapper equivalents every quarter and after every template or plugin change, then diff the call sites against the declarations. We work with thousands of publishers, each above one million monthly pageviews. Keep the declaration update in the same ticket as the code change: the merge that ships the refresh call should ship the declaration too, and a split review is where the gaps open.

If you advise publishers

Agencies and consultants carry a specific exposure: the violation lands on the client, but the configuration came from the advisory. Put refresh declarations into the statement of work for any site migration, template redesign or monetization audit. Demand an interval matrix before launch: every refresh call site, its trigger class, its interval, and the matching declaration. When a client inherits a property, run the code search on day one, because refresh call sites can survive a migration even when the declaration does not.

The refresh audit, in eight steps

Run this sequence before any refresh launch, after any template change, and once a quarter on a live property. It takes one engineer an afternoon, and it closes every gap described above.

1. Search the codebase for googletag.pubads().refresh and every wrapper equivalent, and list each call site.
2. Classify each call site as user action, event-driven content change, or time interval.
3. Confirm that no excluded trigger drives refresh anywhere: hovering, scrolling, gameplay clicks, comment arrivals, publisher updates made solely to generate new ads, or events under about 120 seconds.
4. Set the clock: 30 second minimum for event and time triggers, 60 seconds for mobile apps, and an honest interval inside the 60 to 240 second range for everything else.
5. Write the declaration under Inventory rules with the minimum interval at or below the actual rate, and declare against the fastest cycle when the rate varies: actual 220, declare 180, never 240.
6. Verify that both the UI and the page define the trigger before the code ships.
7. Label the cycles with a key-value and segment refresh impressions into deals buyers can price deliberately.
8. Baseline ad requests per pageview before launch, then watch it in ten-minute reporting through the first full day.

Refresh keeps paying only while buyers trust the label on it. Declare honestly, gate on view, keep the intervals long, audit the code on a schedule, and the extra impressions arrive without the notification. Our publisher monetization program pairs curated demand with the ten-minute console and Net 30 payments, across every display and video surface described above.