某年某月某天早上，你打开数据看板一看，这数据曲线不太妙啊，DAU降低了很多啊，怎么办怎么办，开始方了。
不要方，数据下跌不可怕，可怕的是数据下跌了还不知道，甚至是知道下跌了都根本找不到原因。
本文想用一个数据下降的Case来讨论下分析思路。文章主要分为两部分，一部分是针对DAU下降原因的一些探索，一部分是针对这种问题的拓展。

DAU下降了，怎么办

在我们讨论这个问题之前，需要先明确一下DAU的定义，有的公司的DAU可能是启动UV，有的公司可能是登录UV，有的公司可能是发生了特定行为的UV。
在讨论一个数据指标之前，需要先理清楚定义或者具体的计算规则、统计口径，避免讨论了很久，最后发现大家对这个指标的定义是不一样的局面。
为了简单分析，这里用的定义是启动UV，分析思路是从外部原因和内部原因两个方面入手。

外部原因

首先需要明确的是数据是否准确，这可能是一个巨大无比的坑。
如果数据是依赖于客户端埋点上报的，在发新版本，或者某些功能改版的时候，很可能会出现问题。
常见的问题比如埋点缺失，上报的数据存储丢失，接口更换等，这种现象一般比较明显，对应在数据上基本上是腰斩级别的异常。
如果数据是从BI的某些报表中取的，字段的增删、数据表的更换，都可能带来数据异常，但这些异常一般比较明显。
其次是明确数据是否是周期性波动。
一些业务模式会有明显的周期效应，比如有的业务模式是周一-周五是数据低谷，周末是高峰，有的业务模式是周一-周五是数据的高峰，周末是低谷。
在当前周期往前多对比几个月的数据，基本能判断出来是常规波动还是异常波动，有的可能需要对比一下去年同期的数据。
比如有的业务模式会受到季节的影响，在某些城市，一旦到雨季，共享单车这种出行类的App就会受影响，对应的打车类的App也会受影响。
另外就是最近是否有什么节日，有些节日对业务的影响是正向的，有些节日对业务的影响是负向的。
最后是运营和市场最近有没有做什么活动，数据看起来下降可能并不是真的下降，也可能只是回归正常，只是之前的数据是高于正常水平的，所以看起来像是下降了。
有的时候到此为止就可以定义到主要的原因了，有的时候上面这些可能都是正常的，那就需要继续分解了。

内部原因

有时候我们讨论的是某个功能的DAU，甚至整个业务就是某个App中的一个功能模块，这个时候，首先需要看的就是上级的入口流量或者整个App的DAU是否有变化。
我们可以通过某个公式，或者某个流程，找到所有相关联的因子，然后再层层细分，直到找到原因。
一般来说，DAU=新增用户DAU+老用户DAU+回流用户DAU

有些时候，可能没有把回流用户单独拆分出来，不重要，那就只看前两项就好。
把这几个因子都往下拆分一个或者多个层级，就得到下面这样一个基础公式。

接下来我们需要对每个因子进行排查，确定异常因子之后，再往更下面的层级进行深挖。
假定是新用户DAU异常的话，接下来就需要再往更深一层看是数量异常，还是留存率异常。
数量异常的话，可以按照渠道再往下一层拆解，看是单一渠道异常，还是多渠道异常。单渠道异常的话，是不是某个渠道的投放出问题了，多渠道异常的话，是不是削减投放预算了。
留存率异常的话，也是按照渠道再往下一层拆解，看是单一渠道异常，还是多渠道异常。单渠道异常的话，是某个渠道存在刷量的嫌疑，还是渠道投放的人群不匹配，多渠道异常的话，是不是更换了投放策略，投放素材，投放的落地页等。
假定是老用户DAU异常的话，接下来也是再往更深一层看是数量异常，还是留存率异常。
假定数量异常的话，往下再拆一层，看是安卓还是iOS异常，还是整体都异常，然后可以再按照版本进行拆分，看是不是最近哪个版本里改动什么东西了。
假定留存异常的话，也是一样的，按照终端（安卓、iOS）、版本、手机类型再进行进一步的拆分，对比最近的版本，看有没有什么改动可能会影响到。
假定是回流用户DAU异常的话，接下来也是再往更深一层看是数量异常，还是留存率异常。
假定数量异常的话，接着看一下发送的召回的短信、Push的数量有没有发生变化、到达的触达率、点击率有没有变化。
假定留存异常的话，看一下推送的策略、推送的内容是否有变化，以及进来的落地页承接有没有变化。
经过这样逐层的拆解，一般情况下是能找到一些异常点，然后需要做的就是针对这些异常点，进行不断的拆分、细分，最终找到一些我们认为可能有影响的点，得出一些猜想，然后再进行调整、测试、迭代。

问题回顾，拓展

我们来回顾下上面那个问题中，我们是怎么做的，以及遇到这种通用问题的时候，我们可以怎么办。
上面那个DAU下降了的问题，我们经历了这几步：

  • DAU下降》具体是谁下降》为什么会下降》要怎么办。

那对应在一般的问题上就是：

  • 发现问题》收敛问题》得出猜想》验证猜想

在发现问题的层面上，没什么好说的，日常看看数据，看异常的趋势变化，看同比环比变化。
收敛问题是把问题的范围不断缩小直到找到问题，一般是先外部再内部，整体再局部，然后不断的进行细分拆解。
外部原因就是先找找会影响当前问题的外部系统要素，有的时候可能系统本身没什么问题，只是外部环境发生了变化。
针对内部某个异常的数据排查一般可以先找到一个公式，把关联的因子都包含进去，然后再看是哪个因子异常，结合着不同的维度进行更细的拆分。
比如上面提到的DAU=新增用户DAU+老用户DAU+回流用户DAU，或者是素材投放的激活数量=曝光量*点击率*下载完成率*安装完成率*启动率*激活率。
常用的细分维度有以下这些：

  • 渠道；

  • 新老用户；

  • 用户关键行为次数；

  • 性别、年龄、地域；

  • 版本；

  • 终端；

  • 等。

猜想一般都是在某些数据或者功能表现不好的情况下展开的，比如以下这些猜想：

  • 是不是推广的渠道、方式、素材有问题，用户来了之后发现和预期不符；

  • 是不是功能入口太弱，看不到；

  • 是不是宣传的东西没有让用户感觉到对自己的价值；

  • 是不是功能太复杂，路径太长，用户还没感觉到价值就流失了；

  • 是不是功能虽然有价值，但与用户预期不相符；

  • 是不是解决方案本身就有问题，不能满足需求；

  • 是不是需求根本不存在。

这些都是基于以往的经验，或者是对业务、对用户的理解得出来的猜想。
猜想终归只是猜想，需要进行证实或者证伪，接下来就是基于这些猜想，给出对应的解决方案。
由于只是猜想，所以最好能用最小的成本进行验证，也就是我们说的MVP。

  • 如何进行MVP验证？

可以按照影响的范围、影响的结果大小、影响的可能性、实现成本来按照性价比进行猜想验证，最好进行单因素验证，因素太多的话不好归因。
最后就是基于这些猜想、数据变化来进行不断的优化迭代。
简单总结下全文：

  • 发现问题：看趋势、看同比、环比；

  • 收敛问题：外部+内部，整体公式+不同维度细分；

  • 得出猜想：基于经验，对业务、用户的理解；

  • 验证猜想：MVP、性价比、单因素验证。

以上，就是本文的主要内容，欢迎斧正、指点、拍砖…
声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。