企业官网建设流程全解析

聊到 RTB，很多刚接触程序化广告的同学可能第一反应是一堆缩写：DSP、SSP、ADX、DMP，感觉像在背字典。我最初接手 RTB 项目时也差不多，盯着某广告交易平台的文档翻来覆去，真正把一次实时竞价从请求到渲染的完整流程跑通，才算是把“RTB 流程”这几个字刻进了脑子里。

这篇文章没有教科书味，我只想站在一个实际做过 RTB 对接的从业者角度，把这套实时竞价链路从宏观逻辑到微观处理完整拆一遍。你会看到一次广告请求里藏着多少判断，也会看到那些文档里不会写、只有踩过坑才知道的细节。无论你是广告服务端的开发、做投放优化的同学，还是想弄懂这套机制的产品经理，读完之后至少不会对着术语表发懵。

1. 先从一次广告请求说起

1.1 RTB 到底在解决什么问题

在没有 RTB 之前，媒体卖广告位通常有两种方式：固定位置按天售卖，或者用广告网络自带的广告联盟慢慢匹配广告。前者效率太低，一个广告位可能要排期几天甚至更久，广告主想临时改预算根本来不及；后者对媒体来说不太透明，流量和收益常常被压得很低。

RTB，Real-Time Bidding，直译就是“实时竞价”。它解决的问题其实很朴素：把传统线下谈判和人工询价的过程，压缩到用户打开一个页面或者 App 的几百毫秒内，让“这次曝光到底该展示什么广告、这个曝光值多少钱”由算法现场决定。用户端看到的是一个广告位瞬间出内容，服务端背后可能已经完成了一场几十个系统参与的竞价。

这种方式的好处也很直接。对媒体来说，每一个流量都可以在真正曝光前卖给最高出价方，尤其是那些难以打包售卖的剩余流量，价格比原先分销模式高出一截。对广告主来说，投放不再依赖人工盯盘，可以做到每个曝光都参与竞价，并且动态控制预算。用户看到自己更可能感兴趣的广告，体验也不会那么差，虽然有时候仍然觉得“被监视了”，但这是另一个话题。总之，RTB 把广告交易从“批量排期”改成了“每单实时撮合”，这就是它的核心价值。

1.2 参与这次竞价的每一个角色都在忙什么

一次 RTB 流程里，表面上看只有用户打开页面、然后广告出现了，实际上背后是多个平台同时协作。我习惯把这条链路上的角色分成五类，逐个理解会比看流程图更清楚。

广告主和广告代理商：他们是出钱的人和投放的执行方。广告主提需求，比如品牌曝光、应用拉活、电商下单；代理商或者投放团队制定投放计划，设定预算、目标人群、出价策略。

DSP（需求方平台）：这是广告主这边的核心系统，代表广告主对接流量，决定“要不要这个流量”和“值多钱”。DSP 会同时接入很多广告交易平台，甚至直接对接一些媒体，统一管理多个投放活动。我日常主要就是开发和维护 DSP 系统，大部分工作都在这个环节。

SSP（供给方平台）和广告网络：他们站在媒体侧，帮媒体管理广告位库存，把流量接进 RTB 生态。SSP 也可以理解成媒体的“管家”，负责把广告位信息包装成一个标准请求，转发给广告交易平台赚取收入。

ADX（广告交易平台）：这是 RTB 的核心撮合场所，有点像股票交易所。它同时接收媒体通过 SSP 发来的请求，也接收多个 DSP 的竞价响应，然后按价格排序，把流量分配给胜出者。广告交易平台还负责时间控制、底价设定、反作弊过滤、最终曝光结算。

DMP（数据管理平台）：负责提供用户画像、行为标签、兴趣分类等数据。DSP 拿到请求后，经常要先向 DMP 查询或者携带本地已经同步好的标签，才能判断这个用户是否符合定向要求。数据管理平台不是每次都必须出现，但精准投放基本离不开它。

除了这五类，还有第三方监测、创意代理、反作弊服务商等配角。把这些角色串起来，一次 RTB 的大致路径就出来了：用户访问媒体页面 -> 媒体请求 SSP -> SSP 包装成广告请求发给 ADX -> ADX 向多个 DSP 发起竞价 -> DSP 出价并返回广告 ID -> ADX 选出胜者 -> 胜者广告素材下发到客户端展示 -> 后续曝光/点击行为回传。整个链路要在百毫秒级完成，这就是 RTB 最刺激的地方。

