正如我们在本书之前所述，在线广告行业由许多广告技术平台组成，如广告服务器、DSP、SSP和广告网络。
这些广告技术平台的目标各不相同——一些负责提供广告，而另一些则旨在帮助广告商和出版商买卖在线媒体。
在本章中，我们将了解推动这些AdTech平台的媒体购买过程。

主要的媒体购买过程

image.png

手动购买媒体

在网络广告的早期，广告商和出版商之间的广告买卖是一个非常手工的过程。
广告商将与出版商合作，直接向他们发送广告标签。因为没有涉及任何技术平台，所以没有任何方法来定义目标或生成报告。
幸运的是，广告服务器的引入解决了这一问题，并启动了编程媒体购买革命。

编程媒体购买

编程意味着什么？
编程一词对不同的人可能意味着不同的事情，但这里有一个简单而明确的定义：
编程是指使用技术、算法和数据以自动化方式买卖在线媒体。
与之相比，人工购买广告的方式不涉及技术或算法的使用，而是人与人之间的交易。
以下是一些示例，说明了手动购买的介质和程序购买的介质的执行过程之间的差异：

手动购买媒体

image.png

手动媒体事务的执行：
广告客户和出版商签署插入订单（IO），这是一份定义活动条款和条件的合同，如投放日期和位置。
广告客户将其广告标签发送给出版商。这些广告标签是将在发布者网站上显示广告的HTML片段。
出版商将广告客户的广告标签添加到其网站，并开始广告活动。

编程媒体购买

image.png

编程媒体事务的执行：
广告客户和出版商签署插入订单（IO），就像他们在手动媒体交易中所做的那样。
然后，广告客户的AdOps团队在广告客户的广告服务器中配置活动，并将广告标签发送给发布者。
出版商的AdOps团队设置活动，将广告客户的广告标签添加到出版商的广告服务器并开始活动。
虽然上述过程看起来很相似，但使用广告服务器的主要优势是，与手动购买媒体相比，它们提供了额外的好处，例如定位、放置、报告，以及消除了繁琐和重复的任务。
例如，与发布者在其网站上添加广告客户的广告标签（该标签在页面加载时仅显示广告）不同，广告标签可以重定向到广告客户的广告服务器。这样做的好处是，广告服务器可以根据许多因素（例如位置和设备）决定向用户显示哪个广告。
手动购买和编程购买媒体的另一个关键区别是，我们可以在活动运行时启动和修改活动的速度。
在程序化的AdTech平台（如DSP）中创建和启动活动只需几分钟。如果没有编程技术，活动开始前可能需要几天时间。
此外，在没有编程平台的情况下手动购买媒体时，对活动的每次更改都必须经过出版商的AdOps团队，这可能需要几天的时间来实现。当在programmatic media-buying platforms调整活动时，AdOps所做的更改几乎实时反映出来。
这一点变得非常重要，因为品牌必须对任何变化做出快速反应，并且可以每小时或每天对活动进行优化。

活动优化基础：手动与算法

营销活动优化涉及对营销活动进行更改，以提高其性能并使媒体购买更经济。
在一场活动中，有许多方面可以改变，例如目标定位标准和广告本身。
可以手动或通过算法优化活动。

手动优化

手动优化通常涉及广告商调整其CPC、CPA和CPM出价，通常每天进行。
基本上，广告客户使用由广告平台提供的所有不同维度分解的数据，例如地理位置、性别、兴趣、设备类型等，并使用这些维度来扩展或限制针对特定群体的目标。
通过这样做，广告客户创建了非常具体的目标定位标准，提供了最佳的点击率、点击率或转换率。
为了进行优化，广告商利用数据确定要调整的出价，包括：
广告的CTR
广告产生的点击次数
广告产生的曝光数量

以下是媒体买家可以用来手动优化活动的流程：

• 从按一个或多个维度分解数据开始，例如地理位置、设备、发布者域、时间、运营商等。
• 过滤掉不重要的数据。例如，只有产生少量印象或点击的广告，或按重要数据过滤的广告，例如产生最多曝光或点击的广告。
• 查看性能最佳和最差的值，例如设备类型或地理位置。
• 此外，您可以查看某些指标，这取决于您想要优化的内容。例如电子书下载的有效千次曝光成本（eCPM）或销售或营销漏斗中较低的成本，例如每合格潜在客户的成本。
• 将表现不佳或根本没有表现的领域（即排除在目标之外）列入黑名单。

广告客户可以使用许多其他技术来优化活动，包括：

• 运行A/B测试：更改creatives并运行测试，以查看哪个变体表现更好。
• 个性化创意（动态创意）：改变创意的信息或视觉方面，使其与不同的细分市场更相关。例如，可以向creatives添加城市名称，使其与用户的位置相匹配。
• 实验不同的流量来源：通过实验广告客户预算的一小部分（5-10%），并相互比较eCPA、eCPM等指标，了解不同来源（例如网站）、媒体（例如显示和视频广告）和AdTech平台的表现。

