``# OpenRTB_API_Specification中文版(V2.3.1)

名词解释

IAB: Interactive Advertising Bureau 交互式广告局。

前言

简介

RTP工程， 前身为OpenRTB组织， 在2010年11月份组建。致力于为数字媒体自动化交易开发一套全新的开放标准，以应对更大范围的平台，设备以及广告解决方案。本文档就是RTB工程努力的结晶，你可以在www.iab.net找到最新的官方文档。

关于IAB的广告网络和交易协会

IAB 广告网络和交易协会主要由广告网络和广告交易平台成员公司的高层领导组成。该协会致力于促进当今世界日益复杂的广告市场中数字生态系统的利益。协会目标是促进完成在广告商，发布者，中间商，代理协会之间专业性和责任心的最高标准， 开发能够保证收入增长的程序以及创建保护消费者和行业的最佳实践。

RTB工程是IAB广告科技理事会下的一个工作小组。

IAB 联系方式

Melissa Gallo 产品总监 – 数据和程序自动化, IAB 科学实验室 melissa@iab.net

许可证

OpenRTB 规范是在Creative Commons Attribution 3.0 License许可之下，基于http://openrtb.info的工作。 在该许可证之外的权限你可以在http://openrtb.info找到。如果要查看该许可证的副本， 可以访问https://creativecommons.org/licenses/by/3.0/或者写信给Creative Commons, 171 Second Street, Suite 300, San Francisco, CA 94105, USA.

新手入门

本规范包含了实时竞价接口的详细解释。以下相关解释中多处涉及“对象”这个概念， 所以这里提前说明以下：并不是所有的对象都是必须的，每个对象可能包含多个可选的属性参数。为了帮助第一次接触本文档的读者，我们已经在文档中标注了不同场景下（比如banner, video等等）要完成一个最小可行的实时竞价接口，哪些参数是不可缺少的以及哪些属性是可忽略的。

最小可行接口应该包括标识有required以及recommended的参数，但是这些参数的作用范围与其特定的使用场景相关。在这些场景的参数描述表中， [Description] 列可能会进一步的标识及注解参数的required或者recommended状态。为了尽可能填充对象， 可选参数也是可以被填充的，这都取决于该行为的参与者（对象填充者）。

下表展示了不同修饰符的作用：

• 带有required为必须参数，带有recommended的选项是推荐参数，其余的（带有default修饰符或者什么都不带）则是可选参数。
• 按照习惯，通常会按照 required—>recommended->default->none 的顺序防止参数。

注意： 由于recommended属性不是必须的， 所以并不是从每个数据源都可以获取到的。 所以建议所有的OpenRTB事务参与者完成下页中的集成清单来标识供应方在竞价请求中支持，哪些属性是需求方需要用来做广告决策的。

集成清单列表

1. 介绍

1.1 目标/概览

OpenRtb工程的任务是为广告买家和广告位库存买家之间的通信提供开放的工业标准，以刺激实时竞价市场的增长。标准涉及到很多方面，包括但不限于实时竞价协议，信息分类，离线配置同步以及其他很多。

本文档为从早期”block list”项目和”OpenRTB Mobile”项目发展而来的实时竞价接口规范标准。这些标准旨在简化广告媒体库存的提供商（例如，广告交易， 代表发布商利益的广告网络， 卖方平台） 与其有竞争力的买家（例如，竞价者， 需求方平台以及代表广告商利益的广告网络）之间的关系。

OpenRTB总的目标是为买家和卖家之间的沟通创造一种通用语言，这种倾向不是精确的规定每个交易的操作。 作为一个工程， 我们的目标是让参与的各方可以更容易的集成， 从而促进生态系统中交易的各方都能够进行更深层次的创新。

1.2 OpenRTB的历史

OpenRTB于2010年的11月份在三个需求方平台（DataXu, MediaMath和Turn）以及三个卖方平台（Admeld, PubMatic以及The Rubicon Project)上作为试点项目启动的。 第一个目标是使交易block lists各方的沟通标准化。OpenRTB 1.0 block list规范在2010年的12月发布。

在得到了业界普遍的正面响应之后， Nexage 介入 OpenRTB工程，并建议在实时竞价请求和响应协议上为OpenRTB创建API规范，尤其是为支持手机移动广告。 移动小组委员会在买方公司（DataXu, Fiksu以及[X+1]和卖方公司(Nexage, Pubmatic, Smaato以及Jumptap)之间形成了。这个项目促成了OpenRTB Mobile 1.0标准， 该标准在2011年2月发布。

随着移动规范的发布， 在与DataXu和ContextWeb协作的视频广告交易（BrightRoll以及Adap.tv)中，一个视频小组委员会也形成了，其目标在于合作支持将普通展示型广告，视频广告以及移动广告规范在一个文档中。这个努力最终促成了一个统一的标准-OpenRTB2.0,在2011年6月发布。

由于业界的广泛采纳， 随着OpenRTB在2012年1月2.1版本的发布，它被采纳为美国互动广告局（Interactive Advertising Bureau）的一项标准。

1.3 版本历史

OpenRTB 实时竞价API

• 2.3 支持原生广告以及多个微小改动
• 2.2 为私有市场直接交易，视频，移动广告以及regulatory signals做出的一些新的改动
• 2.1 按照QAG规范进行一些修正，一些小的改动以及错误修正。
• 2.0 将展示广告，移动广告以及视频广告标准归一到一个统一的标准
• 1.0 OpenRTB 移动版的最初发布版

OpenRTB 展示 Block List分支

• 1.2 发布商API
• 1.1 为包含creative attributes的实时交易进行小改动
• 1.0 OpenRTB block list规范的最初发布。

1.4 资源

• OpenRTB Google Groups: http://openrtb.info
• OpenRTB Github 地址 http://github.com/openrtb/OpenRTB
• 开发者社区邮件列表 http://groups.google.com/group/openrtb-dev
• 用户社区邮件列表 http://groups.google.com/group/openrtb-user

1.5 术语

2. OpenRTB 基础知识

