何时该迁移您的广告聚合平台？
切换广告聚合平台是移动发布商可以做出的最重要决定之一。聚合层控制着用户看到的广告、每次展示的收益以及广告体验的流畅度。迁移带有实际风险，但留在次优平台上会产生每天递增的复合成本。
需要评估迁移的明确信号：
- eCPM下降却没有市场解释：如果您的eCPM在行业基准保持稳定的情况下下降，您当前的平台可能存在需求缺口或优化问题，而新的竞争者已经解决了这些问题。
- 其他地方有更好的竞价支持：如果您的平台支持3个竞价合作伙伴而竞争对手支持8个，您正在损失竞拍密度（和收入）。
- SDK停止支持或弃用：当聚合平台宣布SDK生命周期结束或停止积极开发功能时，迁移不再是可选项。这是时间问题，而不是是否的问题。
- 缺少广告格式：如果您的平台不支持应用开屏广告、激励插屏广告或原生竞价，而竞争对手支持，每个缺失的格式都代表着损失的收入。
- 报告限制：如果您无法获得按网络、地理位置、广告单元和格式细分的详细eCPM数据，您就是在盲目运营。现代平台将此作为标准功能提供。
迁移规划：并行测试方法
聚合迁移的基本规则是永远不要硬切换。并行测试方法在用真实流量验证新平台性能的同时保护您的收入底线。
并行策略的运作方式如下：
- 阶段1（设置）：将新的聚合SDK与现有SDK并行集成。在两个平台中配置相同的广告单元、需求来源和底价。
- 阶段2（流量分配）：将10–20%的流量导向新平台，同时在现有平台保留80–90%。使用远程配置标志或A/B测试框架来控制分配。
- 阶段3（监控）：至少并行运行两个平台2周，比较分配中的eCPM、填充率、延迟和崩溃率。
- 阶段4（扩展）：如果新平台达到或超过旧平台，逐步增加其流量份额：20%到50%到80%到100%。
- 阶段5（清理）：一旦100%的流量在新平台上稳定运行至少一周，删除旧的聚合SDK和相关配置。
切换前所需数据
在启动任何迁移之前，从您的当前平台导出并记录全面的基线数据。这些数据有两个目的：为评估新平台提供比较基准，以及为您新的瀑布或竞价设置的初始配置提供依据。
关键数据点
- 按网络和地域分类的历史eCPM：至少要有按国家或国家组细分的每个需求来源的过去90天每日eCPM。这告诉您哪些网络在哪些市场表现良好，并为您的新瀑布排序提供依据。
- 按网络和广告格式分类的填充率：填充率为5%的高eCPM网络与填充率为90%的中等eCPM网络贡献不同。准确配置需要两个指标。
- 按广告单元分类的展示量：了解哪些广告展示位置产生最多展示。这些是您影响最高的单元，应该最后迁移以最小化风险。
- 延迟数据：如果可用，记录每个网络的平均广告加载时间和超时率。这有助于在新平台上设置适当的超时值。
- 按星期几和每天时间分类的收入：广告市场有每周和每日周期。记录这种规律可以确保您不会将正常的周期性变化误认为是与迁移相关的变化。
理想额外数据
- 按队列划分的用户级ARPDAU
- 会话级广告频次数据
- 与广告SDK活动相关的崩溃和ANR率
- 详细的竞价级日志（如果您的当前平台提供）
逐步迁移流程
步骤1：安装新的聚合SDK
将新的聚合SDK和所有必需的适配器SDK添加到您的项目中。还不要删除旧SDK。在并行测试阶段两者将共存。关键操作：
- 添加核心聚合SDK依赖项
- 为您计划使用的每个需求来源添加适配器SDK
- 在您的Application类或AppDelegate中初始化新SDK，在远程配置标志的控制下
- 验证构建在新旧SDK之间没有冲突的情况下能够编译
步骤2：配置广告单元和需求来源
在新平台的仪表板中重新创建您的广告单元配置：
- 创建与现有展示位置匹配的广告单元（相同格式，横幅相同刷新间隔）
- 添加所有需求来源及其各自的应用ID和展示位置ID
- 根据旧平台的历史eCPM数据设置初始底价
- 为所有支持的来源启用竞价；为其余来源配置瀑布条目
步骤3：实施流量分配
使用远程配置系统（Firebase Remote Config、您自己的功能标志系统或简单的服务器端切换）控制哪个聚合SDK处理每个会话：
- 在应用启动时，检查远程标志以确定哪个SDK在此会话中处于活动状态
- 整个会话只通过活动SDK请求广告。不要在会话内混合SDK。
- 在您的分析中记录哪个SDK处于活动状态，以便您可以清晰地分割性能数据
步骤4：至少并行运行两周
两周是最短评估期。这段时间涵盖工作日和周末模式，考虑需求波动，并让竞价算法有时间学习您的库存。在此期间：
- 每天监控两个组的eCPM、填充率和总收入
- 跟踪两个组的应用稳定性指标（崩溃率、ANR率）
- 关注用户体验问题（广告加载缓慢、空白广告框架、意外的全屏广告）
- 除非有明显问题，否则在此期间不要对任何平台进行配置更改
步骤5：比较并决定
并行期结束后，从以下几个维度比较两个平台：
- 每DAU收入：主要指标。如果新平台每日活跃用户产生的收入相同或更高，它通过了核心测试。
- 填充率：更高的填充率意味着更多可变现的展示。填充率高5%且eCPM相似的新平台是明显赢家。
- 延迟：更快的广告加载意味着更好的可见性和用户体验。
- 稳定性：如果新SDK增加了崩溃率，收入增长可能不值得。
步骤6：切换和清理
一旦您决定采用新平台，将流量增加到100%，再监控5–7天，然后完全删除旧SDK。更新依赖项列表，删除旧的初始化代码，并清理与流量分配相关的任何条件逻辑。
聚合迁移中的常见错误
即使计划周密的迁移也会遇到问题。了解常见错误有助于您避免或快速从中恢复：
- 历史优化数据丢失：旧平台上的竞价算法拥有几个月关于您的库存的数据。新平台从零开始。预计在算法学习期间会有1–2周的次优性能。
- SDK冲突：同时运行两个聚合SDK可能会导致依赖冲突，特别是如果两者都以不同版本包含相同的需求来源SDK。在部署到生产环境之前，在预发布环境中进行彻底测试。
- 不匹配的底价：在新平台上设置过高的底价会破坏填充率。设置过低会在桌上留下钱。以历史数据为起点，在第一周后进行调整。
- 比较不对等的时间段：广告市场会波动。将新平台的第1周与三个月前旧平台的第1周进行比较不是有效的比较。并行测试消除了这个问题。
- 急于推进时间表：展示快速结果的压力会导致过早的结论。两周的并行数据是最低要求。对于拥有大量流量的发布商，四周更佳。
从AdMob聚合迁移到Google Ad Manager
最常见的迁移路径之一是从AdMob聚合迁移到完整的Google Ad Manager平台。这一升级由GAM对规模化发布商的卓越功能驱动：
- 直接交易支持：GAM允许直接销售的广告系列与程序化需求竞争，这是AdMob聚合不支持的
- 高级报告：GAM按广告订单项、广告主、广告素材和自定义维度提供详细报告
- Open Bidding：GAM的服务器端竞价比AdMob的客户端聚合支持更广泛的交易所合作伙伴
- 统一定价规则：从单一界面为所有需求来源设置具有地理、设备和格式精细度的底价
这个特定的迁移是RevenueFlex经常处理的迁移之一。从AdMob聚合过渡到完全托管的GAM设置涉及在GAM中重建整个广告配置、映射需求来源、根据历史性能建立新的底价，以及运行并行评估以确认收入中立或改善。以适当规划进行此过渡的发布商在GAM瀑布完全优化后通常会看到10–25%的收入增长。
聚合迁移不是周末项目。这是一个需要周密规划、严格并行测试和耐心的多周流程，同时新算法要学习您的库存。但对于在低效平台上的发布商来说，切换带来的长期收入影响使短期努力变得非常值得。