前言

最近工作接触了用户增长（User Growth）领域，深入了解后才意识到：广告投放（Ad Delivery）正是驱动用户增长的核心引擎。

各大互联网公司背后都有一套精密运转的投放体系，每天动辄数千万的预算，正是通过这套系统被分配到海量广告曝光之中。

广告投放连接着广告主、媒体平台与用户，是商业化与增长链路中的关键枢纽。理解它的底层机制，是继续学习 RTA、DPA、归因等核心技术的前提。

广告

广告概述

  • 品牌广告：借助媒体的能力，向用户展示品牌信息，提升品牌中长期知名度和用户忠诚度。
  • 效果广告：利用广告手段直接带来购买和转化行为。

广告层级分类

在大多数广告平台里，一条广告通常不是孤立存在的，而是被组织在一套分层结构中。这样做的目的，是把投放目标、预算控制、定向策略、创意素材拆到不同层级里管理，既方便运营，也方便系统做投放决策。

常见的广告层级一般可以分为三层：

  • 广告计划（Campaign）：最上层，主要定义投放目标和整体预算，比如是为了拉新、激活，还是提升转化。
  • 广告组（Ad Group）：中间层，主要承载定向、人群、出价、投放时段、版位等策略配置。
  • 广告（Ad / Creative）：最底层，是真正展示给用户看的内容，比如图片、视频、标题、文案、落地页等。

可以把它理解成一句话：计划管目标，广告组管策略，广告管素材。

举个例子，如果一个电商 App 想推广新品：

  • 可以先建一个新品拉新的广告计划，确定总体预算和转化目标；
  • 在下面拆出多个广告组，分别投给新用户、老用户、召回用户，或者区分不同出价策略；
  • 每个广告组里再放多条广告创意，由系统根据效果自动选择更合适的素材去展示。

不同平台的命名方式可能略有差异，但核心思路基本一致：都是通过“目标层 - 策略层 - 创意层”来组织广告投放。

交易参与方

广告投放体系里会涉及多类角色。其中，实时交易链路里的核心参与方通常包括广告主（Advertiser）、媒体平台（Publisher）和用户（User）；此外还常见数据管理平台（DMP）这类辅助系统，为定向投放提供数据支持。

广告主（Advertiser）：是广告投放的发起方，会花费一定的预算来投放广告，并负责定义要投放的广告的内容、目标、预算和投放位置等。

各大互联网公司不仅是赚取广告费的流量平台，它们本身也是市场上实力最雄厚、预算最庞大的广告主之一。

在互联网行业，流量就是生命线。即使是拥有亿万用户的巨头，也需要不断通过投放广告来维持增长和开展新业务。

广告主

媒体平台（Publisher）：为实现流量变现，会提供广告位（Ad Unit）。对大多数媒体平台来说（尤其是内容平台），广告是最早、最稳定、规模最大的收入来源。

用户（User）：是广告投放的最终目标。当广告被媒体渲染出来时，会触发展示事件；当用户进一步点击广告时，会触发点击事件。

数据管理平台（DMP）：是广告投放中的辅助平台，通过对人群画像的分析与管理，帮助广告主更精准地定位目标受众，实现定向投放。

投放链路

链路角色

在广告投放链路过程中，通常会涉及三类核心角色：SSP 代表供给侧，负责承接媒体流量；Ad Exchange 代表交易撮合层，负责组织竞价；DSP 代表需求侧，负责代广告主进行定向、出价和投放决策。

从配合关系上看，SSP、Ad Exchange、DSP 可以理解为一条实时交易链路上的三个关键环节。

  1. 媒体侧通过 SSP 管理广告位；当用户打开 App 或访问页面时，媒体会将这次可售曝光连同广告位信息、设备信息、用户上下文等一起封装成流量请求，发送至 SSP。
  2. SSP 会把这次流量送到 Ad Exchange，由后者作为交易中枢，将请求分发给多个 DSP，并组织一次实时竞价。
  3. 各个 DSP 会根据广告主的定向条件、预算约束、出价策略以及对用户价值的判断，决定是否参与竞价以及出多少价。
  4. Ad Exchange 按照拍卖规则选出获胜方，把结果返回给 SSP，再由 SSP 将最终广告返回给媒体完成展示。

