大多数发布商都能把eCPM精确到小数点后两位。他们按地区和广告形式追踪fill rate，每天盯着ARPDAU。但如果你问他们：用户触发广告后，要多久这条广告才能真正渲染出来？你通常会得到一脸茫然的表情。latency是几乎没人测量的指标——而它正是移动变现中最昂贵的问题之一。
什么是广告latency？
广告latency指的是从你的应用请求一条广告，到该广告完全渲染并呈现在用户眼前之间的时间。对于rewarded video，它是用户点击"观看广告"到视频真正开始播放之间的空档。对于interstitial，它是触发事件到全屏广告出现之间的延迟。对于banner，它是banner位在内容加载之前空置的时长。
在理想状况下，这个数字应该是零。现实中，从优化良好的配置下的200毫秒，到配置糟糕的waterfall中的3秒以上都有——而每一毫秒都在让你损失金钱。
latency如何摧毁收入
被放弃的展示
当一条rewarded video要花三秒才能加载出来时，相当一部分用户会直接放弃并关掉提示。他们想要奖励，但还没到愿意盯着转圈加载动画等下去的程度。那次展示本来是值钱的——你的waterfall找到了买家，竞价也赢了——但用户根本没看到广告。你的dashboard里fill rate看起来还不错，因为从技术上说广告确实被投递了。但收入已经丢了，因为用户在广告渲染之前就放弃了。
更低的完成率
那些熬过慢加载的用户，在广告开始之前就已经烦躁了。烦躁的用户更倾向于想办法跳过或尽早关闭广告，这会拉低你的完成率。由于许多需求方按每次完整观看付费，更低的完成率直接拉低你的有效eCPM——即便dashboard里显示的原始eCPM看起来没变。
用户体验退化
广告latency不仅让你丢掉眼前这次展示——它还会训练用户彻底回避广告位。如果你的rewarded video一贯很慢，用户会学到：点"观看广告"按钮就意味着等待，于是他们就不点了。你的互动率会永久下降，可用于变现的展示总量也随之减少。
latency从何而来
waterfall层级过多
在传统waterfall中，每个需求源都是按顺序依次调用的。如果你有八个需求源，每个响应需要300毫秒，那么在你开始渲染获胜广告之前就已经过去了2.4秒。这正是in-app bidding和Open Bidding最有力的理由——它们会同时调用所有需求源，把顺序latency坍缩为一次往返。
SDK初始化
有些SDK采用懒加载，也就是说它们要等到第一次广告请求时才开始初始化。这些SDK的第一次展示会明显比后续展示慢很多。在应用启动时预先初始化你最重要的SDK——即便会让启动时间略微增加——通常能带来净正向收益，因为它消除了首次展示的latency。
过重的创意素材
一段15兆的视频素材，下载和buffer所花的时间显然比3兆的素材长得多，在新兴市场常见的慢速网络下尤其明显。你无法直接控制创意的大小，但你可以设置timeout阈值，跳过加载缓慢的素材，改用更轻的备选项。
如何测量广告latency
大多数mediation平台默认不会把latency指标呈现出来，你必须自己埋点。记录应用发出广告请求时的时间戳，再在广告的展示回调触发时再记一次，两者之差就是你真实的latency。把它当作一个分布来追踪，而不是一个平均值——中位数可能是400毫秒，但如果你的95百分位是4秒，就说明你有一个严重的长尾问题，正影响着5%的全部展示。
如果你不测量广告latency，你就是在变现堆栈中最具影响力的变量之一上盲飞。今天就开始测量——你几乎一定会发现一笔自己从不知道正在损失的收入。
如何降低latency
积极预加载
当前广告一结束就立即请求下一条。对于rewarded video，在用户看到"观看广告"按钮之前就把下一条广告准备好。对于interstitial，在应用流程中自然的过渡节点进行预加载。
设置timeout
为每个需求源配置最大等待时长——通常是1到2秒。如果某个需求源在timeout内没有响应，就直接跳到下一个。丢掉少数几条高eCPM但慢速的展示是值得的，只要其余95%的展示能即时加载。
迁移到bidding
尽可能用并行bidding替代顺序waterfall调用。通过GAM的Open Bidding以及通过mediation平台的in-app bidding，相比传统waterfall都能大幅降低latency。
与托管合作伙伴合作
托管变现合作伙伴会在你整个广告堆栈上持续监控latency，在追求收入的同时也持续优化速度。他们能识别出哪些需求源在贡献不成比例的latency，并调整你的配置来消除瓶颈——往往能帮你找回那些你根本没意识到自己在损失的收入。