Ad Refresh and Lazy Load Policy for GAM and Prebid

Refresh stops paying earlier than most stacks assume. Across the inventory I have measured, on Google Ad Manager with a Prebid wrapper, the second impression in a slot clears at roughly seventy percent of the first and the third near half; past that the added revenue stops covering what it costs you, because buyers holding a seventy percent viewability floor price the domain down rather than the refreshed slot. So this engagement does not answer whether to refresh. It answers which slots refresh, on which event, and where the counter stops. What the policy is built on: Refresh fires on Active View's viewable-impression event, not on a timer that starts at render. The timer pauses when document.visibilityState leaves visible, so a tab left open in the background stops manufacturing impressions nobody saw. Ad Manager's own thirty-second minimum is the floor, not the target; on long-form article slots I usually set it higher, and cap refreshes per slot and per session. Sticky footers, video companions and slots behind an open interstitial are excluded outright. Lazy load, which is the other half: fetchMarginPercent and renderMarginPercent get set per breakpoint, with mobileScaling adjusted rather than left at default, and I will tell you where a tight fetch margin has raised your unfilled rate instead of your revenue. If you run single request architecture, we decide explicitly what it costs to give it up for per-slot auctions. Slot containers get reserved heights before any of this ships, because a lazy-loaded slot that lands late is a layout shift, and the Prebid auction competes with your own scripts for the main thread. I read INP from field data, not from a lab run. What I will not do: Refresh on scroll position alone. Keep a timer running on a hidden tab. Treat a rendered impression as a seen one. Propose more slots as a substitute for fixing the ones you have. I also decline this work where ad operations cannot get template changes merged; a policy nobody can implement is an invoice, not a result. Who this is not for: Sites that buy their traffic, arbitrage inventory, and publishers who have already decided the answer and want a document that agrees with it. If your brief contains a target RPM lift, we are not a fit. I can tell you what a change did; what it will do depends on your demand, your readers and your layout, and I am not going to pretend otherwise in a proposal. How the work runs: Nothing changes in week one. I instrument first: slot-level viewability by refresh index, revenue per session next to revenue per thousand impressions, time-in-view distribution, and the gap between SSP-reported and ad-server-reported impressions on refreshed slots, which is usually where bad refresh shows up before anyone notices it in revenue. Two weeks of that, then a written policy with the specific values, the events they hang off, and the reasoning behind each one. Implementation runs against a staging build with a holdback, so the before-and-after is a comparison rather than a story about seasonality. What you hold at the end is a document your ad operations lead can defend to a buyer, your editors can live with, and your next agency cannot quietly reverse, because every rule states what it protects and what breaks if you loosen it.