2. RTB 链路中的关键环节拆解

2.1 流量请求从哪来，怎么到竞价系统的

很多人以为 RTB 是从 ADX 开始的，其实第一步是从媒体端的广告位被请求开始的。用户打开一个带广告位的页面或 App 时，前端 SDK 或者 Ad Server 会根据广告位 ID 发起一个本地代码位请求，SSP 收到这个请求后，会填充一套标准化的 Bid Request，再发送给广告交易平台。

这一步有一个非常容易忽略的点：SSP 发给 ADX 的请求，跟 ADX 转发给 DSP 的请求，内容并不完全一样。ADX 通常会做一层“脱敏”和“标准化”，把媒体直连信息、底价信息、设备信息等处理之后，再广播给所有参与竞价的 DSP。所以咱们做 DSP 的同学，拿到请求后第一个动作就是校验数据的完整性和合法性，不要假设所有交易平台都会发全字段。

一个典型的 Bid Request 长这样，我简化掉了大量字段，保留核心部分：

{ "id": "req_20241120_001", "at": 2, "tmax": 100, "cur": ["USD"], "imp": [ { "id": "imp_01", "banner": { "w": 320, "h": 100 }, "instl": 0, "tagid": "ad_slot_8888" } ], "app": { "id": "app_12345", "name": "模拟短视频App", "cat": ["IAB1", "IAB3"] }, "device": { "ua": "Mozilla/5.0 (Linux; Android 12)", "ip": "203.0.113.10", "geo": { "city": "beijing", "country": "CN" }, "os": "android", "osv": "12" }, "user": { "id": "uid_cookie_or_transferred_id" } }

这份请求里有几个信息非常关键：tmax表示广告交易平台允许 DSP 返回的极限时间，单位是毫秒，常见值是 80、100、120 甚至更短，如果超过这个时间，你的响应直接被丢弃。imp是广告位数组，一个请求可能带多个广告位，但大部分情况下只有一个，如果有多个广告位，需要检查是否插屏、激励视频等不同格式混在一个请求里，处理逻辑要分开。device里的 UA 和 IP 是后续识别假量、做地域定向的基础，而user部分的用户 ID 现在越来越敏感，很多时候已经拿不到原始设备 ID 了，只能用匿名化后的转置 ID，这一点后面细说。

到了 DSP 这边，收到与这个类似的请求后，处理步骤大致是：先做基础解码和格式校验，然后拉取内部缓存的用户画像，再判断这个流量是否匹配当前投放活动的定向条件，如果匹配就计算出一个 CPM 出价，拼装好 Bid Response 返回。这个流程看起来短，实际每一步都藏着大量工程细节，我会在实操章节里展开。

2.2 竞价决策：怎么在几十毫秒内算出“值多少钱”

竞价决策是整个 RTB 链路最核心的环节，也是所谓“资源分配算法”的主战场。DSP 要在几十毫秒内判断这个曝光有没有价值，并算出一个价格，看起来像一门玄学，其实背后的逻辑非常清晰。

首先要做的是定向匹配。比如一个投放活动要求面向北上广深、年龄在 18-30 岁、对游戏感兴趣的用户。DSP 会把请求携带的信息和活动定向条件逐条比对。这里有个容易踩坑的点：请求里并不永远有完整的用户画像，媒体段只给了匿名 ID，所以 DSP 需要靠本地 DMP 缓存或者实时 DMP 查询来补充用户兴趣标签。如果本地没有命中，常见的做法是用规则兜底，比如默认人群、热点地域流量，甚至可以放弃竞价，因为为了一个流量去实时查一遍用户画像，时间上往往不允许。

定向通过之后，才进入出价计算。业界常见的简化公式大概是：

期望CPM = 目标CPA × 预估点击率(EC) × 预估转化率(CVR) × 1000

