Recently, at AdMonsters’ Sell Side Summit Nashville, during a session about signals led by Scott Messer, Principal and Founder of Messer Media, I shared how we (at Major League Fishing) don’t rely on header bidding to control our refresh. Instead, I came up with a JavaScript snippet that pauses refresh if the ad isn’t in view. It shot our viewability up from 55% to 89%. We then used this increased viewability to help sales show higher value by converting CPMs into viewable CPMs, proving that we were actually the better deal compared to competitors.
Light bulbs went off across the room. Something I thought was common practice turned out to be a thought starter for several publishers. I was even approached afterward and asked if I could publicly release the script.
There’s nothing secret about the script, so here it is:
A Quick Disclaimer
I’m not a developer by trade. I’ve taken some web programming classes, and back in the day I had to convert Flash templates (RIP) into HTML5 + jQuery/JavaScript. I’ll admit I have a top-level understanding of HTML, CSS and JavaScript. I just know what should be possible, and I go from there.
This article will include code snippets, but don’t let that scare you off. The code is to be passed along to your developers, but I’m going to walk you through what it does.
Defining Viewability
When we talk about viewability, there are multiple definitions out there. Instead of chasing all of them, I went with the one that was easiest to measure and code for: 100% of pixels visible on screen.
But the definition isn’t enough; we need a way to put that definition into action.
Now that we’ve defined what counts as in view, we can move toward how to detect it. We need to set up a JavaScript function that checks whether an ad unit is truly on screen.
Think of it like asking, “Is the entire box (top and bottom, left and right) fully inside the edges of the browser window, on screen?” If yes, then it’s considered in view.
Adding a Refresh Flag
Now we have a function that can detect if the ad is on screen. The next step is deciding what to do with that information. That’s where a simple boolean (true or false) flag comes in:
This flag is like a traffic light: green (true) means the ad can refresh. Red (false) means it can’t. We set it to false by default just in case an ad renders outside the viewport on page load. We don’t want those ad units refreshing and tanking our viewability.
Updating the Flag
Now we need a function to update this refresh flag based on whether the ad unit is in view or not. This connects our detection logic to the refresh behavior:
Triggering the Updates
Once the flag can update correctly, we need a way to actually trigger it at the right time. The easiest way is to tie it to scroll events:
In plain English, every time the user scrolls, check if the ad is in view and decide if it can refresh. Simple.
When Users Don’t Scroll
What if someone never scrolls? (Your page is THAT perfect! No scroll necessary!)
If the ad loads in view but the user doesn’t move, the code (as is) never refreshes.
To solve this, we add a one-time check five seconds after page load:
This is our safety net. If an ad is in view from the start, it still gets a chance to refresh.
Putting It All Together
At this point, all the pieces are there. Let’s see the full snippet in action:
*Implementation Note
What I’ve shared here is essentially code in a vacuum. It shows the logic, but it isn’t a turnkey solution. Every publisher’s environment is unique. Ad slots may be defined differently, refresh rules might already exist and integration with header bidding or CMPs can add complexity.
That’s why it’s important to hand this over to your development team to adapt. They’ll need to make sure it works within your site’s ad stack, plays nicely with existing wrappers and doesn’t introduce conflicts. Think of this as the blueprint: The foundation is solid, but it needs tailoring to fit the architecture of each publisher’s setup.
Wrapping Up the Core System
At this point, we’ve built a full refresh system that listens at the right times but only allows refresh when the ad is actually visible. That means you’re no longer wasting impressions on ads no one can see, and you’ve got a lightweight way to boost viewability without bloated scripts or dependencies.
But what if you want to go one step further and improve the user experience? Make sure that refresh never interrupts someone actively engaging with an ad? I just came up with this idea last week, when talking to Adam Sadur, VP of app monetization at Dotdash Meredith.
Bonus: Stopping Refresh During Engagement
Here’s how we keep refresh from being “that annoying ad that reloads just as you click.” We add engagement listeners.
This way, ads pause refresh while someone is hovering (desktop) or pressing (mobile) and resume once they leave or lift their finger. No more ad refresh during engagement.
Wrapping It Up
Here’s what this lightweight in-view refresh system does:
- Runs on scroll and once after load
- Only allows refresh when ads are viewable
- Pauses during engagement
- Gives every ad a fair shot
Don’t leave refresh to chance or to default settings. Take it into your own hands, and you might find the payoff moves you from “developing” to “advanced.”
Try this out on your own site and see how your viewability story changes. And if your sales team suddenly looks like heroes for closing higher CPM deals, do me a favor: Buy your dev a coffee (or three). They’ve earned it.