下图展示了广告交易平台和它的竞拍者之间的交互行为。 广告请求首先从发布者的站点发起。 对于每一个请求，广告交易平台都会向多个竞拍者广播竞价请求，从竞拍者返回的竞拍响应信息会按照常用的竞拍规则进行决策，获胜者会被通知， 广告审定结果被返回。获胜通知地址以及广告审定结果可能包含任何标准宏以保证广告交易平台能够与竞拍者之间沟通竞拍相关的关键数据。

注意对于通知是否会丢失并没有显式规定。 这是由于该操作会消耗一定的系统性能和带宽。建议广告交易平台在请求/响应协议之外通过离线或者独立的处理流程来提供丢失的竞拍数据信息。

本规范专注于实时竞价交互中的竞价请求和响应以及胜出通知及其响应。其他的交互（比如阻塞列表同步， 流量控制）要么是未来执行的可选行为，要么是已经被OpenRTB定义的。

2.1 数据传输

交易平台和它的竞拍者之间的基础通讯协议是HTTP. 特别要说明的是，在发起竞价请求的时候需要使用HTTP POST方式，因为它比HTTP GET可以附带更多的内容，并且也更容易支持二进制数据。 胜出通知则可以使用HTTP POST 或者 GET, 这个是由交易平台决定的。除了空的竞价响应应当返回HTTP 204之外， 所有的调用都应当返回HTTP 200（例如，推荐的方式是在响应体中指明”no bid”),

最佳实践: 一种最简单和最有效的提高连接性能的方式是启用HTTP长连接， 也就是我们通常说的Keep-Alive. 通过减少两端的连接管理以及CPU使用， 对整个过程会有明显的性能提升。

2.2 安全性

SSL(Secure Socket Layer) 不是必须的， 因为这些调用都是服务器之间的调用， 可以用其他方式对数据的安全进行保护。除此之外， SSL 不被推荐使用也由于它额外的处理负载。

2.3 数据格式

JSON(Javascript Object Notation) 是竞价请求和响应的推荐数据格式。 JSON被选择是因为它的可读性以及紧凑性。数据负载的相关信息我们会在第3节和第4节详细描述。

交易平台可能需要提供额外的内容信息给有需要的竞价者。这些内容可能包括一个JSON, XML, Apache Avro, ProtoBuf, Thrift以及其他种类的格式的压缩形式。

竞价请求需要使用HTTP的Content-Type头在mime-type中指明内容的类型。标准JSON类型的mime-type是”application/json”. 竞价响应的数据格式必须跟竞价请求相同。 ··· Content-Type: application/json ···

如果要使用其他可选的二进制类型， 交易平台或者SSP应当适当的指明Content-Type, 例如”Content-Type: avro/binary” 或者 “Content-Type:application/x-protobuf”, 如果没有content-type头， 竞拍者应当认为类型是”application/json”, 除非交易平台选择了另一种不同的默认类型。

作为约定，某个属性的确实有其确定的意义，大多数情况下，这标识该属性值是未知的，除非被特殊指明。

2.4 OpenRTB 版本号 HTTP 头

OpenRTB版本号应当在竞价请求的头中使用自定义头传递。这可以让竞价者在解析请求体之前判断消息的版本号。 此外，建议竞价者在响应头中使用相同的格式信息标识自己实现的协议版本，这个版本号可能与请求头中的版本号是不同的。

 x-openrtb-version: 2.3

版本号应当以 <主版本号>.<次版本号>的格式（例如， 2.3). 第一位或者第二位数字的变动标识着协议的改变。通常，第二位版本的改变应当向兼容，第一位版本的改动不需要向后兼容。任何第三位版本号的改动（例如2.0.1)都不应当改变协议自身， 而仅仅改变不影响协议内容的描述和注释。第三位的版本号不应当在HTTP头中包含，因为他们对整个实现不会有技术上的影响。

2.5 隐私设计

OpenRTB工程支持广告中卖方和买方之间的隐私策略。特别是OpenRTB支持 do-not-track(3.2.11节）， COPPA restriction signaling(7.1节）， 以及从卖方向买房通过User　Object传递用户数据（3.2.13节）的能力。

2.6 与 IAB 质量保证指南 之间的关系

OpenRTB与IAP的质量保证指南（QAG)完全兼容， 你可以在这里找到http://www.iab.net/ne_guidelines. 特别是本文档中的分类标准是从QAG继承而来。

2.7 定制与扩展

OpenRTB规范允许交易病态对其进行定制和扩展。每一个对象都可以包含扩展。为了保证扩展字段的一致性，扩展字段应当始终使用”ext”命名。

3. 竞价请求规范

RTB 事务在交易平台或者其他广告提供源向竞价者发起竞价请求是被发起。竞价请求由顶级请求对象组成，至少一个展示对象， 以及可能有选择性的包含一些其他的对象用于提供展示相关的上下文信息。

3.1 对象模型。

下图展示了竞价请求的对象模型。顶级对象（例如， 在JSON中没有命名的最外层对象）在这个模型中是表示BidRequest的。在它的直属子对象中，只有Imp是技术上必须的，因为它是描述一次展示的基础信息，必须使用Banner, Video以及Native中的至少一个来定义展示的类型（例如， 无论一个或者多个展示者想要接收；尽管一次竞价是这些指明类型中的明确的一种）。一个展示对象可能包含一组私有市场。

竞价请求的其他直属子对象用于为竞价者的用户定向及广告定价提供多种形式的辅助信息。这包括用户的详细信息以及他们使用的设备，位置信息，监管约束条件以及广告的展示载体。

对于后者，在站点（即web站点）以及应用（即手机中安装的非浏览器应用）有一个区别。抽象类DistributionChannel 仅仅是一个模型上的抽象， 用于表明一个BidRequest与一个Site或者App相关联，但不会同时与他们关联（即一个发布渠道是一个抽象的站点或者一个应用). 站点和应用都可以被更进一步的描述， 比如他们的发布者， 内容，内容产生者。

