产品日活DAU下降，我该如何着手分析？
写在最前：上一篇文章写的是用户增长的思考框架，但是其实我们大多数人在工作中都是只负责其中一小块，可能写一些具体的细分问题会对大家更有帮助。
故第二篇文章，我选择了一个具体的问题着手写。产品核心数据异常是在工作中经常会遇到的问题，也是常见的互联网面试问题。在此我结合网上的一些分享以及自己的经验，总结一些思考分析框架，让大家在遇到此类问题的时候有一个明确的着力点。
案例简介
一款信息流APP平时日活稳定在79w-80w之间，但是在6月13日起突然掉到了78.8w，到6月15日已经掉到78.5w，这时产品负责人着急了，让你尽快排查一下数据下跌的原因。这样的问题对大多数人来说还是比较头疼的，因为对于80w量级的产品，一两万并不是一个非常大的波动，但原因还是要排查。拿到这个问题，会觉得不知道从哪点着手开始分析？没关系，我们把常用套路捋清楚了，然后回头再看这个案例。
image.gif
核心点：
先做数据异常原因的假设，后用数据验证假设
不建议大家第一步先自己对着数据去拆，影响日活数据的因素很多，不可能把所有维度逐一拆解对比，容易浪费时间却没有任何有价值的发现。
做数据异常原因分析的核心就是结合以往经验及各种信息，找出最有可能的原因假设，通过数据的拆分进行多维度分析来验证假设，定位问题所在。过程中可能会在原假设基础上建立新的假设或者是调整原来假设，直到定位原因。
第一步：确认数据真实性
在开始着手分析前，建议先确认数据的真实性。我们经常会遇到数据服务、数据上报、数据统计上的BUG，在数据报表上就会出现异常值。所以，找数据流相关的产品和研发确认下数据的真实性吧。
第二步：根据几个常见维度初步拆分数据
image.gif
计算影响系数：每一项数据都要和以往正常值做对比，算出影响系数。
影响系数=(今日量-昨日量)/(今日总量-昨日总量)
影响系数越大，说明此处就是主要的下降点
以上是几种常见的初步拆分维度，通过初步拆分，定位原因大致范围。
第三步：异常范围定位后，进一步做假设
针对初步定位的影响范围，进行进一步的排查。分三个维度来做假设，建议针对数据异常问题专门建一个群，拉上相应的产品、技术、运营人员一起，了解数据异常时间点附近做了什么产品、运营、技术侧调整。
image.gif
综合考虑以往数据异常原因、产品运营技术侧调整、初步定位的影响范围最可能由什么原因造成，再结合自身业务经验确定几个最可能的原因假设，给这些假设排数据验证的优先级，逐一排查。
最后：细分假设，确立原因
除了上述，可以细分分析的维度实在太多，逻辑上说核心点在于一个假设得到验证后，在这个假设为真的基础上，进行更细维度的数据拆分。我们需要记住这种分析方式，当猜测是某种原因造成数据异常时，只要找到该原因所代表的细分对立面做对比，就可以证明或证伪我们的猜测，直到最后找到真正原因。
案例分析
以上就是核心数据异常的分析套路，是不是刚才拿到问题还不知道从哪开始分析，现在觉得其实有很多点可以去着手？让我们回到刚才的案例吧。
根据上述套路，首先我们拆分新老用户活跃量，如下图（老用户左轴、新用户右轴）：
image.gif
发现老用户日活较平稳，但是新用户自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+其他渠道 ，于是我们把新用户日活按渠道进行拆分：
image.gif
通过渠道拆分，我们发现渠道3自6月13日起新用户下降严重，于是我们把问题定位在渠道3，应该是渠道3的渠道效果发生问题。联系渠道3的负责人一起定位具体原因，渠道线索量降低？渠道转化率降低？渠道平台的问题？找出原因后，再针对原因解决问题，制定渠道优化策略。
最后要说的
至此本篇文章已到尾声，详细叙述了核心数据异常的分析套路以及讲了一个易于大家理解的小案例，相信大家下次再遇到这类问题，至少有一个明确的着手点。还有一些想对大家说的是：
为了方便大家理解，这个小案例的数据是我虚构的，问题定位过程也比较简单。但是在实际业务中，数据异常的影响原因可能是多方面的（本篇只讲到了一些内部因素，外部环境和竞对其实也会影响核心数据），有的时候也需要建立统计分析模型来做一些定量分析。可能要花几天的时间去不断排查问题，这个过程繁琐且枯燥，假设验证失败可能会有挫败感，或许忙活了很久但是最后并没有找出原因。其实这是很正常的事情，数据异常分析甚至对于一个资深数据分析师都是一个令人头疼的问题。所以我们需要在平时工作中多留意数据变化，随着对业务的熟悉和数据敏感度的提升，针对数据异常分析我们也会越来越熟练，更快找到问题所在。
网友评论