自动优化

自动优化涉及使用算法为优化过程提供动力。

许多AdTech平台都有内置算法，可以提供某种自动优化功能。

成功的自动优化的关键组成部分是历史数据。只有当算法拥有适当数量和质量的数据来支持它们时，它们才能做出决策和优化。

Programming direct

Programming direct（又名程序保证、程序保留、自动保证）是一种买卖媒体的方法，但与RTB不同，不举行拍卖。
相反，广告客户和出版商就库存和CPM达成一致，然后通过使用AdTech平台以编程方式处理其余过程。
Programming direct与互联网之前甚至在线广告早期的媒体买卖方式非常相似，但由于使用了广告技术，它提供了更大的规模。

image.png

编程直接过程类似于在电子商务平台上下订单，但不是购买产品，而是购买媒体库存。
过程如下所示：

• 广告客户浏览网站目录。
• 它选择地点、投放日期和曝光量。
• 它配置了creatives 和额外的跟踪像素。
• 它在平台上下订单。
• 发布者审核并验证活动。
• 除审计外，订单的执行不需要AdOps团队的额外参与。

Programming direct的主要优点是能够以溢价获得溢价库存。
尽管与其他媒体购买流程（如RTB）相比，Programming direct意味着广告商可能需要支付更高的CPM，但他们能够在公开RTB拍卖中提供广告空间之前获得溢价库存。这使他们能够接触到在其他情况下可能无法接触到的目标受众。
对于出版商来说，这会导致更高的CPM。
对于广告商来说，Programming direct的主要缺点是可用的目标选择较少，因为他们只是根据网站的上下文和已知受众来显示广告。
例如，一家银行可以在金融网站上展示关于其新银行账户的广告。
与RTB相比，同一家银行可以在许多不同的网站上只向访问过其网站的人展示相同的广告。
对于出版商来说，主要缺点是他们可能无法通过Programming direct销售其所有库存。然而，许多出版商设立了一个瀑布，以确保他们销售尽可能多的库存。下面将对此进行详细介绍。

实时投标（RTB）

90年代中后期出现了许多广告网络，以至于到了21世纪中期，市场上出现了数百个广告网络。
然而，广告网络很快发现自己成了广告活动不足或过量的受害者。

image.png

出版商很快意识到他们的广告网络并没有销售所有可用的库存，所以他们开始与更多的广告网络合作。然而，这意味着在他们的网站上添加更多的标签，这会导致延迟问题和糟糕的用户体验。

为了解决延迟问题，出现了一种新型平台，即供应端平台（SSP），最初称为网络优化器。

第一供应侧平台（SSP）
第一批投放市场的SSP是Collective、Pubmatic、Admeld和Magnite（以前是Rubicon项目）。

发布者没有向网站添加多个标签，而是只包含一个重定向到SSP的标签。
从那里，SSP确定了哪些广告网络有兴趣购买出版商的库存，然后完成了交易。
21世纪中后期，不仅出现了SSP的崛起，还出现了需求侧平台（DSP）。
DSPs是媒体购买者（广告商和代理机构）连接到通过SSPs提供的出版商库存的一种方式。

第一个需求侧平台（DSP）
最早出现的DSP是Invite Media（现在是谷歌营销平台的一部分）、dataxu和MediaMath。

大约在同一时间，下一个冲击在线显示广告行业的革命性AdTech平台是广告交易所。

广告交易是一种帮助解决流动性问题的方式，它通过逐个曝光位拍卖出版商的库存。

image.png

解释广告交易所如何运作的最简单方法是将其与证券交易所进行比较。
正如证券交易所促进股票、债券和其他证券的买卖一样，广告交易所实时处理广告商和出版商之间的广告曝光位买卖。

这种实时买卖单个曝光的能力称为实时竞价（RTB）。

什么是实时投标（RTB）？

实时竞价（RTB）是在21世纪末引入的一种协议，它极大地改变了在线媒体的买卖方式。
RTB最初旨在帮助出版商向广告商出售剩余库存，现在用于销售所有类型的库存，包括优质库存。
RTB允许广告商跨多个出版商购买单个曝光，而不是从同一个出版商购买数千个曝光，以更准确地到达其目标受众，并根据特定时间网站和用户的已知信息进行出价。
出版商还受益于其库存获得更高的CPM。

什么是RTB项目（OpenRTB）？
RTB项目，以前称为OpenRTB财团，现在称为OpenRTB，是一个由互动广告局领导的集团，由来自需求和供应双方的AdTech公司组成。
OpenRTB于2010年11月启动，为AdTech供应商提供API规范。该协议（称为OpenRTB协议）允许平台之间使用通用语言进行通信，以买卖数字媒体。

