Wrapper Wars: Exchanges And Publishers Question Fairness Of Index Exchange’s Wrapper

Six exchanges and a handful of top publishers who work with Index Exchange’s wrapper say they consistently notice anomalies indicating the exchange prioritizes itself.

At least two of those exchanges are composing a letter to Index Exchange CEO Andrew Casale threatening to withdraw from its wrapper unless it takes steps to ensure neutrality, AdExchanger has learned.

Do these exchanges have a valid point, or is this simply a case of competitors piling on one of the top header bidding providers after its credibility was weakened by revelations about its non-transparent bid caching activities?

Index Exchange denied that its auction isn’t fair.

“Our header tag wrapper is 100% totally unbiased, transparent and auditable. By intention, [it] was always designed to be that way,” said Gabe DeWitt, VP of product and technical operations at Index Exchange.

But exchanges disputed that Index Exchange’s wrapper is auditable.

The JavaScript in a wrapper on a publisher’s page is “minified” to load faster, a process which makes it impossible to understand exactly what the code does – the main reason behind the letter being penned by the exchanges. Plus, different versions of its wrapper exist and publishers configure them differently, making it possible for wrappers to vary in neutrality.

The dispute between rival exchanges and Index Exchange unfolds against an increasingly competitive exchange landscape. Google sells the most publisher inventory, leaving the other exchanges to fight over the rest in a zero-sum game, where Index Exchange’s loss is their gain.

“This is the state of a commodity marketplace,” a publisher said. “[Exchanges] do need to find a way to give themselves an edge.”

The infighting among exchanges seems never-ending and harms the interests of the programmatic industry, noted a top DSP executive.

“If you are spending all your free engineering time finding ways to kill each other, you are not spending time finding ways to drive outcomes for our marketers,” the DSP exec noted. “It’s not clear that the wrapper games negatively impact our customers’ marketing. That said, we want a fair and well-lit playing field.”

Mechanics of prioritization

Many seemingly benign changes to a header bidding setup can yield outsize benefits for one exchange over another.

A wrapper sends bid information to other exchanges and then passes that information into Google’s ad server, where the final decision is made about which ad to serve. Subtle nuances in when and how the wrapper relays information can tip the scales.

Does the wrapper call each partner every time and give them all an equal chance to respond? Does it pass through precise pricing information? Do the exchanges get to bid on the same ad units with the same identifiers?

Exchanges working in Index Exchange’s wrapper say the answer to those questions is a resounding no. Consequently, they don’t win as many impressions when they work within its wrapper compared to when they use open-source wrapper alternative Prebid.

One executive from a rival exchange offered the most sanguine explanation of how bias can be introduced. For example, it’s natural that Index Exchange would pay more attention to its own code. By implementing new features, optimizing and debugging for itself first, it can create an edge.

Index Exchange denies that it unintentionally creates bias.

Resource issues play out as well in the support Index Exchange offers other publishers, multiple competitive exchanges said. If their integration with Index Exchange’s wrapper stops working, what may be a drop-everything problem for the exchange isn’t the same priority for Index Exchange.

They complain they often wait inordinately long times for Index to fix critical wrapper issues, hurting their revenue dramatically. Code updates take months, they said. Sometimes, they don’t receive ad calls for every slot on the page.

All these delays in support and configuration cost them revenue.

Earlier this year, Index Exchange changed OpenX’s integration code without notifying the company to win more impressions, according to an OpenX spokesperson.

“We detected our integration code within the Index container had been altered to deactivate our ability to deliver an advertiser’s first-price auction bid,” the spokesperson said. “This artificially inflated Index’s win rate, but more importantly, it delivered less revenue to publishers by not paying them the amount that advertisers were willing to pay.”

The exchange contends that publishers lost millions in incremental revenue because Index Exchange deliberately disabled bid information about OpenX’s auction type for billions of impressions, forcing first-price auction bids to instead compete at second-price auctions.

Although Index Exchange ultimately returned the code to its original configuration, performance suffered for months as the company tried to figure out what was preventing advertisers and publishers from competing fairly in the Index wrapper.

“These kinds of practices not only hurt publishers and brands, they ultimately damage the overall trust in programmatic advertising. As an industry we need to prioritize trust, transparency and integrity, and these kinds of practices need to end,” the OpenX spokesperson said.

News of this code change has traveled around the industry, and a number of people brought it up to AdExchanger. But Index Exchange said it couldn’t recall encountering an issue around how it passed bid information. “It doesn’t ring a bell,” DeWitt said. “I can say that partners manage their own code.”

In a third example, multiple exchanges contend that Index Exchange advantages itself by calling itself first, giving it precious milliseconds to return a bid request. Or that it calls itself for the first few pages in a user session, when bids are highest.

Index said that it calls partners randomly. But has that always been the case? “I couldn’t say offhand,” DeWitt said.

