DAU下降了，怎么办？

某年某月某天早上，你打开数据看板一看，这数据曲线不太妙啊，DAU降低了很多啊，怎么办怎么办，开始方了。

不要方，数据下跌不可怕，可怕的是数据下跌了还不知道，甚至是知道下跌了都根本找不到原因。

本文想用一个数据下降的Case来讨论下分析思路。

文章主要分为两部分，一部分是针对DAU下降原因的一些探索，一部分是针对这种问题的拓展。

一、DAU下降了，怎么办？

在我们讨论这个问题之前，需要先明确一下DAU的定义：有的公司的DAU可能是启动UV，有的公司可能是登录UV，有的公司可能是发生了特定行为的UV。

在讨论一个数据指标之前，需要先理清楚定义或者具体的计算规则、统计口径，避免讨论了很久，最后发现大家对这个指标的定义是不一样的局面。

为了简单分析，这里用的定义是启动UV，分析思路是从外部原因和内部原因两个方面入手。

1. 外部原因

首先需要明确的是数据是否准确，这可能是一个巨大无比的坑。

如果数据是依赖于客户端埋点上报的，在发新版本，或者某些功能改版的时候，很可能会出现问题。

常见的问题比如埋点缺失、上报的数据存储丢失、接口更换等；这种现象一般比较明显，对应在数据上基本上是腰斩级别的异常。

如果数据是从BI的某些报表中取的，字段的增删、数据表的更换，都可能带来数据异常，但这些异常一般比较明显。

其次是明确数据是否是周期性波动。

一些业务模式会有明显的周期效应，比如有的业务模式是周一——周五是数据低谷，周末是高峰；有的业务模式是周一-周五是数据的高峰，周末是低谷。

在当前周期往前多对比几个月的数据，基本能判断出来是常规波动还是异常波动，有的可能需要对比一下去年同期的数据。

比如有的业务模式会受到季节的影响，在某些城市，一旦到雨季，共享单车这种出行类的App就会受影响，对应的打车类的App也会受影响。

另外就是最近是否有什么节日，有些节日对业务的影响是正向的，有些节日对业务的影响是负向的。

最后是运营和市场最近有没有做什么活动，数据看起来下降可能并不是真的下降，也可能只是回归正常，只是之前的数据是高于正常水平的，所以看起来像是下降了。

有的时候到此为止就可以定义到主要的原因了，有的时候上面这些可能都是正常的，那就需要继续分解了。

2. 内部原因

有时候我们讨论的是某个功能的DAU，甚至整个业务就是某个App中的一个功能模块，这个时候，首先需要看的就是上级的入口流量或者整个App的DAU是否有变化。

我们可以通过某个公式，或者某个流程，找到所有相关联的因子，然后再层层细分，直到找到原因。

一般来说，DAU=新增用户DAU+老用户DAU+回流用户DAU

有些时候，可能没有把回流用户单独拆分出来，不重要，那就只看前两项就好。

把这几个因子都往下拆分一个或者多个层级，就得到下面这样一个基础公式。

接下来我们需要对每个因子进行排查，确定异常因子之后，再往更下面的层级进行深挖。

假定是新用户DAU异常的话，接下来就需要再往更深一层看是数量异常，还是留存率异常。

数量异常的话，可以按照渠道再往下一层拆解，看是单一渠道异常，还是多渠道异常：单渠道异常的话，是不是某个渠道的投放出问题了；多渠道异常的话，是不是削减投放预算了。

留存率异常的话，也是按照渠道再往下一层拆解，看是单一渠道异常，还是多渠道异常：单渠道异常的话，是某个渠道存在刷量的嫌疑，还是渠道投放的人群不匹配；多渠道异常的话，是不是更换了投放策略、投放素材、投放的落地页等。

假定是老用户DAU异常的话，接下来也是再往更深一层看是数量异常，还是留存率异常。

假定数量异常的话，往下再拆一层，看是安卓还是iOS异常，还是整体都异常，然后可以再按照版本进行拆分，看是不是最近哪个版本里改动什么东西了。

假定留存异常的话，也是一样的，按照终端（安卓、iOS）、版本、手机类型再进行进一步的拆分，对比最近的版本，看有没有什么改动可能会影响到。

假定是回流用户DAU异常的话，接下来也是再往更深一层看是数量异常，还是留存率异常。

假定数量异常的话，接着看一下发送的召回的短信、Push的数量有没有发生变化、到达的触达率、点击率有没有变化。

假定留存异常的话，看一下推送的策略、推送的内容是否有变化，以及进来的落地页承接有没有变化。

经过这样逐层的拆解，一般情况下是能找到一些异常点，然后需要做的就是针对这些异常点，进行不断的拆分、细分；最终找到一些我们认为可能有影响的点，得出一些猜想，然后再进行调整、测试、迭代。

二、问题回顾，拓展

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

上面那个DAU下降了的问题，我们经历了这几步：

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

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

发现问题——收敛问题——得出猜想——验证猜想。

在发现问题的层面上，没什么好说的，日常看看数据，看异常的趋势变化，看同比环比变化。

收敛问题是把问题的范围不断缩小直到找到问题，一般是先外部再内部，整体再局部，然后不断的进行细分拆解。

外部原因就是先找找会影响当前问题的外部系统要素，有的时候可能系统本身没什么问题，只是外部环境发生了变化。

针对内部某个异常的数据排查一般可以先找到一个公式，把关联的因子都包含进去，然后再看是哪个因子异常，结合着不同的维度进行更细的拆分。

比如上面提到的DAU=新增用户DAU+老用户DAU+回流用户DAU，或者是素材投放的激活数量=曝光量*点击率*下载完成率*安装完成率*启动率*激活率。

常用的细分维度有以下这些：

• 渠道；
• 新老用户；
• 用户关键行为次数；
• 性别、年龄、地域；
• 版本；
• 终端等。

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

• 是不是推广的渠道、方式、素材有问题，用户来了之后发现和预期不符；
• 是不是功能入口太弱，看不到；
• 是不是宣传的东西没有让用户感觉到对自己的价值；
• 是不是功能太复杂，路径太长，用户还没感觉到价值就流失了；
• 是不是功能虽然有价值，但与用户预期不相符；
• 是不是解决方案本身就有问题，不能满足需求；
• 是不是需求根本不存在。

这些都是基于以往的经验，或者是对业务、对用户的理解得出来的猜想。

猜想终归只是猜想，需要进行证实或者证伪，接下来就是基于这些猜想，给出对应的解决方案。

由于只是猜想，所以最好能用最小的成本进行验证，也就是我们说的MVP。

如何进行MVP验证？

可以按照影响的范围、影响的结果大小、影响的可能性、实现成本来按照性价比进行猜想验证，最好进行单因素验证，因素太多的话不好归因。

最后就是基于这些猜想、数据变化来进行不断的优化迭代。

简单总结下全文：

• 发现问题：看趋势、看同比、环比；
• 收敛问题：外部+内部，整体公式+不同维度细分；
• 得出猜想：基于经验，对业务、用户的理解；
• 验证猜想：MVP、性价比、单因素验证。

以上，就是本文的主要内容，欢迎斧正、指点、拍砖。

#作者#

王家郴 ，公众号：产品经理从0到1，喜欢网球和骑行的产品汪，目前奔走在产品的道路上，漫漫产品路，与君共勉。

本文

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！