Ad Refresh and Lazy Load Policy, Tested on Session RPM

Refresh raises impressions and lowers price. The only question worth asking is what it does to revenue per session, and the answer is placement-specific: on long-dwell article pages a 30-second viewability-gated refresh capped at three per slot has added 8 to 22 percent to session RPM in our tests, and the same rule applied to listing and category pages, where median dwell is under 25 seconds, lost money. Anyone quoting a single refresh interval for a whole site has not measured one. The measurement comes first: Before a line of configuration changes, we read dwell time by template from GA4 and viewability by slot from Ad Manager, and sort your pages into templates that behave differently. Policy is written per template, never per site. The test is a 50/50 split by user bucket held for a minimum of 30 days, reading revenue per thousand sessions, Active View rate, fill, and p75 INP and CLS from field data rather than a lab run on a fast laptop. We publish the losing arms as well as the winning ones. The refresh rules we hold to: A slot refreshes only after Active View has counted it, which is 50 percent of pixels for one continuous second on display, and only while the tab has focus, checked through the Page Visibility API rather than a naive timer that bills a buyer for an impression in a backgrounded tab. A per-slot cap, a per-session cap, and a dwell floor beneath which a template does not refresh at all. Every refreshed request carries a key-value into Ad Manager and into the Prebid bid request so buyers can price it down or exclude it. They find out either way, and the ones who find out on their own reprice all of your supply, not just the refreshed part. AdSense units are not refreshed. Google's policy tolerates disclosed refresh on Ad Manager demand and does not tolerate it on AdSense tags, and every suspended account we have been called in to look at was refreshing AdSense. Lazy load: GPT lazy loading with fetchMarginPercent and renderMarginPercent tuned separately, because fetching too late costs fill while rendering too early costs only viewability. Slot heights reserved in CSS so the reflow never lands in CLS. On mid-range Android over mobile networks outside the big Brazilian capitals, the margins that work are wider than the defaults every tutorial repeats, and we set them from your own connection and device mix in CrUX rather than from the tutorial. Where we stop: We will not implement a refresh that fires on blur, on scroll-past, or on any signal that does not imply a human currently looking at the slot. We will not hide the refresh flag from your demand partners. And we pull any change that moves p75 INP past 200 milliseconds or CLS past 0.1 in field data, whatever it did to RPM. That is a commitment written into the engagement rather than a preference, and it is why this work sometimes ends with us recommending fewer slots instead of more refreshes. Not included: Building the stack, choosing demand partners, direct sales pricing, adblock recovery. Video player configuration is out of scope entirely; player-level refresh has its own rules and we do not write them. Not for you if: Your median session is a single pageview from search under 20 seconds, where the honest recommendation is placement and page speed work rather than refresh, and we will say so in week one rather than ship something that pays for the engagement. Or if you want refresh live this week without a holdout. Shipping it takes an afternoon. Knowing whether it worked takes a month, and only the second one is the service.