当APP产品业务线的某个数据指标出现异常的波动时，该如何着手数据异常分析呢？
一般来讲，产品的某些数据指标都会具有固定的波动周期，而且每个周期内数据的变化应该趋于稳定，但在数据监控体系里的日报、周报、月报中某数据指标突然不再符合预期的稳定变化，这就是我们所说的数据出现异常波动。在这种情况下，我们就需要去深挖数据异常产生的原因。
而做数据异常分析核心就是结合以往经验及各种信息，找出最有可能的原因假设，通过将数据指标的进行拆分，再多维度分析来验证假设，定位问题所在。其过程中可能会在原假设基础上建立新的假设或者是调整原来假设，直到定位原因。
使用该框架最重要的一点是在回答问题的开始就告诉面试官你的回答框架！你为什么要提前告诉面试官你的框架呢?
你要知道面试官并不完美，他们有时会问一些不清楚或不正确的问题。所以，如果你能提前给他们提供你的框架，他们就能在问题问得不好的情况下纠正错误。
最重要的是，你需要让面试官知道你是如何看待这个问题的。例如，面试官让你分析一下，为什么我们的产品增加了15%的注册量。
如果你向面试官解释你的框架，面试官可能会说：让我们只关注数据分析——不需要进行竞争对手的研究或客户研究。这样，你可以推断出你应该关注季节性、群体、价格变化等。
类似地，如果你告诉面试官整个框架，但面试官更关心竞争分析，他会告诉你跳过框架的其他部分，这样我们就可以专注于竞争对手的行为。
在面试里你不可能在短时间内阐明每个步骤，因此你需要和面试官进行交流确认你重点关注的内容。现在让我们深入研究框架中的每个步骤。
第一步：确认数据以及统计来源的准确性
在这里强调一下：数据真实性是根基。
实际上因为数据源出问题，导致的指标异常非常非常多。工作中经常会遇到诸如服务器异常、数据后台统计出现错误、在数据报表上出现异常值、数据测量工具有问题等情况。所以在开始着手分析前，必须首先确认数据的真实性。
所以，遇到问题第一顺位先确认数据没有错，找数据统计相关的产品和开发确认下数据的真实性。
第二步：确认数据波动是否异，了解清楚数据指标(如app日活)具体业务情况和异常情况
现在，我们先来明确一下数据指标出现异常：上升或下跌，通常有以下情况：
- 一次性波动：只在某个时间节点发生波动。一次性上升/下跌背后原因的一般都是短期/突发事件，比如系统更新导致数据统计错误，突发的渠道投放冻结等。
- 周期性波动：会周期性发生上升/下跌，比如双十一、周末、春节等季节性因素。一般业务开展都有周期性，比如考勤工具类APP，就是以周为单位循环。工作日和周末就是有明显差异波动。
- 持续性波动：从某时间开始，一直出现上升/下降趋势。而持续性上升/下跌背后原因往往都是深层次的，比如用户需求转移，渠道投放长期暂停，大环境等因素，导致出现持续性的。
以上，这三种情况意味着问题本身不同的严重程度
如果是数据指标下跌的话，周期性下跌一般都不需要做特殊处理；一次性下跌往往来的比较突然，要关注事件持续性；持续性下跌的，特别是不见好转，持续的时间越长问题越严重。
需要注意是：不能单纯的看日周月报表中趋势图的走势，要结合波动的幅度来看——幅度越大，说明出现的异常问题越值得注意。
因此，我们需要明确以下问题：
- 明确日活究竟下跌了多少？持续的时间是多久？
- 相比昨天、上周都分别跌了多少？（同比、环比）
- 确认指标波动幅度是不是在合理的范围？
- 引起日活下跌的因素有哪些？这些因素分别对日活的影响程度有多大？
- 与这些因素相关的运营以及产品部门对日活的影响程度有多大？
- 这些部门是不是会因为产品迭代或者运营策略得到改变影响日活？
- 确认日活下跌对整体产品业务线的KPI影响程度?
- 了解日活下跌对产品业务线有哪些影响？
- 以前日活下跌后，都采取过哪些措施？
清楚了数据指标的具体情况，有了轻重缓急的判断，下一步就可以进行指标的拆解，再缩小怀疑范围，建立分析假设。而建立假设，有助于去伪存真的进行验证，进一步逼近真实原因。
第三步：将数据指标进行拆解, 当波动异常，我们需要明确问题根源
如：日活=新增用户+老用户留存+流失用户回流，二级指标拆解如下
- 可拆解新增用户来源渠道：如应用市场，百度搜索等
- 可拆解老用户留存渠道：华为、vivo应用商店等
- 可拆解新老用户登录平台：安卓、iOS等
- 可拆解新老用户用户的地区：天津、北京等
- 可拆解新老用户使用版本：新老版本
- 可拆解新老用户活跃时间：节假日、周期性等
- 可拆解流失用户：自然回流， 回访干预回流等
- 可分别计算每个维度下不同的活跃用户数。
通过这种方法，定位到导致哪个区域或者渠道的日活下降的用户群体是谁，以及定位原因有了大致范围。
比如定位是新用户问题，我们需要再把新用户日活按渠道进行拆分：新用户=渠道1+渠道2+渠道3+其他渠道；通过渠道拆分，我们会发现是具体哪个渠道效果发生的问题。那么，继续下一步我们要根据实际业务进一步做假设，具体情况具体分析。
常见拆分维度
以上是几种常见的初步拆分维度，通过初步拆分，定位原因大致范围。
若拆分后的指标均下降，我们需要找出最显著的哪个，这就引申到
计算影响系数：每一项数据都要和以往正常值做对比，算出影响系数。
影响系数=(今日量-昨日量)/(今日总量-昨日总量)
影响系数越大，说明此处就是主要的下降点，需要对此进一步分析。
案例：某App某日日活指标异常下降
按照上述套路，我们先拆分新老用户活跃量，如下图（老用户左轴、新用户右轴）：
新老用户活跃量变化
发现老用户日活较平稳，但是新用户自6月13日下降严重，于是计算新老用户影响系数：
老用户影响系数=(77.89-78)/(78.8-79.5)=0.16
新用户影响系数=(0.98-1.5)/(78.8-79.5)=0.84
新用户影响系数0.84，说明DAU下降是出在新用户身上，明确范围后进一部细分，新用户由什么构成？
新用户=渠道1+渠道2+渠道3+其他渠道 ，于是我们把新用户日活按渠道进行拆分：
不同渠道新用户日活量
通过渠道拆分，我们发现渠道3自6月13日起新用户下降严重，于是我们把问题定位在渠道3。
不过，只找到根源问题，我们需要找到导致这个问题发生的原因，才能提出解决方法。
因此，联系渠道3的负责人一起定位具体原因，是渠道线索量降低？是渠道转化率降低？还是渠道平台的问题？这就引申到下一步骤了。
第四步：异常范围定位后，要根据业务进一步做假设，实际具体情况具体分析
具体分析可以采用“内部-外部”事件因素考虑。
内部 -- 外部事件因素
在一定时间内同时发生可能很多种，主要关注数据指标的起点、拐点、终点。
- 数据指标起点：数据指标刚下跌时，发生了什么事件；往往起点事件是问题发生的直接原因。
- 数据指标拐点：在指标持续下跌过程中，是否某个事件的出现，让问题变得更严重，或者开始转暖。拐点意味着，这是可以通过运营手段改善指标的。
- 数据指标终点：当某个事件结束后，指标恢复正常。或当开始某个事件后，指标下跌结束。终点事件的两种形态，代表着两种改善指标的方法：等问题自己过去，或者主动出击解决问题
1. 内部事件因素
分三个维度来做假设，建议针对数据异常问题专门建一个群，拉上相应的产品、技术、运营人员一起，了解数据异常时间点附近做了什么产品、运营、技术侧调整。
内部事件因素
具体举例有：
- 分为获取用户（渠道转化率降低、渠道平台的问题等）
- 满足用户需求（新功能变更等引起某类用户不满）
- 促活运营手段（签到等提活手段没达成目标、产品自然使用周期低导致上次获得的大量用户短期内不需要再使用等）
- 内部功能和运营策略调整（产品、运营、技术在数据异常时间点附近做了什么策略调整）等
2. 外部事件因素
- 考虑用户行为的变化：用户需求发生变化？与他们进行定性的用户研究，观察用户需求是否发生了变化。他们现在有不同的需求吗？痛点或需求是否有所改变？
- 考虑竞争分析：如果用户的需求没有改变，那么该考虑你的竞争对手了。竞争对手刚加入吗？竞争对手刚离开吗？定价有变化吗
- 考虑大环境问题：采用PEST分析）——政治（政策影响）、经济（短期内主要是竞争环境，如对竞争对手的活动）、社会（舆论压力、用户生活方式变化、消费心理变化、价值观变化等偏好变化）、技术（创新解决方案的出现、分销渠道变化等）。
如果，你的用户仍然有相同的痛点，而你的竞争对手并未采取任何有意义的措施。
你可以考虑一下整体经济。是经济衰退还是经济强劲？政治或法规改变了格局吗？
例如，一场贸易战会严重影响一些企业。举例来说，影响木材和金属价格的贸易战可能会影响整个建筑业。
如果不是政治，法规或经济学因素，那么最后要考虑的因素就是自然变化。是否发生了自然灾害？这些都会改变客户的行为，最终影响数据指标。
我们遵循短期变化找内因，长期异动找外因。
查找顺序一般也是按文中提及的顺序来，先内而外，先考虑用户其次对手最后环境。
除了上述，可以细分分析的维度实在太多，逻辑上说核心点在于一个假设得到验证后，在这个假设为真的基础上，进行更细维度的数据拆分。我们需要记住这种分析方式，当猜测是某种原因造成数据异常时，只要找到该原因所代表的细分对立面做对比，就可以证明或证伪我们的猜测，直到最后找到真正原因。
第五步：提供解决方案，预测未来是否还会下跌？应该采取什么方式避免下跌？
与业务沟通反馈分析结论，探讨后续方案的执行；再针对原因解决问题，制定优化策略。
最后，我们要预测影响到什么时间；并运营、产品沟通反馈分析结论，探讨后续方案的执行。
实际业务中，数据异常的影响原因可能是多方面的（本篇只讲到了一些内部因素，外部环境和竞对其实也会影响核心数据），有的时候也需要建立统计分析模型来做一些定量分析。可能要花几天的时间去不断排查问题。
所以我们需要在平时工作中多留意数据变化，在条件允许范围内，再结合自身业务经验确定几个最可能的原因假设，给这些假设排数据验证的优先级，逐一排查，深入分析，比如本次指标下跌是因为新功能不符合预期不给力、渠道投放力度不够、竞品太厉害、版本更新大bug、流失严重等。
随着对业务的熟悉和数据敏感度的提升，针对数据异常分析我们也会越来越熟练，更快的找到问题所在。
网友评论