案例简介

这是一个关于一款信息流APP的案例。平时该APP的日活用户量保持在79万到80万之间，但在6月13日开始，突然下降到了78.8万，到6月15日已经降到了78.5万。产品负责人感到很紧张，要求尽快排查下降原因。对于大多数人来说，这样的问题可能会感到头疼，因为对于80万级别的产品来说，一两万的波动并不算大，但还是需要找出原因。

为了解决这个问题，我们需要从何处着手进行分析呢？不用担心，我们先梳理一下常见的分析方法，然后再看这个案例。

核心点：先假设数据异常原因，再用数据验证假设

我们不建议直接对数据进行拆解分析，因为影响日活数据的因素很多，不可能逐一对比所有维度，这样只会浪费时间而得不到有价值的发现。数据异常原因分析的核心是结合以往经验和各种信息，找出最有可能的原因假设，然后通过对数据进行多维度分析来验证假设，最终定位问题所在。在这个过程中，可能会在原假设的基础上建立新的假设或调整原来的假设，直到找到原因。

第一步：确认数据的真实性

在开始分析之前，建议先确认数据的真实性。我们经常会遇到数据服务、数据上报、数据统计等方面的问题，这些问题会导致数据报表上出现异常值。因此，建议联系数据服务和研发团队，确认数据的真实性。

第二步：根据几个常见维度初步拆分数据

计算影响系数：对每个数据项都要与以往的正常值进行对比，计算影响系数。

影响系数 = (今日量 - 昨日量) / (今日总量 - 昨日总量)

影响系数越大，说明此处是主要的下降点。

以上是几个常见的初步拆分维度，通过初步拆分，可以大致定位原因的范围。

第三步：异常范围定位后，进一步做假设

针对初步定位的影响范围，进行进一步的排查。从三个维度做假设，建议专门建立一个群组，邀请相应的产品、技术和运营人员一起讨论，了解在数据异常发生的时间点附近，是否有产品、运营或技术方面的调整。

综合考虑以往数据异常原因、产品运营技术方面的调整以及初步定位的影响范围，可以确定几个最可能的原因假设，并为这些假设排列数据验证的优先级，逐一排查。

最后：细分假设，确立原因

除了上述方法，还有很多可以进行细分分析的维度。关键是在验证一个假设为真的基础上，进行更细致的数据拆分。我们需要记住这种分析方式，当我们猜测某种原因导致数据异常时，只需要找到该原因对应的细分对立面进行对比，就可以证明或证伪我们的猜测，直到找到真正的原因。

案例分析

以上是核心数据异常分析的方法，现在回到刚才的案例。根据上述方法，首先我们对新老用户的活跃量进行拆分，如下图所示（老用户在左轴，新用户在右轴）：

发现老用户的日活量比较平稳，但新用户从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的渠道效果出现了问题。我们联系了渠道3的负责人，一起定位具体的原因，例如渠道线索量的降低、渠道转化率的降低、渠道平台的问题等。找到原因后，我们可以针对原因解决问题，并制定渠道优化策略。

最后要说的

至此，本文已经结束，详细介绍了核心数据异常分析的方法，并且给出了一个易于理解的案例。相信下次遇到类似的问题时，大家至少有一个明确的分析起点。

还有一些要提醒大家的是：为了方便理解，本案例中的数据是虚构的，问题定位过程也比较简单。但在实际业务中，数据异常的影响原因可能是多方面的（本文只涉及了一些内部因素，实际上外部环境和竞争对手也会影响核心数据），有时还需要建立统计分析模型进行定量分析。

可能需要花费几天的时间不断排查问题，这个过程既繁琐又枯燥，如果假设验证失败可能会有挫败感，也许会忙活很久，最后却没能找到原因。

但这是很正常的情况，数据异常分析甚至对于一个经验丰富的数据分析师来说都是令人头疼的问题。因此，我们需要在平时的工作中多留意数据的变化，随着对业务的熟悉和对数据的敏感度提高，我们对数据异常分析也会变得更加熟练，更快地找到问题所在。

希望本文对大家有实际的帮助。如果想了解更多互联网数据分析相关内容，欢迎关注、点赞和转发，也欢迎大家一起探讨更多话题。