产品的某些数据指标都会具有固定的波动周期

在日常的工作中，我们经常会遇到“产品XX数据指标出现异常波动，或上升或下跌”的问题，XX指标包括但不限于日活、次日留存率、注册转化率、GMV、客单价等等。我们该如何着手处理分析呢？

这也是面试数据方面的工作比较常见的问题。那么，今天将系统的梳理总结一下这类问题的分析框架以及需要考虑的问题，今后在遇到此类问题时，希望能有一个明确的着力点以及分析思维。

01

一般来讲，产品的某些数据指标都会具有固定的波动周期，而且每个周期内数据的变化应该趋于稳定，但在数据监控体系里的日报、周报、月报中某数据指标突然不再符合预期的稳定变化，这就是我们所说的数据出现异常波动。在这种情况下，我们就需要去深挖数据异常产生的原因。

而做数据异常分析核心就是结合以往经验及各种信息，找出最有可能的原因假设，通过将数据指标的进行拆分，再多维度分析来验证假设，定位问题所在。其过程中可能会在原假设基础上建立新的假设或者是调整原来假设，直到定位原因。

其实，通过我们每一次的异常分析来定位造成数据波动的问题及原因，建立起日常运营工作和数据异常波动之间的关联性，进而就可以从中找到促进数据增长的新的思路和方法，改变数据结果。

02

现在，我们先来明确一下数据指标出现异常：上升或下跌，通常有以下情况：

• 一次性波动：只在某个时间节点发生波动。一次性上升/下跌背后原因的一般都是短期/突发事件，比如系统更新导致数据统计错误，突发的渠道投放冻结等。
• 周期性波动：会周期性发生上升/下跌，比如双十一、周末、春节等季节性因素。一般业务开展都有周期性，比如考勤工具类APP，就是以周为单位循环。工作日和周末就是有明显差异波动。
• 持续性波动：从某时间开始，一直出现上升/下降趋势。而持续性上升/下跌背后原因往往都是深层次的，比如用户需求转移，渠道投放长期暂停，大环境等因素，导致出现持续性的。

以上，这三种情况意味着问题本身不同的严重程度。

如果是数据指标下跌的话，周期性下跌一般都不需要做特殊处理；一次性下跌往往来的比较突然，要关注事件持续性；持续性下跌的，特别是不见好转，持续的时间越长问题越严重。

需要注意是：不能单纯的看日周月报表中趋势图的走势，要结合波动的幅度来看——幅度越大，说明出现的异常问题越值得注意。

03

那么接下来，捋清楚思路，我们以“某APP的日活有所下降”，该如何着手分析呢？

第一步：确认数据以及统计来源的准确性

在这里强调一下：数据真实性是根基。

实际上因为数据源出问题，导致的指标异常非常非常多。所以在开始着手分析前，必须首先确认数据的真实性；经常会遇到服务器异常、数据后台统计出现错误、在数据报表上出现异常值。

所以，遇到问题第一顺位先确认数据没有错，找数据统计相关的产品和开发确认下数据的真实性。

第二步：了解清楚数据指标（app日活）具体业务情况和异常情况

明确以下问题：

1. 明确日活究竟下跌了多少？持续的时间是多久？
2. 相比昨天、上周都分别跌了多少？（同比、环比）
3. 确认指标波动幅度是不是在合理的范围？
4. 引起日活下跌的因素有哪些？这些因素分别对日活的影响程度有多大？
5. 与这些因素相关的运营以及产品部门对日活的影响程度有多大？
6. 这些部门是不是会因为产品迭代或者运营策略得到改变影响日活？
7. 确认日活下跌对整体产品业务线的KPI影响程度?
8. 了解日活下跌对产品业务线有哪些影响？
9. 以前日活下跌后，都采取过哪些措施？

清楚了数据指标（APP日活）的具体情况，有了轻重缓急的判断，下一步就可以进行指标的拆解，再缩小怀疑范围，建立分析假设。

而建立假设，有助于去伪存真的进行验证，进一步逼近真实原因。

第三步：将数据指标进行拆解

如：日活=新增用户+老用户留存+流失用户回流，二级指标拆解如下

1. 可拆解新增用户来源渠道：如应用市场，百度搜索等
2. 可拆解老用户留存渠道：华为、vivo应用商店等
3. 可拆解新老用户登录平台：安卓、iOS等
4. 可拆解新老用户用户的地区：天津、北京等
5. 可拆解新老用户使用版本：新老版本
6. 可拆解新老用户活跃时间：节假日、周期性等
7. 可拆解流失用户：自然回流， 回访干预回流等

可分别计算每个维度下不同的活跃用户数。

通过这种方法，定位到导致哪个区域或者渠道的日活下降的用户群体是谁，以及定位原因有了大致范围。

比如定位是新用户问题，我们需要再把新用户日活按渠道进行拆分：新用户=渠道1+渠道2+渠道3+其他渠道；通过渠道拆分，我们会发现是具体哪个渠道效果发生的问题。

那么，继续下一步我们要根据实际业务进一步做假设，具体情况具体分析。

第四步：异常范围定位后，要根据业务进一步做假设，实际具体情况具体分析

具体分析可以采用“内部-外部”事件因素考虑。

▶ 内部-外部事件

在一定时间内同时发生可能很多种，主要关注数据指标的起点、拐点、终点。

• 数据指标起点：数据指标刚下跌时，发生了什么事件；往往起点事件是问题发生的直接原因。
• 数据指标拐点：在指标持续下跌过程中，是否某个事件的出现，让问题变得更严重，或者开始转暖。拐点意味着，这是可以通过运营手段改善指标的。