面向媒体方和广告网络的头部竞价：托管封装、开源 Prebid，还是自建一层

头部竞价让媒体方在广告服务器决定展示什么之前，同时向多家广告买方询价。所有买方由此争夺同一个广告位。实现方式有三种。一是托管封装，即供应商提供的代码及其设置的托管版本。二是由你自己的团队运行免费的开源 Prebid 软件。三是自己编写一层。三者的差别主要在于：谁来负责日常维护，谁能看到原始的竞价数据。

头部竞价是做什么的？

页面上有广告位时，页面里的一小段代码会向多个竞价方发出竞价请求。竞价请求会说明哪个广告位在出售、在哪个页面。Prebid.org 为此发布了免费的开源软件，并这样描述常见的搭建方式：“Prebid 在调用广告服务器之前收集出价，最终决定由广告服务器做出。”竞价方包括供应方平台（SSP）、需求方平台和广告交易平台，各自返回一个价格。代码把最高的出价交给广告服务器，由广告服务器拿它们与你的直接交易比较。本文引用的所有页面均于 2026 年 11 月 10 日查阅。

封装是围绕这段代码的容器：买方名单、应答时限、价格规则，以及与广告服务器的连接。Prebid.org 称，它的软件是这类封装中使用最广的。它还补充说，Prebid“也可以用作完整的竞价库”，在页面上选出胜出者，任何广告服务器都可以像其他需求方一样向其中出价。

头部竞价对收入有什么影响？

更多买方同时看到每个广告位，所以成交价可能升高。增幅有多大，取决于你的流量、广告形式，以及哪些买方想要你的受众。Prebid 说请求是并行发出的：“请求会同时发给所有竞价方，而不是一个接一个地发。”

这是有代价的。Prebid 的页面写道：“延迟广告投放，可能会损失那些很快就离开的用户所带来的展示。”竞价方越少，竞价越快，“但需求方越少，也意味着得到最优出价的机会越少。”请把每千次页面浏览的收入（页面 RPM）和页面速度放在一起衡量。

客户端还是服务端，页面速度会怎样？

在客户端竞价中，由访问者的浏览器发出竞价请求，Prebid.js 就是这么做的，它是“一个在浏览器中运行的 JavaScript 库”。在服务端竞价中，浏览器只向一台服务器发一个请求，由服务器去询问买方。Prebid 的服务端产品是 Prebid Server。Prebid.org 说，把负载交给服务器，“可能比在浏览器的客户端运行更快”，也可以两种方式混用。它建议在你自己的页面上测试“竞价方数量、超时值，以及客户端与服务端的取舍”。

Prebid.org 说，服务端竞价“在没有 HTML 头部区域、无法放置 JavaScript 的环境中是必需的，比如移动应用和 Accelerated Mobile Pages（AMP）站点。”对于应用流量，这就决定了一部分选择。

托管封装包含什么？

托管封装是一种服务，由供应商替你搭建、托管并更新头部竞价的配置。Prebid.org 说，没有工程师的媒体方可以使用“能为你集成并维护 Prebid 的托管服务公司”，并列出了这些公司。它的名录里有 Adapex、Aditude、AdPushup、Assertive Yield、Freestar、Livewrapped、Magnite、Media.net、Microsoft Monetize、PubMatic、Setupad 等。

各家供应商的服务范围不同。Magnite 称，它的 Prebid 即服务能让大型媒体方“无需编写代码，就能部署并掌控定制的头部竞价实现”。这是 Magnite 自己的说法。下面这些内容你大概会遇到其中几项，请问清楚哪些包含在价格里：

• 封装代码、买方名单和时限的持续更新，以及广告服务器的设置
• 一个无需开发人员就能修改设置的界面，以及报表
• 用户同意的对接，以及在你想做服务端竞价时提供托管的 Prebid Server

使用托管封装，你要放弃什么？

代价体现在钱、控制权和数据三个方面，合同可以对其中每一项加以限制。

• 钱。托管服务可能收月费、按收入分成、在与供应商自有需求打包时加收差价，或者几种混合。这里读过的供应商页面都没有标明价格，所以请问清楚确切的计算公式，并要求报告的收入是扣除所有费用后的净额。
• 控制权。供应商可能决定增加哪些买方、如何调整竞价、哪次更新上线。要问清楚你能否覆盖这些设置，修改是否有记录。
• 数据。许多报表只显示合计，而不是每一次竞价。要核查供应商，你需要每次竞价的记录：询问了谁、谁应答了、价格多少、速度多快。要问清楚你能不能拿到、什么格式、保留多久。

