OpenRTB详解（二）
Bid Response 规范
RTB响应包含着一个对特定展示的出价信息。 出价信息本质上是一个购买要约。竞价响应由顶层的竞价响应对象和用于描述该出价信息的一些可选对象组成。 表示不出价的最节省带宽的方式是使用空的HTTP响应。 不符合标准格式的响应或者没有包含实际出价信息的响应都可以解释为不出价。
4.1 Object Model
下边是竞价响应的对象模型。模型中的顶级对象（即没有名字的最外层的JSON对象）表示 BidResponse. 一个竞价响应可能包含来自多个席位（即来自实际出价者的购买实体）。 实际上一个响应可能包含来自同一个席位的多个出价； 通常来自不同的camapigns,但也不一定总是这样。 这样可以提高席位的胜出可能性， 因为大多数交易平台会为了展示者的利益强制设置了一些限制列表。
从上图可以看出，真实的响应对象都显示在左边：顶级对象BidResponse, 表示席位的SeatBid以及Bid对象。 其他展示的对象都是与竞价响应相关的来自竞价请求的对象。特别要指出的是出于积极的追踪目的， BidResponse包含了BidRequest的ID。由于一个竞价请求可以包含多个展示， 所以Bid对象包含了Imp的ID, 用以表示是对该展示的出价。 如果某个出价符合某个私有交易市场的交易管制信息， Bid也应当包含特定Deal对象的ID.
图中没有展示的是扩展对象。扩展对象是一个没有定义结构的对象， 它可以添加到任何对象中以纯属交易相关的扩展信息。 使用这些对象的竞拍者有责任将这些扩展信息传递给交易平台。
下表总结了竞价响应中的对象， 可以作为作为下文详细信息描述的索引。
对象 章节 描述
BidResponse 4.2.1 顶级对象
SeatBid 4.2.2 竞拍者给出的一组出价信息
Bid 4.2.3 在特定商业条款下购买某个指定展示的要约
Object Specifications
以下部分将会详细介绍竞价响应模型中的每个对象。 首先介绍下适用于所有如下内容的公约：
带有required修饰的属性的缺失将会技术上导致协议的破坏。
处于某些可选属性的业务重要性， 会被标识为recommended。
除非默认值被显示指定，一个缺失的属性被解释为unknown。
4.2.1 BidResponse
顶级的竞价形影对象（即没有名称的最外层JSON对象）。 id属性是竞价请求的ID,用于记录日志。 同样的bidid是一个可选的响应追踪标识， 如果指定了该标识， 如果之后竞拍者胜出了，则在胜出通知子流程中，需要将该标识填充进去。 至少一个 seatbid对象是必须的， 表示对该展示的至少一个出价。 其他的属性都是可选的。
如果要表示不出价， 可以选择使用空的HTTP响应体以及HTTP 204响应码。 如果竞拍者想要向交易平台传递不出价的原因， 可以返回一个只填充nbr属性的BidResponse对象。
属性 类型 描述
id string; required 竞价请求的标识
seatbid object array 一组SeatBid对象， 如果出价，则至少应该填充一个
bidid string 竞拍者生成的响应ID, 辅助日志或者交易追踪
cur string; default ‘USD’ 使用ISO-4217码表标识货币类型
customdata string 可选特性，允许出价者以设置cookie的方式向交易平台传递信息。 字符串可以是任何格式， 必须使用base85编码，JSON编码必须包含转义的引号。
nbr integer 不出价的原因， 参考表5.19
ext object 特定交易的OpenRTB协议的扩展信息占位符
4.2.2 SeatBid
一个竞价响应可以包含多个SeatBid对象， 每个代表着不同的出价者且包含一个或多个独立的出价信息。 如果请求中有多个展示信息， group属性可以用来指定一个席位对胜出任何展示感兴趣（可以不是全部展示）或者它仅对胜出所有展示感兴趣。
属性 类型 描述
bid object array; required 至少一个Bid对象的数组，每个对象关联一个展示。多个出价可以关联同一个展示
seat string 出价者席位标识， 代表本次出价的出价人
group integer; default 0 0 标识展示可以独立胜出， 1标识展示必须整组胜出或失败
ext object 特定交易的OpenRTB协议的扩展信息占位符
4.2.3 Bid
一个SeatBid对象包括一个或者多个Bid对象， 每一个Bid对象通过impid关联竞价请求中的一个展示, 由一个对该展示出价组成。
属性 类型 描述
id string; required 竞拍者生成的竞价ID，用于记录日志或行为追踪
impid string; required 关联的竞价请求中的Imp对象的ID
price float; required 虽然本次只是对某一个展示的出价，但是竞拍价格是以CPM表示。需要注意数据类型是float,所以在处理货币的时候强烈建议使用相关的数学处理对象（比如，Java中的BigDecimal)
adid string 预加载的广告ID, 可以在交易胜出的时候使用
nurl string 胜出通知地址， 如果竞价胜出的时候由交易平台调用； 可选标识serving ad markup
adm string 竞拍胜出之后可选的传输ad markup的方式， 如果胜出通知中包含ad markup则优先使用adm
adomain string array 用于限制检测的广告主域名， 对于旋转的物料可以是一个数组， 交易平台可以限制只允许一个域名
bundle string 被广告的应用的包名或者其他信息， 如果可以，倾向于使用交易内唯一的ID
iurl string 用于质量或者安全监测的表示广告活动内容的图像地址， 不允许缓存
cid string Campaign ID , 辅助广告质量检查，iurl代表的一组物料
crid string Creative ID, 辅助广告质量检查
cat string array creative的IAB内容类型，参考表5.1
attr integer array 描述creative的属性集合，参考表5.3
dealid string 如果出价从属与某个私有市场直接交易规则， 则指向竞价请求中该交易规则的deal.id
h integer creative 的高度， 以像素为单位
w integer creative 的宽度， 以像素为单位
ext object 特定交易的OpenRTB协议的扩展信息占位符
对于每一个Bid对象， nurl属性包含了一个胜出通知地址，如果竞拍者胜出了一个展示， 交易平台会通过通知地址通知竞拍者胜出信息并通过替换通知地址中的宏向竞拍者传递特定的信息。 胜出通知的返回或者adm书慈宁宫可以用于提供markup. 不管使用哪种方式， 交易平台需要对markup执行前面提到的宏替换操作。
4.3 Ad Serving Options
在OpenRTB规范范围内的RTB过程实现核心在与markup的传输。 随着展示以及其他广告类型的限制， markup可以使XHTML, 带有内嵌Javascript的XHTML，用于视频的超大文档， 一个Native广告单元结果以及其他未来可能出现的类型。
除了宏替换以及传输到提供方， OpenRTB标准没有要求对ad markup做任何处理。 然而， 还是有很多标准方式用于从竞拍者向交易平台传输markup信息。具体的方式由竞拍者决定， 一个遵从OpenRTB协议的交易平台应当支持以下定义的所有方式。
4.3.1 Markup Served on the Win Notice
在这种实现方式中， ad markup是通过胜出通知返回给交易平台的。 在这种情况下， 胜出通知的响应体包含且仅包含ad markup信息。 响应体中必须不能再有其他数据， 使用这种方式， bid.adm属性必须被忽略。
4.3.2 Markup Served in the Bid
在这种实现方式中， ad markup在bid实体中被返回。 这需要通过bid.adm属性完成， 如果adm属性和胜出通知都返回数据， adm内容会被使用。
4.3.3 Comparison of Ad Serving Approaches
每种广告提供方式有它自己的优势，且这种优势随着交易平台和竞拍者不同而不同。
** Ad Served on the Win Notice**
较少带宽： 仅仅在胜出之后提供ad markup可以节省大量的带宽使用， 尤其是对于交易平台， 其代价是非常巨大的。
额外的竞拍者灵活性： 竞拍者可能在竞拍的时候已经知道了将要提供的广告信息， 但是这种方式在结算价格发布之后提供了附加的可选决策点。
** Ad Served in the Bid**
减少广告丢失的风险： 一次广告丢失是这样的场景， 一个竞拍者胜出了， 但是在提供广告内容的时候失败了。 但是额外的HTTP 失败可能被减少了。
潜在的并发： 交易平台可以选择并发的返回ad markup和进行胜出通知， 从而提高用户体验。
4.4 Substitituion Macros
胜出通知地址以及它的格式是由竞拍者定义的。为了让交易平台可以向胜出的竞价者传输确定的信息，可以在胜出通知地址中插入一些可替换的宏。在调用胜出通知地址之外， 交易平台会在竞拍者提供的胜出通知地址中查找已定义的宏并使用合适的数据进行替换。 注意这个替换过程是非常简单的，仅仅是在查找到宏的地方直接进行替换， 不会进行任何的语法校验。如果响应的值是可选的且没有被指定， 响应的宏就会直接被删除掉（即使用空字符串替换）。
相同的替换宏业可以出现在ad markup中。 交易平台会做相同的数据替换操作。 这个操作是不会关心markup是在胜出通知中返回或者通过bid.adm属性在竞价响应中传递。 将宏用在ad markup中的一个用例是当竞拍者希望从设备本身接收官方胜出通知。 为了完成这些， 竞拍者需要在ad markup中包含一个追踪像素， 该追踪像素的地址可能包含任何可用的宏。
Micro Description
${AUCTION_ID} 竞价请求的ID; 来自 BidRequest.id 属性.
${AUCTION_BID_ID} Bid的ID; 来自 BidResponse.bidid 属性.
${AUCTION_IMP_ID} 胜出的展示的ID ; 来自 imp.id 属性.
${AUCTION_SEAT_ID} 竞拍者的席位ID
${AUCTION_AD_ID} 竞拍者要提供的广告的ID ; 来自 bid.adid 属性.
${AUCTION_PRICE} 拍卖价格，与Bid使用相同的货币类型
${AUCTION_CURRENCY} 竞价使用的货币类型（隐式或者显式）， 仅仅用于确认
在替换之前， 处于安全性考虑， 宏对应数据的信息是可以使用多种混淆或者加密算法加密的。 当比如价格信息通过广告信息中的一个追踪像素被带出交易平台， 通过发布者，最终到达设备浏览器这种场景下， 这种做法就尤其有用。
要制定某个特定的宏是被加密的，需要将“:X”后缀附加到宏名称之后， X是一个表示所使用算法的字符串。 本规范并没有规定的具体的算法选项，这需要交易平台和竞拍者之间进行协商。 举个例子， 假设表示价格的宏使用Base64加密其使用加密码“B64”, 宏就会被写成如下模样：
${AUCTION_PRICE:B64}
最佳实践： 应该尽量少的对宏进行加密，因为这需要额外的处理消耗（加解密）。 对于完全在竞拍者和交易平台之间的通信（比如， 从交易平台发起的一个胜出通知）， 加密通常是没有必要的。