上图中没有展示的是扩展对象。这是一个未定义的但是可以附加到任意其他对象中用于传达交易相关的扩展信息的对象。使用这些对象的交易平台有责任将这些扩展信息传递给竞拍者。

下表总结了竞价请求模型中用到的对象，可以作为以下子章节的索引。

　3.2 对象规范

以下部分将会详细介绍竞价请求模型中的每个对象。 首先介绍下适用于所有如下内容的公约：

• 带有required修饰的属性的缺失将会技术上导致协议的破坏。
• 处于某些可选属性的业务重要性， 会被标识为recommended。
• 除非默认值被显示指定，一个缺失的属性被解释为unknown。

3.2.1 BidRequest

顶层竞价请求对象， 包含一个全局唯一的竞价请求或拍卖ID。 id属性是必须的因为其中至少包含一个展示对象（见3.2.2节）。 在这个对象中的所有其他对象所建立的规则和限制适用于其中的所有展示对象。

有一些子对象用于提供潜在买家的详细信息，在这些对象中个，Site和App对象，用于描述展示广告的发布媒体的类型。这些对象是高度推荐使用的， 但是每个竞价请求中只能使用一个，这取决于发起广告请求的是基于浏览器的页面内容或者非浏览器应用。

3.2.2 Imp

这个对象描述了一个广告位或者将要参与竞拍的展现。一个竞价请求可以包含多个Imp 对象，这种状况的一个示例是一个交易平台支持售卖一个页面的所有广告位。 为了便于竞拍者区分， 每一个Imp对象都要有一个唯一标识（ID).

Banner, Video以及Native对象都属于Imp对象，只是标明了各自的展示类型。 展示者可以选择其中的一种类型或者混合使用多种类型。 但是，对于展示的任何给定的竞价请求必须属于提供的类型之一。

3.2.3 Banner

Banner是最常见的展示类型。 虽然“banner”这个名词在其他的场景有很特别的意思， 在这里它可以是包括静态图像， 可扩展的广告单元或者一个在banner中播放的视频在内的很多东西。一组Banner对象可以出现在Video对象中来描述可选择在VAST贵方中定义的附加广告。

Banner作为Imp的子对象出现表示它是一个具有banner类型的展示对象. 同样的展示也可以是一个视频或者Native广告， 只要包含Video对象或者Native对象。然而， 任何为展示给定的竞价请求必须符合提供类型中的一个。

3.2.4 Video

这个对象表示一个流式视频展示。 许多属性对于最小可用功能不是必须的，但是为了在需要的时候提供更好的控制能力会被使用。OpenRTB中的视频通常都是与标准一致的，复合广告的概念也是支持的， 可以包含用于定义复合广告的一组Banner对象。

Video作为Imp的子对象出现表示它是一个具有视频类型的展示对象。 同样的展示也可以是一个Banner或者Native广告， 只要包含Banner对象或者Native对象。然而， 任何为展示给定的竞价请求必须符合提供类型中的一个。

3.2.5 Native

表示一个Native类型的展示。Native广告单元需要无缝的插入其周围的内容中（例如， 一个对Twitter或Facebook赞助）。 因此，响应必须具有良好的结构， 让展示者能够在细粒度上控制渲染过程。

Native小组委员会为OpenRTB开发了一个组合规范，名为Native Ad规范。 定义了Native广告的请求参数以及响应结构。这个对象以字符串的形式提供请求参数， 这样的话具体的请求参数就可以按照Native Ad规范独立演进。同样的， 广告markup也会按照该文档指定的结构提供。

Native作为Imp的子对象出现表示它是一个具有native类型的展示对象。 同样的展示也可以是一个Banner或者Video广告， 只要包含Banner对象或者Video对象。然而， 任何为展示给定的竞价请求必须符合提供类型中的一个。

3.2.6 Site

如果广告载体是一个网站时应该包含这个对象，如果是非浏览器应用时则不需要。 一个竞价请求一定不能同时包含Site对象和App对象。 提供一个站点标识或者页面地址是很有用的， 但是不是严格必须的。 | 属性 | 类型 | 描述 | | —- | —- | —- | | id | string; recommended | 交易特定的站点标识| | name | string | 站点名称 （可以在展示者请求中作为别名标识）| | domain | string | 站点的域名 （例如，”mysite.foo.com”) | | cat | string array | 站点的一组IAB 内容类型，参考表5.1 | | sectioncat | string array | 描述站点当前部分的一组IAB内容类型，参考表5.1 | | pagecat | string array | 描述站点当前视图的一组IAB内容类型，参考表5.1 | | page | string | 展示广告将要被展示的页面地址 | | ref | string | 引导到当前页面的referrer地址 | | search | string | 引导到当前页面的搜索字符串 | | mobile | integer | 移动优化标志， 0表示否，1表示是 | | privacypolicy | integer | 表示该站点是否有隐私策略， 0表示没有， 1表示有 | | publisher | Object |Publisher对象， 站点发布者的详细信息 | | content | Object | Content对象， 该站点内容的详细信息 | | keywords | string | 逗号分隔的站点的关键字信息 | | ext | object | 特定交易的OpenRTB协议的扩展信息占位符 |

3.2.7 App

如果广告载体是非浏览器应用（通常是移动设备）时应该包含该对象， 网站则不需要包含。一个竞价请求一定不能同时包含Site对象和App对象。 提供一个App标识或者bundle是很有用的， 但是不是严格必须的。

3.2.8 Publisher

用于描述展示广告的媒体的发布者。通常发布者就是OpenRTB事务中的卖方。

3.2.9 Content

3.2.10 Producer

定义内容的提供者， 广告会在这些内容中展示。 当内容会被多个发布者展示时是对于区分发布者和生产者是否是同一实体是有用的。

3.2.11 Device

提供用户使用的设备的详细信息。设备信息包括硬件，平台以及附加信息。设备可以是一部移动手机， 桌面电脑，机顶盒或者其他数码设备。

最佳实践: 当前没有关于设备生产商，型号，操作系统或其他附加信息的有效的开源列表。 交易平台通常使用商业产品或者其他专有列表来填充这些属性。 在适当的开放标准可用之前， 推荐交易平台向竞拍者发布他们支持的设备生产商， 型号，操作系统以及附加信息。