这个公式看起来很简单，但实操时还要叠加很多修正因素，比如当前预算剩余量、流量历史表现、竞价激烈程度、是否对新广告计划进行集冷启动探索。比如一活动目标 CPA 是 50 元，系统预估 CTR 是 1%，CVR 是 5%，那么期望 CPM = 50 × 0.01 × 0.05 × 1000 = 25 元。如果媒体设置的这个曝光底价是 30 元，那这单就没必要跟了；如果底价是 10 元，我可能会出一个略高于期望值的价格，比如 27 元，去抢下比心理价低的流量。

之所以要修正式计算而不是生硬套用，是因为单纯按公式出价会让预算消耗极不均匀。流量高峰段竞争激烈，很容易把预算在凌晨就烧光；尾部流量便宜，但转化差，也要靠调参控制。后面我会专门写这个。

还有一个跟决策强相关的问题是频次控制。同一个用户如果一天被同一个广告活动曝光了十几次，效果会快速衰减，还会被媒体和用户投诉。DSP 一般会用内存缓存维护一个用户维度的曝光计数，比如“同一用户在某个广告活动下每分钟至多竞价 1 次、每小时 3 次、每天 8 次”。这些计数更新必须快，但不需要绝对精准到毫秒，所以常用 Redis 加本地计数的混合方案，防止因为一次计数失败导致错过所有流量。

2.3 胜出之后：广告渲染与监测回传

当 DSP 把 Bid Response 返回给广告交易平台，竞价就进入了收尾阶段。竞价结果通常不是实时同步的，因为 ADX 要等所有参与者的响应到达，或等到超时才统一比价。胜出的判断标准是出价高于其他所有 DSP，并且不低于底价。有时候还要看“优先级”：有些广告位是自家优先，外部 DSP 出多高都没有机会，这在 PMP 这种私有交易中尤其常见。

胜出之后，ADX 会把它选中的广告创意返回给客户端去展示。这里有一个容易被误会的点：DSP 在 Bid Response 中返回的并不是广告图片本身，而通常是创意 ID、广告素材 URL 或者一个可跳转的追踪链接。最终的素材渲染是由媒体端完成的，DSP 反而没有直接下发。所以如果创意服务出了问题，哪怕竞标赢了，用户也看不到广告，收益照样没有。

渲染完成，紧接着还有一环：监测回传。曝光监测、点击监测、第三方验证监测都会以“监测 URL”的形式出现在交易平台提供的 win notice 或者竞价响应参数里。曝光时客户端去请求监测链接，把曝光信息记录下来；点击时再触发点击监测；后续如果产生转化，比如下载、注册、购买，又会回流到 DSP 的转化接口。

这一步是把 RTB 闭环掉的关键，因为数据回传如果不准确，后面的算法调优、预算分配都无法进行。实际操作中，监测链接经常因为各种网络限制、脚本拦截、配置错误而丢数据，结果就是后台看到曝光很多、点击很少，甚至转化完全空白。排查这类问题时，第一步一定要先确认监测请求是不是真的发出去了、有没有到达服务器，而不要急着改出价。

3. 实操还原：对接一场 RTB 竞价的全流程

3.1 与广告交易平台交换的参数定义

刚才讲了链路逻辑，接下来我按自己做过的模拟项目 X，走一遍从拿到请求到返回响应的完整实操流程。这里为了贴合多数广告交易平台的标准，参数命名基本沿用常见协议，所以看起来会比较眼熟。

接入前要明确几个必填参数：API Endpoint，也就是竞价地址；一次请求和响应的最大字节数；支持的广告位格式和尺寸；广告分类表；以及最重要的，合同里的响应超时时间。这些不提前谈清楚，联调的时候会浪费时间。比如有些交易平台要求响应里的创意在 200 字节以内，只给创意 ID，素材另外走创意配置接口上传；另一些平台则要求返回完整的 VAST XML 或原生广告数据，格式完全不同。

我通常会在代码里维护一套统一的对象模型，把不同交易平台的请求转换成内部标准结构。像 Bid Request 里的 Imp 对应内部 Imp 对象，Exchange 对应 Exchange 枚举。这样做的原因很简单：同时接入多个广告交易平台时，如果每个平台写一套解析逻辑，新增一个平台就要改一遍投放判断代码，迟早要出乱子。标准化之后，只有接入适配器需要处理平台差异，核心投放逻辑完全复用。

3.2 一次完整竞价的时序与代码还原