同时出售需求的供应商，有理由偏向自己的买方。要问它如何证明自己的买方与其他买方一视同仁，并且让对方书面作答。

自己运行 Prebid 需要做什么？

这个软件不收许可费，Prebid.org 说：“任何想用 Prebid 的人都可以免费使用。”你付出的是人力时间：

• 更新。Prebid.org 说：“我们建议至少每六个月升级一次。”每次发布都会带来“错误修复、性能改进、新功能、更好的法规支持”，而每个买方都通过一个适配器接入，适配器是与它对话的小模块。
• 构建与测试。你要在 Prebid.js 文件中选择买方模块和分析模块，重新构建，并在每次发布前，在多种浏览器的真实页面上测试。
• 报表。Prebid.org 列出了“许多分析适配器插件”。你选一个，接上，并决定存储什么。每次竞价的记录就来自这里。
• 广告服务器设置。订单项，也就是广告服务器对每个价格档位的记录，以及价格规则，必须与代码发出的内容一致，否则收入会悄悄流失。
• 服务端托管，如果你用的话。Prebid 的托管指南写道：“Prebid Server 不是开箱即用的方案。”它还说：“你需要承诺至少每季度检查一次更新。几乎每周都有新版本。”Prebid 的服务端概述也警告说，安装它“远不如 Prebid.js 那么容易”。

折中的办法是，请一家公司在你名下的账号里搭建并维护 Prebid。代码和数据都归你。

用户同意和隐私规则在哪里起作用？

每个竞价请求都可能带有关于某个人的信息，所以凡是适用隐私规则的地方，每条路线都必须记录访问者的选择，并把它传给买方。

在欧盟，用户同意记录通常是 IAB Europe 的透明度与同意框架（TCF）字符串。它由同意管理平台（CMP）生成，也就是向访问者弹出询问的那个窗口。IAB Europe 的页面说，TCF v2.3 于 2025 年 4 月推出，并且“TCF 参与者须在 2026 年 2 月 28 日之前采用 TCF v2.3”。IAB Europe 2026 年 7 月 16 日的通知，给了 CMP 到 2026 年 10 月 23 日的期限，在网页上落实新的 TCF v2.4 披露要求。应用和联网电视的期限是 2027 年 2 月 23 日。欧盟法院就 C-604/22 案于 2024 年 3 月 7 日作出判决，其新闻稿称该字符串“包含与可识别用户有关的信息，因此构成 GDPR 意义上的个人数据。”新闻稿还补充说，当该字符串与 IP 地址等标识符关联时，这些信息可能使人能够识别用户。在你的日志里，请把它当作个人数据。对于 Google Ad Manager，Google 的帮助页面说：“在向 EEA 和英国的用户投放个性化广告时，需要使用与 TCF 集成的认证 CMP。”

在美国，规则因州而异。加利福尼亚州总检察长的页面列出了“选择退出出售或共享其个人信息的权利，包括通过 GPC 退出”。GPC 即全球隐私控制（Global Privacy Control），是某些浏览器中的一项设置或一个浏览器扩展，它告诉网站停止出售或共享某人的数据。Prebid 有一些模块，能从 CMP 读取同意信号并传给买方，其中包括一个对应 IAB 全球隐私平台（Global Privacy Platform）的模块。它们的局限，用 Prebid 的话说：“为满足监管要求而创建的 Prebid 功能，并不能取代各方自行确定其法律义务并遵守所有适用法律的责任。”

使用托管封装时，要问清楚谁是竞价数据的数据控制方，谁来签署数据处理条款。

身份和 Cookie 如何影响头部竞价？

对于认得出的访问者，买方可以出更高的价。Prebid 的 User ID 模块设置共享的匿名化 ID，其页面称这是“提高头部竞价价值的重要途径”。你要选择 ID 模块，并就向访问者发出的告知，听取法律意见。

服务端竞价多了一个环节。Prebid Server 指南说：“许多竞价方通过 Cookie 追踪各自专属的用户 ID”，而这些 Cookie“必须整合到 Prebid Server 域名之下”。这叫作 Cookie 同步，并且只会在“隐私法规允许时”运行。没有同步的地方，买方可能认不出这位访问者。

2025 年 4 月 22 日，Google 写道，它将“维持我们目前在 Chrome 中让用户选择是否使用第三方 Cookie 的做法，不会推出新的独立第三方 Cookie 提示”。2025 年 10 月 17 日，Google 称将“停用以下 Privacy Sandbox 技术”，其中包括 Topics 和 Protected Audience，这是它基于浏览器的两种广告定向工具。它的 Cookie 页面仍然说，Cookie“可能被浏览器设计、企业策略或用户选择所屏蔽”。Chrome 153 版本的发布说明（稳定版计划于 2026 年 9 月 8 日发布）仍然引用 Chrome 的声明，即“将维持目前对第三方 Cookie 的做法”。就本文所查到的信息，没有 Google 之后的声明改变这一点。

