程序化广告生态全景：DSP / SSP / ADX / Ad Server / DMP 在一次曝光里各管什么

刚进 AdTech 的工程师几乎都会遇到同一个困惑：DSP、SSP、ADX、DMP、Ad Server、Trading Desk 这一堆三个字母的缩写，听起来都在”买卖广告”，彼此的边界却像糊在一起。更糟的是，现实里同一家公司经常同时戴着好几顶帽子——Google 一家就把 DSP（DV360）、SSP / ADX（Google Ad Manager / AdX）、Ad Server（GAM）全占了。

这篇文章不讲营销话术，而是从一次曝光（impression）在系统之间怎么流动的角度，把每个角色拆开：它站在买方还是卖方、解决什么工程问题、靠什么收费、以及它和上下游用什么协议对接。读完之后，再看任何一张”程序化生态图”，你都能立刻指出每个框在链路里的位置。

TL;DR

• 一根轴线分清所有角色：买方（出钱买流量）↔ 卖方（卖出库存）。Trading Desk、DSP、广告主 Ad Server 偏买方；SSP、ADX、媒体 Ad Server、客户端 SDK 偏卖方；DMP 与归因平台（MMP）则横跨两端。
• DSP 和 SSP 是一枚硬币的两面。两者都是程序化竞价的自动化引擎，只是服务对象相反：DSP 帮广告主”用最低价买到对的人”，SSP 帮媒体”把每个广告位卖到最高价”。它们之间用 OpenRTB 对话。
• ADX 是撮合双方的拍卖场。SSP 把库存挂到 ADX，DSP 在 ADX 上竞价。现代技术栈里 SSP 与 ADX 的边界已经高度融合，很多平台两者都做。
• Ad Server 有两个，别混为一谈。广告主 Ad Server（如 Campaign Manager 360）管素材投放、计数与归因；媒体 Ad Server（如 GAM）管库存排期与”程序化 vs 直采”的流量分配。
• DMP 横跨两边，是数据层。它给 DSP 提供”该不该追这个人”的受众信号，也给 SSP 提供流量分层依据。在第一方数据与 CDP 兴起后，DMP 的角色正在被重塑。
• 归因层回答”钱有没有花对”。Web 端由广告主 Ad Server（CM360）记账，App 端则由 MMP（AppsFlyer / Branch / Adjust）这个中立第三方主导：统一接收各渠道的点击数据、判定转化算谁的、再把 postback 回传给渠道优化。而 Google / Meta / TikTok 这些 自归因平台（SAN） 不交出原始数据，由它们自己”认领”归因。
• Trading Desk 是人坐的操作台，不是一套竞价系统。它是代理商 / 广告主用来跨多个 DSP 统一操盘、做策略与归因的管理层。
• JS SDK 是整条链路的”扳机”。跑在浏览器里的客户端库（Web 端的 GPT、Prebid.js，App 端的原生 Ad SDK）才是真正发起广告请求的人；现代媒体靠它在页面里跑 Header Bidding，让多个 SSP 公平并行竞价，再把最高价喂给 Ad Server。
• 整条链路在 ~100ms 内跑完，而广告主每 $1 预算里，往往只有一半左右真正变成媒体侧的”有效曝光”，其余是各层的 ad tech tax。

Table of contents

1. 先立一根轴：买方 vs 卖方

程序化广告的所有角色，本质上都可以挂到一根轴上：

• 买方（Buy Side / Demand Side）：花钱的人。广告主想买到”对的用户在对的场景下的一次曝光”，并且越便宜越好。
• 卖方（Sell Side / Supply Side）：卖货的人。媒体（Publisher、App）手里有用户注意力——也就是库存（inventory），想把每个广告位卖到最高价。

中间夹着一个交易市场（marketplace），让成千上万的买方和卖方能在一次曝光发生的瞬间完成撮合。

把缩写按这根轴排一下，混乱立刻消失一大半：

