Banner and Video Objects

[chompi]

Original author: [email protected] (July 22, 2011 21:10:36)

The “imp” object has been reorganized from the OpenRTB Mobile specification to require either a banner or a video object. There are a couple issues with this. First, the either-or notion requires that the ad request limits itself to one or the other a priori. We have some applications in the field that make ad requests that are happy to receive either a banner or a video and do not know until the ad is received. This would preclude that. The structure also adds the complexity of an additional object to the incredible majority of requests that are non-video and in the process takes us further away from backward compatibility. Here are the points I strongly urge to address this:

• Restore “w”, “h”, “pos”, “battr”, and “atype” back into the “imp” object and remove them from “banner” and “video”. Even for VAST companion banners, I believe these would all have the same values. If I’m wrong about that, then keep the ones that do vary in “banner” as well as “imp”.
• Copy the remaining attributes from “banner” up to the “imp” object except “id”, since that is only meaningful to VAST companion banners.
• The presence of a “video” object can be used to indicate that a video ad is allowed.
• Change “atype” back to “btype” (i.e., a block list rather than a white list as it is in the OpenRTB Mobile specification). If people also want the flexibility of a white list, then keep them both but rename the white list to be “wtype” to be consistent with the convention established in the OpenRTB Mobile specification.
• If only a video ad is welcome, then the “video” object would be included and “btype” would be used to block the banners.
• The “banner” object can still exist in the specification for reference by the “video” object. But since it would only be used as video companion ads, there may be the opportunity to further simplify it, but I’ll leave that to a VAST champion. It would probably make sense to rename it to “companion” at this point.
• The “h” and “w” attributes should be recommended rather than required as their descriptions indicate. While we tend to include it all the time, it is quite common in mobile to derive screen height and width from the UA and go with the largest MMA ad unit that will fit.

Summary note: This may feel less object-oriented from a spec perspective, but it makes requests for non-video ad units (i.e., the huge majority of global ad requests) simpler and more backward compatible with the existing OpenRTB Mobile specification.

Original issue: http://code.google.com/p/openrtb/issues/detail?id=23