最佳实践: 对于移动设备的IP合理的检测方式不是去直接检测的，通常存在于HTTP 的x-forwarded-for头中， 跳过私有的网络（例如10.x.x.x或者192.x.x.x), 扫描出已知的IP. 当交易平台向竞拍者传递设备的IP地址的时候， 要求交易平台仔细的研究并实现该属性。

3.2.12 Geo

用于封装一个地理位置信息的多种不同属性。 当作为Device对象的子节点的时候，标识设备的地理位置或者用户当前的地理位置。 当作为User的子节点的时候，标识用户家的位置（也就是说，不必是用户的当前位置）。

3.2.13 User

描述了解或者持有设备的用户的信息（也就是广告的受众）。 用户id是一个exchange artifact, 可能随着屏幕旋转或者其他的隐私策略改变。 尽管如此，用户id必须在足够长的一段时间内保持不变，以为目标用户定向和用户访问频率限制提供合理的服务。

3.2.14 Data

Data和Segment对象一起允许指定用户附加信息。数据可能来自多个数据源， 可能来自交易平台自身或者第三方提供的信息， 可以使用id属性区分。 一个竞价请求可以混合来自多个提供者的数据信息。 交易平台应该优先提供正在使用的数据提供者的信息。

3.2.15 Segment

数据字段， 描述用户信息数据的键值对。 其父对象Data是某个给定数据提供者的数据字段的集合。交易平台必须优先将字段的名称和值传递给竞拍者。

3.2.16 Regs

描述任何适用于该请求的法律，政府或者工业管控条例。 coppa(Children’s Online Privacy Protection Act)标志着是否该请求是否符合美国联邦贸易委员会颁布的美国儿童在线隐私保护法案，详情可参考7.1节。

3.2.17 Pmp

包含本展示涉及的买卖双方的直接交易相关的私有市场信息。 真实的交易信息使用一组Deal对象表示， 详情可参考7.2节。

3.2.18 Deal

描述限制买卖双方之间交易的一些条款。 它在Pmp集合中的出现表示该展示符合交易描述的条款。详情参考7.2节。

4. Bid Response 规范

RTB响应包含着一个对特定展示的出价信息。 出价信息本质上是一个购买要约。竞价响应由顶层的竞价响应对象和用于描述该出价信息的一些可选对象组成。 表示不出价的最节省带宽的方式是使用空的HTTP响应。 不符合标准格式的响应或者没有包含实际出价信息的响应都可以解释为不出价。

4.1 Object Model

下边是竞价响应的对象模型。模型中的顶级对象（即没有名字的最外层的JSON对象）表示 BidResponse. 一个竞价响应可能包含来自多个席位（即来自实际出价者的购买实体）。 实际上一个响应可能包含来自同一个席位的多个出价； 通常来自不同的camapigns,但也不一定总是这样。 这样可以提高席位的胜出可能性， 因为大多数交易平台会为了展示者的利益强制设置了一些限制列表。

从上图可以看出，真实的响应对象都显示在左边：顶级对象BidResponse, 表示席位的SeatBid以及Bid对象。 其他展示的对象都是与竞价响应相关的来自竞价请求的对象。特别要指出的是出于积极的追踪目的， BidResponse包含了BidRequest的ID。由于一个竞价请求可以包含多个展示， 所以Bid对象包含了Imp的ID, 用以表示是对该展示的出价。 如果某个出价符合某个私有交易市场的交易管制信息， Bid也应当包含特定Deal对象的ID.

图中没有展示的是扩展对象。扩展对象是一个没有定义结构的对象， 它可以添加到任何对象中以纯属交易相关的扩展信息。 使用这些对象的竞拍者有责任将这些扩展信息传递给交易平台。

下表总结了竞价响应中的对象， 可以作为作为下文详细信息描述的索引。

4.2 Object Specifications

以下部分将会详细介绍竞价响应模型中的每个对象。 首先介绍下适用于所有如下内容的公约：

• 带有required修饰的属性的缺失将会技术上导致协议的破坏。
• 处于某些可选属性的业务重要性， 会被标识为recommended。
• 除非默认值被显示指定，一个缺失的属性被解释为unknown。

4.2.1 BidResponse

顶级的竞价形影对象（即没有名称的最外层JSON对象）。 id属性是竞价请求的ID,用于记录日志。 同样的bidid是一个可选的响应追踪标识， 如果指定了该标识， 如果之后竞拍者胜出了，则在胜出通知子流程中，需要将该标识填充进去。 至少一个 seatbid对象是必须的， 表示对该展示的至少一个出价。 其他的属性都是可选的。

如果要表示不出价， 可以选择使用空的HTTP响应体以及HTTP 204响应码。 如果竞拍者想要向交易平台传递不出价的原因， 可以返回一个只填充nbr属性的BidResponse对象。

4.2.2 SeatBid

一个竞价响应可以包含多个SeatBid对象， 每个代表着不同的出价者且包含一个或多个独立的出价信息。 如果请求中有多个展示信息， group属性可以用来指定一个席位对胜出任何展示感兴趣（可以不是全部展示）或者它仅对胜出所有展示感兴趣。

4.2.3 Bid

一个SeatBid对象包括一个或者多个Bid对象， 每一个Bid对象通过impid关联竞价请求中的一个展示, 由一个对该展示出价组成。

对于每一个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中包含一个追踪像素， 该追踪像素的地址可能包含任何可用的宏。

在替换之前， 处于安全性考虑， 宏对应数据的信息是可以使用多种混淆或者加密算法加密的。 当比如价格信息通过广告信息中的一个追踪像素被带出交易平台， 通过发布者，最终到达设备浏览器这种场景下， 这种做法就尤其有用。

要制定某个特定的宏是被加密的，需要将“:X”后缀附加到宏名称之后， X是一个表示所使用算法的字符串。 本规范并没有规定的具体的算法选项，这需要交易平台和竞拍者之间进行协商。 举个例子， 假设表示价格的宏使用Base64加密其使用加密码“B64”, 宏就会被写成如下模样：

