每个变现团队都熟悉这种感觉：你确信某项waterfall调整会带来收入增长，但当你真正把它推送上线的那一刻，你屏住了呼吸。万一适得其反怎么办？万一fill rate下降怎么办？万一在你察觉并回滚之前，这个变更已经让公司损失了数千美元怎么办？
这种担忧并非毫无根据——正是因为这种担忧，大多数发布商在长达数月的时间里根本不去动waterfall配置，任由大量收入白白流失。解决之道不是停止做出任何改变，而是在正式上线之前对每一项变更进行充分的测试。
为什么Waterfall测试与众不同
对waterfall进行A/B test和测试按钮颜色或新手引导流程完全不是一回事。广告收入本身就带有很强的噪音——它会随小时、星期几、季节以及其他数十个因素波动。某项变更在周一看起来带来了10%的提升，实际上可能完全可以用正常的周度波动来解释。而且，与产品A/B test中劣质版本只会让用户体验略微变差不同，一个劣质的waterfall变体可能意味着每天数千美元的收入损失。
流量切分方法
测试waterfall变更最安全的方式，是将你的流量在当前配置（对照组）和拟议变更（实验组）之间进行切分。大多数mediation平台——包括AppLovin MAX和Unity LevelPlay——都支持流量分段功能，允许你将一定比例的用户路由到不同的waterfall配置上。
如何搭建一次干净的测试
从90/10的切分开始：90%的流量继续跑当前waterfall，剩余10%切换到新配置。这样可以将你的下行风险限制在10%的流量范围内，同时又能获得足够的数据来识别出真正有意义的差异。测试至少要运行七天，以便覆盖广告需求的周度周期性波动。
应该衡量什么
不要只盯着eCPM。请同时跟踪两组的以下指标：每千名日活跃用户带来的总收入（每千DAU收入）、fill rate、平均eCPM、每次会话的展示次数，以及至关重要的用户留存率。一个让eCPM提升15%、但同时拉长广告加载时间、让7日留存下降2%的waterfall变更，综合来看其实是负面的。
保留组方法
对于更重大的变更——例如新增或移除某个需求源，或是对整个waterfall结构进行重构——请使用保留组方法。永久性地（或在整个测试期间）将20%的流量保留在旧配置上，将新配置推送给剩余的80%流量。这为你提供了一个持续存在的基准用于对比，对于那些需要数周时间才能充分显现影响的变更而言，这一点尤其宝贵。
渐进式放量
一旦测试在10%的流量上显示出积极结果，也不要立刻就推送到100%。先提升到25%再观察几天，然后再提升到50%、75%，最后才到100%。每一步都是一个检查点，帮助你验证增长效果在更大流量下是否依然成立，并及时捕捉那些只有在规模化之后才会暴露的问题——例如某个需求合作方在小流量下表现良好，但分配更多流量后就无法维持fill rate。
那些能够持续做大广告收入的发布商，并不是那些做出最激进变更的人——而是那些对每一项变更都进行系统性测试、只把获胜方案推向全量的人。微小但经过验证的改进，会随着时间的推移复利成巨大的收益。
常见的测试误区
一次测试太多变量
每次测试只改动一件事。如果你同时调整底价、引入新的需求源、又重新排列waterfall优先级，那么结果就无法归因到任何单一变更上。请务必隔离变量。
测试过早结束
广告收入具有明显的星期效应。一个从周一跑到周三的测试，和一个完整包含一个周末的测试，所呈现的结论会完全不同。请始终让测试至少运行完整的七天，最好是十四天。
忽视统计显著性
在小流量段上观察到的5%收入增长，很可能只是噪音。在宣布胜者之前，请先确认差异在统计上是显著的——大多数mediation平台都会提供置信区间，或者你也可以使用标准的统计工具进行验证。
让流程自动化
托管式的变现合作伙伴可以代表你持续运行waterfall测试，使用自动化系统来切分流量、衡量结果并将获胜配置推向全量——完全不需要你的工程团队去搭建和维护测试基础设施。这会把waterfall优化从一项偶发性的手动工作，转变为一台持续改进的引擎。