1. AD系统概述：广告系统发展史、程序化广告生态、ADX/SSP/DSP/DMP角色定义

大家好，我是这门课的主讲。今天咱们聊聊广告系统的前世今生。

说实话，我刚入行那会儿，广告系统还没这么复杂。那时候的广告，说白了就是「买位置」——你花钱，我给你个广告位，放上去就完事。但现在呢？整个生态已经变成了一个实时竞价、数据驱动的精密机器。

1.1 广告系统发展史：从「买位置」到「买人」

广告系统的发展，我习惯把它分成三个阶段。你想想看，这其实也是互联网商业化的缩影。

第一阶段：传统广告时代（1994-2005）

最早的互联网广告，就是门户网站上的横幅。我记得2000年左右，新浪首页一个banner能卖到几十万一个月。那时候的广告交易，跟线下买报纸版面没啥区别——人工谈判、固定价格、按天售卖。

• 典型模式：CPD（按天付费）、CPM（按千次展示付费）
• 痛点：广告位空置率高、投放不精准、效果难衡量
• 代表产品：新浪、搜狐、网易的门户广告

第二阶段：搜索广告与定向时代（2005-2010）

Google AdWords 和百度推广的出现，彻底改变了游戏规则。为什么？因为搜索广告第一次实现了「意图匹配」——用户搜什么，就给他看什么相关的广告。

我在项目中遇到过最典型的案例：一个卖登山鞋的客户，在门户投了三个月，ROI不到1.2。转到搜索广告后，只投「登山鞋」「户外装备」这些关键词，ROI直接飙到4.5。这就是定向的力量。

• 典型模式：CPC（按点击付费）、关键词定向
• 突破：从「买位置」进化到「买人群」
• 代表产品：Google AdWords、百度推广

第三阶段：程序化广告时代（2010至今）

嗯，这里要注意。程序化广告不是某个公司发明的，而是整个行业被逼出来的。广告位越来越多，流量越来越碎片，人工谈判根本忙不过来。于是，RTB（实时竞价）应运而生。

说白了，就是每次广告展示机会出现时，多个广告主在100毫秒内竞价，价高者得。我2013年第一次调试RTB接口时，被那个100ms的超时限制折磨得够呛——后来才发现是DSP端的QPS预估出了问题。

• 典型模式：RTB（实时竞价）、PMP（私有市场）、PDB（程序化保量）
• 核心：数据驱动、自动化、实时化
• 代表产品：Google AdX、阿里妈妈 Tanx、腾讯广点通

1.2 程序化广告生态：四个角色一台戏

程序化广告生态里，有四个核心角色。我经常跟团队说，搞懂这四个角色，你就搞懂了整个广告系统的数据流。

1.2.1 DSP（需求方平台）——广告主的「智能采购员」

DSP 是 Demand-Side Platform 的缩写。它的任务很简单：帮广告主在多个广告交易平台上，用最合理的价格买到最合适的流量。

我曾经接手过一个 DSP 系统，它的出价策略写得跟天书一样。后来我重构时，核心就三件事：用户画像匹配、出价预估、预算控制。

• 核心功能：人群定向、实时出价、频次控制、预算分配
• 技术难点：100ms内完成用户画像查询、出价计算、竞价请求
• 典型产品：Google Display & Video 360、The Trade Desk、京东钼媒

1.2.2 SSP（供应方平台）——媒体的「智能管家」

SSP 是 Supply-Side Platform 的缩写。它帮媒体方管理广告位库存，对接多个广告交易平台，实现收益最大化。

嗯，这里有个常见的误解：很多人以为 SSP 就是「卖广告位的」。其实它更核心的能力是流量分级和底价策略。我见过一个媒体，SSP 配置了 7 层底价策略，从公开竞价到私有市场，层层过滤，最终把填充率从 60% 提到了 85%。

• 核心功能：流量管理、底价设置、广告位优化、收益分析
• 技术难点：多平台对接、流量反作弊、延迟优化
• 典型产品：Google Ad Manager、PubMatic、Magnite

1.2.3 ADX（广告交易平台）——广告界的「证券交易所」

ADX 是 Ad Exchange 的缩写。它是连接 DSP 和 SSP 的中间市场，负责撮合交易。

为什么需要 ADX？你想想看，如果没有 ADX，每个 DSP 都要去对接每个 SSP，那复杂度就是 N×M。有了 ADX，复杂度降为 N+M。我2015年参与过一个自建 ADX 的项目，最头疼的就是竞价逻辑的公平性——既要保证实时性，又要防止 DSP 作弊。

• 核心功能：竞价撮合、流量分发、反作弊、结算
• 技术难点：高并发（每秒百万级请求）、低延迟（<100ms）、数据一致性
• 典型产品：Google AdX、Index Exchange、OpenX

1.2.4 DMP（数据管理平台）——广告系统的「大脑」

DMP 是 Data Management Platform 的缩写。它负责收集、整合、分析用户数据，为 DSP 和 SSP 提供决策依据。

我曾经踩过一个坑：DMP 的用户画像更新频率设成了每天一次，结果广告主投诉说「昨天还在看车的用户，今天怎么还在推汽车广告？人家已经下单了！」后来我改成了实时更新，配合事件触发机制，才解决了这个问题。

• 核心功能：用户画像、人群标签、Look-alike 扩展、数据交易
• 技术难点：海量数据存储（PB级）、实时标签计算、隐私合规
• 典型产品：Oracle BlueKai、Lotame、TalkingData

1.3 角色之间的数据流：一次广告请求的完整旅程

说了这么多角色，它们之间到底怎么配合？我画个流程图你就明白了。

用户访问媒体网站
    ↓
SSP 收到广告位请求
    ↓
SSP 向 ADX 发送竞价请求（包含用户ID、广告位信息、底价）
    ↓
ADX 向多个 DSP 广播竞价请求
    ↓
DSP 查询 DMP 获取用户画像
    ↓
DSP 计算出价并返回（100ms内）
    ↓
ADX 选择最高出价者
    ↓
ADX 通知 SSP 获胜者
    ↓
SSP 返回广告创意给用户
    ↓
用户看到广告

整个过程，从用户打开页面到看到广告，必须在 200ms 内完成。我调试过最极端的情况：一个 DSP 的响应时间从 80ms 突然飙升到 300ms，结果整个 ADX 的填充率从 95% 掉到了 40%。排查后发现是 Redis 集群的某个节点挂了，导致用户画像查询超时。

1.4 小结：为什么你要搞懂这些角色？

说实话，很多刚入行的同学觉得这些概念太抽象，不如直接写代码。但我的经验是：不懂业务架构，你连 Bug 都找不到。

举个例子：有一次线上广告展示率突然下降，开发同学查了半天代码，没发现问题。后来我一看，是 SSP 的底价策略变了，导致大部分流量流向了私有市场，公开竞价拿不到量。如果不懂 SSP 和 ADX 的关系，你永远想不到是这个原因。

所以，搞懂这四个角色，你才能理解广告系统的数据流、瓶颈点、优化方向。下一章，我会带你深入每个角色的技术实现，从代码层面拆解它们的核心逻辑。