整个过程通常只发生在几十到几百毫秒内，但背后已经完成了一次流量接入、请求分发、广告决策、竞价结算、创意返回的复杂流程。

这里要特别分清一点：SSP、Ad Exchange、DSP 说的是广告链路中的三种职能角色，不等于三家彼此独立的公司。
在实际业务里，很多大厂会把媒体变现、交易撮合、广告主投放这几类能力整合到同一个广告平台里。
但从理解原理和分析链路的角度看，最好还是把它们当成不同职责分别来看。

SSP

SSP（Supply-Side Platform）：供给侧平台，主要服务媒体方，负责管理广告位、封装流量，并把可售曝光发送到交易市场。

可以把 SSP 理解为媒体侧的流量管理与变现入口。常见形态包括媒体自建广告平台，或第三方移动广告联盟、媒体变现平台中的供给侧能力，例如穿山甲、优量汇等。

以字节跳动的穿山甲平台为例，开发者接入后，可以将自身 App 的广告位接入交易链路，从而实现流量变现。

穿山甲

Ad Exchange

Ad Exchange（广告交易平台）：交易撮合平台，连接 SSP 和 DSP，负责接收流量、组织竞价，并按拍卖规则选出获胜广告。

可以把 Ad Exchange 理解为广告库存进入公开或半公开市场后的交易中枢。它一端承接 SSP 发来的可售流量，另一端向多个 DSP 广播竞价请求，并返回最终胜出的广告创意。

DSP

DSP（Demand-Side Platform）：需求侧平台，主要服务广告主，负责根据定向、人群、预算和出价策略，决定是否参竞以及出多少钱。

可以把 DSP 理解为广告主侧的自动化投放系统。它会综合用户标签、广告位质量、转化概率和预算约束，实时判断这次曝光值不值得买，以及应该出什么价格。

像巨量引擎、百度营销、腾讯广告这类广告投放平台，通常都带有 DSP 能力，帮助广告主自动完成定向、出价和投放。

RTB 竞价

随着广告交易从人工售卖逐渐走向程序化交易，媒体不可能靠人工为每一次曝光逐条挑选广告主，广告主也不可能靠人工判断每一次展示值不值得买。

当流量规模、广告主数量和定向复杂度都不断上升时，行业就需要一种能在毫秒级自动完成询价、出价和成交的机制，RTB 就是在这个背景下出现的。

RTB 核心是把每一次广告曝光都变成一次可实时定价、可实时竞争的交易机会：当用户打开 App 或页面时，媒体侧会把这次曝光机会发送到交易链路里，由多个 DSP 在极短时间内同时判断要不要买、出多少钱、投哪条创意，最后再由平台选出赢家完成展示。

  • 对广告主来说，RTB 的价值在于按人群价值精细买量，把预算花在更值得买的曝光上。
  • 对媒体来说，RTB 的价值在于把同一次广告机会同时开放给更多买家竞争，从而提升填充率和变现效率。

典型的 RTB 链路如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

用户打开 App
    │
    ▼
媒体发起广告请求 ──► SSP ──► Ad Exchange
                                │
            ┌───────────────────┼───────────────────┐
            ▼                   ▼                   ▼
          DSP-A               DSP-B               DSP-C
            │                   │                   │
   返回 BidResponse     返回 BidResponse     返回 BidResponse
            │                   │                   │
            └───────────────────┼───────────────────┘
                                ▼
                       RTB 拍卖（按平台规则）
                                │
                                ▼
                        选出胜出 DSP 与创意
                                │
                                ▼
                        返回中标结果（win notice）
                                │
                                ▼
                 媒体渲染广告 → 曝光上报 / 计费回传

OpenRTB 标准

随着 RTB 生态里参与方越来越多，SSP、Ad Exchange、DSP 之间如果各自使用不同的协议，接入和协作成本就会迅速升高。

OpenRTB 就是在这个背景下出现的行业标准：它把广告请求、竞价响应和常见字段定义尽量统一，让不同平台之间可以用同一套通用语言完成实时竞价。

