Forced Redirect Ads Cost Publishers Money, But So Does Blocking Them

The current crop of forced mobile redirect ads tell users they’ve just won a $1,000 Amazon gift card or an Apple iPhoneX.

People in ad tech have come to view them in the same way they see blizzards: They’re a hassle and unavoidable in certain climates, including programmatic advertising.

“This comes up every year – and this is the worst case [we’ve seen in] the past several years,” said Dave Pond, GM of display and programmatic at Vox Media, whose readers were hit by the forced redirect ads in late Q4.

With every iteration, the creators of forced redirect ads hatch new ways to outsmart exchanges and publishers screening for them. The current bad batch of redirects, for example, outfoxes scanners by taking advantage of subtle indicators that users are seeing the ad.

“The ads look exactly at how an iPhone renders JavaScript, and then will check to see if the phone is moving in your hand a tiny bit. Then, they will redirect the page,” said Jerome Dangu, co-founder and CTO at Confiant, which blocks forced redirect ads for publishers and exchanges.

In general, mobile forced redirect ads trigger under specific conditions, such as the wireless carrier, location and time of day, allowing them to wriggle through audits undetected.

The forced redirect ads occur at low enough rates that they’re often seen as a nuisance, not a priority to fix.

Malware accounts for .5% of all ads served, but can vary by a factor of five during an outbreak of forced redirect ads, according Louis-David Mangin, CEO at Confiant, which examines 15 billion programmatic impressions per month.

Although these forced redirect ads prompt users to install ad blockers and publishers to lose revenue, the fixes available are often more painful, leading to low adoption.

In short, the bad ads cost money. But so does blocking them.

However, as technical solutions get better – and publishers decide revenue trade-offs justify it – adoption of techniques that block forced redirect ads may pick up speed in 2018.

The double-edged sword of SafeFrames and sandboxing

Publishers and ad tech vendors can restrict how ad creative behaves via sandboxing or SafeFrames, an IAB-developed form of sandboxing that sets rules for an ad’s behavior.

Sandboxing “puts ads inside a protective container so they can’t misbehave on a publisher page,” explained Gabriel DeWitt, VP of product and tech ops at Index Exchange.

The technology operates on a continuum. Depending on how the code is written, sandboxing can restrict an ad’s behavior a lot or just a little.

The IAB’s SafeFrame technology isn’t restrictive enough to address the current crop of redirect ads – though the IAB Tech Lab expects its next version will.

“SafeFrames cannot currently solve this problem, but sandboxing via an iframe can,” said Dennis Buchheim, SVP and GM of the IAB Tech Lab.

The IAB Tech Lab still recommends that publishers use SafeFrames. They are “the best scalable solution available to be used by both the sell side and buy side,” Buchheim said.

But few publishers have adopted SafeFrames because sandboxing causes problems for legitimate advertisers. Sandboxing can also restrict third-party vendors – such as those measuring viewability or brand safety – from seeing what’s happening on the page.

SafeFrames render ad creative more slowly, leading to discrepancies, DeWitt noted. Plus, they simply don’t work with old browsers.

Since all of these restrictions reduce publisher revenue, Vox Media and other publishers are looking for middle ground. To stop the forced redirect ads, Vox developed custom sandboxing code, which it may share with other publishers.

It wants to use sandboxing during outbreaks of forced redirect ads and turn it off to give advertisers the best experience when ad quality improves.

“SafeFrames don’t solve for the monetization issues and data and information fidelity issues we have seen,” Vox Media’s Pond said. “We can use SafeFrames all day long, but the buy-side platforms rely on information that doesn’t work in that framework, so it’s not the silver bullet.”

CafeMedia enables SafeFrames for most of its ad creative, but getting more advanced creative to function requires extra work. Although “they aren’t a panacea,” EVP Paul Bannister said, the protections offered by SafeFrames are worth it.

“[Not having SafeFrames] ultimately costs more time and revenue,” Bannister said. “A publisher without SafeFrames has to deal with more mobile redirects and other malicious ad issues.”

The header bidding twist

One benefit of SafeFrames is that they “allow the publisher to be in control of ad safety,” the IAB Tech Lab’s Buchheim noted.

But that hasn’t always been true. When publishers use header bidding, they rely on tech partners to support sandboxing because header bidding takes place outside of the ad server.

