广告聚合

广告聚合是做什么的

广告聚合（ad mediation）是管理多个需求源竞争应用广告库存的那一层。应用不再只接一家广告网络、被动接受它的价格，而是集成一个聚合 SDK，由聚合层针对每次广告请求决定让哪家接入的网络来投放。链条是：应用广告请求 → 聚合层 → 需求源竞争 → 胜出广告 → 用户。

聚合平台具体提供：

• **一个 SDK 包住多个。**为每家接入网络提供适配器，应用只需维护一个主集成，而不是十几个原生 SDK。
• **选择逻辑。**历史上是瀑布流（按预期 eCPM 排序依次调用网络）；如今以实时应用内竞价（in-app bidding）为主——各网络对每次展示提交真实出价。
• **统一报表。**分网络、分广告位、分地理的收入、展示、填充率和延迟——一个地方、一套口径。
• **运营控制。**广告位配置、频次上限、网络开关、A/B 测试和分人群规则，全部无需发版。

主流平台有 AppLovin MAX、Google AdMob 聚合、Unity LevelPlay 和 DT FairBid。注意一个结构性张力：每家主要聚合服务商同时运营自己的广告网络，而这个网络又在该平台主持的竞价中出价。把竞价透明度和报表诚实度当作选型标准，而不是默认假设。

瀑布流 vs 应用内竞价

瀑布流按历史平均 eCPM 给网络排序、依次调用直到有人填充。它的缺陷是慢性的：历史平均值对单次展示定价失准，每次顺序调用都叠加延迟，排名靠前的网络可以挑走优质展示、退回剩下的。运营一条有竞争力的瀑布流意味着无止境的手动层级调优——许多团队为了强制细颗粒度竞争，给同一家网络维护多个不同价格地板的副本。

应用内竞价（应用世界的 header bidding 等价物）用按展示出价取代了按历史排序：接入网络实时报价，价高者得。实际收益是延迟变平（一场并行竞价取代顺序遍历）、按展示的价格发现，以及瀑布流运营工作的基本消失。

现实是混合的：多数配置让竞价网络与传统网络的残余瀑布并行，聚合层把两者合并成一个决策。方向很明确——竞价持续吞噬份额——但"完全竞价化"在所有网络和地区还不是普遍现实。

把聚合运营好

1. **为增量收入加网络，不为数量。**每家网络都增加 SDK 体积、初始化耗时和隐私合规面。测量每新增网络的边际 ARPDAU；多数应用在几家精选竞价方之后就到平台期。
2. **盯每家网络的延迟。**一个慢出价方拖累它参与的每场竞价。聚合仪表盘有分网络响应时间——强制超时，砍掉慢性拖延者。
3. **竞价架构下慎用价格地板。**地板在瀑布流时代是制造竞争的工具；在实时竞价里，激进的地板大多是拿填充率换微薄的 eCPM 收益。先对照保留组测试，再相信地板有用。
4. **报表按地理和格式分段。**网络实力在不同市场和格式（激励视频 vs 插屏 vs 横幅）之间极不均匀；在美国激励位值得保留的网络，在拉美横幅位可能就是死重。
5. **每月用网络方的付款仪表盘对账聚合报表的收入。**适配器配置错误和差异条款都会表现为"报告的"和"实付的"之间的缺口。
6. **管好 SDK 物料清单。**每个适配器的版本锁定、每家网络的数据采集行为、每条隐私清单条目，都是你名下的维护负担。每季度审计适配器清单；不交房租的就清退。

常见错误

• **加网络不测延迟。**第 9 家出价方带来的收入增益，很少能扛得住它造成的竞价变慢——而广告交付变慢会压低所有网络的每会话展示数。
• **盲目使用历史 eCPM。**在残余瀑布流里，过期的平均值系统性地错配展示；在竞价里，历史 eCPM 是报表输出，不是控制输入。
• **无视 SDK 体积和维护成本。**聚合栈是应用体积膨胀、ANR 率上升和发版摩擦的主要来源之一。边际网络必须既付媒体收入的账，也付工程拖累的账。
• **优化 eCPM 的同时填充率崩塌。**收入 = eCPM × 已填充展示数；拉高单价、饿死交付的聚合调优是在甲板上摆椅子。ARPDAU 是让聚合保持诚实的指标。
• **假设裁判是中立的。**在自家聚合里出价的第一方需求值得审视：对同样的广告位，比较它和第三方出价方的竞胜率与价格。

FAQ

只用 AdMob 还需要聚合吗？ 首发或小应用用单一网络没问题——AdMob 一家就能充分填充多数地区。当可观的收入依赖于竞争时，聚合才配得上它的复杂度：通常是应用的规模足以让多家网络认真出价的时候。

该选哪家聚合平台？ 诚实的差异点：竞价网络在你关键地区的覆盖、平台自有需求的强度（它会是大出价方）、报表质量、SDK 工程质量。游戏向的栈偏向 MAX 或 LevelPlay；更广的应用品类常从 AdMob 聚合起步。决策风险高就跑分流测试——结果确实因应用和受众而异。

应用内竞价一定比瀑布流好吗？ 在网络参与度相同的前提下，竞价在延迟和运营上胜出。边缘情况仍存在——有些网络通过托管瀑布位的出价仍高于其竞价适配器。混合架构的存在正是为了两头都拿到。

聚合和用户获取怎么互动？ 广告收入喂进 LTV，而几家聚合平台（特别是 AppLovin 和 Unity）坐在两边——它们的网络买你的库存，它们的 UA 产品花你的预算。展示级收入数据流入 MMP 才能闭合 ROAS 回路；应用变现路径覆盖完整的收入栈。

为什么实际到账比仪表盘显示的低？ 网络侧差异（他们的计数规则）、无效流量回扣、被计为已填充的自有广告或交叉推广展示、适配器在部分设备上静默失败。每月分网络对账；持续超过几个百分点的缺口值得调查或清退。