广告技术系列（五）：聚合平台的运作原理

一个运动内容 App 想通过广告支持免费训练计划。它同时接入几家广告联盟，运动鞋品牌的预算可能经不同广告源到达同一个广告位。对开发者来说，问题不只是选最高报价：广告要能及时加载、适合当前场景、只展示一次，收入和奖励还要能核对。

前四篇解释了商业关系、竞价、数据与度量，本篇把这些概念连接到移动端聚合系统。聚合平台的价值，是把多方接口和不同价格语义组织成可控的交付流程，并让每次选择能够解释、每笔反馈能够追踪。 最优决策受到截止时间、参与范围和业务约束限制，不能承诺每次获得整个市场的最高收益。

聚合层连接的是角色，不是四类互斥公司

开发者提供广告展示机会，广告主购买触达，DSP 支持广告主参与交易，SSP 支持媒体管理和出售供给。Network 可以同时汇聚库存和预算。聚合平台主要帮助开发者接入并调度多个广告源；这些角色可能由同一家公司兼任。

SDK 是端侧集成方式，Network 是业务角色，不能将它们视为同义词。部分交易在服务端进行，客户端再用适配器完成素材加载与展示；并非每次报价都由各家 SDK 在本机独立计算。

AdMob Mediation、AppLovin MAX、Unity LevelPlay 等产品可以作为接入研究对象，但应逐项比较广告格式、地域覆盖、适配器版本、收益事件、费用和支持方式，而不是给出没有统一条件的“填充率最高”排行。

聚合服务可以通过订阅、技术服务、分成或关联广告业务获利，实际费率和付款关系以合同为准。拥有自有广告源不等于已经存在不公平行为，独立部署也不自动证明中立。可审计的选择规则、费用口径和结果记录，才是开发者判断透明度的依据。

一次加载从请求走到可展示状态

端到端链路应区分三个时段：决定调用哪些来源，取得可用广告，以及用户触发后的实际展示。网络、格式、素材大小和预加载命中都会改变时间，不能统一写成“打开 App 后 200ms 看到广告”。

请求创建时生成 request ID，读取同一版本的广告位配置、使用限制、频次与实验分组，并确定整个加载任务的截止时间。向来源分配的超时必须服从剩余总预算；每层各给一个完整超时再串行等待，最终仍可能超出页面能接受的时长。

竞价完成后，候选广告仍需通过素材、有效期和可展示状态检查。用户离开页面、广告对象已销毁或策略已禁止展示时，应停止后续交付。竞价成功、加载成功、展示成功、奖励达成和收入结算是不同事件，不应共用一个“成功”计数。

预加载移动等待时间，也引入状态管理

可以在训练结束前提前加载奖励广告，让用户主动选择观看时更快进入播放。命中预加载才能获得这种体验；缓存未命中、过期或网络失败时，仍需要清楚的等待和退出路径。

广告对象的有效期、可展示次数、线程要求和生命周期由具体 SDK 决定。例如 AdMob 的 Android 激励广告文档提醒缓存广告一小时后过期，不能把这个时长推广为所有来源的通用值。AdMob 激励广告文档

缓存键和失效判断需要覆盖广告位、来源、格式及影响资格的状态。用户撤回授权、应用切换账户或政策配置变更后，不能只因素材还在内存中就继续展示。内存、带宽和未展示广告的浪费也应进入预加载评估。

Waterfall 与实时竞价比较的是什么

Waterfall 根据人工配置或历史 eCPM 排列来源，按顺序尝试，直到找到可交付广告。优点是能够接入不支持实时报价的来源，代价是排序依据可能无法反映当前机会。

假设 A 的历史 eCPM 为 12 元、B 为 8 元，A 在序列中靠前。这不代表 A 为本次展示承诺支付 12 元；如果它成功返回，系统通常不会再知道 B 对这个机会的潜在收益。因此不能把历史排序值当作真实报价，再计算一次竞价的确定收益损失。

In-App Bidding 让符合本次条件的来源提交实时报价。它与 Web Header Bidding 都是在分配前引入竞争的方式，但端侧集成和服务端调用方式不必相同。未参与、超时、无合格广告或不满足约束的来源不会出现在有效候选中；同步发起请求也不意味着获得所有来源的真实估值。

实时竞价结果还可以进入 Waterfall。在 AdMob 的公开流程中，竞价胜者按 eCPM 被放入中介序列；排序在它之前的 Waterfall 来源可以先尝试，未填充时再轮到竞价胜者。AdMob 竞价流程

图中的数字均为构造示例，单位为同一币种每千次展示。A 的 10 是历史排序值，B 的 9 是本次有效竞价报价：A 先尝试，并不代表最终一定赚 10；A 未填充时，仍需检查 B 是否有效、可加载且还有时间。

底价、预测收入、历史 eCPM 和当前报价应保存各自的类型。币种、税费、分成和毛额/净额需归一化后比较，报价的精确程度也不能因统一单位而消失。对历史均值乘固定折扣不能保证校准；需要按来源、地域、格式和样本质量评估偏差，并保留探索机会。

将端侧、决策和数据职责分开

以下是设计分工，不要求五层各自部署为独立服务。

