自有 SSP：什么时候 Prebid Server 或租用的 SSP 就够用，以及谁能为你搭建

SSP，即供应方平台，是把发布商的广告位同时提供给许多买方、并就卖出的部分向发布商付款的软件。只在自有网站或应用上出售广告位的发布商，很少需要自建 SSP。它可以通过现有的 SSP 出售广告位，并用开源程序 Prebid Server 在这些 SSP 之间运行自己的竞价。只有当出售其他发布商的广告位就是你的业务时，自有 SSP 才说得通。即便如此，租用的 SSP 也可能够用，直到你的业务量让它的费用变得太高，或者你的发布商需要它做不到的功能。如果自建，就聘请一家会交付代码、并以你公司的域名和名义搭建 SSP 的公司。

SSP 为发布商做些什么？

发布商的网页或应用每当有广告位需要填充，就会发出一个广告请求。SSP 把这个请求转成发给需求方平台（DSP）的竞价请求；DSP 是广告主用来购买广告位的软件。SSP 收集它们的出价，选出胜出者并记录这笔销售，以便日后向发布商付款。发布商也会在 SSP 里设定规则，比如它接受的最低价格（称为底价），以及它拒绝的广告类型。

每场竞价都有时限。IAB Tech Lab 是为数字广告制定技术标准的非营利组织，它发布了竞价请求标准 OpenRTB。其 2.6 版（2026 年 10 月 23 日查阅）把 tmax 字段定义为“为避免超时，广告交易平台允许接收出价的最长时间（毫秒），包含互联网延迟。”晚于这个时间到达的出价，视同没有出价。

SSP 还负责处理资金。它统计已展示的广告并向买方收费，然后向每个发布商支付其应得的份额。当这些计数与某个买方的计数不一致时，必须有人在发票发出之前查明原因。

对发布商来说，Prebid Server 够用吗？

对只出售自有广告位的发布商来说，只要有发布商自己的团队或托管服务商来运行，Prebid Server 就可能够用。它是为头部竞价而设计的。在头部竞价中，发布商会在它的广告服务器决定展示哪条广告之前，同时向多个 SSP 和广告交易平台征求出价。广告交易平台为广告位运行竞价，方式与 SSP 大致相同。

Prebid.org 的概览页面（同一天查阅）写道：“Prebid Server 是一种用于服务器到服务器头部竞价的开源解决方案。”页面说，它有“230 多个服务端出价适配器”，也就是与 SSP、广告交易平台等出价来源之间现成的连接。

根据同一页面的说明，Prebid Server 会检查每个传入的请求，执行隐私规则，并调用各个出价适配器。等这些适配器作答，或者“超时时间已过”，它就把答复发回给发出请求的一方，比如网页或应用。

使用 Prebid Server 时，发布商在与它合作的 SSP 和广告交易平台之间运行竞价，通常无需自己与 DSP 签订合同。每个 SSP 仍然就它售出的广告位向发布商付款，而与 DSP 的大部分连接仍由 SSP 负责。

概览页面描述了两种常见情形：“精通技术的发布商”和“托管服务提供商：适合其他所有人”。页面写道：“开源社区不提供任何配置工具。”它还提醒，安装 Prebid Server“远没有 Prebid.js 那么容易”；Prebid.js 是 Prebid 在访问者浏览器中运行的头部竞价代码。

GitHub 上的 prebid-server 代码（同一天查阅）以开源许可证 Apache License 2.0 发布。该许可证允许任何人使用和修改代码，包括用于商业用途。发布商可以在自己的服务器上运行它，也可以使用托管它的服务商。概览页面说，托管服务商还“提供管理已存储请求的工具”。

什么时候应该自建 SSP？

自有 SSP 适合替其他发布商出售广告位的业务。广告网络、应用变现公司，以及联合出售广告位的发布商群体，都是这样的例子。对它们来说，竞价及其费用就是产品本身，而租用的软件会限制对这两者的改动。

如果租用的 SSP 按每个请求或每笔销售收费，而你的业务量还在不断增长，自建也可能是合理的。第三个理由是：你的发布商需要某种竞价规则或广告格式，而你试过的所有租用产品都不支持。