Index Exchange’s wrapper also controls timeouts in its wrapper. Some exchanges that are called later in the bid process are shut out of the auction because they can’t return a bid in time, exchanges charged. They can infer this information when they inspect code on a single page load, and consistently see the same pattern.

Another source of bias cited by multiple sources involves how the wrapper passes all of the bid information into Google’s ad server via line items, which helps determine which ad to serve.

Index Exchange’s control of the wrapper allows it to recommend how those line items are configured and prioritized. Some publishers create their own line items when they use Index’s wrapper, but not everyone.

For example, if the Index Exchange wrapper passes bids through in penny price increments, but other exchanges’ information has larger price bands, that decision would hurt other exchanges.

The Google ad server rounds down based on that increment when it picks the highest bid. A larger increment means it’s rounding down more.

If Index sends a $1.36 CPM and a competitive exchange sends a $1.39 CPM, the competitive exchange should win. But if the price increments are set more widely for the competitive exchange (let’s say in five-cent increments), its bid would be rounded down to $1.35, making it lose the auction.

Index Exchange said that its wrapper operates fairly every step of the way, and its documentation indeed suggests a setup where everyone gets the same number of line items. “It’s not true that we create bias in line items,” DeWitt said.

Also at stake: how a wrapper communicates identity information.

“The Index wrapper fetches user IDs, such as consortium or buyer user identifiers, ahead of the auction and only passes those identifiers to their own header bidder. This results in an auction highly favoring Index bids,” said Nishant Khatri, VP of product management at PubMatic.

“That’s incorrect,” DeWitt said, adding that Index Exchange’s ID is provided to all the bidders in the wrapper.

It may have already acted to fix this issue: It sent an email to partners announcing it would support use of IDs the same day AdExchanger spoke to Index Exchange.

Rival exchanges also claim Index Exchange’s wrapper calls itself every time, but not everyone else, reducing competition. Exchanges can observe this behavior by talking to a publisher and figuring out they’re only bidding on a subset of impressions.

DeWitt denied this was true: “Our wrapper doesn’t work that way,” he said.

Which wrapper?

Because wrappers include many configuration issues that can create bias and affect performance, Rubicon Project CTO Tom Kershaw wants to see the industry rally around open-source solution Prebid.

“We have seen poorer performance on proprietary wrappers compared to Prebid,” Kershaw said. “The purpose of the wrapper is to create a level playing field so publishers can call as many demand sources as possible. You want a situation where the wrapper is neutral, fair and calling as much demand as possible.”

Some publishers told AdExchanger they chose Prebid over Index Exchange’s solution because, as an open-source solution, it’s more neutral than a proprietary solution.

Other publishers didn’t care if Index Exchange’s wrapper partner creates an edge. If they made more money and buyers weren’t impacted, great.

“I automatically assumed bias. And we are OK with it, because they are our partner working to do the best for us,” one publisher using Index Exchange’s wrapper said, noting that it tests constantly to confirm Index Exchange’s value and to hold it accountable.

But in an industry obsessed with transparency, a proprietary header bidding wrapper is decidedly not transparent. Two other top publishers familiar with Index Exchange’s wrapper disagreed with the premise that inequality should be accepted, and didn’t use Index’s wrapper for that reason.

“This kind of bad behavior by exchanges is what makes [P&G Chief Brand Officer] Marc Pritchard say you have to do X, Y and Z before we buy you so we can protect our brands,” one publisher said. “We wind up having to defend programmatic as a whole because of the actions of an exchange. It hurts the entire ecosystem.”

The backstory (and next chapter) of the wrapper wars

Header bidding was designed to get around an advantage that Google had created between its exchange and ad server. But as Index Exchange’s proprietary wrapper takes hold, many feel the same dynamics have been recreated.

Header bidding wrappers cropped up in 2016, about a year after header bidding picked up speed. They were designed to help publishers manage multiple header bidding partners.

Sensing that a wrapper would be a sticky technology and difficult for publishers to switch, every major exchange clamored to build a proprietary wrapper. Besides Index Exchange, Rubicon Project, OpenX, PubMatic, Technorati, Sonobi and Yieldbot were building or had already released header bidding wrappers by early 2016.

Some wrappers were dead in the water because they openly favored themselves or were latecomers to the market.

Only Index Exchange’s wrapper gained wide adoption. It had moved quickly to build its free tech and attracted top publishers. Rival exchanges begrudgingly worked within its wrapper because they needed access to those publishers’ supply.

Taking the opposite tack, AppNexus engineers built Prebid.js and made it open-source. Its customizability made it a top pick among sophisticated publishers, and its neutrality won over exchanges and publishers alike. Last November, AppNexus, Rubicon Project and PubMatic joined together to launch Prebid.org – where partners must follow a code of conduct around auction logic, data, transparency and user experience.

But as programmatic starts to grow up and close loopholes in its architecture through projects like ads.txt, the behavior of the exchanges themselves remains clear as mud.

“I am mistrustful of everyone at this point,” a publisher said. “Everyone has done something objectionable. When is this going to stop?”

 

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>