OpenRTB version 2.4 is now released. While not a major upgrade by any stretch, the new protocol does introduce several new features that will bring clarity to programmatic transactions.
Support for Audio-only ads has been the feature most talked about. Podcasters and music apps will definitely welcome the addition, but few publishers will benefit besides this niche.
Another widely anticipated feature is video skippability, now included in bid requests. Publishers can indicate pre-bid if a video ad can be skipped, and under what conditions. PulsePoint will encourage its publishers to send this flag, in order to bring more transparency to video buy.
Those concerned with brand safety can rejoice. With 2.4, buyers can indicate in their bid responses, if their creative is suitable for either young children or adults, which may help with ongoing monitoring of buyer performance in the long term. PulsePoint, like most platforms, rely on third party vendors and manual checks to ensure compliance of creative with what’s requested. Obliging advertisers to systematically indicate the media rating of their creatives will make it easier for all parties to monitor compliance and flag violators.
Not all of the 2.4 upgrade is augmentative, as the IAB is removing some flexibility in resizing banners. Prior to this new version, maximum and minimum sizes could be specified; however recently, the IAB opted to mandate a list of exact banner sizes, reserving the resizing of banners exclusively for native impressions. This signals that IAB now sees banner as a single purpose ad format.
Finally, IAB added 6 attributes to the content section of the bid request, including the artist and genre of the content where the ad will appear. However, I doubt this will be of much use. The content section is rarely populated on PulsePoint exchange, and even less often consumed by buyers.
A few disappointments.
The IAB trumpeted increased support for location in 2.4, however this is quite a stretch. The new lat/long accuracy parameter (designed to specify the accuracy of the device that generates the location signal) will be of little value, as precise lat/long are used by geofencing campaigns which aren’t effected by the discrepancy of a few meters. More importantly, since the device of the GPS is often passed along, geofencers already have a sense of the accuracy of the GPS, and probably won’t trust what the publisher sent through the bid request. Knowing the IP geolocation provider will be of even less value, as most DSPs will keep using their own vendor lookup.
Despite some actions to enhance the monitoring of compliance, OpenRTB 2.4 still fails to mandate a maximum time lapse between a bid request and when the creative is finally delivered. We’ve seen bots circumventing quality filters by holding a creative for a few minutes and releasing them in batches, taking advantage of a hole in OpenRTB specifications. This topic caused many discrepancies between platforms and advertisers as well, yet OpenRTB 2.4 only added a recommended maximum time lag. PulsePoint will strongly suggest its buyers to provide this maximum lapse with each bid, and we are considering contractual wording to define liabilities accordingly.
Quickly implemented, quickly forgotten.
It appears that the most significant change may be the specs’ upgrade for native. This comes up in a different specifications document: The Dynamic Native Ads Protocol. The main OpenRTB protocol is unchanged, only referring this Native API.
PulsePoint will become 2.4 compliant right after the specs are finalized. Mostly because this is expected from a leading exchange, and less for the business value of the upgrade.