在 DSP 同意接收它的竞价请求之前，SSP 一分钱也赚不到，而每一条 DSP 连接都意味着一次单独的对接、一轮单独的测试和一份单独的合同。动手开发之前，先写下哪些 DSP 已经同意接入你的 SSP，以及哪些发布商会在上线时带来它们的广告位。

租用 SSP 能给我们带来什么？哪些东西仍归供应商所有？

租用是指由供应商运行软件，你按合同使用，有时还可以用你自己的品牌。广告服务器供应商 Epom 把它的 SSP 模块作为广告服务器套餐的附加项出售。它的价格页面（同一天查阅）上，套餐起价为每月 250 美元，“SSP module”的价格为“每 1000 个 ext.reqs 0.001 美元”。这个模块让你可以“接入自定义的 DSP 端点”。另一个附加项“White-label solution”每月 250 美元，让你可以“使用你公司的名称、标志和域名，而不是默认的那些。”

印着你品牌的租用产品，仍然归供应商所有。Epom Server 的条款与条件（Epom Server Terms and Conditions，同一天查阅）写明：“本协议不构成销售，也不转让本软件中或对本软件的任何所有权。”同一份条款说，客户拥有其“账户数据”（Account Data），即客户使用该软件所产生的使用信息和流量模式；条款还说，“在不续约或提前终止后三十（30）天内，所有账户数据将从本软件中删除”。在合同结束之前，就要规划好数据导出。

其他供应商的合同写法各不相同，所以在比较价格之前，先读所有权条款。按请求计价的价格取决于供应商把什么算作一个请求，而 Epom 的页面并没有定义“ext.reqs”。要求对方以书面形式给出这个定义，并问清楚你的发布商会把哪个域名列为其广告位的卖方。

哪些文件告诉买方是谁在出售广告位？

买方在出价之前，会先查看广告位来自哪里。发布商会在自己网站上一个名为 ads.txt 的文件里，列出获准出售其广告位的每一个系统。应用则使用配套文件 app-ads.txt。ads.txt 规范 1.1 版（同一天查阅）把每一行的第一个字段定义为“出价方所连接的 SSP、广告交易平台、Header Wrapper 等系统的规范域名。”

ads.txt 每行的第三个字段表明发布商是否直接与该系统合作。规范说，“DIRECT”表示发布商“直接控制该账户”，也就是该行中列出的账户。规范还说，这“往往意味着发布商与该广告系统之间存在直接的商业合同”。

SSP 会发布一个名为 sellers.json 的文件，列出它所出售广告位的每一个卖方。sellers.json 规范 1.0 版（日期为 2019 年 7 月，同一天查阅）写道：“广告系统应当在其根域名以及按需在任何子域名上发布 sellers.json 文件。”

这个文件必须列出每一个卖方：“所有卖方都必须列入，即使它们是保密的。”每个卖方 ID 代表一家公司。用规范的原话说：“每个 seller_id 只能对应一个实体，该实体就以该 seller_id 成交的库存获得付款。”

SSP 的域名也可能出现在竞价请求中。OpenRTB 2.6 建议在每个竞价请求中加入 SupplyChain 对象：它列出参与出售该广告位、并在这一过程中获得付款的公司，这份清单可以标记为不完整。其中的 asi 字段，定义措辞与 ads.txt 每行的第一个字段相同：出价方所连接的系统的域名。

对于展示给欧盟用户的广告位，还要考虑另一个框架。广告行业组织 IAB Europe 运营着透明度与同意框架（Transparency and Consent Framework，TCF），它把每个人的隐私选择（比如是否给予同意）从发布商的网站或应用传递给广告技术公司。IAB Europe 称 TCF 为“一项自愿性标准”。它面向供应商的页面（同一天查阅）说，供应商“可以是广告服务器、衡量服务提供商、广告代理商、DSP、SSP 等等”。该页面还写道：“供应商必须注册才能参与 TCF。”

SSP 建成后，我们应当拥有什么？

上面提到的每个文件和每项注册，都写明了一个域名或一家公司。请确认下面每一项最终都归你的公司所有：