${AUCTION_PRICE:B64}

最佳实践： 应该尽量少的对宏进行加密，因为这需要额外的处理消耗（加解密）。 对于完全在竞拍者和交易平台之间的通信（比如， 从交易平台发起的一个胜出通知）， 加密通常是没有必要的。

5. 枚举列表规范

所有的参考列表由IAB维护并及时更新到OpenRTB的网站上。 介于此， 实现者应当保证他们是根据最新的列表和枚举来实现。

5.1 内容类型

以下列表描述了IAB的类型分类信息。 为了方便对象之间对第一级和第二级类型的沟通方便，已经采用了标准的ID标识。

这个OpenRTB表中的值都是继承自IAB的质量保证指南（QAG). 实现者应当与IAB.net上的QAG中的值保持同步。

5.2 Banner 广告类型

下表展示了除被展示者站点设置限制的交易平台可以接受的广告类型。

5.3 Creative 属性

下表展示了广告物料属性的标准列表， 用于描述一个被提供的广告或者作为限制提供。

5.4 广告位置

下表描述了广告相对于可见范围的位置。表中的值继承自IAB QAG. 实现者应当保持与QAG中值同步。

5.5 伸展方向

下表罗列了一个可伸展广告可以伸展的方向，考虑了广告单元在页面汇总的位置以及被内容的限制。

5.6 API 框架

下表罗列了展示者支持的API框架。 注意MRAID-1是MRAID-2的子集。在OpenRTB2.1及之前版本，“3”对应的是”MRAID”, 然而并不是所有MARID兼容的API可以理解MRAID-2的特性，所以最安全的方式是将3理解为MRAID-1.在OpenRTB2.2中， 该值已经被显式标明了， MRAID-2也使用值5被加入。

5.7 视频 Linearity

下表描述了视频 linearity的选项， “in-stream” 或者 ”linear” 表示在视频开始，中间或者结束插入的视频广告， 用户被强制观看广告内容。 “overlay”或者”non-linear”指那种在视频内容之上的广告。

这个实行是可选的， 竞拍者可以根据其是否在竞价请求中出现按照如下规则解析：

• 如果该值没有被设置， 任何广告（不管是否是linear)都可以在竞价响应中出现。
• 如果被设置了，仅指定类型的关高可以在竞价响应中出现。

读者需要注意：该表中的值继承自IAB QAG.实现者应当与最新的QAG值保持一致。

5.8 视频竞价响应协议

下表罗列了交易平台需要支持的视频广告竞价响应协议。

5.9 视频播放方式

下表罗列了不同种类的视频播放方式

5.10 视频播放延时

下表罗列了视频播放延时的各种选项。如果播放延时值大于0， 表示视频中广告且该值表示广告开始播放的延时。

5.11 视频质量

下表罗列了视频质量选项。这些值在IAB的long-form-video-final.pdf中有定义。

5.12 VAST 伴随类型

下表罗列了允许的视频伴随广告的类型。表格继承自IAB VAST2.0+, 更多信息参考www.iab.net/vast.

5.13 内容传输方式

下表罗列了视频内容传输的不同方式。

5.14 内容上下文

下表罗列了广告可能出现的内容类型选项。 该表继承自QAG,实现者应当与QAG的相关描述保持一致。

5.15 QAG 媒体级别

下表罗列了基于QAG的媒体内容级别。详细信息参考http://www.iab.net/ne_guidelines.

5.16 位置类型

下表罗列了位置信息来源相关的选项。

5.17 设备类型

下表罗列了广告展示所在的视频类型。

OpenRTB规范版本2.2区分了手机和平板， 建议任何竞价者添加对2.2的支持， 可以将1等价4&5解析。 该表继承自QAG,实现者应当与QAG的相关描述保持一致。

5.18 Connection Type

下表罗列了设备网络连接方式的各种选项。

5.19 No-Bid Reason Codes

下表罗列了竞拍者不能为交易平台的展示请求提供广告的原因类型。 | 值 | 描述 | 中文释义 | | —- | —- | —- | | 0 | Unknown Error | 未知错误 | | 1 | Technical Error | 技术错误 | | 2 | Invalid Request | 非法请求 | | 3 | Known Web Spider | 已知的网络爬虫 | | 4 | Suspected Non-Human Traffic | 怀疑非人为请求 | | 5 | Cloud, Data Center, or Proxy IP | 来自云，数据中心或者代理的IP | | 6 | Unsupported Device | 不支持的设备类型 | | 7 | Blocked Publisher or Site | 来自受限展示者或站点 | | 8 | Unmatched User | 用户不匹配 |

6. 竞价请求/响应 示例

6.1 Github 仓库地址

官方的OpenRTB Github仓库地址现在包括一系列已经验证的请求示例，实现者可以在实现协议的时候作为参考。 https://github.com/openrtb/examples

6.2 验证器

OpenRTB提供了一个用于验证请求及响应json是否是有效openrtb请求或响应json的库.源文档给出的链接已经不能使用（404），可能的Github地址如下： https://github.com/openrtb/openrtb2x/tree/2.0/openrtb-validator

6.3 竞价请求

6.3.1 Banner请求示例

以下是一个Banner广告的竞价请求示例，示例中也包含了一些可选参数。

{
    "id": "80ce30c53c16e6ede735f123ef6e32361bfc7b22",
    "at": 1,
    "cur": [
        "USD"
    ],
    "imp": [
        {
            "id": "1",
            "bidfloor": 0.03,
            "banner": {
                "h": 250,
                "w": 300,
                "pos": 0
            }
        }
    ],
    "site": {
        "id": "102855",
        "cat": [
            "IAB3-1"
        ],
        "domain": "www.foobar.com",
        "page": "http://www.foobar.com/1234.html ",
        "publisher": {
            "id": "8953",
            "name": "foobar.com",
            "cat": [
                "IAB3-1"
            ],
            "domain": "foobar.com"
        }
    },
    "device": {
        "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13
(KHTML, like Gecko) Version/5.1.7 Safari/534.57.2",
        "ip": "123.145.167.10"
    },
    "user": {
        "id": "55816b39711f9b5acf3b90e313ed29e51665623f"
    }
}