下面我用伪代码的方式展示一个 DSP 处理请求的完整时序。这不是生产级代码，只是把关键逻辑串起来，帮助理解每一步的位置和取舍。

# bid_handler.py - 简化版DSP竞价入口 def handle_bid_request(raw_request): # 1. 基础解码与校验 bid_req = parse_and_validate(raw_request) if bid_req is None: return empty_response() # 2. 广告位过滤 if not check_imp_size(bid_req): return empty_response() # 3. 用户画像补充 user_profile = profile_cache.get(bid_req.user_id) if user_profile is None: user_profile = query_dmp_online(bid_req.user_id) # 4. 定向匹配 matched_ads = find_eligible_campaigns(bid_req, user_profile) if not matched_ads: return empty_response() # 5. 出价计算 best_bid = 0 best_ad = None for campaign in matched_ads: price = calculate_bid(campaign, bid_req, user_profile) if price > best_bid and check_budget(campaign, price): best_bid = price best_ad = campaign # 6. 拼装响应 if best_ad is None: return empty_response() return build_bid_response(best_ad, best_bid)

第一步的parse_and_validate看起来不起眼，但最容易出问题。广告交易平台每秒会推给我们大量请求，其中有不少是重复的、字段缺失的、甚至格式错误的。如果在这里做太多复杂的规范解析，延迟会上升；如果完全不做，后面很多数据都用不了。我习惯只校验关键字段：id是否为空、imp是否为空、device或app是否缺少一个，缺了直接返回空响应，不参与竞价。

第二步的check_imp_size是广告位尺寸匹配，比如只支持 320x100 和 1280x720 的横版横幅，如果请求里是 320x480 的插屏，可以直接放弃。有些广告交易平台还支持多尺寸广告位，imp里带了一组尺寸候选，这时候我们就要识别出最合理的那一个，而不是只看第一个。

第三步获取用户画像，是性能瓶颈高发区。本地缓存命中率高的话，这一层基本在 1-2 毫秒内返回；如果缓存不中，实时去 DMP 查询可能耗时 5-20 毫秒，对 RTB 来说已经不可接受了。所以我一般不会在每次未命中的情况下都去查 DMP，而是把未命中的用户视为“未知人群”，用低优先级规则做兜底，或者直接放弃竞价。

第五步算出价时，要结合预算控制。check_budget不是一个简单的“剩余预算 > 出价”判断，而是要做预算预热。我遇到过很多次这样的情况：数据库里还剩不少预算，但因为并发太大，每次都要锁一行数据去扣减，结果响应直接被拖到超时。后来改成内存计数扣减，再异步同步到数据库，瞬间就稳了。关于预算的方法，我会在后面展开。

3.3 预算、频控、超时这三个坑

先说说预算。RTB 的投放需求是预算是按天或者按小时设置的，不是一笔大额资金放在那慢慢扣。如果每次竞价都去数据库实时扣预算，高峰期百万 QPS 根本顶不住。常见的做法是预算预热到 Redis 和本地内存，竞价时只扣内存计数，扣满或者达到设置的上限就停止参与竞价，然后每隔几秒异步同步一次消费记录到数据库。

这里面有个细节：本地内存预算预热很容易出现“多台机器各自有各自的计数”的问题。如果每台机器各拿 10 万预算，那么四台机器加起来可能实际消耗 40 万，超过总预算四倍。我常用的办法是中央预算服务按比例分配，每台机器拿预估预算的 1/N或者固定一个配额，然后定期从中央服务拉取最新的剩余预算校准。如果某台机器配额快用完了，可以实时向中央服务申请扩容一段。这也是为什么自研 DSP 的预算系统经常比竞价引擎本身还复杂。

再说频控。频控做不好会出现同一个用户短时间内看到同一个广告几十次，用户反感不说，转化率也会明显掉。RTB 频控不能只靠媒体端配置，因为一次 RTB 请求无法可靠地获知用户最近七天的曝光次数，DSP 自己的投放日志才是精确依据。所以我通常在本地维护一个近期的曝光计数表，键是“用户ID + 广告活动ID”，值是一个滑动窗口内的次数和最近时间戳。这套表本身也会成为热点，所以还要做缓存淘汰和降级策略。高峰时如果 Redis 挂了，宁可放弃部分非核心活动的频控校验，也不要连累整体响应延迟。

