OpenRTB Best Practices
The following is a collection of some known best practices when buying or selling over OpenRTB. These points assume compliance with OpenRTB specifications, but provide additional tips to help achieve success:
Before launching any exchange or bidder solution, consider using an OpenRTB validation utility to ensure bid request or response structures are in compliance. A free utility for this purpose is available for use at OpenRTB Validator, which also includes a link to the validation source code.
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 is substantial savings especially on text payloads such as JSON.
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.
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.
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.