Ad Refresh Impact Estimator

What Ad Refresh Is (and What It Isn’t)

Ad refresh is the idea of requesting a new ad creative for an existing placement after a trigger. Instead of loading one impression per slot per page view, a refreshed slot can potentially load additional impressions while the user remains on the page. In practice, refresh is not a single feature you “turn on.” It is a behavior that depends on the ad stack you run, the inventory you sell, the buyer expectations you must satisfy, and the policies you must follow.

The important distinction is that refresh is an optimization tactic, not a revenue hack. If refreshed impressions are not viewable, not high quality, or not policy-compliant, the “extra inventory” can do more harm than good. Buyers may bid lower, viewability may fall, user experience can degrade, and invalid activity risk can increase if impressions are artificially inflated. A good refresh strategy is measured and selective.

Why Publishers Consider Refresh

On long sessions—especially on guides, tutorials, tools, and interactive pages—users may stay long enough that a single ad request per slot leaves money on the table. Refresh aims to match ad opportunities to real attention time. The most sustainable refresh strategies generally share a few traits:

• They refresh only eligible units: usually a subset of in-content placements, not every unit.
• They use viewability as a trigger: refreshing only when the unit has been seen.
• They apply caps: limiting refreshes per slot per page view to keep behavior predictable.
• They protect the first screen: avoiding aggressive refresh near the top of the page.

AdSense vs Ad Manager vs Other Stacks

The first question is not “what interval should I choose,” but “what am I allowed to do.” Different stacks have different requirements. For example, AdSense policies generally do not allow auto-refreshing an element without a user-initiated refresh, which means time-based refreshing of AdSense ad units is typically not appropriate. :contentReference[oaicite:1]{index=1}

In other environments—such as Google Ad Manager configurations in specific contexts—refresh controls may exist and may allow setting a refresh rate within a defined range (for example, 30–120 seconds in certain app settings). :contentReference[oaicite:2]{index=2} If you use header bidding or another stack, you may also need to disclose or signal refreshed inventory so buyers know what they’re purchasing. :contentReference[oaicite:3]{index=3}

This is why the estimator includes an “Ad Stack / Network Type” input and provides a policy/risk flag. The tool itself does not implement refresh; it helps you estimate outcomes so you can plan experiments within your allowed framework.

Time-Based vs Viewable-Time Refresh

A time-based refresh triggers after a set number of seconds, whether or not the ad is in view. It’s simple to implement in some stacks, but it’s also the easiest way to create low-quality inventory: refreshed impressions can happen when the user has scrolled past the slot or switched tabs. Viewable-time refresh, in contrast, counts time only when the slot is actually viewable. That tends to align better with buyer value and viewability.

If you want refresh to be sustainable, viewability-based triggers are usually the safer starting point. They can reduce “wasted” refreshed impressions and help keep viewability metrics healthier as you test.

How This Estimator Calculates Refreshes

The estimator models refresh opportunities per slot as a function of session time (or viewable time) minus an initial delay, divided by the refresh interval, then capped by your max refresh cap:

Refreshes per slot ≈ min( cap, floor( max(0, time − delay) / interval ) )

If you choose “Time-based,” the model uses average session duration as the “time” input. If you choose “Viewable-time,” the model uses your average viewable time per eligible slot. This difference matters. Many pages have long sessions but short viewable exposure per individual unit because users scroll past quickly. Viewable-time triggers recognize that reality.

Impressions: Baseline vs Refresh

Baseline impressions are estimated as:

Baseline impressions ≈ pageviews × total slots × fill rate

Refresh impressions add incremental impressions only from the eligible slots:

Refresh impressions ≈ baseline impressions + (pageviews × eligible slots × refreshes per slot × fill rate)

In real systems, refresh may change fill rate, change auction dynamics, and change viewability. This model keeps the arithmetic transparent so you can see which assumption drives the outcome. That transparency is valuable because it helps you design tests that measure the uncertain parts.

Revenue Modeling and Why CPM Might Change

If CPM stayed constant, more impressions would generally mean more revenue. But CPM often changes with refresh. If refreshed impressions are less viewable, buyers may bid less. If inventory becomes harder to evaluate, demand can soften. If users become annoyed and spend less time on the page, the lift can evaporate. For that reason, the estimator includes an optional CPM “risk penalty” that reduces modeled eCPM when refresh becomes more aggressive.

The penalty is not a rule; it’s a planning tool. You can toggle it off for a best-case scenario, but for realistic planning, it’s safer to assume some CPM pressure at shorter intervals or with time-based triggers.

Viewability Standards and Why They Matter

Refresh strategy is linked to viewability because viewability is how buyers evaluate whether they received real attention. Industry standards commonly describe display viewability as at least 50% of pixels in view for at least 1 second (and for video, longer). :contentReference[oaicite:4]{index=4} When refreshed impressions are not viewable, you may generate inventory that is hard to monetize sustainably. This is why viewable-time triggers often outperform pure timers in the long run.

Choosing a Starting Interval

Instead of searching for a perfect number, choose a conservative baseline that fits your content type. Long guides and tools may support a different cadence than short posts. In some stacks, refresh controls may have minimums or recommended defaults (often discussed around 30–60 seconds and above, depending on context), but the more important principle is alignment with attention. :contentReference[oaicite:5]{index=5}

A reasonable testing path is:

• Start with viewable-time refresh on a subset of in-content units.
• Use a meaningful delay (so the first view is stable).
• Cap refreshes (so long sessions don’t spiral into excessive inventory).
• Measure changes in viewability, engagement, and revenue together.

What to Measure in a Refresh Test

Refresh is one of those optimizations where revenue alone can mislead you. You should watch:

• Viewability rate: does it drop after refresh is enabled?
• Session quality: time on page and scroll depth.
• RPM (or page revenue): not just raw impressions.
• CPM trends: are bids softening over time?
• Traffic quality signals: protect against invalid activity risk.

Google’s traffic-quality guidance emphasizes avoiding artificial inflation of impressions/clicks and keeping traffic legitimate. :contentReference[oaicite:6]{index=6} Refresh should be an attention-aligned tactic, not an inflation tactic.

Using This Tool as a Planning Document

The estimator is most useful when you treat it like a planning worksheet:

1. Model baseline with refresh off.
2. Create 2–4 scenarios: conservative, balanced, and aggressive.
3. Export scenarios and annotate which pages/templates will be tested.
4. Run a controlled test and compare measured results to modeled assumptions.

When your measured results differ, that’s not failure—it’s learning. The gap tells you which assumptions were wrong: viewable time, CPM stability, fill rate changes, or user behavior.

Common Pitfalls

Most refresh failures come from predictable mistakes:

• Refreshing too many units: a few eligible slots often outperform refreshing everything.
• Refreshing on a timer only: without viewability checks, you may create low-quality inventory.
• No caps: long sessions can explode inventory and harm buyer trust.
• Ignoring mobile UX: mobile interruptions are felt more strongly.
• Not validating policy: some networks prohibit auto-refresh without user action.