6.3.2 可伸展广告物料

本示例是第一个示例的改进版，增加了一些用于描述可伸展广告物料支持的参数， 并使用“Data Provider 1”传输用户相关的信息。

{
    "id": "123456789316e6ede735f123ef6e32361bfc7b22",
    "at": 2,
    "cur": [
        "USD"
    ],
    "imp": [
        {
            "id": "1",
            "bidfloor": 0.03,
            "iframebuster": [
                "vendor1.com",
                "vendor2.com"
            ],
            "banner": {
                "h": 250,
                "w": 300,
                "pos": 0,
                "battr": [
                    13
                ],
                "expdir": [
                    2,
                    4
                ]
            }
        }
    ],
    "site": {
        "id": "102855",
        "cat": [
            "IAB3-1"
        ],
        "domain": "www.foobar.com",
        "page": "http://www.foobar.com/1234.html",
        "publisher": {
            "id": "8953",
            "name": "foobar.com",
            "cat": [
                "IAB3-1"
            ],
            "domain": "foobar.com"
        }
    },
    "device": {
        "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13
(KHTML, like Gecko) Version/5.1.7 Safari/534.57.2",
        "ip": "123.145.167.10"
    },
    "user": {
        "id": "55816b39711f9b5acf3b90e313ed29e51665623f",
        "buyeruid": "545678765467876567898765678987654",
        "data": [
            {
                "id": "6",
                "name": "Data Provider 1",
                "segment": [
                    {
                        "id": "12341318394918",
                        "name": "auto intenders"
                    },
                    {
                        "id": "1234131839491234",
                        "name": "auto enthusiasts"
                    },
                    {
                        "id": "23423424",
                        "name": "data-provider1-age",
                        "value": "30-40"
                    }
                ]
            }
        ]
    }
}

6.3.3 手机信息

本示例使用Device对象来描述移动手机设备， 以及一个App对象来描述该请求所来自的移动端应用。

{
    "id": "IxexyLDIIk",
    "at": 2,
    "bcat": [
        "IAB25",
        "IAB7-39",
        "IAB8-18",
        "IAB8-5",
        "IAB9-9"
    ],
    "badv": [
        "apple.com",
        "go-text.me",
        "heywire.com"
    ],
    "imp": [
        {
            "id": "1",
            "bidfloor": 0.5,
            "instl": 0,
            "tagid": "agltb3B1Yi1pbmNyDQsSBFNpdGUY7fD0FAw",
            "banner": {
                "w": 728,
                "h": 90,
                "pos": 1,
                "btype": [
                    4
                ],
                "battr": [
                    14
                ],
                "api": [
                    3
                ]
            }
        }
    ],
    "app": {
        "id": "agltb3B1Yi1pbmNyDAsSA0FwcBiJkfIUDA",
        "name": "Yahoo Weather",
        "cat": [
            "IAB15",
            "IAB15-10"
        ],
        "ver": "1.0.2",
        "bundle": "com.yahoo.wxapp",
        "storeurl": "https://itunes.apple.com/id628677149",
        "publisher": {
            "id": "agltb3B1Yi1pbmNyDAsSA0FwcBiJkfTUCV",
            "name": "yahoo",
            "domain": "www.yahoo.com"
        }
    },
    "device": {
        "dnt": 0,
        "ua": "Mozilla/5.0 (iPhone; CPU iPhone OS 6_1 like Mac OS X)
AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A334 Safari/7534.48.3",
        "ip": "123.145.167.189",
        "ifa": "AA000DFE74168477C70D291f574D344790E0BB11",
        "carrier": "VERIZON",
        "language": "en",
        "make": "Apple",
        "model": "iPhone",
        "os": "iOS",
        "osv": "6.1",
        "js": 1,
        "connectiontype": 3,
        "devicetype": 1,
        "geo": {
            "lat": 35.012345,
            "lon": -115.12345,
            "country": "USA",
            "metro": "803",
            "region": "CA",
            "city": "Los Angeles",
            "zip": "90049"
        }
    },
    "user": {
        "id": "ffffffd5135596709273b3a1a07e466ea2bf4fff",
        "yob": 1984,
        "gender": "M"
    }
}

6.3.4 视频广告示例

以下示例展示了一个包含两个附加广告（其中一个可伸展）的视频广告展示， 此外， 视频内容本身在”content”对象中描述，对于本示例一些特殊需要注意的点如下：

• protocol: 仅VAST2.0和VAST3.0允许。
• sequence: 没有被指定，所以默认为1.
• battr: 对于视频以及它的附加广告， 用户交互以及提示型广告（分别是13和14）被显式的限制。
• pos: 展示了本次展示是“在内容之上”的广告。
• api: 标识VPAID 1.0容器被显式支持。因此，VPAID支持的 mime-type仅仅是”application/x-shockwave-flash”以及“application/javascript”.需要注意有一个隐式的限制是对于不同的mime-type有哪些类型的协议是允许的。Javascript支持在VPAID2.0之前是没有指定的， 而VPAID1.0和2.0都支持Flash.
• companiontype: 标识只有静态和HTML资源被允许。