RTB是如何工作的？

RTB的技术方面非常复杂，涉及多个AdTech平台。
下面是RTB广告交换工作原理的详细说明和描述。

image.png

• 用户访问页面（example.com）。
• 该页面包含一个带有JavaScript代码的广告槽，该代码从第一方广告服务器请求内容，称为广告请求。该请求还传递有关用户的其他数据，例如用户的位置、设备类型和操作系统。
• 广告服务器检查是否有任何与用户匹配的直接活动。如果没有，广告服务器将返回SSP的广告标签，这将在RTB拍卖中提供印象。
• 浏览器从服务器加载SSP ad标记中包含的脚本。用户信息和位置详细信息（如页面URL、大小和限制）传递给广告交换。
• 广告交易所通过投标申请向所有投标人公布可用的广告曝光。
• 投标人评估投标请求并匹配目标参数，例如页面域、上下文、位置和收集的关于用户的其他数据。然后他们出价——基本上，他们会说他们想为这个曝光付出多少，如果有的话。他们还发送他们想要显示的广告的标记。投标价格和广告加价包含在一个称为投标响应的对象中。
• 广告交易所收到了投标书，给曝光到出价最高的人。最高出价者支付第二高出价的价格，加上额外的小额（通常为0.01美元）。这被称为二价拍卖。包含最终价格的中标通知从广告交易所发送到中标DSP，通过服务器对服务器请求或通过广告标记通过带有价格宏的像素完成，价格宏由广告交易所自动填写。获胜的DSP的广告标记被发送到浏览器。
• DSP的广告标记加载到浏览器中，并发送从DSP的广告服务器检索创意（ad）的请求。广告标记通常从内容交付网络（CDN）而不是直接从广告服务器请求创意。印象跟踪像素也会触发，通知广告服务器印象已送达。
• DSP的广告服务器将创意发送到浏览器，广告显示给用户。

当广告加载到页面上时，整个过程会实时发生，通常在100–150毫秒内。从长远来看，眨眼大约需要300毫秒！

每次加载或刷新页面时，都会从该页面发送一个新的广告请求，随后会启动一个新的RTB拍卖。

投标申请和投标回复包含哪些信息？

投标请求和投标响应通常使用JSON格式，以实现其可读性和紧凑性。
以下是IAB的OpenRTB 2.5规范的部分bid request示例：

{
     "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"
}
}

下面是response:

{
     "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 ]
          }]
     }]
}

OpenRTB规范列出了数十个对象（例如BidRequest、源和设备）和对象属性。
这些对象和对象属性有助于DSP决定一个印象是否值得竞标，并通过DSP将其他信息传递给广告客户。
以下是一些主要OpenRTB对象及其属性的列表：

Imp (impression)

• id
• banner
• video
• audio
• native

Banner

• w (width)
• h (height)

Video

• minduration (minimum duration of video ad)
• maxduration (maximum duration of video ad)
• skip (denotes whether the ad can be skipped)

还有其他用于音频、本机和in-app mobile广告的对象。

Publisher

• id
• Name
• Domain
• Device

ua (user agent)

• geo (location)
• devicetype
• make
• model
• os (operating system)
• language
• carrier

Geo

• lat (latitude)
• lon (longitude)
• country
• region
• city
• zip

User

• id
• yob (year of birth)
• gender

Data

• id
• name
• segment

Segment

• id
• name
• value

For a detailed list of the different objects and attributes, view the OpenRTB 2.5 and 3.0 specifications.

RTB对广告商和出版商的好处

对于广告商

提高广告效果：广告商能够实时查看其广告活动的结果，并对其进行更改以提高性能。这些更改可以由广告客户或DSP的算法手动进行。
欺诈性库存识别：因为广告商有实时的活动报告，所以更容易发现欺诈活动，例如极高的点击率。许多RTB平台整合了广告欺诈预防和检测软件，以帮助广告商减少广告浪费。

对于出版商

收入增加：RTB向数十个甚至数百个广告商开放了出版商的库存，这导致更好的广告匹配和更高的CPM。
优化价格下限：与广告商使用实时分析改进其活动的方式相同，出版商也可以使用实时分析调整其库存的CPM底价以增加收入。

关于RTB生态系统中佣金和可视性的透明度问题

早在广告主和出版商之间的媒体移动纯粹是直接的那一天，双方都知道媒体的销售和购买价格。

虽然这一直接过程至今仍在发生，但技术平台（DSP、SSP、DMP等）带来的好处正在导致针对剩余和高级库存的程序化媒体购买量的增加。

然而，尽管这些平台为广告商和出版商提供了更简单、更优化的媒体买卖方式，但它们基本上已成为中间商，使媒体的真实成本更难确定。