下面这张图把它们连成一条主干线——蓝色是买方、绿色是卖方、灰色是中间的交易市场，顺着箭头从左往右读即可。

读法很简单：主干线一气呵成——广告主 → DSP → 交易市场 → 客户端 SDK → 用户；蓝色买方在左，绿色卖方在右，灰色市场居中。两个旁挂层不在主竞价链路上却至关重要：黄色的 DMP 在前端给两侧”喂数据”，粉色的 MMP 在后端收集转化、把”什么有效”回传给 DSP 优化——一进一出，构成闭环。

接下来逐个拆。

2. 卖方一侧：SSP、ADX、媒体 Ad Server

2.1 媒体 Ad Server：库存的”调度中心”

故事要从媒体说起。一家媒体（新闻网站、视频 App、游戏）有一堆广告位，但这些广告位的卖法不止一种：

• 直采（Direct）：销售团队和品牌签的合同，“首页 banner，包月，CPM $20”。
• 程序化（Programmatic）：剩下没卖掉的、或者愿意走公开市场的库存，扔到实时竞价里。

媒体 Ad Server（典型如 Google Ad Manager）就是决定”这次请求该给谁”的调度中心。它的核心工作是 ad decisioning：当一次广告请求进来，它要在已售的直采订单、保量合约、以及程序化竞价之间做优先级排序，挑出收益最高且满足合约的那一个。

关键直觉：媒体 Ad Server 解决的是**分配（allocation）**问题，不是竞价问题。它决定”这个广告位走直采还是走程序化”；一旦决定走程序化，真正的”卖”才交给 SSP。（它的 line item 优先级、decisioning 流水线与 dynamic allocation，完整展开见专文《媒体 Ad Server 深挖》。）

2.2 SSP：替媒体自动卖货的引擎

SSP（Supply-Side Platform，供给方平台） 是媒体接入程序化市场的引擎。媒体不可能手动跟成千上万的买家逐个谈价，SSP 把这件事自动化：

• 把媒体的库存实时挂出去，向众多需求方（DSP / ADX）广播竞价请求；
• 跑收益优化：底价（floor price）、流量分层、需求方筛选；
• 帮媒体做收益管理：哪些买家可以进、哪类广告主屏蔽、品牌安全规则。

一句话：SSP 站在媒体这边，目标是把每一次曝光卖到尽可能高的价格。

2.3 ADX：撮合买卖的拍卖场

ADX（Ad Exchange，广告交易所） 是真正”撮合”的地方——一个中立的实时拍卖市场。SSP 把库存送进 ADX，无数 DSP 在 ADX 上对同一次曝光竞价，ADX 跑拍卖、定出胜者和成交价。

那 SSP 和 ADX 到底什么关系？这是新人最容易绕进去的地方：

• 理论上：SSP 是”帮单个媒体卖货的代理”，ADX 是”所有人交易的市场”。SSP 把库存接入 ADX。
• 现实中：两者高度融合。像 Google AdX、Magnite、PubMatic 这类平台，既是交易所也是 SSP；很多场景下你说 “SSP” 和 “ADX” 指的是同一个系统。Header Bidding 普及之后，媒体甚至会同时接入多个 SSP/ADX 做并行竞价。

所以遇到一张图把 SSP 和 ADX 画成两个框，不用纠结——把它们理解成”卖方接入市场的那一层”即可，区别更多是历史和商业角色，而非两套截然不同的技术。

2.4 客户端 SDK：跑在用户设备上的”扳机”

前面几个角色都偏服务端。但整条链路的真正起点，在用户的设备上——网页里的 JS SDK、App 里的 原生 Ad SDK。下面以 Web 为主线讲，App 端的对应物放在本节末尾。

媒体要接入程序化，光在后台配好 Ad Server 和 SSP 还不够，还得在网页里嵌一段客户端代码，由它来发起广告请求、接收并渲染广告。常见的两类：