如果沿着 OpenRTB 这条主线来理解，RTB 本质上就是一套标准化的请求 - 竞价 - 返回 - 展示流程：

  • 媒体侧发起 BidRequest：SSP 或 Ad Exchange 把广告位、媒体场景、设备信息、用户信息等上下文封装成标准请求，发送给多个 DSP。
  • DSP 返回 BidResponse：每个 DSP 基于定向、人群价值、预算和出价策略，决定是否出价、返回哪条创意，以及愿意出多少钱。
  • 平台执行拍卖：Ad Exchange 或 SSP 按平台约定的拍卖规则，从多个报价中选出胜出广告。
  • 胜出广告完成展示：平台向胜出方发送中标通知，媒体拉取或渲染创意，随后进入曝光、点击、转化等回传链路。

在 OpenRTB 里，最核心的两个对象就是 BidRequest 和 BidResponse：

  • BidRequest：媒体侧发起的广告请求，包含了广告位、媒体场景、设备信息、用户信息等上下文。
  • BidResponse：每个 DSP 返回的竞价响应，包含了是否出价、返回哪条创意、愿意出多少钱等信息。

进一步阅读可以直接看下面两份资料：

开源 RTB

https://github.com/prebid/prebid-server

RTA 决策

RTA（Real-Time API）是部署在广告主侧的实时决策接口。DSP 在发起竞价前会先请求 RTA，由广告主基于自有数据判定是否参与本次出价，从而实现精细的流量过滤。

换句话说，RTA 不是独立的一套拍卖机制，而是嵌在 DSP 出价前的一次实时业务判断，用来影响“要不要出价”和“应该怎么出价”。

在 DSP 拥有大量用户画像情况下，为什么还需要 RTA？

广告主相比于 DSP 拥有更丰富的用户信息，能够更精准地定位目标受众，实现广告的定向投放。这些用户数据较为敏感，无法直接暴露给 DSP。

比如在用户增长拉新场景下，广告主可以结合自有数据识别用户特征，评估其长期价值，再决定是否对这次曝光出价。

  • 新用户：提升出价系数，尽可能争取广告曝光，争取新客转化。
  • 已注册老用户：降低出价系数，避免为无增量流量付费。
  • 风控黑名单用户：直接拒绝出价，规避作弊与欺诈风险。

典型的 RTA 回调链路如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

用户打开 App
    │
    ▼
媒体发起广告请求 ──► SSP ──► Ad Exchange ──► DSP
                                           │
                                           ▼
                                      是否启用 RTA？
                           ┌───────────────┴──────────────┐
                           ▼                              ▼
                      DSP（无 RTA）                   DSP（有 RTA）
                           │                              │
                           │                        ① 回调广告主 RTA
                           │                              │
                           │                        ② 判断用户价值、
                           │                          风控与预算约束
                           │                              │
                           │                       ③ 返回是否参竞&系数
                           │                              │
                           │                       false ───→ 拒绝出价
                           │                              │
                           └────────── true / no-RTA ─────┘
                                           │
                                           ▼
                                 召回广告 + 预估 CTR / CVR
                                           │
                                           ▼
                                   按 RTA 系数调价（可选）
                                           │
                                           ▼
                                     参与 RTB 拍卖
                                           │
                                           ▼
                                  胜出后渲染广告 → 曝光上报

计费模式

计费方式

广告计费方式表面上看是在回答怎么收钱，但本质上是在回答另一个问题：这次投放效果的不确定性，到底由谁来承担。

你可以把它理解成一条逐步后移的责任链：从只保证展示，到至少有人点击，再到尽量拿到真实转化，平台承担的效果责任越来越重，广告主买到的结果也越来越接近最终业务目标。

主流的计费方式有：

  • CPM（Cost Per Mille，按曝光）：平台只对广告完成展示负责，至于用户看完会不会点、点完会不会买，主要还是广告主自己承担结果风险。它更适合品牌广告，或者广告主本来就更看重触达规模的场景。
  • CPC（Cost Per Click，按点击）：平台需要进一步保证用户愿意点击，风险比 CPM 更往平台侧挪了一点。它常见于效果广告早期，适合先用点击验证素材和人群是否匹配。
  • CPA（Cost Per Action，按转化）：广告主只愿意为注册、下单、留资这类明确动作付钱，平台承担的效果风险明显更高。它更接近广告主真正关心的业务结果，但对平台的流量质量和转化能力要求也更高。
  • oCPX（Optimized CPx，按转化优化）：这是当前主流效果广告最常见的形态。广告主表面上仍然按点击或曝光被扣费，但平台会围绕转化目标去优化投放，本质上是平台用模型把更多效果责任接了过去。