当广告客户与其代理机构进行媒体购买时，通常不知道其预算通过了多少手，以及在到达用户之前向中介机构和技术平台支付了多少佣金。

广告在到达出版商之前要经过五个不同的方面，这并不罕见。也就是说，多达五家中间商都收取不同的佣金，并收取各自的费用。

image.png

中介佣金和费用

要准确地知道每个技术平台（DSP、广告交换、SSP）需要多少佣金是极难计算的，即使这些信息传递给广告客户，也可能更难验证和确认。
然而，普华永道（PwC）和英国广告商协会（ISBA）于2020年发布的一份题为《程序化供应链透明度研究》（Programming Supply Chain Transparency Study）的报告发现，平均而言，出版商只收到51%的广告支出，其中35%流向了中介机构，例如广告代理和广告技术公司。该报告还发现，15%的广告支出，被称为未知三角洲，无法解释。
报告中的一些关键亮点包括：
需求方技术费用，如广告服务、验证工具和数据，平均占广告客户支出的10%。
SSP费用平均占出版商收入的14%，相当于广告客户支出的8%。
出版商收到的广告支出百分比从49%到67%不等。
普华永道（PwC）在IAB赞助下进行的2014年行业研究也发现，广告主的媒体预算中约有50%用于收费和佣金。

在与行业高管的对话中，我们一直听到，项目广告技术费用很高，通常接近50%或更高。在我们的谈话中，这些广告技术费用通常被称为“广告技术税”。本文中的广告技术税是指买方和卖方因利用广告技术和/或ATD、DSP、SSP、广告服务器和广告网络的增值而征收的费用。在许多情况下，这些费用随着一个供应商的费用增加到项目价值链中下一个供应商的成本中而复合。
[1] IAB计划收入报告2014结果：普华永道进行的行业研究，由互动广告局（IAB）赞助。2015年7月。

该研究还指出，这一比例因公司而异，可能会更低，这取决于广告客户用于开展媒体活动的广告技术平台的数量。
例如，一个广告客户只使用一个DSP通过广告交易所购买媒体，可能比使用广告代理（使用ATD和DSP从广告交易所购买媒体）支付更少的费用。
在当前的节目系统中，广告商只被告知与数量相关的媒体价格（例如，1000次曝光10美元=每分钟一次），但他们无法确定技术平台将占多大比例，以及出版商将实际收到多大比例。
除了主要平台和中介之外，广告商还可以从数据管理平台（DMP）支付第三方数据（例如行为和人口统计验证数据）以及其他服务（可视性、品牌安全验证等）。
虽然广告客户通常知道数据的成本，但数字信号处理可能会为其价格增加一些隐藏的利润。

这个行业将何去何从？

毫无疑问，缺乏透明度是一个需要立即关注的问题。一个开始的方法是教育广告商了解各种技术平台的内部运作，并强调它们提供的价值。
谢天谢地，许多AdTech供应商在收费和佣金方面变得更加透明。

私人市场（PMP）

虽然RTB帮助出版商在公开市场上出售其剩余库存，但许多优质出版商发现，他们在最优质的库存上正在亏损。
广告商也开始担心他们错过了优质库存，他们的广告甚至没有被访问者看到。
为了克服这些问题，私人市场应运而生。
私人市场是RTB模式的一种仅限邀请的变体，在RTB模式中，出版商向特定数量的买家提供其最优质的库存。
参与PMP交易的广告商可以在出版商在公开RTB拍卖中提供可用库存之前对其进行出价。

image.png

尽管CPM高于公开RTB拍卖，但在PMP上购买库存的广告商在公开拍卖或通过其他途径出售之前，首先可以获得出版商的优质库存。
出版商通过在投标请求中传递交易ID来标记其PMP库存。为了让广告商购买该库存，他们必须有一个匹配的交易ID。

image.png

上述过程比较

image.png

现在，我们已经介绍了媒体买卖的主要方式，我们将看看出版商可以用来管理和组织上述媒体购买方法的两个过程。

出版商的瀑布

瀑布，也称为daisy chain or waterfall tags，是出版商出售所有剩余库存的过程。当出版商无法销售其优质广告位时，就会发生此过程，这些广告位通常是为出版商的内部销售团队和广告客户之间的直接广告销售预留的。
Waterfalling的名字来源于销售库存的瀑布式流程；需求源一次一个地启动，一个接一个地启动。
这种瀑布的优点是出版商能够出售其库存；然而，随着曝光进一步下降，作为平均值计算的CPM价格会下降。

出版商的困境：高CPM还是高填充率？

虽然广告网络允许出版商出售其剩余库存，但他们仍然面临着被称为出版商困境的问题——他们是否应该以较高的CPM出售库存，冒着无法填满所有可用广告位、错过收入机会的风险？还是他们应该填满所有的库存，减少广告位的CPM，错过潜在的更高收入机会？