{
    "id": "1234567893",
    "at": 2,
    "tmax": 120,
    "imp": [
        {
            "id": "1",
            "bidfloor": 0.03,
            "video": {
                "w": 640,
                "h": 480,
                "pos": 1,
                "startdelay": 0,
                "minduration": 5,
                "maxduration": 30,
                "maxextended": 30,
                "minbitrate": 300,
                "maxbitrate": 1500,
                "api": [
                    1,
                    2
                ],
                "protocols": [
                    2,
                    3
                ],
                "mimes": [
                    "video/x-flv",
                    "video/mp4",
                    "application/x-shockwave-flash",
                    "application/javascript"
                ],
                "linearity": 1,
                "boxingallowed": 1,
                "playbackmethod": [
                    1,
                    3
                ],
                "delivery": [
                    2
                ],
                "battr": [
                    13,
                    14
                ],
                "companionad": [
                    {
                        "id": "1234567893-1",
                        "w": 300,
                        "h": 250,
                        "pos": 1,
                        "battr": [
                            13,
                            14
                        ],
                        "expdir": [
                            2,
                            4
                        ]
                    },
                    {
                        "id": "1234567893-2",
                        "w": 728,
                        "h": 90,
                        "pos": 1,
                        "battr": [
                            13,
                            14
                        ]
                    }
                ],
                "companiontype": [
                    1,
                    2
                ]
            }
        }
    ],
    "site": {
        "id": "1345135123",
        "name": "Site ABCD",
        "domain": "siteabcd.com",
        "cat": [
            "IAB2-1",
            "IAB2-2"
        ],
        "page": "http://siteabcd.com/page.htm",
        "ref": "http://referringsite.com/referringpage.htm",
        "privacypolicy": 1,
        "publisher": {
            "id": "pub12345",
            "name": "Publisher A"
        },
        "content": {
            "id": "1234567",
            "series": "All About Cars",
            "season": "2",
            "episode": 23,
            "title": "Car Show",
            "cat": [
                "IAB2-2"
            ],
            "keywords": "keyword-a,keyword-b,keyword-c"
        }
    },
    "device": {
        "ip": "64.124.253.1",
        "ua": "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.16)
Gecko/20110319 Firefox/3.6.16",
        "os": "OS X",
        "flashver": "10.1",
        "js": 1
    },
    "user": {
        "id": "456789876567897654678987656789",
        "buyeruid": "545678765467876567898765678987654",
        "data": [
            {
                "id": "6",
                "name": "Data Provider 1",
                "segment": [
                    {
                        "id": "12341318394918",
                        "name": "auto intenders"
                    },
                    {
                        "id": "1234131839491234",
                        "name": "auto enthusiasts"
                    }
                ]
            }
        ]
    }
}

6.3.5 带有直接交易规则的私有广告市场

以下是一个带有直接交易规则的Banner广告竞价请求示例，其中包含了一些可选参数。

{
    "id": "80ce30c53c16e6ede735f123ef6e32361bfc7b22",
    "at": 1,
    "cur": [
        "USD"
    ],
    "imp": [
        {
            "id": "1",
            "bidfloor": 0.03,
            "banner": {
                "h": 250,
                "w": 300,
                "pos": 0
            },
            "pmp": {
                "private_auction": 1,
                "deals": [
                    {
                        "id": "AB-Agency1-0001",
                        "at": 1,
                        "bidfloor": 2.5,
                        "wseat": [
                            "Agency1"
                        ]
                    },
                    {
                        "id": "XY-Agency2-0001",
                        "at": 2,
                        "bidfloor": 2,
                        "wseat": [
                            "Agency2"
                        ]
                    }
                ]
            }
        }
    ],
    "site": {
        "id": "102855",
        "domain": "www.foobar.com",
        "cat": [
            "IAB3-1"
        ],
        "page": "http://www.foobar.com/1234.html",
        "publisher": {
            "id": "8953",
            "name": "foobar.com",
            "cat": [
                "IAB3-1"
            ],
            "domain": "foobar.com"
        }
    },
    "device": {
        "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13
(KHTML, like Gecko) Version/5.1.7 Safari/534.57.2",
        "ip": "123.145.167.10"
    },
    "user": {
        "id": "55816b39711f9b5acf3b90e313ed29e51665623f"
    }
}

6.3.6 原生广告

以下是一个Native广告的竞价请求示例， 与6.3.1节描述的请求示例有点像，需要注意的是native对象中的request属性包含的是一个已编码的native广告请求字符串。字符串的具体格式需要符合Native广告请求规范，ver属性指明了Naitve广告符合的规范版本是1.0.

{
    "id": "80ce30c53c16e6ede735f123ef6e32361bfc7b22",
    "at": 1,
    "cur": [
        "USD"
    ],
    "imp": [
        {
            "id": "1",
            "bidfloor": 0.03,
            "native": {
                "request": "...Native Spec request as an encoded string...",
                "ver": "1.0",
                "api": [
                    3
                ],
                "battr": [
                    13,
                    14
                ]
            }
        }
    ],
    "site": {
        "id": "102855",
        "cat": [
            "IAB3-1"
        ],
        "domain": "www.foobar.com",
        "page": "http://www.foobar.com/1234.html ",
        "publisher": {
            "id": "8953",
            "name": "foobar.com",
            "cat": [
                "IAB3-1"
            ],
            "domain": "foobar.com"
        }
    },
    "device": {
        "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.13
(KHTML, like Gecko) Version/5.1.7 Safari/534.57.2",
        "ip": "123.145.167.10"
    },
    "user": {
        "id": "55816b39711f9b5acf3b90e313ed29e51665623f"
    }
}

6.4 竞价响应

6.4.1 在胜出通知响应中返回的广告内容。

以下展示了在胜出通知响应中返回的竞价响应， 对于该次展示的竞拍价格是$9.43 CPM.

{
    "id": "1234567890",
    "bidid": "abc1123",
    "cur": "USD",
    "seatbid": [
        {
            "seat": "512",
            "bid": [
                {
                    "id": "1",
                    "impid": "102",
                    "price": 9.43,
                    "nurl": "http://adserver.com/winnotice?impid=102",
                    "iurl": "http://adserver.com/pathtosampleimage",
                    "adomain": [
                        "advertiserdomain.com"
                    ],
                    "cid": "campaign111",
                    "crid": "creative112",
                    "attr": [
                        1,
                        2,
                        3,
                        4,
                        5,
                        6,
                        7,
                        12
                    ]
                }
            ]
        }
    ]
}

6.4.2 VAST XML Document Returned Inline

以下是返回VAST文档格式的广告竞价响应示例。示例中需要注意的点如下：

• 展示的竞拍价格是￥3.00CPM
• Note that since there both a win notice URL and an inline VAST document in the adm attribute, which constitutes the ad markup. The win notice is still called, but if it were to return markup it would be ignored in favor of the contents of the adm attribute