• Google Publisher Tag（GPT）：Google Ad Manager 的客户端标签，负责定义广告位、向媒体 Ad Server 发请求、把返回的素材渲染到页面。
• Prebid.js：开源的 Header Bidding（头部竞价） 库，这是过去十年卖方侧最重要的一次变革（完整架构见专文《Header Bidding：Prebid.js vs Prebid Server》）。

为什么 Header Bidding 重要？在它出现之前，媒体 Ad Server 用的是 瀑布流（waterfall）：按事先排好的优先级一个个询问需求源，前面的吃饱了后面的就没机会，价高者未必能买到——对媒体不公平，对买方也不透明。

Prebid.js 把这件事搬到了浏览器里：在调用 Ad Server 之前，先在客户端并行向多个 SSP 同时询价，收齐所有出价，取最高的那个，再作为一个 key-value 塞进 Ad Server 让它做最终决策。所有需求源站在同一条起跑线上公平竞价——这就是”头部”竞价的含义（发生在页面加载的最前端）。

一句话：用户进页 → Prebid 并行向 SSP 询价并缓存候选 → Ad Server 在直采 / HB 最高价 / AdX 等之间拍板 → 谁赢就渲染谁的创意（HB 赢家多为已缓存素材，不是拍板后再向 SSP 要一次）。

几个工程上绕不开的点：

• 延迟与性能的权衡：客户端 Header Bidding 会在页面加载关键路径上多出几百毫秒的询价等待，直接影响用户体验和收益。于是又演化出 Server-Side Header Bidding（S2S）——把并行询价从浏览器搬到服务器，省客户端开销，但牺牲一部分 cookie 匹配率。
• SDK 体积即成本：每多接一个 SSP adapter，页面就多一份 JS 和一次请求。SDK 的体积和超时配置（timeout）是收益与性能之间最直接的调节旋钮。
• App 端的对应物：App 里没有浏览器 JS，靠的是各家的原生 Ad SDK（如 AdMob、Mintegral、Pangle 等）。职责一样——初始化广告位、拉广告、渲染、计数，很多也支持 In-App Bidding（Header Bidding 的 App 版本）。这套端上的变现 SDK、聚合（Mediation）与 In-App Bidding 怎么运作，单独展开见《App 广告 SDK 深挖》。

3. 买方一侧：DSP、Trading Desk、广告主 Ad Server

3.1 DSP：替广告主自动出价的引擎

DSP（Demand-Side Platform，需求方平台） 是 SSP 在镜子里的倒影。广告主同样不可能手动对每一次曝光出价，DSP 把买量自动化：

• 接收来自 ADX/SSP 的 bid request（OpenRTB 格式），里面描述了”这是谁、在什么场景、什么广告位”；
• 在 ~100ms 内决策：这次曝光值不值得买？出多少钱？用哪个素材？
• 决策依据包括：活动预算与节奏（pacing）、频次控制（frequency cap）、定向条件、以及从 DMP 拿到的受众信号和自家的出价模型（bid model）。

一句话：DSP 站在广告主这边，目标是用尽可能低的价格买到对的人。

DSP 与 SSP 的对称性是理解整个生态的钥匙：同一套 OpenRTB 竞价机制，DSP 在压价、SSP 在抬价，ADX 在中间撮合。 三者构成实时竞价（RTB）的铁三角。

3.2 Trading Desk：人操盘的那一层

这里有个常见误解：以为 Trading Desk 是又一套竞价系统。不是。Trading Desk（交易桌）是人坐在前面操盘的管理层。

一个大广告主或代理商往往同时在用多个 DSP（不同 DSP 擅长不同渠道、不同地区）。Trading Desk 就是把这些 DSP 收拢到一个操作台：

• 统一操盘：在一个界面里跨多个 DSP 建活动、调预算、改定向；
• 统一归因与报表：把各 DSP 的数据汇总，避免重复计算、统一看 ROI；
• 策略层：决定预算怎么在渠道间分配、用什么受众、追什么 KPI。

