时间：2018.5.10
译者：孙淼
重点：落实安全供应链准则 ，IAB 201709发布的公众意见征求草案
IAB原文链接：https://iabtechlab.com/wp-content/uploads/2017/09/OpenRTB-3.0-Draft-Framework-for-Public-Comment.pdf
简介
OpenRTB3.0版本是自从2010年成立以来最大的翻修版本。本次大规模更新的目的是满足市场对于安全性、透明性、 验证性和程序化广告信任度。尤其是以下三个重点更新的建议：
- 支持Supply Chain的签名功能，能够使需求方（Demand端）在bid request中对这些签名进行验证（公钥验证），确保信息不被篡改；
- 支持新的广告对象模型(Ad-COM)，为发布商（Publisher端）提供更安全的创意控件；
- 标准框架升级
随着OpenRTB的升级，IAB Tech Lab也同步更新了跨屏协议的开发。这个文档也不是一个完成的说明。本文档稍后会详细介绍OpenRTB 3.0完整规范的发布时间表。我们已经发布了这些重要的更新提案，以延长公众意见征询期。我们鼓励业界就3.0的工作流程和技术实施提供反馈意见。
RTB的现状挑战: RTB需要怎么进化？
RTB创建之初是个简单的世界，供应链短、欺诈机会更少。伴随着如今的复杂且多样的供应链，仍存在广告展现量的欺诈机会，包括：
- 域欺诈:把域名改成更有价值的域名
- 地域欺诈:把地理位置改成更有价值的地方
- 用户ID欺诈:把Device id或是Buyer id改成商业化历史比较好的用户ID
- 设备欺诈:设备标识改成商业化历史表现更好的型号，例如更高端的手机等
不幸的是，在现在的标准协议里很难去检测这些类型的欺诈。这些以及其他类型的欺诈行为削弱了广告主获得的价值以及优质发行商所获得的收益，从而侵蚀了整个生态系统的平衡。
相反，由于传统展示广告传输的不透明方式，发布商和发布商平台几乎无法控制他们在其网站上投放的广告素材类型。有时许多不受欢迎的广告会出现在发布商的网站中，例如:
-
重负载
-
非品牌安全广告
-
木马
这些行为会导致糟糕的用户体验和用户安装广告拦截器，从而降低用户的信任度并进一步侵蚀发布商获利。此外，欧盟的一般数据保护条例（GDPR）等新的立法可能难以在传统显示领域实施。
OpenRTB 3.0试图扩展先前的解决方案（如支付链和最近的授权数字卖家ads.txt），以解决这些问题并改善程序化各方的利益（用户，发布者和广告商）。
随着OpenRTB 3.0的推进，我们鼓励买家开始要求其合作伙伴和发布商提供认证，以便向其需求合作伙伴要求安全的高性能广告。
A. OpenMedia规范架构
OpenMedia是IAB Tech Lab程序化标准观点和方法论的规范架构，这种方法既是概念性的（提高对规范架构的理解）又是务实的（作为指示新标准最有效的工具）.OpenMedia描述了一种分层方法（类似于OSI网络模型）来组织交易规范和领域规范 ； 或者简单地说,一个关于如何交易的层，一个描述交易的层。
[图片上传失败...(image-1bd2bf-1525948322506)]
通过使用OpenMedia作为所有程序化标准的基准，在交易规范中和允许可快速扩展的新媒体对象中创建规则。
第3层和第4层的规范名称都由IAB Tech Lab命名的。OpenRTB，OpenDirect一直是长久以来的协议。在架构图中有两个新规范：广告管理规范（Ad Management Specification）和广告通用对象模型(AdCOM)。广告管理规范阐述了标准的方式来传达广告规范的信息（包括广告审核）。AdCOM阐述了通过RTB交易以及将来的OpenDirect进行交易的广告、素材、媒体渠道。解构领域层对象模型可以让发布者控制要在其页面上投放的广告素材。更多细节可以在D区Protocol layers, G区Domain Layer, 和J区 Ad Management查看。
B.OpenRTB3.0更新点
本文件的目标是强调OpenRTB协议的重要更新，以便更好地支持透明的供应链和创新的程序化市场。请参阅下文，了解OpenRTB 3.0更新建议的概述，以及这些更新为何对数字广告业至关重要。
image
C.复杂的数字广告供应链
OpenRTB通常被认为是交易平台和需求方之间的交互，有时也被认为是拍卖商与和竞价者之间的交互。这是通过v2.x版本的基础模型。 如果关注需求方平台和交易平台-N，那么在下图中可以很好地看到这一点; 假设这是图片中唯一的交换，并且发布商直接供应需求。
image
如上图，OpenRTB定义了从exchange发送bid request给需求方销售微商品（例如广告展现），在response中收集竞价信息，并根据竞价规则确定胜出者。如果标记未包含在竞价中，则可能会要求提供标记。根据交易商业规则可进行销售时，exchange通知竞价成功买家重要数据例如结算价格。其它参与竞价者被告知竞价失败。
然而如今的生态系统更为复杂。Header bidding变得常见，这导致发布商或用户代理处被视为不再是唯一的决定因素。拥有多个供应链中介机构也变得很普遍; 也许是一个中介或交易平台，除了自己的直接整合需求方之外，还使用另一个交易平台所作为需求来源。
这些架构在完整的参考模型图中进行了描述，其中每个中介可以使用其他中介（在图中的右侧）作为需求方来源，并且每个中介可以与发布商具有直接关系或者向上游的中介竞价（在图中的左侧）。 请注意，尽管该图显示了N个exchange的交互情况，但考虑实际情况（例如延迟）往往会有自然限制。
OpenRTB的bid requests, bid responses和events 可以在任何实体间进行实施，尽管发布商的聚合（这里描述成Exchange-1）常常是不标准化的。一个给定的实体可能会也可能不会意识到更大的供应链，但这个链可能会因不同的发布商而有所不同。 无论如何，OpenRTB都假设一个既定的实体中只有一个商业关系，至少在既定交易的情况下，其左侧（供应方）和右侧（需求方）可直接实施。
私人市场交易可以说明这一点的含义，从第一人称的角度来讲这个参考模型中的实体:
- 假设我收到的所有结算或损失的事件都来自我的供应方合作伙伴（即我左侧的实体）的授权；
- 我有责任将结算或损失事件仅发送给我的需求方合作伙伴（即我右侧的聚合实体）；
- 我代理和执行我的供应方和需求方合作伙伴（即，我的左侧和右侧的实体）之间的交易。 没有其他实体有义务，将我的交易进一步向上或向下扩展或传播。
D. OpenRTB协议层
自OpenRTB v3.0开始采用分层方法，为了帮助对象重复使用不同规范，并能使规范向各个方面能够以不同的节奏进化。 下图说明了这个模型。简单的说，第1层在各方字节中移动，第2层表示这些字节的编码，第3层详细说明使用此编码的交易，第4层描述了被交易的对象。
image
以下小节将指定这些层与OpenRTB规范相关。
第1层:交易层
通信（Communications）
Exchange和需求方的基础协议是HTTP.特别的是，在bid request中发送HTTP POST更好的有效负载回传的HTTP GET。呼叫返回内容（例如bid response）应该返回HTTP码200.响应于有效请求而没有返回内容的呼叫应当返回HTTP204。
版本头 （Version Headers）
带有自定义参数的OpenRTB 版本号必须在bid request中的header中被传输，这将允许竞价者在解析request前识别被包含信息的版本号。这个版本应该被描述成<major>.<minor>，例x-openrtb-version: 3.0
除此之外，仍然建议在response中带有版本号相同格式的HTTP header去响应。然而，假设任何response将兼容request的版本，并且版本支持在各方之间先被使用。
最佳实践:改善连接效果的最简单和最有效的方式之一是启用HTTP持久连接，也被熟知叫做Keep-Alive.通过降低在两方交互中连接管理开销和CPU使用率，对整体性能产生非常深远影响。
安全性 （Security）
在OpenRTB 3.0中，Https是OpenRTB合规性所必须使用的，用于附加的exchange的安全性/竞价通信，因此要求exchange和竞价者都要支持HTTPS，并加密传输信息。
第2层:格式层
形式（Representation）
JOSN是bid request和bid response数据有效负载的默认格式。JOSN用于此是因为它的可读性和简洁性。
可选地，exchange也可以提供二进制格式（例如，压缩的JSON，ProtoBuf，Avro等），其在传输时间和带宽方面可以更高效。IAB Tech Lab可以为这些或其他格式提供参考实施方案。 如果可用，强烈建议使用这些IAB参参考实施方案来减少集成时的多样性。
Bid request指定使用Content-Type HTTP标头将作为MIME类。如图所示，标准JSON表示的mime类型是“application / json”。 出价响应的格式必须与出价请求相同。例 Content-Type: application/json
如果替代二进制被使用，exchange/SPP应指定内容类型。例如：“avro/binary” or “application/x-protobuf”。如果内容类型丢失，竞价者应假设类型是“application/json”，除非不同的默认值已经被exchange删除。
编码（Encoding）
在exchang和需求方间压缩数据是非常重要的，压缩大大减少了传输数据的数据量，从而为exchange和需求方节省了网络带宽。为了充分的实现这个节省，exchange发送的bid request和需求方回传的bid response都需要压缩数据。
使用标准的HTTP 1.1机制可以对bid response进行压缩。大多数Web服务器已经支持response内容的gzip压缩，因此它是理想的选择。Exchange发送信号想要使response被压缩，它应该设置标准的HTTP 1.1 Accept-Encoding标头。例如Accept-Encoding: gzip
这个标头表示exchange要求需求方response接受gzip的压缩。如果需求方服务器支持并且配置正确，它将自动响应gzip的编码内容。这将使用标准的HTTP 1.1内容编码头来指示。例如Content-Encoding: gzip
为了能在bid request中压缩，首先在exchange和需求方要达成一致并都支持。这与使用自定义数据格式时类似，因为exchange在发送bid request之前必须知道格式和编码。如果需求方支持，exchange应通过设置HTTP 1.1 Content-Encoding标头指示它正在发送gzip压缩的bid request。使用的编码值应该是“gzip”。例Accept-Encoding: gzip
如果未设置该头部，则假定请求内容未被编码。在HTTP1.1中，Content-Encoding header 常被用来响应内容。然而，通过将这个头部用于请求内容，我们也能够指定一个请求被压缩，而不管所使用的数据格式如何。
第3层:交易层
交易层是RTB竞价协议的核心。它定义了在exchange和竞价者之间的商业协议，或更通常的说，是供应方中介或是需求方聚合。
有关完整的详细信息，请参阅本文档的规格部分。
第4层:领域层
领域层定义了交易层运行的对象。在一个典型的广告竞价中，bid request在两个地方包含领域对象。第一个，整个请求将包含描述销售上下文的域对象，例如网站或应用程序，设备和用户。第二个，每个被销售的项目都要包含域对象，例如展示细节，规格和限制。响应中的每个出价都会包含域对象，用于定义在赢得拍卖时将交付给用户的广告素材。因为域层规范的版本能独立于交易层变化，在交易层的root对象包括域规范和版本规范。这也是重要的，因为exchange和需求方的版本信息会随着时间的变化而不同。
（未完待续，翻译到原OpenRTB 3.0 Draft Framework for Public Comment文档12页）
网友评论