如果你正在运营一款移动应用，希望最大化 ARPDAU、eCPM 和整体广告收入，那么在瀑布流广告聚合与应用内竞价（有时也称为移动端头部竞价）之间做出选择，就是你今年最关键的一项配置决策。几乎所有广告变现 SDK 都支持这两种模式，而我们审查过的账户几乎都只使用其中一种，而且通常并不适合其当前发展阶段。
这是我们提供给接入 Apps Kit SDK 前 30 天开发者的实操指南。本文假设你已经了解广告聚合的概念：向多个广告平台请求出价，并展示收益最高的广告的中间层；现在，你想知道如何进行配置。我们将逐一介绍两种模式的运作机制、一个具体竞价案例、影响每项决策的延迟预算，以及一份明天就能带到团队站会上讨论的 30 天上线清单。
瀑布流广告聚合：最初的广告变现模式
瀑布流广告聚合根据历史 eCPM 对广告需求源排序，再依次向各个需求源发起广告展示请求。第一个以不低于所设底价完成填充的广告平台胜出。这种模式简单、易于排查问题，且结果可预测，因此支撑了移动应用广告变现的第一个十年。
代价是竞价效率不高。针对某个特定用户，排在第三位的广告平台可能愿意比第一位支付更高的价格，却根本没有参与竞争的机会。每一次展示都可能损失收入，而随着用户群体变得更加多样化，这种收入差距还会扩大。另一个隐性成本是运营：瀑布流中每次底价调整都需要人工决策，手动调优的瀑布流有效期大约只有两周，之后 eCPM 曲线就会发生漂移，原有的优先级排序又会失准。
应用内竞价：实时发现广告价值
应用内竞价针对每一次广告展示，让所有广告需求源参与统一的实时竞价。它没有固定排序，实时出价最高者胜出。这与推动网页展示广告转向头部竞价的机制相同，只是迁移到了移动端。
对于大多数应用广告变现体系，将广告请求链路顶部从瀑布流切换为应用内竞价，可以使 eCPM 提升 10–30%。提升最明显的是 Tier 1 国家市场的优质激励视频广告库存，因为竞价方之间存在真正的竞争；提升最小的则是价格不敏感细分市场中的横幅广告库存，因为竞价几乎无法发现额外价值。
需要权衡的是延迟。一次竞价必须等待希望纳入的竞价方中响应最慢的一家，或者在超时后放弃该竞价方可能带来的收益。超时时间设得太短，会限制 eCPM；设得太长，则会限制单次会话的广告展示次数。大多数团队在启用竞价后的第一周才吃到这个教训：ARPDAU 上升了，会话时长却下降了。
具体竞价案例：额外收益从哪里来
假设有一次激励广告展示机会，四家广告平台都有意参与。在按上周 eCPM 排序的瀑布流中，广告平台 A 排在首位，底价为 9 美元；B 为 7 美元，C 为 5 美元，D 为 3 美元。广告平台 A 以 9 美元完成填充，你获得 9 美元。
现在将同一次展示改为实时竞价。广告平台 A 出价 8.40 美元，因为这个用户的预估价值低于上周的用户群体。广告平台 C 恰好有一个精准定向该地区和操作系统的广告活动，因此出价 11.20 美元。最终以 11.20 美元成交：同样的四家广告平台，无需新增任何接入，单次展示收益就提升了 24%。把这个增幅乘以每天数百万次展示，收益差异就很直观了。
这个例子也说明，竞价并不意味着收入会自动增加。如果广告平台 C 的适配器需要 1100 毫秒才能响应，而你设置的超时时间是 900 毫秒，C 就无法参与竞价，A 以 9 美元胜出。你承担了竞价带来的延迟成本，却没有获得任何额外收益。
为什么混合模式几乎适合所有开发者
能够持续最大化 ARPDAU 的配置是混合模式：在广告请求链路顶部使用应用内竞价，这部分竞价方竞争充分，值得承担延迟成本；随后通过一条层级数受限的短瀑布流兜底填充。瀑布流承接没有实时竞价方愿意购买的展示机会，让填充率保持接近 100%，同时避免将所有广告源配置项都纳入竞价所带来的额外延迟。
Apps Kit SDK 的默认混合配置是：让所有支持应用内竞价的竞价方参与竞价，包括 AdMob、AppLovin MAX、Meta Audience Network、Unity LevelPlay、Mintegral 和 Pangle；之后配置两层非竞价广告平台的兜底瀑布流，并设置较保守的底价。即使开箱即用，这套配置的效果也能达到甚至超过我们在配备专职广告运营团队的工作室中见过的手动调优配置。
没人写下来的延迟预算
每次广告请求都有一个以毫秒计的延迟预算，你应该把它明确写下来。激励视频可以先将端到端延迟预算设为 1500 毫秒：SDK 组装请求 200 毫秒，竞价 900 毫秒，广告素材下载 300 毫秒，渲染 100 毫秒。超过这个时间，用户可能早就去做别的事了。
每新增一家竞价方，都应在你的前三大国家市场使用真机测量其 p95 响应时间。如果某个国家的 p95 高于竞价超时时间，该竞价方在当地的每次竞价中都会悄无声息地落败。应按竞价方分别设置超时上限，而不是统一设置全局超时，这样既能挽回收入，又不会延长中位数水平广告展示的等待时间。
今天就能落地的决策矩阵
以这份矩阵为起点，只有在数据明确支持其他方案时才做调整：
- 尚未上线 / DAU 低于 5 万：仅使用瀑布流，接入三家广告平台，优先关注留存，而不是 ARPDAU
- DAU 为 5 万–50 万，以激励广告为主：使用混合模式，激励广告启用竞价，插屏广告使用瀑布流
- DAU 为 50 万–500 万，广告形式多样：采用全面混合模式，所有支持竞价的广告源均启用竞价，并配置两层兜底瀑布流
- DAU 超过 500 万，覆盖多个地区：采用全面混合模式，按国家设置竞价超时时间，并按广告形式配置底价矩阵
- 工具类 / 单次会话不足 5 分钟的应用：仅使用瀑布流，竞价带来的额外开销无法通过收益弥补
让收益叠加增长的广告展示配置技巧
广告聚合模式决定单次展示的收入上限。广告展示配置则决定实际展示多少次广告，以及每次展示的价值。无论使用哪种聚合方案，以下四个调优方向都能进一步放大收益：
- 按国家和广告形式设置底价，每周根据过去 14 天的出价数据重新计算；每个广告单元配置一套底价矩阵，而不是一个固定数值
- 限制瀑布流层级：保留前六家竞价方，加上两家兜底广告平台；再往后增加的广告源只会增加延迟，不会增加收入
- 按时段设置展示频控：晚上 8 点在 Wi-Fi 环境下有效的配置，到了凌晨 3 点的低端设备上，可能会严重损害留存
- 将日活用户人均广告展示次数作为领先 KPI：它通常比 ARPDAU 提前约一周发生变化，让你能在财务团队发现问题前完成修复
什么时候纯瀑布流仍是正确选择
在两种情况下，纯瀑布流广告聚合仍然优于混合模式。第一，应用的平均会话时长不足五分钟，任何实时竞价产生的延迟成本都会抵消竞价带来的收益提升。第二，应用所在市场中，真正形成有效竞争的竞价方不足三家，竞价无法发现额外的价格空间，额外开销就成了纯粹的成本。
除这两种情况外，混合模式更有优势。如果你不确定，可以选一个激励广告位开展为期两周的 A/B 测试，对比不同用户分群的 ARPDAU。通常不到十天，就能清楚看出哪种方案更适合你的应用。
能够最大化广告收入的开发者，并不是接入广告平台最多、或拿到最亮眼聚合合作条款的人，而是让聚合模式与广告库存相匹配，并将广告展示配置作为日常运营工作持续管理的人。
30 天上线清单
如果你的团队正在从纯瀑布流迁移到混合模式，可以参考我们部署 Apps Kit SDK 时采用的以下顺序。每一步都可以通过远程配置回滚，无需发布应用新版本。
- 第 1–3 天：接入指标监测，覆盖日活用户人均广告展示次数、广告请求 p95 延迟，以及各竞价方的超时率
- 第 4–7 天：仅在第一大国家市场的一个激励广告位启用竞价，其他设置保持不变
- 第 8–14 天：将实验组的 ARPDAU 和第 7 天留存率与对照组比较；如果两项指标均达标，就扩展到所有激励广告位
- 第 15–21 天：在同一国家市场将竞价扩展到插屏广告，密切关注对会话时长的影响
- 第 22–30 天：推广到全球，按国家设置竞价超时时间，并移除瀑布流尾部的低效广告源
本周该做什么
如果这篇文章只让你采取一项行动，那就是对照上述默认混合配置，审查当前的广告聚合方案，并按用户分群监测日活用户人均广告展示次数。将这两项调整结合起来，通常能在两周内让 ARPDAU 提升 20–40%，无需新增任何广告平台，也无需修改一行应用代码。本文其余所有建议，都是在这两项基础之上的进一步优化。
