编辑导读：工作里常常会出现关注的指标或数据出现波动，或者在分析某个功能时发现难以理解的数据的情况，当APP产品业务线的某个数据指标出现异常的波动时，该如何着手数据异常分析呢？本文作者从自身经验出发，围绕数据波动的问题展开了思考，一起来看看~

一大早，刚刚到工位。

领导：“小明，XX指标昨天有些异常，你尽快确认下原因”。

小明：“好的，我这就看看，尽快给出结论”。

大家看到这个情景，不用我说，肯定都知道怎么回事儿。

相信大家都和小明一样，遇到波动时，我们都会条件反射的疑问：啥又异常了？

但是，再深入想想，这个“异常”是我们“理所应当”认为的“异常”，并不一定是真异常。

数据分析切忌“理所应当”，某些问题的原因，查到最后都在”理所应当“里。

我们来拆解下“啥又异常了”这句话

“啥”

一定有个主体。

我们要非常明确的知道，XX指标波动了，代表的业务含义是什么。

我们才能知道，业务上，这个波动可能引发的原因，以及可能影响的范围。

“波动”

就是起伏不定。

那么起伏了多少，我们如何量化？

量化了波动大小，再去对比校验，是否才能知道波动是否异常？

确认了波动异常，是否才应该去定位引发异常的原因？

“又”

说明不止一次的发生了波动。

那么，对于这些不止一次发生过的波动，我们是否有详尽的监控机制，预警机制，原因钻取机制？

再发现波动后，我们如何更高效、准确的落地原因和后续改进措施？

根据 “啥又异常了” 这句话的拆解，我们来总结下如何解读指标的波动。

第一步：定位波动主体及波动性质

我们先来解决“啥”的问题，也就是波动的主体以及波动是否异常。

关于波动的主体

明确是什么指标波动了，对应的业务含义是什么。

如果是通用指标，那可以视情况而定是否需要解释对应的业务含义。

• 步骤1：什么指标在什么时间内产生了波动，对应的指标，在业务上的含义是什么
• 步骤2：这个波动的对比方式是什么？环比？同比？还是历史均值？
• 步骤3：指标波动的大小，即对波动有一个具体量化

公式总结：业务 + 时间段 + 对比方式 + 定性的量化

如：DAU（业务）  昨日（时间段） 同比上周（对比方式）下降了5%（定性的量化）

关于波动是否异常

明确波动是否是异常，并给出自己的判断。

• 步骤1：结合之前的数据经验和业务了解，初步判断波动是否异常
• 步骤2：通过历史一段时间内的自然波动阈值，查看相对波动值是否超出阈值，如果超出，则大概率是异常
• 步骤3：针对异常，给出一个明确的定性，是由于什么原因引起（一定要尝试给结论，哪怕这个结论在初期是错的，在不断提升改进之后，也会越来越好）

tips：步骤3的结论总结，可以后期分析出结论后再给，当然，如果业务方着急，可以通过平时的积累和业务经验做一个初步判断

公式总结：历史情况 + 波动阈值 + 初步判断

如：对比去年的趋势发现（历史情况），此次下降超过了历史波动阈值（3%）（波动阈值），推测由于 XX 原因引起（初步判断）

第二步：定位波动的原因

我们再来解决“波动”的问题，也就是引起波动的原因。

原因初定：从大方向上，初步确定引起波动的原因。

从时间的角度

从时间的角度，我们可以依次看周同比、月同比、年同比。

即：从时间发展的角度，我们确认指标波动是否具有周期性，通过周期性的波动规律，我们能够大致定位该次波动是否属于季节性趋势

比如：

• 招聘的高峰期都在年后，那年后换工作潮，会导致APP的各项指标增长；
• 旅行的高峰期都在节假日，那旅行相关APP的指标在节假日肯定会有波动；

从业务的角度

从业务的角度，我们可以去和对接业务方了解沟通，确认近期“动作”。

