OpenRTB Best Practices
The following is a collection of some known best practices when buying or selling over OpenRTB.
The points below provide additional tips to help achieve success but assume compliance with OpenRTB specifications.
Consider using an OpenRTB validation utility to ensure bid request or response structures are in compliance before launching any exchange or bidder solution. Several free utilities are available online, contact your Demand Services Manager with questions.
At scale, bandwidth becomes a premium resource. One simple way to conserve it is to remove white space from JSON bid requests and responses. Also, several app servers (e.g., JBoss) allow compression of HTTP payloads with a simple configuration setting. This will require coordination between exchange and bidder, but can result in substantial savings especially on text payloads such as JSON.
Improve Connection Performance
One of the simplest and most effective ways of improving connection performance is to enable HTTP Persistent Connections, also known as HTTP Keep-Alive. This has a profound impact on overall performance by reducing connection management overhead as well as CPU utilization on both sides of the interface.
Fix Price Attributes
In the specification, price attributes are typed as float. However, fixed point arithmetic operations are recommended when handling currencies. For example, implementations should consider using BigDecimal rather than float or double.
Reduce Encoding Substitution Macro Data
Encoding of substitution macro data should be used sparingly due to the additional processing overhead. Encoding is generally unnecessary for communications strictly between exchange and bidder (e.g., a win notice called from the exchange).
Best Practices for Bidders
The most bandwidth-efficient way for a bidder to express a no-bid is to return an empty response and an HTTP code of 204. In the 1.0 Mobile and 2.2 versions of OpenRTB, a means exists of informing the exchange why no bid is being presented via the nbr attribute. It is recommended that this be used only to inform the exchange of bid requests the bidder never should have received (i.e., a condition the exchange can act upon).
Bidder may send markup to the exchange either in response to the win notice or in the bid itself via the adm attribute. The latter avoids a potential forfeit (i.e., win notice failure resulting in undelivered markup), but this is generally rare and including markup in bids is not bandwidth-efficient, especially when submitting multiple bids per response. Unless an exchange explicitly requires otherwise, it is best to deliver markup via the win notice.
Many exchanges implement some form of ad quality control features. Some publishers direct exchanges to reject any ad deemed not screenable. Thus bidders are urged to make proper and accurate use of seatbid and bid attributes seat, cid, crid, iurl, adomain, attr, and in OpenRTB 2.2 h and w. If their meanings are in any way unclear, contact your exchanges for detailed expectations.
Bids on behalf of multiple seats are encouraged since ad quality control features or publisher blocks can prevent the highest bid from winning a given auction. Multiple bids especially when presented from properly identified seats can increase a bidder’s win rate.