历史上分两类：代理商的 ATD（Agency Trading Desk），以及广告主自建的 in-house desk。它不直接竞价——竞价永远是 DSP 干的——它是坐在 DSP 之上的指挥层。

3.3 广告主 Ad Server：素材、计数与归因

买方这边也有自己的 Ad Server（典型如 Campaign Manager 360，前身 DoubleClick Campaign Manager）。它和媒体 Ad Server 同名，职责却完全不同，这是新人最容易混的一对概念：

广告主 Ad Server 的价值在于统一真相口径：同一个活动可能同时跑在 DSP、社交、直采等多个渠道，每个渠道自己的报表都”屁股决定脑袋”。广告主把所有素材托管在自己的 Ad Server，靠它统一打点（impression / click / conversion）和做跨渠道去重归因，才能拿到一份可信的总账。

4. 横跨两侧：DMP（与正在接棒的 CDP）

DMP（Data Management Platform，数据管理平台） 是这张图里唯一不在主竞价链路上、却给两端都供数据的角色。

它干的事是把数据变成可激活的受众：

• 采集与整合多来源数据——网站行为、第三方数据、CRM 等；
• 用 cookie / 设备 ID 把它们归并成用户画像；
• 切分出受众包（segments），比如”近 30 天看过 SUV 的男性”；
• 把这些受众**推送（激活）**到 DSP，让 DSP 知道”这个 bid request 里的人属于哪些值得追的人群”。

在买方，DMP 让 DSP 的出价从”盲买”变成”有依据地买”。在卖方，SSP 也会用数据给流量分层、提高优质库存的定价。

时代背景：随着第三方 cookie 退场、隐私法规收紧，纯靠第三方数据的 DMP 模式在快速衰退，重心转向以第一方数据为核心的 CDP（Customer Data Platform）。如果你今天看到一张图里还把 DMP 画在 C 位，记得在心里加一句”，以及正在接棒它的 CDP”。

5. 归因层：AppsFlyer / Branch 与自归因平台

到这里，“投放”那一半讲完了。但广告主真正关心的另一半是：钱到底有没有花对？哪一次曝光、哪一个渠道，真的带来了那次安装或购买？ 这就是归因（attribution）。

第 3.3 节说过，Web / 展示端的归因由广告主 Ad Server（CM360）统一记账。但在移动 App 世界，这件事由一类专门的角色主导——MMP。

5.1 MMP：中立的归因仲裁者

MMP（Mobile Measurement Partner，移动测量伙伴） 的代表是 AppsFlyer、Branch、Adjust，以及 Kochava、Singular 等。广告主把 MMP 的 SDK 集成进自己的 App，由它来做一件别人都做不公正的事：判定每一次转化（安装 / 注册 / 付费）到底该算在哪个渠道头上。

为什么必须是中立第三方？因为每个渠道都会邀功。同一次安装，如果让各个 DSP / 网络各自上报，安装数会被严重重复计算——10 个渠道可能报出 3 倍的总安装量。MMP 作为单一仲裁者，统一接收所有渠道的点击 / 展示数据，用 click-id、设备指纹、referrer 等做匹配，按**归因模型 + 时间窗（lookback window）**选出唯一的胜者，再去重给出一份可信总账。

这和广告主 Ad Server 解决的是同一类”统一真相”问题——只是战场从 Web 换到了 App，且因为 App 安装链路的特殊性（应用商店跳转、设备标识），演化出了 MMP 这个独立物种。

判定之后，MMP 还会把 postback 回传给中标渠道。这一步常被忽略，却是整个程序化闭环的关键：它把”什么有效”实时喂回 DSP / 网络的出价模型，让买方知道该往哪里加预算——呼应第 3.1 节 DSP 的出价模型和第 4 节 DMP 的受众。归因不只是记账，更是优化的反馈回路。

5.2 自归因平台（SAN）：围墙花园的例外