image.png

在上图中，我们可以看到出版商首先尝试通过直销销售其库存，因为这些直销通常提供最高的千次曝光成本（CPM）。
如果无法做到这一点，出版商将把曝光传递给SSP和广告交易所，并计划在RTB公开拍卖会上出售曝光。如果广告空间仍未售出，它会将曝光传递给广告网络。

如何实施waterfalling？

AdOps团队建立了一个带有跟踪标签的广告网络，该跟踪标签将在曝光未填充时执行。
这通常配置在发布者的广告服务器以及发布者使用的每个广告网络系统中，在称为回退广告、回传、重定向、默认广告或类似字段中。
需要为发布者使用的每个广告网络配置这些回传。参考上图，出版商的AdOps团队将高级广告网络配置为“回传”到残余广告网络。

waterfalling是如何工作的？

如果出版商无法销售其直接购买的产品，其广告服务器将执行第一个广告网络的标签。
有两种可能的结果，让我们看看几个可能的场景。

场景1

与广告客户的直接交易#1能够为这次广告通话提供曝光，因此它会将广告发送回用户的浏览器。

image.png

场景2

出版商的直接交易没有曝光可供提供，因此它加载标签以与广告交易所#1和#2举行RTB拍卖，这也没有曝光可供提供，因此它加载剩余广告网络#1的广告标签，这能够为该广告请求提供曝光。
然后将曝光发送到用户的浏览器，并显示广告。

image.png

为什么没有任何直接交易或RTB来源购买库存？

这两个来源没有曝光，可能有几个原因。其中包括：
没有匹配的活动：广告客户的目标标准可能与网站或用户不匹配，这意味着需求源（广告网络或DSP）不会有合适的广告来显示。
高底价：出版商的高底价可能高于广告客户愿意支付的价格。
曝光封顶：广告商设置曝光封顶来限制广告向给定用户显示的次数，因此在给定的时间段内，广告可能已经达到了其最大印象数。
超时：另一个原因是广告客户的广告服务器、广告网络或DSP可能花费了太长时间来响应广告请求，这意味着它超时了。如果发生这种情况，它将不会发送回passback广告标签，这意味着瀑布将结束，并且不会显示任何广告。这种情况是使用瀑布选项的主要缺点之一。

场景3

如果所有的需求来源都没有曝光，那么出版商就会激活其后备选项。在大多数情况下，这是一个广告宣传自己的产品或服务。

image.png

广告服务器如何知道首先加载哪个广告网络？

出版商通常会建立一个排名系统，根据该系统，需求来源从最高的平均历史产量到最低的产量。
平均历史收益率只是需求来源过去为出版商创造的平均收入。
该系统的缺点是，一些需求来源可能愿意为给定的曝光支付高于其平均历史收益率的价格。
例如，队列中第三名的剩余广告网络的平均历史收益率可能为每分钟2美元，但如果用户满足其目标标准，则可能愿意为给定曝光支付每分钟5美元。
waterfalling无法准确提供可用曝光的实时成本，这是header bidding崛起的原因之一。

标题投标

标题竞价（也称预竞价、提前竞价和整体收益管理）是一种媒体购买过程，使出版商能够在其广告服务器加载其他标签（如直接交易）之前，同时从多个需求源（如DSP）收集竞价。

image.png

出价是通过位于网站标题部分的一段JavaScript代码收集的，因此称为标题出价。
标题竞价之所以出现，是因为waterfalling效率低下，也因为谷歌对自己的广告产品的偏好。由于许多出版商使用谷歌的广告服务器，以前称为DoubleClick for Publisher（DFP），谷歌青睐谷歌广告交易所（AdX）的出价。
这导致其他广告技术平台的需求错过了购买广告空间的机会，即使他们想支付更高的费用。

标题招标如何工作？

为了实现标题竞价，出版商需要在其网站上的标签之间添加一段JavaScript代码（也称为代码片段或标签）。
这个JS代码通常以包装器（又名容器）的形式出现，包装器通常由SSP和ad交易所提供。
下面是一个基本的标题出价示例，来自开源标题出价包装器Prebid。js:

<html>
 
    <head>
        <link rel="icon" type="image/png" href="/favicon.png">
        <script async src="//www.googletagservices.com/tag/js/gpt.js"></script>
        <script async src="//acdn.adnxs.com/prebid/not-for-prod/1/prebid.js"></script>
        <script>
            var div_1_sizes = [
                [300, 250],
                [300, 600]
            ];
            var div_2_sizes = [
                [728, 90],
                [970, 250]
            ];
            var PREBID_TIMEOUT = 1000;
            var FAILSAFE_TIMEOUT = 3000;
 
            var adUnits = [
                {
                    code: '/19968336/header-bid-tag-0',
                    mediaTypes: {
                        banner: {
                            sizes: div_1_sizes
                        }
                    },
                    bids: [{
                        bidder: 'appnexus',
                        params: {
                            placementId: 13144370
                        }
                    }]
                },
                {
                    code: '/19968336/header-bid-tag-1',
                    mediaTypes: {
                        banner: {
                            sizes: div_2_sizes
                        }
                    },
                    bids: [{
                        bidder: 'appnexus',
                        params: {
                            placementId: 13144370
                        }
                    }]
                }
            ];
 
            // ======== DO NOT EDIT BELOW THIS LINE =========== //
            var googletag = googletag || {};
            googletag.cmd = googletag.cmd || [];
            googletag.cmd.push(function() {
                googletag.pubads().disableInitialLoad();
            });
 
            var pbjs = pbjs || {};
            pbjs.que = pbjs.que || [];
 
            pbjs.que.push(function() {
                pbjs.addAdUnits(adUnits);
                pbjs.requestBids({
                    bidsBackHandler: initAdserver,
                    timeout: PREBID_TIMEOUT
                });
            });
 
            function initAdserver() {
                if (pbjs.initAdserverSet) return;
                pbjs.initAdserverSet = true;
                googletag.cmd.push(function() {
                    pbjs.que.push(function() {
                        pbjs.setTargetingForGPTAsync();
                        googletag.pubads().refresh();
                    });
                });
            }
            // in case PBJS doesn't load
            setTimeout(function() {
                initAdserver();
            }, FAILSAFE_TIMEOUT);
 
            googletag.cmd.push(function() {
                googletag.defineSlot('/19968336/header-bid-tag-0', div_1_sizes, 'div-1').addService(googletag.pubads());
                googletag.pubads().enableSingleRequest();
                googletag.enableServices();
            });
            googletag.cmd.push(function() {
                googletag.defineSlot('/19968336/header-bid-tag-1', div_2_sizes, 'div-2').addService(googletag.pubads());
                googletag.pubads().enableSingleRequest();
                googletag.enableServices();
            });
 
        </script>
 
    </head>
 
    <body>
        <h2>Basic Prebid.js Example</h2>
        <h5>Div-1</h5>
        <div id='div-1'>
            <script type='text/javascript'>
                googletag.cmd.push(function() {
                    googletag.display('div-1');
                });
 
            </script>
        </div>
 
        <br>
 
        <h5>Div-2</h5>
        <div id='div-2'>
            <script type='text/javascript'>
                googletag.cmd.push(function() {
                    googletag.display('div-2');
                });
 
            </script>
        </div>
 
    </body>
 
</html>

下面概述了标题投标流程的工作原理：

image.png

下面是上图中发生的事情：

• 用户打开其web浏览器并键入发布者的URL（例如，publisher.com）。
• 浏览器开始加载页面。
• 位于标签中的标题JavaScript代码或包装器执行并向各种AdTech平台（SSP和ad交易所）发送请求。
• SSP和ad交易所向多个DSP发送投标请求。
• DSP分析出价，如果曝光机会与他们的活动相符，则返回出价响应。
• 出价最高者获胜。
• 出价将传递给出版商的广告服务器，并与其他活动竞争，如直接交易。
• 如果DSP的出价高于出版商的其他活动，则会向用户显示。

就像其他媒体购买过程一样，延迟是标题竞价的一个大问题。
如果DSP、SSP或ad exchange未及时响应ad或投标请求，他们将超时，无法提交投标。
超时率各不相同，在台式机、笔记本电脑和移动设备上也不同。在台式机和笔记本电脑上，超时范围为400-800毫秒，而在移动设备上，超时范围为800-1200毫秒。

Prebid.js–使出版商更容易进行标题竞价
Prebid.js是一个百分之百免费的开源JavaScript框架，旨在使发布者更容易运行标前拍卖，并以最小的集成麻烦获得更多需求。Available at prebid.org.

如何实现标题竞价：客户端与服务器端

在实现标题竞价时，有两种选择：客户端标题竞价（CSHB）和服务器端标题竞价（SSHB）。
客户端标题出价直接从web浏览器（即客户端）收集出价，而服务器端标题出价从服务器收集出价。
对于CSHB和SSHB，发布者仍然需要向其网站添加包装器或JS片段。
下面是客户端和服务器端头竞价实现工作原理的并列比较：

image.png

客户端标题竞价的优势：

• AdTech平台之间的Cookie匹配率较高，因为该过程发生在浏览器中。
• 对标题竞价包装有更多的控制，这意味着出版商可以轻松地添加和删除它们。
• 需求来源和结算价格更加透明。

客户端标题招标的缺点：

• 由于标题招标代码位于页面上，因此加载页面需要更长的时间，这会提供较差的用户体验。
• 可能存在一些浏览器兼容性问题，这意味着标题代码可能无法在旧浏览器上正常工作。
• 浏览器一次只能发出这么多请求，这意味着从包装器或标记发送的请求数量将限制在十几个左右。

