先做数据透视（可以增加UGC数量、PVUV数据等维度） 。按照日期标记：产品更新、活动节点、事故/事件、竞品动作等 。
其他观点：
一款信息流APP平时日活稳定在79w-80w之间 。但是在6月13日起突然掉到了78.8w 。到6月15日已经掉到78.5w 。这时产品负责人着急了 。让你尽快排查一下数据下跌的原因 。这样的问题对大多数人来说还是比较头疼的 。因为对于80w量级的产品 。一两万并不是一个非常大的波动 。但原因还是要排查 。\r
拿到这个问题 。会觉得不知道从哪点着手开始分析？没关系 。我们把常用套路捋清楚了 。然后回头再看这个案例 。
核心点：先做数据异常原因的假设 。后用数据验证假设 。不建议大家第一步先自己对着数据去拆 。影响日活数据的因素很多 。不可能把所有维度逐一拆解对比 。容易浪费时间却没有任何有价值的发现 。做数据异常原因分析的核心就是结合以往经验及各种信息 。找出最有可能的原因假设 。通过数据的拆分进行多维度分析来验证假设 。定位问题所在 。过程中可能会在原假设基础上建立新的假设或者是调整原来假设 。直到定位原因 。
第一步：确认数据真实性在开始着手分析前 。建议先确认数据的真实性 。我们经常会遇到数据服务、数据上报、数据统计上的BUG 。在数据报表上就会出现异常值 。所以 。找数据流相关的产品和研发确认下数据的真实性吧 。
第二步：根据几个常见维度初步拆分数据计算影响系数：每一项数据都要和以往正常值做对比 。算出影响系数 。
影响系数=(今日量-昨日量)/(今日总量-昨日总量)
影响系数越大 。说明此处就是主要的下降点以上是几种常见的初步拆分维度 。通过初步拆分 。定位原因大致范围 。
第三步：异常范围定位后 。进一步做假设针对初步定位的影响范围 。进行进一步的排查 。
分三个维度来做假设 。建议针对数据异常问题专门建一个群 。拉上相应的产品、技术、运营人员一起 。了解数据异常时间点附近做了什么产品、运营、技术侧调整 。综合考虑以往数据异常原因、产品运营技术侧调整、初步定位的影响范围最可能由什么原因造成 。再结合自身业务经验确定几个最可能的原因假设 。给这些假设排数据验证的优先级 。逐一排查 。最后：细分假设 。确立原因除了上述 。可以细分分析的维度实在太多 。逻辑上说核心点在于一个假设得到验证后 。在这个假设为真的基础上 。进行更细维度的数据拆分 。
当猜测是某种原因造成数据异常时 。只要找到该原因所代表的细分对立面做对比 。就可以证明或证伪我们的猜测 。直到最后找到真正原因 。
新用户=渠道1+渠道2+渠道3+其他渠道。于是我们把新用户日活按渠道进行拆分：通过渠道拆分 。我们发现渠道3自6月13日起新用户下降严重 。于是我们把问题定位在渠道3 。应该是渠道3的渠道效果发生问题 。联系渠道3的负责人一起定位具体原因 。渠道线索量降低？渠道转化率降低？渠道平台的问题？找出原因后 。再针对原因解决问题 。制定渠道优化策略 。最后要说的至此本篇文章已到尾声 。详细叙述了核心数据异常的分析套路以及讲了一个易于大家理解的小案例 。相信大家下次再遇到这类问题 。至少有一个明确的着手点 。
还有一些想对大家说的是：为了方便大家理解 。这个小案例的数据是我虚构的 。问题定位过程也比较简单 。但是在实际业务中 。数据异常的影响原因可能是多方面的（本篇只讲到了一些内部因素 。外部环境和竞对其实也会影响核心数据） 。有的时候也需要建立统计分析模型来做一些定量分析 。可能要花几天的时间去不断排查问题 。这个过程繁琐且枯燥 。假设验证失败可能会有挫败感 。或许忙活了很久但是最后并没有找出原因 。其实这是很正常的事情 。数据异常分析甚至对于一个资深数据分析师都是一个令人头疼的问题 。所以我们需要在平时工作中多留意数据变化 。随着对业务的熟悉和数据敏感度的提升 。针对数据异常分析我们也会越来越熟练 。更快找到问题所在 。
【产品日活DAU下降,我该如何着手分析？】
文章插图
推荐阅读
- 除夕意味着什么意思 大年三十为什么叫除夕有什么寓意
- 元宵节为什么吃汤圆
- 英雄联盟各个段位的人数比例是多少呢,哪个段位人最多？
- 《和平精英》改回端游版本后,推出全新职业,日活竟然破了5000万,你们怎么看？
- 元宵节吃什么呢
- 为什么只有孔捷去了朝鲜,李云龙,丁伟那段时间大概在忙什么？
- 苹果12掉水里有没有事 苹果12防水吗
- 元宵节可以吃生菜吗
- 阿富汗战争,是美国继朝鲜战争,越南战争之后,最大的失败吗？