Our impressions of the IAB OpenRTB 2.4

The IAB’s Advertising Technology Council has recently upgraded the Open RTB guidelines to version 2.4.

The IAB’s Advertising Technology Council has recently upgraded the Open RTB guidelines to version 2.4. This latest version of the standard used between SSP/Exchanges and DSPs is out for public review so we will be highlighting some of the positive updates as well as recommending areas we expect to see improve in version 2.5.

1.    Impression expiry

Open RTB 2.4 goes some way to improving fraudulent impressions caused by Xindi style bot networks which have caused the industry huge losses. Last year Pixelate identified how these bots work by subverting frequency caps targeting a highly desired user base. The botnet works when malware infected machines make massive amounts of ad requests within a short space of time, holding on to them without showing them. Those requests are stored over the course of a few hours or even a day, then impression trackers call them simultaneously. This causes them all to fire at the same time, evading fraud filters and making huge amounts of money on false impressions.

Xindi is sophisticated in the way it targets corporate environments or even universities allowing it to generate fake viewable impressions from recognised IP addresses that attract high CPMs, at scale. The below diagram taken from Pixalate shows how this process works.

One of the updates in the OpenRTB 2.4 involves expiring the impression tracker which in-turn will stop the botnet being rewarded. The table below shows new guidelines of impression expiry times related to video ad impressions, guidelines we will be implementing as part of our video ad tech platform and third generation exchange.

“The following expiration times are offered as examples of reasonable delays based on the nature of the impression. These are only provided as rules of thumb. A more data-driven method of determining these times in specific situations is highly recommended. “ (IAB)

For display or video ad formats:

Desktop and mobile web browsers: 1 Minute
Mobile app banner or native ads that may be cached: 5 Minutes
Mobile and video interstitials: 30 Minutes (or even longer)
Audio or video with server-side stitching: Very Long or Unknown

2.      SSL support – encoding

In version 2.3 SSL was not recommended “due to the additional processing overhead.” The fact is hardware has gotten so cheap that this argument hasn’t been valid for a long time, so from our perspective it’s great to see it finally recommended.

Legacy exchanges and DSPs may drag their feet when it comes to securing web traffic but it’s worth the industry as a whole embracing this and we’re certainly ensuring our own processes incorporate stringent security. Historically speaking and reflected in current practices, we see an ad tech ecosystem that’s essentially self-policed, especially in terms of DSPs not making targeting segments from bid requests etc. ‘Bad actors’ from outside the industry are not bound by that, and can get a view on the browsing history or millions of people if they hack the bid request stream (think Snowden). Securing web traffic is the zeitgeist as anyone working in tech knows and we’re very happy to finally see an expectation of encryption across OpenRTB. Securing web traffic guarantees the connection and what comes through making the entire process much more secure and transparent. In our opinion this one is a no brainer!

3.    Video skip ability support

OpenRTB 2.4 allows publishers to declare if they want to impose a skip button on the ad, something that until now they’ve had very little control over. However, there is not yet a clear definition as to who is responsible for creating it – the publisher in their player? Or advertiser in VPAID? The advice at this stage is for the DSP to consult the publisher, so whilst this is a good addition it would benefit from further clarification.

4.    Location support

Accurate location data is a big demand of advertisers, especially in mobile. The problem is, not much of mobile location data that’s offered is actually valid. Putting aside the fraud for a second, the problem here has been the advertiser inferring absolute accuracy because it has been given a lat/lng. The device may know it’s only accurate to 10 or even 500 meters but the exchange it made the ad request to, couldn’t pass that on to its bidders. This has all changed with the latest update. The exchange can now pass on this location information with the “accuracy” value set in meters, along with a “lastfix” value to say how long ago that fixed.

Where location is looked up via IP address, exchanges can now declare the vendor they used as ip2location, Neustar, or Maxmind. Sorry DigitalElement, looks like you’re not on the list?! Perhaps that’s one for the IAB to address once public comments have been considered.

5.    Audio object

The addition of the audio object enables live audio streams such as podcasts or services such as Spotify or potentially SoundCloud to request ads from bidders with the OpenRTB standard. This update assumes DAAST standard compliance, with companion banners as an option just like video. The audio object/ad can be stitched into the playback, and even downloaded by the user.

Look for more legacy ad exchanges to jump on this as a new way to differentiate themselves.

Others worth a mention

Other updates include the ability to format the size of banner ads, additional creative attributes for Adobe Flash and the guidelines detailing best practices for DSPs responding with deal ID. They are all valid updates but don’t add a huge amount to the innovation of the space.

Here’s some of the updates we feel could have been implemented in 2.4 that we expect to see in 2.5, hopefully sooner rather than later.

As a market leading third generation video ad exchange and ad platform, we operate with multiple DSP’s, we also push demand through our SSP as well as other supply partners so it’s very important to us to constantly update and upgrade our proprietary technology. Our We’ve made a very conscious choice to ensure we operate and implement above and beyond the industry standard – if we can do something better now –we do it, we’re not waiting to be told, and we don’t believe the guidelines should wait either.

What Coull expect in 2.5

HTTP2 and Advertising

The current OpenRTB spec does not take HTTP2 into account, it assumes HTTP1 as the standard. We believe there are a few parts of the new HTTP2 spec that are exciting from an advertising point of view.

Currently HTTP1 only allows for a single conversation to go on between 2 computers, so if there are to be more conversations then more connections are needed. HTTP2 allows a single connection to have multiple conversations go on with no specific order in them.

HTTP2 is also a binary protocol, meaning it’s more aligned to how a computer speaks than a human. It’s evident that the overall efficiency of a connection and the data sent over it is far better. This is obviously quite relevant in exchange to DSP connections.

Security in HTTP2 was also thought about from the beginning with the downsides of secure connections in HTTP1 considered. Secure connections in HTTP2 can easily send both secure headers and body while being compressed effectively saving bandwidth.

Another subtle change that has an advantage in exchange to DSP connections is the ability to cancel a request without dropping a connection. In theory this saves computation power should an exchange make a decision – maybe securing a PMP deal before a DSP has decided on a bid.

These all add up to some good increases in efficiency of connections, both in between clients and ad servers as well as exchanges and DSPs, though obviously both parties in all examples need to be able to handle the HTTP2 connections.

Our third generation exchange has already implemented some of these changes and are well underway to go even further. Our feeling is the industry as a whole should be guided in this direction because these improvements make programmatic advertising safer, more reliable and more efficient for everyone.

Loss Notification

To ensure the most efficient means of bidding and yield optimization we have loss notification built in to our exchange. It’s something that could easily be included as a standard within OpenRTB and would expect to this appearing in 2.5. Within the Coull exchange we inform bid loss notification in real time without revealing the identity of bid winners, so advertisers and DSPs can better optimize their campaigns. Not only does loss notification help streamline yield optimization but it aids in stopping ad fraud such as that mentioned above. By letting the bidder know they’ve lost the auction, they can finish it within their systems without worrying about when a future impression might arrive. It just makes sense which is why we’ve already applied this technology within our own platform.


Do your part and get your feedback to Melissa at the IAB before the 19th of Feb.

A link to the latest spec can be found here.

Posted by simonholliday