The Pandora’s Box of Cache-Gate
A few weeks ago, we discussed bid caching — the potentially fraudulent practice that Index Exchange practiced. This was discussed extensively, both here and throughout industry publications. Yet it also begs a few additional questions around header bidding and transparency that are worth exploring. We discuss these below.

Prebid is an open source solution and it is clear upon inspection of the code and the way that it is necessarily implement (at least on the client side) that every header bidder is treated equally. Index, however, does not make its code available for inspection. While it is generally loaded on the client side — meaning it is interpreted by the browser and thus can be evaluated by people to see if it’s fair — it’s obfuscated (there are special tools that take javascript code and make it do the same thing but in a fashion that is particularly hard to understand). So unless an individual spends a particularly significant amount of effort, it’s very difficult to know what exactly Index’s wrapper is doing. That said, given bid caching, it is likely that rival exchanges may undertake this very effort.
TripleLift has historically shown a lower win rate on the publishers using wrappers controlled by exchanges than on publishers using Prebid, despite no other significant differences in these publishers. Thus, while purely speculative, it is reasonable to suspect that there are other similar activities, especially considering the incentives of an exchange-and-wrapper owner. Some thoughts on potential other activities include (to be clear, this is simply thoughts on what else could be happening, not that it necessarily is):
Earlier auction triggers: the expectation of a header bidding wrapper is that it treats all bidders identically. An important element in header bidding is the timeout, meaning there’s only so much time that an exchange has to respond to the browser and if it’s too late, even if it had the highest bid, it won’t count. In Prebid, the client-side code is delivered by a content delivery network to the browser and then the browser calls each exchange in a random order. The exchanges then have up until the timeout to respond. In obscured code, it is possible that the browser makes a call to the content delivery network which may, at that time, trigger an auction in the header wrapper’s own exchange. The code would then be returned to the browser and the browser would call all the other exchanges — but only with a delay relative to that initial call. Thus header-wrapper-plus-exchange in this example would timeout far less than other exchanges. Further, if they work with the publisher to set timeouts that are lower than average, their auction will be given a further boost by, in a sense, artificially timing out competitors.
Reserves: Every time an exchange wins in a header, there is a margin above the second-highest exchange. The difference technically belongs to the publisher and could be considered the incremental yield of the winning exchange for that impression. Another option if you own the header wrapper and are an exchange looking to maximize your win rate would be to reduce the amount you pay the publisher to just slightly over the the second-place impression, but bill the winning DSP the full amount. The “savings” would be added to a reserve and could then be applied against future impressions where, as a bidder, it came below another exchange — but could be counted as a win by simply reducing applying some of the reserve to its bid to a level sufficient to beat the otherwise-winning exchange. In the aggregate, the publisher’s yield would be lower with this strategy but the header-wrapper-exchange’s win rate and total margin for itself would be higher.
Variable margins: Controlling the wrapper gives a fair amount of flexibility to change your margin to maximize your win rate. After all, winning at 10% margin is more money to the exchange than losing at 20% margin. Header bidders typically submit their net amount, meaning the DSP bid minus the exchange’s margin. If you control the wrapper, you can submit your gross bid and your maximum contractual margin for the publisher and then take the highest margin that would have you win against all the other net bids. This is even more likely in a server-side wrapper setup.
DFP setup: Publishers will setup price buckets in DFP to prioritize higher bids. It is rare that they will have a price bucket for every single penny, and instead it might be at ten cent or similar increments. If you control the wrapper and work closely with the publisher, you may setup separate price buckets for yourself with more granularity, or simply with different intervals. Knowing the different intervals for your own exchange as compared to everyone else, it’s possible to value a lower-valued impression as higher than a competitor’s. If this is implemented in the wrapper, especially in conjunction with the gross model discussed above, it’s possible to artificially increase win rates while perhaps lowering aggregate payments to publishers. As a simple example, if hypothetical wrapper-and-exchange has price buckets at $1.00, $1.04, and $1.08; whereas other exchanges have price buckets at $1.00 and $1.10 then another exchange’s bid of $1.09 would reduce to the $1.00 price bucket, while the bid at $1.05 would reduce to $1.04 for the wrapper-exchange — knowing this, the wrapper could say “I know the publisher would record more money in DFP at $1.04, so I’ll use that bid” even though it’s not in that publisher’s overall interest.
Biases: The simplest, least impressive, and potentially least legal gimmick would be to just bias competitors down. It could be either periodically and randomly just making other exchanges lose, counting some fake fee against their bids, or similar.
Above are a number of potential header auction manipulations that are possible when the wrapper code isn’t open source and is run by an entity that also has a horse in the game (and also a history of shenanigans). This is far from exhaustive. It’s not clear that any of these are actually happening — but it’s also not clear that they’re not. Publishers may see a positive result by A-B testing their yield between different wrapper solutions and seeing which results in a higher aggregate yield (and doing so continuously). None of the auction manipulations listed above are will increase a publisher’s overall yield — but instead will simply increase one partner’s share of voice at the expense of the publisher’s yield. Instead, open source code that treats all partners equally is by far the most effective at maximizing overall yield though it may lag on certain features that may, for a short period of time, provide incremental yield.
