Open RTB: Signaling Ad Refreshes

Introduction

It is common for sellers of digital inventory to refresh their ad slots for better monetization. However, there has been no way to communicate this via OpenRTB, and consequently, buyers do not have ready access to information about this behavior. We are addressing this in OpenRTB 2.6-202303.

There are many examples of this lack of information, most notably the exposure time on digital out-of-home (DOOH) screens, and the refresh time for banners on ad-supported websites, though these are hardly the only use cases. There are other scenarios where an ad slot can remain in view for minutes at a time – e.g., with ads that “float” next to an infinite-scrolling feed or, depending on the content, even regular ad slots – and it is not rare to see publishers refresh these too (typically on a period of 30 seconds).

Transparency is in everyone’s interest

Today it is only possible for a buyer to know that an ad slot refreshes (a) if they extrapolate from having seen it happen before or (b) once they have bought the slot, only to find their ad is replaced some seconds later. The absence of a standard way to communicate refreshed inventory has caused problems:

The Media Rating Council (MRC) has required measurement organizations to detect and segregate such impressions in reporting, if material. Those organizations have been compelled to create custom solutions, resulting in fragmentation.
The calls to refresh the ads will typically be initiated on a timer and are liable to be flagged as non-human traffic.

Update to OpenRTB 2.6

Publishers will now be able to give buyers a better line of sight into the triggers that cause an ad slot to be refreshed via two new objects in the OpenRTB specification. These deliberately follow the pattern established by AdX’s Real Time Bidding Protocol. This is both for the sake of consistency and because of the flexibility built into that API – it recognizes there could be different types of refresh triggers and more than one type in play on a given page view.

The full specification can be found here. It boils down to support for communicating the following:

The types of refresh trigger in play;
For each of these, the minimum interval before the refresh may trigger;
The number of times this ad slot has been refreshed since the last page load.

These behaviors can vary by ad slot, and the specification accommodates this. The absence of these fields means the same as it does today – i.e., that the refreshability of the ad slot cannot be determined from the request.

What’s next for the Programmatic Supply Chain Working Group?

There’s a lot to choose from with this group, though there are two notable proposals under discussion now, and expected to materialize this year. The first relates to the publisher’s ability to set floors per creative format, for differentiation between (for example) banner and video ads vying for the same slot. The second seeks to provide an enforceable mechanism in OpenRTB to inform buyers whether a page visit was direct or resulting from traffic sourcing, staying as close as possible to updated guidance from the Media Ratings Council.