配置可以推送到本地缓存，同时保留周期核对或版本拉取机制，避免丢失一次推送后永久使用旧状态。收到新版本后先校验再原子替换，不能让同一次决策读取半旧半新的规则。

频次控制若完全依赖延迟聚合的展示计数，多个并发请求可能一起通过。严格上限需要相应的一致性或预留机制；近似计数则明确误差和观察窗口。跨设备控制还受合法可用身份与数据延迟限制。

截止时间与失败处理决定链路是否可控

延迟治理不能只看平均值，也不能只报一个 P99。应分别观察各阶段分布、超时率、用户可见等待及成功交付率，并按广告位和网络条件拆分。

历史响应分位数可以帮助设定超时，但超时导致的截尾样本可能掩盖真实慢响应。动态调整仍需上限、最小样本和回退规则，避免在短期噪声下不断振荡。

已返回报价高于其他来源历史最高价，不是安全提前终止条件。 历史最高值并非未来报价的上界。如果决定提前结束，应将它作为收益与时延的策略取舍；只有协议提供可信上界等更强条件，才能证明等待不会改变选择。

迟到响应要检查任务状态，不能覆盖已经选定或展示的广告，也不能重新触发展示。结束逻辑和回调处理需要幂等状态转换；请求取消是否真能停止远端工作，要依据适配器能力，而不是只把本地状态改为取消。

允许返回“本次无广告”，是保护主业务的一种正常结果。可靠性目标应是限制影响、保留证据并恢复服务，而不是承诺任何故障都不影响收入。

收益事件需要保留精度和结算状态

展示级收入能够帮助比较来源、广告位和获客批次，但回调值未必等于最后到账金额。AdMob 的收入事件包含金额、币种与精度类型，应一起保留；估算值、精确值和未知值不能无差别累加后宣称“真实 ROAS”。展示级收益接口

推荐记录请求、广告对象、来源和事件的关联标识，以及金额单位、币种、发生时间、接收时间、精度、状态和配置版本。不要用浮点数反复累加金融金额；也不能跨币种直接求和。

流处理的 exactly-once 仅在其连接器和事务边界内成立。SDK 重复回调、客户端重试和第三方调整不会自动被消除；还需要稳定事件键、业务幂等、持久记录与结算对账。采用 Flink、Kafka 或某种架构名称，本身不证明端到端只计一次。

将收益与获客数据关联，可以按允许的范围分析批次 LTV，但不必强求每次展示还原到自然人。聚合报告、身份缺失和归因窗口都影响完整性；第五篇沿用第四篇的区分，归因收入并不等于广告造成的增量。

奖励发放与收入确认是两条账

奖励广告需要将“用户满足奖励条件”作为独立业务事件。客户端回调可提供即时体验，但对有价值的奖励，可以使用来源支持的服务端验证，并处理重放、延迟和关联失败。

例如 AdMob SSV 提供签名参数与 transaction ID。服务端按文档校验签名，再关联本应用、本用户和本次奖励，并以事务 ID 去重；验签成功不能替代业务资格检查。SSV 验证说明

奖励发放与幂等记录必须具有一致的提交边界。验证超时后显示待确认，并提供恢复方式，不能一边重试一边反复发奖。

使用限制应进入请求和生命周期

聚合多个来源扩大了数据流向，也增加了 SDK 配置责任。初始化前需要确定哪些数据可以发送给哪些来源，并把适用状态传递给适配器；不能等 SDK 已完成采集后，再用统一弹窗补做全部控制。

ATT 不允许用设备指纹替代未获授权的跨应用跟踪；第一方数据也不代表可以无限制共享。具体处理依据与地区、用途和合同有关，不应给“上下文”“哈希”或某个 API 简单贴上自动合规标签。Apple 用户隐私说明

Google 已在 2025 年 10 月公布包括 Topics、Protected Audience 等技术的退出计划，不能继续把它们作为必将取代移动标识的路线图。选型应检查实际可用的平台能力及版本。Google 的技术调整公告

反作弊可以综合事件关联、异常频率、完整性信号和结算差异，但可见范围取决于接入权限与数据质量。代理网络或异常时序只是线索，不能单独证明欺诈；策略应同时评估漏放、误伤和复核成本。不能借反作弊名义绕过平台对数据使用的限制。

运营策略最终要回到增量交付

引入新来源时，除了 eCPM，还应观察每个合格用户或请求的总收益、展示率、等待、崩溃、留存和 SDK 维护成本。新增来源提高平均报价，却拖慢加载并减少实际展示，未必值得保留。

广告位设计应尊重用户当下任务：主动选择的激励广告说明奖励条件，插屏尽量放在自然间隔，原生广告保留明确标识。频次和广告源数量按实验与产品目标决定，不能根据国家分组直接套用固定数量、价格和展示次数。

自动化可以生成配置建议、发现异常、管理测试与逐步放量，但需要明确发布权限和停止条件。共享预算仍可能让实验组互相影响，物理拆分或普通交叉验证不能自动消除干扰，分析方法应与随机化方式匹配。

聚合平台长期值得积累的是适配能力、清楚的事件契约和可解释的决策记录。有了这些基础，开发者才能判断：增加一个来源是否带来收益，提前停止竞价是否值得，以及收入变化究竟来自策略、流量还是数据。下一篇继续讨论这些事件如何进入计费、预算预留和结算。