Because of the extra legwork required for SafeFrames and sandboxing and the problems with third-party trackers, creative rendering and discrepancies, some ad tech partners pressure publishers to turn them off.

But turning off SafeFrames is often unnecessary, CafeMedia’s Bannister noted, because workarounds exist. “We’re making SafeFrames a requirement for any new partners we bring on board as we feel that they should be able to make things work with the technology.”

The leading open-source wrapper, Prebid, and the leading managed wrapper, from Index Exchange, added support for SafeFrames in product updates last year. Both noted adoption remains low.

“Publishers have reported that sandbox mode can prevent legitimate creatives from loading, as well as third-party verification tools,” said Michael Richardson, chairman of and a product line manager at AppNexus. “Consequently, we have seen publishers continue to seek alternative solutions to sandboxing.”

The Index Exchange header-bidding wrapper added full support for SafeFrames during Q3 and Q4 of 2017. DeWitt expects publishers to try the tech and test how it affects revenue.

“Publishers have not strongly advocated for this, and what we build is in direct response to our customers,” he said. But the exchange does want to offer publishers using its wrapper an extra layer of protection, so it’s exploring creating its own custom security sandbox for ad rendering.

The Google approach

Technologies like SafeFrames are generally implemented on a publisher-by-publisher basis. But Google AdX requires publishers to turn on SafeFrames to access its demand – making security the default setting.

For both Google AdX and exchange bidding, Google’s ad server, DFP, will automatically add in SafeFrames and additional sandboxing wherever it can. Publishers can only turn off the safety mechanisms for direct-sold campaigns.

“Safety is an important part of building a sustainable business,” said Sam Cox, group product manager for AdX policy.

Having those mechanisms in place meant AdX was unaffected by the current outbreak of “$1,000 gift card” ads, he said.

Google is tackling this issue at the browser level, too (unrelated to its Chrome ad filtering project with the Coalition for Better Ads). The next version of Chrome, 65, will block auto redirects, and some of the functionality exists in the Chrome release from late January.

Having extra security around programmatic demand is necessary to tackle the forced redirect issue, Cox said.

“Turning off SafeFrames for demand coming through headers opens up access to bad [ads],” he said. “We are finding that publishers have been treating header partners like extremely trusted agency and brand relationships versus an indirect relationship.”

Outside protection

Besides adding SafeFrames or sandboxing and requiring exchange partners to support the technology, some publishers pay for additional safety tools from the likes of Media Trust, GeoEdge, RiskIQ and Confiant, which detect bad ads, including forced redirects.

Many of these technologies work by scanning a sample of ads. Confiant takes a more extreme approach by examining every ad, which allows it to detect hypertargeted forced redirect ads.

The protection comes at a cost: 50 milliseconds in latency to individually scan ads, and lost revenue from the 2.7% of ads that offend with malware, forced redirects, cookie stuffing or in-banner video.

To minimize the financial impact on publishers, Confiant plans to add pass-back technology to give publishers another shot at filling the ad slot.

Since CafeMedia, which uses Confiant, wasn’t affected by the outbreak of “$1,000 gift card” ads, it didn’t have to manually turn off partners to diagnose the issue during a high-revenue Q4, where every dollar counts.

Index Exchange helped publishers track down the forced redirect ads during a spike in late Q4. (None were traced to Index Exchange, DeWitt noted.) But diagnosing the forced redirect ads meant facing even worse revenue pain.

“Publishers focused on making their revenue numbers in the best quarter were faced with having to turn off partners, and that was a difficult decision for some of them,” DeWitt said.

That has led to renewed interest in ad quality in Q1, DeWitt said. “Publishers don’t want to go through that next Q4.”

Even at .5%, malware is starting to cause an outsized amount of pain, Mangin said.

“We as an industry have to focus on what hurts immediately,” he said. “But we have disregarded this issue for so long it’s gotten to the point that it’s really painful.”

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!


  1. Why not just publicly name name whomever is responsible for running & creating these ads?

    Only the publishers and ad-tech intermediaries seem to get identified, but those truly responsible remain anonymous and never face real consequences.

    There is always a money trail. It should be followed, and whatever’s at the end shouldn’t be a mystery.

    If publicly naming these actors isn’t feasible, then the IAB should maintain a public list of fully vetted companies that do not create/distribute malware.