所以，Cookie 对一部分访问者有效，对另一部分无效。要问清楚每种方案对没有 Cookie 的访问者表现如何。

怎样用对照测试来比较各种方案？

承诺的提升，只是供应商的期望。Assertive Yield 的名录页面说，它已经展现出“访问者收入的显著提升，比现有变现方案高出 20% 以上”。这是它自己的说法，并不能说明你的页面会怎样。

• 把流量随机分给你当前的方案和新方案。两者在同样的页面上同时运行，跑满整周，流量小的话就跑得更久。
• 先把问题定下来：每一组每千次页面浏览的收入，扣除所有费用后的净额，旁边附上页面速度和跳出率。开始之前，就定好测试时长和成功的标准线。
• 数字要取自你自己的广告服务器和记录，不能只看供应商的仪表盘。
• 把难办的情形包括进来：慢速连接、拒绝同意的访问者、应用和欧盟流量。

什么时候自建一层才有道理？

很少，而且通常不是从零开始。Prebid.org 说，其网站上的代码和文档“依据 Apache 许可证发布”，所以公司可以在 Prebid 之上构建。下面任何一种情形，都可以成为定制开发的理由：

• 你经营广告网络或 SSP，竞价本身就是你的产品，底价、交易，或者哪些买方能看到哪些广告位，都有你自己的规则。
• 合同或数据规则要求每条竞价记录都留在你自己的系统内。
• 你的库存不同寻常，比如 Prebid 支持得不好的屏幕或应用形式。
• 以你的规模，供应商费用比一个维护自有代码的团队还贵。

不要因为供应商的报表与你的不一致就自建，因为新系统只会多出一套数字。也不要为了省一个站点上普通展示广告的费用而自建。

离开供应商时，你能保留什么？

Prebid 名录里的好几家供应商，自己就建立在 Prebid 之上。比如 Magnite 说，它的服务通过“Prebid.js、Prebid Mobile 和 Prebid Server”提供，所以在基于 Prebid 的方案之间迁移，应该比离开封闭系统省事。请以书面形式要求：

• 你在每家 SSP 和广告交易平台上的自有账号，这样买方关系和付款都留在你手里
• 完整的封装配置，以可读的形式提供：买方、时限、底价，以及每个页面的设置
• 每次竞价的记录，在整个合同期内，导出到你掌控的存储中
• 用户同意记录、用户 ID 设置和广告服务器的订单项，这些本应已经在你的账号里
• 通知期和交接计划，包括由谁把供应商的脚本从你的页面上移除

替你搭建的公司，应当把代码仓库、构建步骤和测试页面留给你。

该向供应商，或者替你搭建的公司问什么？

• 你们具体怎么收费？在你们向我们报告收入数字之前，扣除了哪些费用？
• 你们是否也出售需求？你们如何避免这影响哪个出价胜出？
• 它是否建立在开源 Prebid 之上？我们现在用的是哪个版本？你们多久更新一次？
• 我们能否导出每次竞价的记录？什么格式、多少费用、保留多久？
• 针对欧盟和美国各州，你们支持哪个同意管理平台和哪些信号？
• 对于没有 Cookie 的访问者，以及在移动应用里，它表现如何？
• 你们能否在我们的流量上做一次分流测试，数字取自我们自己的广告服务器？
• 如果我们离开，我们能保留什么，你们又会交出什么？

amBrain 在其中处于什么位置？

amBrain 发布这个博客。用它自己的话说：“amBrain 为媒体方构建供应方平台（SSP）。”另一句话涉及广告事件数据：“amBrain 构建广告技术的事件分析管道：展示和点击事件的采集、处理和报表。”

amBrain 自 2019 年起开发软件。关于与客户的合作方式，它说：“三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。”它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”签约之前，请要求它逐项列出这些组件的名称。

本文不是案例研究，也没有描述任何客户的工作。上面这些话没有点名任何客户，这里也没有任何内容表示 amBrain 曾为哪家公司构建过头部竞价产品。本文没有给出 amBrain 的价格或时间安排，也不声称与文中提到的任何供应商有任何关系。每一个外部来源，都引自其自己的页面。

本文也不是法律意见。在签字之前，请让律师审阅供应商合同、数据处理条款和你的用户同意设置。如果 amBrain 在你的候选名单上，请用同样的问题去问它，就像问其他任何公司一样。