Google、Meta、TikTok、Snap、Apple Search Ads 这些巨头是个例外，业内称之为 SAN（Self-Attributing Network，自归因网络）。它们不把原始点击数据交给 MMP，于是归因流程反了过来：

1. MMP 把一次安装 / 事件发给 SAN；
2. SAN 在自己的日志里查有没有匹配的点击或浏览；
3. 有就自己认领这次归因，回告 MMP。

也就是说，这些渠道是”自己说自己带来了转化”，MMP 只能基于它们的自报来记账。这带来两个现实问题：利益冲突（裁判和运动员是同一人）和重复归因（多个 SAN 同时认领）。MMP 用一套**优先级排序（priority ordering）**在 SAN 之间、以及 SAN 与普通渠道之间裁决谁先拿到功劳。

下面这张图把两条归因路径画在一起：

普通渠道与自归因渠道（SAN）走的是两条相反方向的归因路径，但终点一样：把”这次转化算谁的”变成可回传、可优化的信号。

5.3 隐私把归因从”确定”推向”概率”

过去移动归因靠的是设备级标识（iOS 的 IDFA、Android 的 GAID）做确定性匹配。Apple 2021 年推出 ATT、默认关闭 IDFA 之后，这套确定性链路基本断了，行业被迫转向 Apple 的 SKAdNetwork / AdAttributionKit——一套聚合、去标识化、带延迟的隐私保护归因；Android 侧也有 Privacy Sandbox 在推进类似方向。

对 MMP 来说，这是一次角色重塑：从”确定性匹配器”变成了多种信号（SKAN 回执、聚合数据、概率建模）的聚合与建模者。今天选 MMP，比拼的早已不是”能不能匹配”，而是”在隐私约束下谁的建模更准”。

6. 把它们串起来：一次曝光的生命周期

抽象的框图不如跟着一次真实的曝光走一遍。下面以一个 App 为例：用户打开 App、到广告在 App 里渲染出来、整个程序化链路在大约 100 毫秒里发生的事。

整个过程对用户是无感的：App 界面还在加载，背后这场拍卖已经分出胜负。注意两个细节——发起竞价的是 App 端的 广告 SDK（In-App Bidding，对应 Web 的 Header Bidding），而曝光与转化的”权威计数”最终落在 App 内嵌的 MMP 归因 SDK，这正是第 5 节归因层存在的意义。

文字版分解：

1. 用户打开 App，广告位触发，App 端的 广告 SDK（Mediation，如 AdMob / MAX / LevelPlay） 发起请求。
2. SDK 先跑 In-App Bidding（Header Bidding 的 App 版本）：并行向多个 SSP / 广告网络 询价。
3. 每个 SSP / 网络 向众多 DSP 广播 OpenRTB bid request。
4. 每个 DSP 在 ~100ms 内决策：查 DMP 画像、对照预算与频控、跑出价模型，回一个 bid response（出价 + 选定的 creative）。
5. 每个 SSP / 网络把自己内部竞价的最高价报回给 SDK。此时 SDK 手里攒了一把来自不同网络的实时出价。
6. 进入最终决策（Mediation / Ad Server）：这些实时出价还不能直接投——它们要和走传统瀑布流（waterfall，按历史 eCPM 预估、不实时出价）的网络、以及直采订单放在一起做”全场比价”。这个裁判在 App 端是 Mediation（AdMob / MAX / LevelPlay），在 Web 端就是 Ad Server（GAM）。它挑出真正出价最高者，把胜出 creative 交回 SDK 在 App 内渲染。也就是说：In-App Bidding 决定”实时竞价里谁最高”，Mediation 决定”实时竞价 vs 瀑布流 vs 直采，整场谁最高”。
7. 渲染后，App 内嵌的 MMP 归因 SDK 触发曝光 / 转化上报；impression 在这里被权威计数，后续再按归因模型判定该算哪个渠道。