• 出现在你的发布商 ads.txt 行和 asi 字段中的域名，注册在你公司名下
• 该域名上的 sellers.json 文件，以及其中列出的卖方 ID
• 与每个 DSP 签订的合同，由你的公司而不是开发方签署
• 以你公司名义完成的 TCF 供应商注册（如果你的 SSP 参与 TCF）
• 以你公司名义开设的代码仓库、构建脚本和云账户
• 日志和报表，以及一种经过测试的导出方式

域名通常是日后最难更改的一项。换一个新域名，就意味着每个发布商的 ads.txt 文件里都要新增一行。在某个发布商加上这一行之前，核查 ads.txt 的买方可能会把通过你的 SSP 出售该发布商广告位的交易视为未经授权。

请开发方逐一列出不归你所有的每一部分代码，无论是它自己的代码还是第三方代码，并注明每一部分的许可证。SSP 内部的开源代码，比如 Prebid Server，仍沿用它自己的许可证。合同措辞的一般问题，在那篇关于如何核查专属团队、确保代码归你所有的文章里有讲。

对一家提出为我们开发 SSP 的公司，我们该怎样核查？

适用于任何广告技术供应商的一般核查项，写在那篇关于自建、授权使用还是租用 DSP 或广告交易平台的文章里。自建 SSP 还会多出六个问题：

• 你们开发的哪个 SSP 或广告交易平台目前正在运行？有哪些 DSP 通过它购买？
• 能给我们看一个你们系统发出的、填好了 SupplyChain 对象的竞价请求吗？
• 在 tmax 之后到达的出价会怎样处理？发布商怎样看到有多少出价迟到了？
• 在向任何一方开具发票之前，你们怎样把自己统计的广告展示数与每个 DSP 的统计数对上？
• 由谁把新的发布商加入 sellers.json？这项变更需要多长时间？
• 交接之后，哪些组件仍归你们所有？

运营过 SSP 的公司，大多数问题都能通过出示文件、日志和报表来回答。如果保密协议要求不公开某个客户的名称，就请这家公司改为安排你与该客户通一次电话。

在计数相关的问题上花最多的时间，因为发布商的收入是按 SSP 的数字支付的。那篇关于广告报表为何与出价方日志对不上的文章，解释了两套计数在哪些地方会出现偏差。

自建或租用 SSP 要花多少钱？

自建首先是第一个版本的一次性成本：竞价、与发布商和 DSP 的连接、上面提到的那些文件、报表以及付款结算。上线之后，运行成本包括服务器、网络流量、监控、值班人员，以及各项费用，比如 TCF 供应商年费。

SSP 的网络流量不仅随广告请求数增长，也随 DSP 的数量增长。对每一个广告请求，SSP 都要向它邀请的每一个 DSP 分别发送一个竞价请求，所以每新增一个 DSP，就会增加请求、流量和服务器。

租用会把这些成本中的大部分变成供应商的费用，比如 Epom 的套餐费以及它按每 1,000 个“ext.reqs”计算的价格。要按你预计两年后的业务量来比较这两种方案。还要把离开的成本算进去，比如当域名属于供应商时，每个发布商的 ads.txt 里都要新增几行。

amBrain 在其中处于什么位置？

amBrain 的服务清单里有这样一句：“amBrain 为发布商构建供应方平台（SSP）。”在 AdTech 领域，amBrain 还从事 DSP 开发、实时竞价平台和广告交易平台工程方面的工作。RTBBidder 是 amBrain 为一家客户开发的需求方平台。

amBrain 自 2019 年起开发软件。它有三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”如果 amBrain 在你的候选名单上，就向它提出与其他任何公司同样的问题，包括它所说的可复用组件具体指哪些。

本文不是案例研究，也不描述任何客户项目。提到 RTBBidder，只是因为它是 amBrain 开发的一个 DSP，本文也不给出关于它的任何数字。

Prebid.org、IAB Tech Lab、IAB Europe 和 Epom 是作为例子出现的，引用的是它们自己的页面，本文并不声称 amBrain 与它们中的任何一方有任何关系。本文不给出 amBrain 的任何价格或工期。本文也不构成法律意见：同意和数据方面的规则因国家而异，所以请与律师核实。