App 广告收入突然下降,先查哪天变了

广告收入掉下来，团队常常先盯住最后一列：今天收入多少，少了多少，能不能把 eCPM 调回来。

这很自然，也很容易把排查带偏。

当前收入只是结果。它把广告请求、填充、展示、点击、竞价和统计口径揉成了一个数字。你看见 1000 元变成 600 元，却还不知道是少了请求、少了展示、点击变差，还是报表晚了一天。

排查的第一问应该换成：从哪一天开始变？

这个日期不是为了立刻给出原因。它的作用更朴素：把原本无限展开的猜测，收缩成一个有限的变更清单。

收入突降是前后对比题

一款已经稳定变现的 App，收入突然偏离常态，说明某个链路或统计过程发生了变化。只看今天的收入，只能知道结果；把曲线拉回首次异常日，才有机会查看异常前后到底动过哪些东西。

先确认“首次异常日”也有边界。不要把自然波动当成异常，也别只看一天。可以用此前一段稳定区间作参照，结合分渠道、分广告位的日数据，找出第一次持续偏离的日期。若报表本来有 T+1 或更长延迟，先等数据回补完成。

这一步看似慢，实际在帮你避免一件更麻烦的事：在证据还没形成前，就把广告源、底价或广告位全部改掉。改动越多，后面越难知道原问题在哪里。

把变化日对齐到五类变化

找到日期后，不要急着下结论。把它前后两三天的记录摊开，依次核验五类事项。

第一类是流量。投放渠道、地区、机型、版本和新老用户结构都可能改变广告需求与出价。DAU 没变，不代表流量价值没变。

第二类是版本和路径。一次发布可能改了广告请求时机、前后台逻辑、埋点或页面跳转。尤其是激励视频和开屏，少一次展示并不一定会立刻在总量指标里显眼。

第三类是广告配置。广告位开关、频控、底价、聚合排序和灰度范围，必须查到生效时点。不要只看“谁改过”，要看改动何时真正覆盖到异常用户。

第四类是广告源状态。把请求量、填充率、展示量、点击率和 eCPM 分开看。收入下降可能从其中一项开始，也可能几项同时发生。

第五类是数据口径。时区、归因、报表延迟、退款或回补都会让一条曲线看上去突然拐弯。先排除数据问题，才能谈业务问题。

这类拆法会直接改变排查路径。

一个智能设备App案例：开屏贡献约 80% 的收入。区域点击启用后，点击率降为原来的 10%，eCPM 从 20 至 30 元降到 1.5 至 3 元。

只看最终收入，团队可能会得到一个宽泛结论：开屏不赚钱了。

这个结论几乎没有行动价值，可能引出加广告位、调底价、换渠道等一串改动。

把收入曲线拉回首次异常窗口，问题会换一种问法：该窗口是否启用了区域点击？只有开屏位受影响吗？CTR 是否先跌，展示和填充是否仍然正常？

这几项答案决定下一步。

若 CTR 先跌，而请求、填充和展示没有同步异常，优先查点击规则和开屏交互路径；若填充先跌，再去看广告源和聚合排序；若所有广告位同时变，再回头查流量结构或报表口径。

变化日没有替你找到原因，却把“什么都可能”变成了几条可以逐项证伪的假设。

虽然这个案例不能证明某条规则必然造成所有 App 的收入下降。但能提供一个实用的方法：规则切换与指标变化相邻时，先对齐时间窗口，再看哪一层指标先动。

如果你自己的曲线在某日开始下滑，而当天恰好有发版、策略发布或流量结构变化，这只是一个优先级更高的假设。还要继续看对应的指标是否在同一窗口变化，才能决定是否回滚、修复或继续观察。

给团队留一份异常变更台账

收入异常不必每次都从零开始查。可以给广告变现建立一份很简单的台账：

收入曲线一旦出现异常，先写下首次异常日，再把这张表补齐。它不能替你找到原因，却能让团队从同一组事实出发，而不是各自带着一个猜测去改系统。

广告收入下降时，最该先保存的不是“今天少了多少钱”，而是变化刚开始的那个时间点。时间点把排查顺序拉回可验证的范围：先确认哪天变了，再决定查哪一层。

如果你的团队曾被一次收入突降打断节奏，不妨把“首次异常日”写进例行复盘。下一次问题出现时，至少不会从一堆猜测开始。