这条链路也解释了为什么延迟是 AdTech 的命门：每多一跳、每多 10ms，都可能让 DSP 来不及出价、让媒体丢掉这次收益。

7. 钱去哪了：ad tech tax

最后一个工程师常常被问到、却很少有人讲清的问题：广告主花的钱，有多少真正变成了媒体的收入？

答案是——一路被抽。这条链路上每一层都要收费，业内称之为 ad tech tax。一个粗略但有代表性的拆解：

注意各层计费基数其实不同——有的按总预算、有的按媒体支出或成交额，这里把它们简化成从 $1 里”逐层平减”，仅作量级示意。具体比例还因交易类型（公开竞价 vs PMP vs 直采程序化）、是否自建技术栈而差别很大。但核心结论是稳定的：广告主每投 $1，常常只有一半上下成为媒体侧的”有效媒体支出（working media）”。

各层大致在收什么：

这也是为什么近年来”供应链优化（SPO，Supply Path Optimization）“成为热词：买方想砍掉中间冗余的跳数，让更多预算落到真正的库存上；以及为什么大平台拼命想把 DSP/SSP/ADX/Ad Server 全握在自己手里——链路上每一层都是一道收费站。

7.1 把账真正算一遍：那笔”找不到主”的钱

上面那张”逐层平减”的图有个善意的简化：它假设每一块钱都落进了某个能点名的口袋。现实更难看。2020 年 ISBA 与 PwC 做过一次业界最认真的供应链审计——追踪 15 家广告主、经 12 家 SSP 投到 12 家媒体的真实花费，结论有三条值得每个工程师记住：

那 15% 不是”被谁贪了”，而是整条链路的可观测性失败：各方的日志对不上账——同一次曝光，DSP 记的成交价、SSP 记的清算价、媒体记的收入，三者之间存在系统性的、无人能解释的缺口。把它折成一次具体投放：

广告主预算           $1.00
├─ 可识别技术费       -$0.34   （有账可查：DSP / SSP / 数据 / 验证）
├─ unknown delta      -$0.15   ← 审计追不到主的钱（日志对不上账）
└─ 媒体实收            $0.51

关键洞察：ad tech tax 里最贵的不是”明税”，而是这 15% 的不可观测。明税你可以靠 SPO 谈下来、靠砍跳数省下来；但 unknown delta 是个测量问题——它的根因是链路上没有一份所有人都认的、对得上账的 log-level data。这也正好解释了 §5 那个反复出现的母题：整个 AdTech 的进步方向，是把越来越多”信任来的”环节，换成”可核查的”环节。 归因如此（确定性 → 可审计的 postback），拍卖如此（last look → 一价 + 可审计日志），供应链也如此（unknown delta → schain / sellers.json 逐跳核验）。

对工程师的落点很具体：当你被要求”优化供应链成本”时，第一优先级不是去谈费率，而是去拿到 log-level data、把三方日志对上账——能被测量的浪费才能被消除，那 15% 之所以一直在，正是因为它一直没被测量。

8. 常见误解 ↔ 正解

这一节专治这堆缩写最容易糊在一起的地方——也是面试和入行时最常翻车的点：

9. 一张速查表

把全篇压成一张随手可查的表：

记住四组对称关系，这张图就再也不会乱：

1. DSP ↔ SSP：买方引擎 ↔ 卖方引擎，中间是 ADX。
2. 广告主 Ad Server ↔ 媒体 Ad Server：同名不同命，一个管”我的广告效果”，一个管”我的库存分配”。
3. Trading Desk ↔ DMP：一个是人操盘的指挥层，一个是喂数据的弹药库，都不直接竞价。
4. DMP ↔ MMP：链路两端的旁挂层——DMP 在前端把数据”喂进去”，MMP 在后端把效果”测出来”再回传，一进一出形成优化闭环。

下次再有人甩给你一张密密麻麻的 LUMAscape，你只需要先找到那根”买方—卖方”的轴，剩下的框自然各就各位。

延伸阅读

