编辑导读：工作里常常会出现关注的指标或数据出现波动，或者在分析某个功能时发现难以理解的数据的情况，当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，整体流量可以拆分为 渠道、机型、城市、年龄、功能、是否算法推荐、是否运营操作等各种维度，在不和业务确认前，我们该如何定位本次波动需要从哪个角度切入？即 先拆解哪个维度，再拆解哪个维度？
以上，就是本期内容，希望对你有帮助。
本文由 @巡山猫 原创，未经作者许可，禁止转载。
微信扫一扫 
支付宝扫一扫 