即：从业务的方向出发，我们确认指标波动是否由于业务的变动导致，通常业务的变动如果和指标的变动时间点能对上，那么大概率是由于业务变化导致

比如：

• 市场近期做了一波市场营销，推广了某活动，那么，某些流量相关指标会出现波动
• 渠道侧调整了渠道投放策略，那么，某些留存&NU指标会出现波动

从指标的角度

从指标的角度，我们可以和数据工程师确认流程中的逻辑和执行流程。

即：从指标本身出发，我们确认指标波动是否由于ETL流程 or 指标计算口径中未发现的“坑”导致，通常ETL流程部分失败，或者埋点中，异常值增大，都是由于一些数据处理流程中的“坑”没被发现导致。

比如：

• 产出业务指标的表格依赖上游3个表格，但是因为没有配置依赖关系，且其中一个表格未产出，导致整体业务指标下跌。

这个问题通常整体指标都会波动，如果仅从时间和业务角度切入问题，对于问题的定位会比较难。

原因下钻：确定大方向后，下钻至能解释波动50%以上的可落地因素

从时间的角度

从时间角度切入波动，一般都是周期性趋势的解读，如：

• 某教育相关APP，高考出成绩那天流量达到顶峰，主要由于高考查分导致
• 某天气相关APP，由于近期天气多变，雨雪交加，导致流量上涨

tips：时间角度的切入，较考验业务的了解程度；只有知道产品的用户是谁，切入实际生活中，我们才能把指标波动和实际生活所结合

从业务的角度

从业务的角度，我们反而更容易切入问题，如：

• 渠道策略调整，导致NU及留存下降，那么我们对渠道细拆，就可以知道具体是哪个渠道影响了NU及留存

tips：针对业务的角度，我们需要确认，是业务上的什么“动作”影响了指标，就能比较清楚的知道原因及拆解方向

从指标的角度

从指标的角度，我们关注一些物理特性就好，如：机房、IP、域名、生成时间、整体数据量的大小。

因为通常情况下，ETL异常or指标中的“坑”，都会有较明显的异常值，我们只需要监控常用的物理特性中的异常值就好。

tips：针对指标本身，我们只需要前期设定部分规则，监控规则下的数据大小变化，就能较容易的发现异常

公式总结：数据结论 + 业务解释

如：拆分渠道后，我们发现，XX渠道NU大幅减少，对整体DAU减少贡献XX%（数据结论）；该情况和市场核对后，发现主要是由于XX渠道ROI太低，渠道侧减少该渠道的花费导致（业务解释）

第三步：确立后续TODO

我们最后来解决“又”的问题，也就是 波动之后，我们该做什么。

我们在上面两个步骤中，阐述了情况，明确了数据，解释了原因。那么，后续我们该做什么呢？

如果是好的波动，我们复盘，我们下次如何做成这样，或者做的更好。

如：市场做的活动，导致活跃orNU增加，那么下次，活动该如何做的更好，活动要不要更频繁的做…

如果是坏的波动，我们复盘，我们下次如何避免这样，或者提高。

如：APP某功能上线，要求用户先使用功能A，才能使用功能B，导致留存下降；那么下次新功能上线时，是否需要做AB测试，是否需要提前做用户问卷调研…

关于波动本身，我们是否对核心指标做了监控？

• 如果有，我们是否需要调整监控阈值，使异常抓取更敏感？
• 如果没有，我们是否需要建设相关的监控，建立异常报警机制？

最后

提一个问题：如果一个指标能拆分至N个维度，我们在不和业务沟通的前提下，如何定位波动解读的切入角度？

如：某流量型APP，整体流量可以拆分为 渠道、机型、城市、年龄、功能、是否算法推荐、是否运营操作等各种维度，在不和业务确认前，我们该如何定位本次波动需要从哪个角度切入？即 先拆解哪个维度，再拆解哪个维度？

以上，就是本期内容，希望对你有帮助。

本文由 @巡山猫 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。