超时是 RTB 所有环节中最残酷的规则。广告交易平台给的 tmax 如果说是 100 毫秒，那么 DSP 必须在 100 毫秒内把 Bid Response 发回去，否则直接忽略。这里的“忽略”不是竞标失败，而是你的响应根本不被处理，连输给谁都不知道。排查超时的时候我会同时看机器负载、网络延迟、解析耗时、DMP 查询耗时。网络延迟是最隐蔽的，有时候机房与广告交易平台网段之间的路由绕了一下，平时看起来延迟不高，高峰下就会突破临界点。条件允许的话，DSP 应该尽量和大型广告交易平台同地域部署，或者在多个地域做分布式接入，就近接收请求。

4. 运行中常见问题与排查实录

4.1 匹配率低：用户画像与流量“对不上”

做 RTB 最让人头疼的问题之一，是系统明明接入了很多流量，但实际竞价的匹配率总是很低。所谓匹配率，就是有资格参与竞价的请求数除以总请求数。这个问题出现的原因很多，我把它总结成下面这张速查表，方便对照排查。

这个表其实是来自我实际踩坑的记录。最典型的一个场景是：投放活动的定向条件写了“兴趣标签为游戏且近三天有广告点击行为”，结果请求量确实大，但只有不到 5% 的请求能命中这个条件。排查的时候发现，DMP 回传的标签更新不是实时的，很多用户已经有小一周没攒新标签了。解决方案是增加“无标签但设备画像相似”的近义人群，并把匹配优先级做了调整，匹配率从 5% 提到了 18%，虽然变准度略降，但整体消耗和效果反而更好了。

4.2 超时率高：谁拖慢了竞价的 100 毫秒

超时率是最直接影响 RTB 收益的指标。想象一下你接了个大盘，流量不错，预算也够，但因为响应总是慢那么 20 毫秒，导致大量响应被广告交易平台丢弃，钱明明可以花出去却花不出去。

按照我的排查经验，超时往往不是某一个环节突然变慢，而是整体时间被各种琐碎消耗磨掉了。我在排查时会把一次请求的处理时间拆成几段：

• 网络接收与初步解析：从前端接入到进入程序的时间，可能受网络抖动影响。
• 业务处理：广告位过滤、定向匹配、出价计算的耗时，这段通常可控。
• 外部资源查询：DMP 查询、Redis 频控查询、预算服务调用的耗时。
• 响应返回：组装完毕后到发出响应的耗时。

有一次很典型的案例：某个广告活动从某广告交易平台接入后，超时率一直徘徊在 15%，优化了一个多月都没降到 5% 以下。后来我们把入口服务的访问日志和响应时间逐条比对，发现每次触发“跨机房 DMP 查询”的时间都在 30 毫秒以上，而命中本地缓存的请求只需要 1 毫秒。于是我们把画像查询结果做成双层缓存：热点用户本地存 5 分钟，冷门用户走 Redis 合并查询，只有真正的未命中才发往 DMP。这个改动直接让 p95 响应时间从 98 毫秒降到 65 毫秒。

也要提醒一下，不要迷信“提高服务器配置”就能解决超时。RTB 引擎的瓶颈通常是大量不合理的阻塞调用，比如没有用线程池、没有做异步化、同步等待外部结果等。生产环境中，宁可偶尔错过少量画像信息，也不要因为一次查询把全局延迟拉高。

4.3 预算消耗不平：凌晨预算被抢光

预算消耗不均是个老生常谈，但几乎每个人都会遇到。主要表现是新投放计划刚上线时，因为出价过高，凌晨流量便宜阶段就把预算全部烧完，导致白天黄金时间反而没有预算可以参与竞价。

这个问题有几种解法。第一种是设置小时级预算上限，比如全天预算一万，那么每个小时最多消耗全天预算的 10%，防止前几个钟头“梭哈”。第二种是动态降低出价峰值，当小时消耗速率超过预期时，把出价的最高阈值往下压，而不是立刻停投。这样可以在保持参与度的同时，把预算留到后面更可能转化的人群上。第三种是建立“预算学习期”，新计划上线前几个小时只投小额测试流量，等数据回来后再逐步放量。