{
    "id": "123",
    "seatbid": [
        {
            "bid": [
                {
                    "id": "12345",
                    "impid": "2",
                    "price": 3,
                    "nurl": "http://example.com/winnoticeurl",
                    "adm": "%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22utf-
8%22%3F%3E%0A%3CVAST%20version%3D%222.0%22%3E%0A%20%20%20%20%3CAd%20id%3D%2212345%22
%3E%0A%20%20%20%20%20%20%20%20%3CInLine%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3C
AdSystem%20version%3D%221.0%22%3ESpotXchange%3C%2FAdSystem%3E%0A%20%20%20%20%20%20%2
0%20%20%20%20%20%20%20%20%20%3CAdTitle%3E%3C!%5BCDATA%5BSample%20VAST%5D%5D%3E%3C%2F
AdTitle%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3CImpression%3Ehttp%3A
%2F%2Fsample.com%3C%2FImpression%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%
20%3CDescription%3E%3C!%5BCDATA%5BA%20sample%20VAST%20feed%5D%5D%3E%3C%2FDescription
%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3CCreatives%3E%0A%20%20%20%20
%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3CCreative%20sequence%3D%221%22%20i
d%3D%221%22%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%
20%20%3CLinear%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%
20%20%20%20%20%20%20%3CDuration%3E00%3A00%3A30%3C%2FDuration%3E%0A%20%20%20%20%20%20
%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3CTrackingEvents%
3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%
20%20%3C%2FTrackingEvents%3E%20%20%20%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2
0%20%20%20%20%20%20%20%20%20%20%20%20%20%3CVideoClicks%3E%0A%20%20%20%20%20%20%20%20
%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3CClickThro
ugh%3E%3C!%5BCDATA%5Bhttp%3A%2F%2Fsample.com%2Fopenrtbtest%5D%5D%3E%3C%2FClickThroug
h%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2
0%20%20%3C%2FVideoClicks%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20
%20%20%20%20%20%20%20%20%20%20%3CMediaFiles%3E%0A%20%20%20%20%20%20%20%20%20%20%20%2
0%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3CMediaFile%20delivery
%3D%22progressive%22%20bitrate%3D%22256%22%20width%3D%22640%22%20height%3D%22480%22%
20type%3D%22video%2Fmp4%22%3E%3C!%5BCDATA%5Bhttp%3A%2F%2Fsample.com%2Fvideo.mp4%5D%5
D%3E%3C%2FMediaFile%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2
0%20%20%20%20%20%20%20%20%3C%2FMediaFiles%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%
20%20%20%20%20%20%20%20%20%20%20%20%3C%2FLinear%3E%0A%20%20%20%20%20%20%20%20%20%20%
20%20%20%20%20%20%20%20%20%20%3C%2FCreative%3E%0A%20%20%20%20%20%20%20%20%20%20%20%2
0%20%20%20%20%3C%2FCreatives%3E%0A%20%20%20%20%20%20%20%20%3C%2FInLine%3E%0A%20%20%2
0%20%3C%2FAd%3E%0A%3C%2FVAST%3E"
                }
            ]
        }
    ]
}

6.4.3 Direct Deal Ad Served on Win Notice

以下示例展示了一个在胜出通知响应中提供广告内容的竞价响应。 此次展示的竞标价格是$5.00 CPM, 且依赖一个直接交易规则。

{
    "id": "1234567890",
    "bidid": "abc1123",
    "cur": "USD",
    "seatbid": [
        {
            "seat": "512",
            "bid": [
                {
                    "id": "1",
                    "impid": "102",
                    "price": 5,
                    "dealid": "ABC-1234-6789",
                    "nurl": "http: //adserver.com/winnotice?impid=102",
                    "adomain": [
                        "advertiserdomain.com"
                    ],
                    "iurl": "http: //adserver.com/pathtosampleimage",
                    "cid": "campaign111",
                    "crid": "creative112",
                    "adid": "314",
                    "attr": [
                        1,
                        2,
                        3,
                        4
                    ]
                }
            ]
        }
    ]
}

6.4.4 直接在竞价请求中返回原生广告

以下是一个返回Native广告的竞价响应，adm属性包含了一个Native广告竞价响应的字符串，该字符串的内容需符合Native广告OpenRTB规范。 另外， 如果广告内容是在胜出通知的响应中提供的话， 就可以不提供adm属性。

7. 实现注意事项

以下部分会简要介绍某些特定的对象和域是如何被解析以及实现的。

7.1 COPPA Regulation Flag

美国联邦交易委员会已经修改了儿童在线隐私保护法案的规则， 从2013年7月1日起生效。该提议对网站和相关的服务进行了明确的分类，如下：

• 直接面向低于13岁的用户。
• 从低于13岁的群体的用户收集信息。

联邦委员会同时撰写了一个便于理解的FAQ, 你可以在这里找到： http://business.ftc.gov/documents/Complying-with-COPPA-Frequently-Asked-Questions

联邦委员会的CTO, Steve Bellovin, 在2013年1月发表了一片博文， 主张为该协议建立一套统一的标准， 你可以在这里找到(翻译时本文已经被删除)： https://techatftc.wordpress.com/2013/01/02/coppa-and-signaling/

影响

FAQ中也特别指出在OpenRTB中指明是“个人信息”的相关领域信息也不能被收集。

• 足够确认街道名称或者城市名称的地理位置信息。
• 可以跨站点或者在线服务能够长时间稳定识别用户的信息。

实现者建议

OpenRTB的交易平台和竞价者应当：

• 为站点提供设施，让他们能标识自己是“直接面向儿童的”。
• 实现规则对象扩展。
• 在广告活动中提供设施来标明其是否是针对儿童。
• 降低地理位置信息的精确度，仅仅用于支持日志或者数据传输。
• 根据使用状况合理控制用户标识的提取和同步。

7.2 PMP & Direct Deals

7.3 No-Bid Signaling

附录A. 附加信息

附录B. 规范版本更新日志