服务器端标题竞价的优势：

• 页面加载延迟显著减少，因为向服务器发出一个调用，所有竞价都在服务器上进行，而不是从浏览器发出多个调用。
• 服务器端标题竞价允许发布者从需求源接收更多竞价，因为它与客户端没有相同的技术限制。

服务器端头投标的缺点：

因为这一过程发生在服务器上，所以对结算价格、需求来源和费用等方面的控制和透明度较低。
服务器端标题竞价很难匹配Cookie，这通常会导致出版商收入下降，因为没有可寻址性（即广告商不知道或无法识别网站上的用户）。

瀑布与标题竞价：优缺点

下面，我们总结了瀑布法和标题竞价对于希望提高填充率和最大化利润的发布者的主要优缺点。

瀑布的好处

• 出售原本会浪费的剩余库存。
• 与header-bidding过程相比，waterfalling更容易实施，需要更少的技术知识。为了实现waterfalling，发布者需要做的就是在广告网络和广告服务器上设置一个标签。

标题招标的好处

• 出版商可以收到买家的出价，这些买家可能比与出版商广告服务器连接的买家更感兴趣（并愿意支付更高的价格）。
• 填充所有类型的可用库存的机会更高，包括溢价和剩余（未售出）库存，因为有更多的买家。
• 出版商能够更深入地了解他们广告位的价值——例如，如果出版商将最低价格（其愿意出售库存的最低价格）设定为每分钟1.50美元，但在利用标题竞价后发现其库存的平均售价为每分钟2.00美元，那么它将更清楚地了解其库存在市场上的实际价值。

瀑布的缺点

• 它可以产生低收益，因为出版商的广告服务器根据最高平均收益率而不是库存的当前市场价格来选择需求源，这意味着给出的价格是平均CPM，而不是真正的CPM。
• 它通常会导致延迟问题，因为加载每一层都需要时间，时间越长，用户看到广告的可能性越小。
• 每个需求源可能无法加载回退或超时，导致收入损失。
• 一些需求源需要在其系统中配置回传，这使得ADOP难以重新配置和管理。

标题竞价的缺点

• 虽然标题竞价可以减少瀑布式拍卖中常见的回传次数，从而提高页面加载时间，但它本身也存在一些延迟问题（主要是由于向页面添加更多脚本引起的）。延迟问题与服务器端标题竞价关系不大。
• 为了高效地工作，客户端标题竞标必须与浏览器向后兼容，并且通常与不同的浏览器兼容。
• 如果出版商使用多个标题合作伙伴，则可能会将相同的曝光机会或库存出售，从而重复竞价处理的开销。这一缺点与客户端和服务器端报头竞价有关。
• 添加额外的逻辑会降低浏览器和网站本身的性能，这在现代硬件上不是什么大问题，但在稍旧的硬件和较旧的智能手机上可能会出现问题。

拍卖动态：一价和二价拍卖以及硬底价和软底价

拍卖是许多不同类型交易的重要组成部分。它们用于在eBay等电子商务网站上买卖房屋、艺术品和产品。它们也是通过RTB交易买卖在线媒体的关键部分。
自21世纪末开始实时竞价以来，用于在线媒体买卖的主要模式是二价拍卖。

第二价格拍卖（2PA）

在第二次价格拍卖（也称为Vickrey拍卖）期间，潜在买家（广告商）提出了他们的出价。
中标人是出价最高的人，但他们支付的不是他们出价的金额，而是第二高的投标人提出的价格加上0.01美元。

image.png

买方支付的价格称为结算价格。广告客户出价与结算价格之间的差额称为减少额或消费者盈余，在上例中为0.29美元。

首次价格拍卖（1PA）

在首次价格拍卖中，出价最高的人获胜并支付他们所出价的确切金额。例如，如果一个广告客户出价2.50美元每分钟，他们赢得了拍卖，结算价格将为2.50美元每分钟。
自RTB模式引入以来，在线广告行业一直使用二次价格拍卖，但在过去几年（自2017/2018年以来），许多广告交易所和SSP开始转向一次价格拍卖。
这样做的主要原因是为了应对标题竞价的影响，并使拍卖对广告商和出版商更加透明和公平。
尽管标题竞价具有优势，但许多广告商在直接交易中失利，尽管他们的初始出价更高。这意味着出版商错过了更高的CPM。

image.png

逐步解释：