我自己的经验是，不要把所有活动都套用一个预算平滑策略。品牌活动更看重有效曝光时间分布，效果好就保持在黄金时段竞价；效果类活动比较依赖转化数据的积累，更适合前几小时集中测试各种人群，然后快速收敛。把这些策略配置做成可调，而不是写死在代码里，运营和优化同学就能自己调整了。

5. 从跑通到跑好：指标、优化与经验

5.1 运营 RTB 系统必备的监控指标

如果只把 RTB 流程跑通，能收到请求、能返回响应、能看到消耗在涨，就以为万事大吉，那是远远不够的。一个 RTB 系统想要稳定跑好，必须有完整的监控体系。我一般会分三层来看指标。

第一层是接入层指标。包括每秒收到的广告请求数、请求解析失败率、请求体量大小分布、来源广告交易平台分布。这些指标反映的是流量质量和接入稳定性。如果请求量大但有效请求率低，首先要怀疑是不是媒体验签配置有问题或者出现了大量重复请求。

第二层是竞价层指标。包括参与竞价率、出价分布、响应率、超时率、胜出率、平均胜出价格。其中“响应率”和“胜出率”经常被混淆。响应率是有响应返回的请求占比，胜出率是返回竞价的请求中最终赢下曝光的比例。比如响应率高但胜出率低，大概率是出价普遍低于市场水平；响应率低但胜出率高，也许是被丢弃了很多无效流量，要认真排查超时和容量问题。

第三层是效果层指标。包括曝光、点击、点击率、激活、转化成本、留存甚至后端 ROI。这部分是广告主真正关心的。如果曝光和点击都正常，但转化特别差，可能是媒体流量质量差、创意卖点不符、落地页体验不佳，甚至监测口径出了问题。RTB 的追求从来不是单纯低价买到很多流量，而是让每一分预算换回可衡量的商业结果。

为了不让你看花眼，我把最常盯的指标列成下面这张表：

5.2 后续可以扩展的方向

RTB 流程跑顺之后，下一步优化方向通常不是“继续加服务器”，而是把系统做得更聪明。

可以尝试把固定公式出价升级成基于模型预估出价。比如用点击率预估模型来算每次曝光的价值，而不是拍脑袋定一个 CPM。我见过很多团队从公式出价切到简易 GBDT 模型后，同样的预算，整体转化成本下降了 10%-20%。模型上线后还要做好兜底，防止部分流量特征缺失引起预估偏差过大。

还可以向多广告交易平台聚合方向发展。只接入一家广告交易平台往往体量有限，而且不同平台的流量风格差异很大。DSP 的历史使命就是广接流量，统一竞价。所以把多平台响应结果统一汇集到同一个流量调度中心，做跨平台频控和预算分配，是早晚要做的事。

另一个很值得关注的方向是 PMP 私有交易。它虽然不再像完全开放的 RTB 那样大规模公开竞价，但基于实时竞价底价和优先级机制的私有挂牌，在品牌广告里越来越常见。提前把 PMP 的交易优先级、底价、包量逻辑融合进现有 RTB 流程里，会让系统适应更多投放场景。

5.3 说一下我个人在这一路踩坑过来的体会

RTB 不像做一个普通接口及时通信那样，调一次通了就可以高枕无忧。它是一个全链路协同的系统，任何一环掉链子都会影响最终投放效果。我实际操作中最大的收获不是某个优化技巧，而是“把没用的东西早点丢弃”的习惯。面对广告交易平台海量的请求，识别出真正值得出价的那些流量，比在每个请求上都精打细算要重要得多。宁可少参加一次竞价，也不要为了未必有效的流量浪费计算资源和预算。

另一个想强调的小技巧是：抓包和日志是最好的老师。前期接入平台拿不到流量像无头苍蝇时，我会把收到的请求原样存一份，再写一个离线分析脚本，把广告位尺寸、来源域名、设备类型、分类分布全部统计一遍。这些分析结果往往比平台自己给的报告更直观，因为它能看出你的实际流量构成长什么样，而后面的定向和出价策略，很多都源于这一步的发现。

RTB 这套机制看起来复杂，拆开看都是很朴素的供需匹配逻辑：先把流量标准化，再在限定时间里判断价值，最后用价格决定资源去向。把这套逻辑吃透了，再往后看任何广告系统，视野都会清晰很多。