Open RTB ecosystem IAB

Our impressions of the IAB OpenRTB 2.4

The IAB has recently upgraded their guidelines for OpenRTB 2.4. We'll be highlighting some of the updates and outlining our expectations for version 2.5.

Sharing is caring!

The IAB’s Advertising Technology Council has recently upgraded the OpenRTB guidelines to version OpenRTB 2.4. We’ll be highlighting some of the positive updates as well as recommending areas we expect to see improvement in version 2.5.

1.    Impression expiry

Open RTB 2.4 goes some way to improving fraudulent impressions caused by ‘Xindi-style’ bot networks. 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 for 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.

OpenRTB 2.4 review - Xindi style bot networks


Xindi targetted corporate environments or even universities, allowing it to generate fake viewable impressions from recognised IP addresses at scale. The diagram below shows how this process works.


Xindi bot network - OpenRTB 2.4 review

Source: Pixelate

One of the OpenRTB 2.4 updates involves expiring the impression tracker which will stop the botnet being rewarded. The table below shows new impression expiry times guidelines for video ad impressions. Guidelines will be implemented 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 become so cheap that this argument hasn’t been valid for a long time. So, from our perspective, it’s great to see it’s finally recommended.

Legacy exchanges and DSPs may drag their feet when it comes to securing web traffic but the whole industry should embrace this. We’re certainly ensuring our own processes incorporate stringent security. Reflected in current practices, we have an ad tech ecosystem that’s essentially self-policed and DSPs aren’t making targeting segments from bid requests etc. ‘Bad actors’ from outside the industry aren’t 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 2.4. 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 they’ve previously had very little control over. However, there’s no clear definition as to who is responsible for creating it – the publisher in their player? Or the 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 mobile location data is actually valid. 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, it 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, like podcasts or services such as Spotify 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.

Other OpenRTB 2.4 updates worth a mention

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

What Coull expect in OpenRTB 2.5

As a market-leading third generation video ad exchange and platform, we operate with multiple DSP’s and push demand through our SSP and supply partners. So it’s very important to constantly update and upgrade our proprietary technology. We’ve made a 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.

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

HTTP2 and Advertising

The current OpenRTB 2.4 spec doesn’t 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. But if there are to be more conversations then more connections are needed. HTTP2 allows a single connection to have multiple conversations 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 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 is well underway to go even further. The whole industry should be guided in this direction. 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 into 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. This means 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 without worrying about a future impression. It just makes sense. Which is exactly 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.

The latest spec can be found here.

If you enjoyed reading this, we also recommend:

MRAID – the Language of Love in the App environment

Uncovering video performance metrics

Sharing is caring!

Posted by simonholliday