Viewability Rising: Why we baked Advertising and Analytics into our platform

This post was originally published on this site

It was called “viewability,” and starting in 2015, ads on the web would have to meet this new standard. In order to count as viewable, a least half the ad had to be visible in the reader’s viewport for at least one second. The goal is to ensure ads have a chance to be seen, and can’t linger invisible at the bottom of the page.

It’s a good idea. Before viewability, advertisers would try to reduce unseen ads by asking for placement above the fold. Of course, on the web, there is no fold, and the user always scrolls, so actually being able to determine which ads were visible would let us get credit for ads that are seen lower on the page and let advertisers guard against stuffing unseen units in the footer.

On the other hand, it was a sea change in a complex system that had been built around doing things the old way. We needed to adapt, and the clock was ticking.

The Challenge

I believe ads are one of the hardest problems on the web, in no small part because there’s so many people involved. The ecosystem spans from the publisher front ends into Google’s targeting/delivery system (DFP), to thousands of creative agencies that actually build the ads’ contents, which have to be able to work in any given context, and countless third parties that count the data and ensure the ads are actually being delivered to real readers.

Any change to this system is a major upheaval. So change happens slowly, and with a moderate amount of turbulence.

It’s easy to shrug off ad technology to third party services, and many other publishers historically have, but I don’t think it’s a good idea.

Ultimately, this is our site, and even if we’re using a tool someone else built, we’re still responsible to both our readers and our advertisers. If we’re going to deliver on viewability, user experience, site performance, etc., we have to be hands on.

And to do that, we need to work in facts.

Lazy load all the things

Many publishers were trying to reach high viewability through sticky ads. These work well in some cases, but they’re untenable for mobile, and limit your layout options. They don’t fit in with large photography or full screen interactive graphics, so they can’t be the only answer.

The Atlantic’s platform, Ollie, relies heavily on post-processing. We have 150 years worth of articles, stored as clean, restricted HTML in our database. If we want to add responsive media, or add any other feature that might be implemented differently some day, we write XML transforms that modify the markup when the page renders.

We could use the same technique to inject ads at natural breakpoints in the story automatically, and attempt to lazy load them just before the reader scrolled to that point. We wanted this to be invisible to the user — nothing should jump — and only load ads when they were probably going to be seen.

But how early should that be? Should ads lazy load differently for different placements? What about different types of devices?

To answer this question, we ran a series of A/B tests on our entire ad suite. Some users would see every ad only start to load just before it came into view. Others would preload several screen-lengths ahead.

The data came pouring in, and painted a complex picture. As we expected, if we loaded the ad too early, the reader might never scroll that far down. If we loaded them too late, readers might scroll past the ad before it finished loading.

But there was no magic number. Different placements did better with different settings. Why? I have some guesses, but in the end, it doesn’t really matter — we configured each position to do the best thing for itself.

The strategy worked. We improved our viewability by over 100%, cleared the industry standard, and continued to tweak and optimize over time.

What gets monitored gets managed

It’s not enough to meet goals. We have to continually improve and prevent our gains from slipping. In an ecosystem this complex, small changes can have unexpected side effects.

We needed a way to keep an eye on it.

We used MOAT to measure viewability, which has all sorts of powerful reporting tools, but they took time to analyze, especially if you want an overview of the whole site broken down many different ways. I wanted Ollie to be able to be able to provide a daily, single-glance answer to the question: “is everything okay?”

So we built MOAT integration into Ollie. Every night, it would generate a handful of granular reports from the API, crunch the numbers, and build a dashboard that let us see the state of the world at a glance. How were we doing overall? How did yesterday’s numbers compare to the last 7 days? Were any positions suddenly underperforming? Did our any recent changes move the needle?

Finally, I added a Slackbot to post the summary into where both the product and ad operations teams would see it every morning.


As a result, no change goes unnoticed. The Slackbot tells us what’s up and down compared to the last week. If there’s a sudden downtick, we can dive in early and fix the problem. If we test a potential improvement, we know how effective it is right away.

It’s been so useful (problems that once went undetected for days now get fixed the following morning) that we’re looking for more metrics to approach the same way.

What’s next?

Let’s be honest: this isn’t enough.

Ads are a huge complex ecosystem with lot’s of moving parts. We need Ollie to apply this caliber of management to every single angle.

When we finished viewability we started on speed. It’s amazing what you find when you start paying close attention. Google’s example implementation injected the ad loader in javascript, but by putting it directly on the page with an async attribute, modern browsers have all sorts of clever prefetching strategies that could kick in. Taking advantage of features like that is really easy, and shaved 400ms right off the top.

Next, because this is all about ongoing optimization, we needed to measure it. Today, we record the time it takes for ads to load for every single user, plug the data into Ollie and report the daily summary with a Slackbot.

In it’s first few months of operation, we’ve caught and reverted several changes that were bad for performance, which, in the past, may have dragged on unmeasured and unnoticed.

Going forward, I think we have two challenges:

What can we do not just to stabilize these numbers, but to improve them? What A/B tests can we run? Where are there places to optimize that would make a meaningful difference? And what other parts of the the ad ecosystem can we expand Ollie to oversee?

We’re a small team that tackles big problems and we would love your help. We’re hiring for dev-ops and full-stack developers. You should also follow us on Twitter or shoot us an email.

Viewability Rising: Why we baked Advertising and Analytics into our platform was originally published in Building The Atlantic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Comments are closed.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