• 加载发布者的网页，并向SSP/ad exchange 发送标题竞价请求。
• SSP/ad exchange 向DSP发送bid请求。每个DSP返回一个bid响应及其各自的bid。由于SSP/ad交易所进行了二价拍卖，中标的DSP比第二高的出价（DSP#2）多支付0.01美元，最终为4.01美元。
• SSP/ad交换将DSP#1的中标传递给出版商的广告服务器。这一出价现在将与出版商的直接交易竞争。
• 在这种情况下，直接交易高于DSP#1（4.01美元）的出价，因此直接交易获胜。

• 直接交易中的广告被发送到网页并显示给访问者。
  如上图所示，广告客户（由DSP#1代表）错过了向访客展示其广告的机会，尽管其愿意支付比直接交易更多的费用。这是具有标题竞标的第二价格拍卖模型的常见陷阱。
  让我们看看第一价格拍卖是如何改善这种情况的。

  
  
  image.png
  
  

  现在，由于SSP/ad交易所和两个DSP之间举行了第一次价格拍卖，因此标题竞价拍卖的中标价格为每分钟6.00美元，这正是DSP#1的出价。因为它比直接交易高，所以它的广告会显示给访问者。

投标阴影（Bid Shading)

虽然从二价拍卖转向一价拍卖让广告客户赢得了更多的曝光，但他们现在不得不付出更高的代价。
如果广告商的出价是每分钟5.00美元，但在第二次价格拍卖中以3.01美元赢得了大多数印象，那么他们现在在第一次价格拍卖中的出价将是每分钟5.00美元。可以想象，这对媒体预算和支出有很大影响。
此外，第二价格拍卖让广告商很好地了解了这些曝光的价值，从而允许他们相应地更改出价。对于首次价格拍卖，广告商真的不容易知道这一点。
为了帮助广告商在首次价格拍卖期间优化其出价，使其更接近出价的实际成本，AdTech公司推出了一种称为出价阴影的功能。
竞价底价本质上是一种算法，旨在告诉广告商他们应该在首次价格拍卖中出价多少。它通过分析历史出价数据来实现这一点，例如曝光售价、广告位置以及出价损失的价格。
目前，投标阴影由供应方平台和一些需求方平台提供。这是因为大多数DSP尚未更新其技术以处理首次价格拍卖。
虽然竞价阴影有助于广告商节省资金，但这并不是一种非常透明的做法。
广告技术公司很容易告诉广告客户，他们应该出价3.00美元/分钟，而实际曝光售价为2.00美元/分钟，然后将差额据为己有。广告客户来哦姐真实成本的唯一方法是从SSP获取数据，这不是程序化中发生的事情。
虽然大多数广告技术供应商都提供免费的竞价阴影功能，但有传言称，许多供应商将开始为此收费，这激怒了广告商，因为他们认为优化竞价应该是他们的技术合作伙伴提供的标准。
出价阴影也使出版商的广告收入减少。如果广告客户使用出价阴影并以3.00美元/分钟 赢得广告位，而他们本来愿意支付5.00美元/分钟

最低价格

AdTech供应商和出版商之间的合同通常会规定广告网络向其广告商提供的最低CPM价格。
这种有保证的CPM价格也称为底价，旨在避免广告技术供应商可能对出版商的库存进行折扣的情况，这将使其在广告商眼中贬值。
底价有两种：硬底价和软底价。

硬价格下限

硬底价是出版商接受的最低曝光价格。
任何低于此最低价格的出价都将被忽略，这意味着出版商不会接受低于硬价格下限的任何出价。

软价格下限

由于投标人可能不一定知道硬底价是什么，许多出版商设定了软底价，以“捕捉”任何略低于出版商要价的出价，否则将被拒绝。

image.png

正如我们在上图中所看到的那样，硬价格下限自动忽略所有低于4.25美元的出价。
硬和软之间的任何出价都将参加第一价格拍卖。如果有出价高于软价格下限，他们将参加第二次价格拍卖。

章节总结

• 广告商可以通过许多不同的方式从出版商那里购买在线媒体，例如：

  • 直接交易：出版商和广告商之间直接达成的交易。
  • 程序化直接：广告客户和出版商就库存和CPM达成一致，其余过程通过编程处理（即通过使用AdTech平台）。
  • 实时竞价（RTB）：实时竞价，广告商通过DSP、广告交易所和SSP对出版商提供的个人印象进行竞价。
  • 私人市场（PMP）：RTB的一个仅限邀请的版本，发行商允许某些广告商在公开RTB拍卖前对其库存进行出价。

• Waterfalling是出版商出售所有剩余库存的过程，出版商的广告服务器通过该过程一个接一个地调用需求源。

• 标题竞价是一个允许发布者在调用其广告服务器之前从多个需求源收集竞价的过程，这增加了他们获得更高CPM的机会。

• RTB中有两种主要的拍卖类型：

  • 第二价格拍卖，中标人支付第二高价格加0.01美元。
  • 第一价格拍卖，中标人支付其投标金额。

• 底价允许出版商设定他们愿意接受的库存最低CPM。