把波动当异常,小心变傻子

一大早,刚刚到工位。

领导:“小明,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,整体流量可以拆分为 渠道、机型、城市、年龄、功能、是否算法推荐、是否运营操作等各种维度,在不和业务确认前,我们该如何定位本次波动需要从哪个角度切入?即 先拆解哪个维度,再拆解哪个维度?

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

 

本文作者 @巡山猫 。

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部