oCPX

oCPX 由 Facebook 引入，解决了媒体平台和广告主之间的分歧。

在 oCPX 出现之前：

  • 媒体平台想要 CPM（按曝光收费）： 平台觉得，我把你的广告展示给了用户，我的任务就完成了，我就该收钱。至于用户买不买你的东西，那是你商品好不好、落地页做得漂不漂亮的问题，我不背锅。
  • 广告主想要 CPA（按转化收费）： 广告主觉得，我花钱是为了卖货、收集线索。用户光看有什么用？只有用户真买单了（或者填表单了），我才愿意掏钱。

这就陷入了僵局。纯 CPA 模式下，媒体如果给一个极差的广告位跑了几百万次曝光，结果没几个人买，媒体就亏死了（流量白白浪费）。

oCPX 的出现，就是为了在这两者之间达成和解。

oCPX 中的 X 可以为 oCPC、oCPM、oCPA 等，其中 oCPM（按转化目标优化，按曝光扣费）是目前的主流。

oCPM 计费模式可以做一个简化理解：

  1. 当一个用户刷新页面，产生一次广告请求时，媒体平台的深度学习算法会瞬间启动，预估这个用户点击广告的概率（pCTR）和点击后最终购买的概率（pCVR）。
  2. 公式转换：系统会通过一个公式，把广告主的目标 CPA折算成底层的eCPM（千次展现期望收益），然后拿着这个 eCPM 去参与竞价：实际竞价 eCPM = pCTR × pCVR × 广告主目标转化出价 × 1000
  3. 竞价结算：媒体平台会根据竞价结果，计算出广告主需要支付的费用。

因为系统需要学习到底什么样的人才会转化，所以 oCPX 投放通常分为两个阶段：

  1. 第一阶段（数据积累期 / 冷启动阶段）： 系统由于没有足够的历史数据，还不太准。这个阶段通常按照传统的 CPC 或 CPM 出价，广告主往往需要承担一定的成本波动（可能会亏钱）。系统需要在这个阶段收集到足够多的转化样本（比如各平台常见的门槛：累计达到 10 个或 20 个转化）。
  2. 第二阶段（智能投放期）： 一旦跨过门槛，系统模型出师了，就会正式切入 oCPX 模式。此时算法全面接管，开始疯狂寻找高转化人群，并将平均转化成本稳稳控制在广告主设定的目标价附近。

既然设置了平均成本 100 元，如果第二阶段系统跑飞了，最终算下来一个转化花了 150 元怎么办？

在 oCPX 机制下，平台为了鼓励广告主放心把出价权交给自己，通常会提供赔付兜底。超出的那 50 元，平台会以广告赠款的形式退给你。

RTA 模式下 oCPX 计算

如果把 RTA 和 oCPX 放在一起看，可以把它理解成两层决策叠加：

  • RTA 负责前置判断：广告主先基于自有数据决定这次流量值不值得买，要不要放大、缩小，甚至直接拒绝。
  • oCPX 负责平台优化：媒体平台再基于自己的模型去预估 pCTR、pCVR，把广告主的目标转化成本折算成底层竞价能力。

所以在工程上，RTA 往往不是替代 oCPX，而是影响 oCPX 的输入。最常见的做法有两种：

  • 直接过滤：RTA 返回 no-bid，这次请求就不再进入后续竞价。
  • 调整系数：RTA 返回一个出价系数或优先级，让原本的 oCPX 出价结果再乘上一个实时调节因子。

可以写成一个简化公式：最终出价 eCPM = pCTR × pCVR × 目标转化出价 × RTA 调节系数 × 1000

这里的关键点在于：

  • pCTR、pCVR 主要反映平台视角下的点击和转化概率；
  • RTA 调节系数 反映广告主基于一方数据做出的实时业务判断；
  • 两者叠加之后，平台既能利用通用模型做规模化优化，也能把广告主自己的业务偏好实时带进竞价过程。

总结

广告投放的链路看似复杂，但拆开来看，无非是在回答三个问题：流量从哪里来、谁来决定这次曝光值不值得买、最后按照什么目标和方式完成计费与优化。

从参与角色到 RTB 交易，再到 RTA 和 oCPX，本质上都是在围绕同一件事展开：在合适的时间，把合适的广告，展示给合适的人。