这篇是整个程序化系列的”地图”，每个角色都有专文展开：

• 程序化交易模式：RTB / PMP / PD / PG：同一条 OpenRTB 管道上，库存到底有几种卖法。
• Header Bidding：Prebid.js vs Prebid Server：§2.4 客户端”扳机”与并行竞价的完整架构。
• 媒体 Ad Server 深挖：§2.1 那个”调度中心”的 decisioning / line item / dynamic allocation。
• App 广告 SDK 深挖：§2.4 / §6 里 App 端的变现 SDK、聚合与 In-App Bidding。
• last look 与拍卖透明度：“裁判兼运动员”与一价 / 统一竞价的来龙去脉。
• RTA 实时 API：DSP 出价前那一次”该不该追这个人”的实时问询。
• IAB TCF Explained：贯穿全链路的同意管理与隐私合规协议。

再是规范与一手资料：

• IAB Tech Lab. OpenRTB 2.6 Specification：DSP ↔ SSP / ADX 之间 bid request / response 的权威协议。
• IAB Tech Lab. ads.txt & app-ads.txt / sellers.json & SupplyChain Object：供应链透明度与卖方身份核验标准。
• ISBA & PwC. Programmatic Supply Chain Transparency Study：ad tech tax 与”无法追溯的差额”的权威实证来源。
• Apple Developer. SKAdNetwork / App Tracking Transparency：§5.3 隐私把归因从确定推向概率的源头。
• LUMA Partners. Display LUMAscape：那张著名的”密密麻麻生态图”的出处。

附录：术语表

• 买方 / 卖方（Buy Side / Sell Side）：出钱买流量的一方（广告主）/ 卖出库存的一方（媒体）。
• DSP（Demand-Side Platform）：替广告主自动出价买量的引擎。
• SSP（Supply-Side Platform）：替媒体自动把库存卖到最高价的引擎。
• ADX（Ad Exchange）：撮合买卖双方的实时拍卖市场；现实中与 SSP 高度融合。
• 媒体 Ad Server（如 GAM）：卖方侧库存排期与”直采 vs 程序化”流量分配的调度中心。
• 广告主 Ad Server（如 CM360）：买方侧素材下发、跨渠道统一计数与归因的系统。
• DMP / CDP：数据管理平台 / 客户数据平台；把数据变成可激活的受众，DMP 靠第三方数据正在被 CDP（第一方数据）接棒。
• Trading Desk：代理商 / 广告主跨多个 DSP 统一操盘的人机管理层，不直接竞价。
• 客户端 SDK：浏览器里的 GPT / Prebid.js、App 里的原生广告 SDK——整条链路的”扳机”。
• Header Bidding / In-App Bidding：调用 Ad Server 前并行公平竞价的卖方技术，网页 / App 两个载体。
• OpenRTB：IAB 定义的实时竞价标准协议。
• bid request / bid response：竞价请求 / 出价响应，OpenRTB 的核心一来一回。
• MMP（Mobile Measurement Partner）：中立的移动归因仲裁者（AppsFlyer / Branch / Adjust）。
• SAN（Self-Attributing Network）：自归因渠道（Google / Meta / TikTok）——不交原始数据、自报归因。
• postback：归因判定后回传给中标渠道、用于出价优化的异步通知。
• lookback window（归因时间窗）：归因系统接受”广告 → 转化”因果的最大时间窗。
• floor price（底价）：媒体 / SSP 给库存设的成交底线。
• frequency cap / pacing：频次控制 / 投放节奏。
• IVT（Invalid Traffic）：无效 / 作弊流量。
• ad tech tax：广告主预算在链路各层被逐层抽成的总和；媒体常只实收约一半。
• SPO（Supply Path Optimization）：买方收敛中间路径、砍掉冗余跳数的供应链优化。
• SKAdNetwork / ATT / IDFA / GAID：Apple 隐私归因协议 / App 追踪透明度 / iOS / Android 广告标识符。