新媒体兔子Tik Tok卖：DAU是产品的日常工作，而每个商业模式的DAU是不同的。DAU值要根据产品本身的调性来确定；DAU价值也会受到很多因素的影响。如果发现DAU减少，要从里到外分析。本文对DAU的衰落进行了探讨和扩展。让我们一起来看看。
某年某月的某个早晨，你打开数据板，看到这个数据曲线不是很好，DAU跌了很多，怎么做，开始了。
另一方面，数据下降并不可怕。可怕的是，我们不知道数据下降，甚至知道找不到原因。
在本文中，我想用一个数据下降的案例来讨论分析思路。
文章主要分为两个部分，一部分是探讨DAU衰落的原因，另一部分是拓展这个问题。
在讨论这个问题之前，我们需要先把DAU的定义搞清楚：有些公司可能会启动UV，有些公司可能会登录UV，有些公司可能是有特定行为的UV。
在讨论一个数据指标之前，需要明确定义或者具体的计算规则和统计口径，避免长时间的讨论。最后，我们发现这个指标的定义是不同的。
为了简单分析，这里使用的定义是从UV开始，分析思路是从外部原因和内部原因两个方面入手。
首先需要明确的是数据是否准确，这可能是一个巨大的坑。
如果数据是客户端的埋点上报的，很可能在发布新版本或者修改一些功能的时候会出现问题。
常见问题如埋点缺失、上报数据存储丢失、接口更换等。这种现象一般比较明显，数据上基本对应腰斩水平的异常。
如果数据取自BI的一些报表，字段的增删和数据表的替换都可能带来数据异常，但这些异常一般都很明显。
其次，数据是否周期性波动是很清楚的。
有些商业模式具有明显的周期性效应。比如有的商业模式是周一——，周五是数据低谷，周末是高峰。一些商业模式是周一至周五是数据的高峰期，周末是低谷期。
通过对比当前周期前几个月的数据，基本可以判断是正常波动还是异常波动，有些可能需要对比去年同期的数据。
比如有些商业模式会受到季节的影响。在一些城市，一旦雨季来临，自行车共享等出行应用会受到影响，相应的出租车应用也会受到影响。
另外，最近有没有节日，有些节日对生意有正面影响，有些节日对生意有负面影响。
最后，不管最近操作和市场有没有做什么，看起来数据下降可能不是真的下降，或者可能只是恢复正常，但是之前的数据高于正常水平，所以看起来是下降了。
有时候主要原因可以定义到目前为止，有时候以上可能是正常的，所以需要继续分解。
有时候我们说的是某个功能的DAU，甚至整个业务都是一个App中的一个功能模块。这个时候我们首先要看的是整个App的上级或者DAU的入口流量有没有变化。
我们可以通过某个公式或者某个过程找到所有的相关因素，然后一层一层细分，直到找到原因。
总的来说，DAU=新增用户DAU+老用户DAU+回流用户DAU
有时候，分开返回的用户可能并不重要，所以只看前两项。
把这些因素分成一个或多个层次，你会得到下面的基本公式。
接下来，我们需要调查每个因素，确定异常因素，然后更深入地挖掘更低的层次。
假设新用户的DAU异常，我们需要更深层次的去观察，是数量异常还是留存率异常。
如果数量异常，可以根据渠道拆解到下一级，看看是单通道异常还是多通道异常：如果单通道异常，是不是某个渠道发货有问题？如果多渠道不正常，是否会削减预算？
如果留存率异常，还会根据通道拆解到下一级，看是单通道异常还是多通道异常：如果是单通道异常，怀疑是某个通道有刷量，或者放入通道的人不匹配；如果多渠道不正常，是否改变了投放策略、投放材料、登陆页面等。
假设老用户的DAU异常，那么下一步就是深入查看，看号码是否异常，或者留存率是否异常。
如果数量假设不正常，那就多拆一层看看是安卓还是iOS不正常，还是整体不正常，然后按照版本拆分，看看最近哪个版本是不是有变化。
如果滞留不正常，也是一样的。根据终端(安卓、iOS)、版本、手机类型进一步拆分，对比最新版本，看看有没有可能影响的变化。
假设退货用户的DAU异常，那么下一步就是深入查看，看是数量异常还是留存率异常。
如果假设数量异常，那就看看召回短信、推送短信的数量、命中率、点击率有没有变化。
如果留存异常，看推送策略，推送的内容是否有变化，传入的登陆页面是否有变化。
这种逐层拆解之后，一般可以发现一些异常点，然后需要做的就是不断的对这些异常点进行拆分和细分；最后，我们找到一些我们认为可能有影响的点，得出一些猜测，然后进行调整、测试和迭代。
让我们回顾一下我们在上面的问题中做了什么，当我们遇到这个一般问题时，我们可以做什么。
对于上面的DAU跌落问题，我们已经经历了这些步骤：
DAU下降——具体是谁下降——为什么会下降——要怎么办。
这与一般问题相对应：
发现问题——收敛问题——得出猜想——验证猜想。
在发现问题的层面，没什么好说的。每天看数据，看异常趋势变化，看同比变化。
收敛问题就是缩小问题的范围，直到发现问题为止。一般是先外后内，先整体后局部，再不断细分拆解。
外部原因是先寻找会影响当前问题的外部系统要素。有时候系统本身可能没什么问题，但是外部环境变了。
一般来说，对于一个内部异常的数据调查，我们可以先找到一个包含所有相关因素的公式，然后我们可以看到哪个因素是异常的，并结合不同的维度进行更详细的拆分。
比如上面提到的DAU=新用户DAU，老用户DAU返回用户DAU，或者说素材投放的激活数=曝光量*点击率*下载完成率*安装完成率*开机率*激活率。
常用的细分尺寸如下：
渠道；
新用户；
用户的关键行为数量；
性别、年龄和地区；
版本；
终端等。
猜想一般是在某些数据或函数没有很好执行的情况下发起的，如以下猜想：
推广的渠道、方式、材料有问题吗？用户来了之后，发现不符合预期；
功能入口太弱看不到吗？
是不是宣传出来的东西并没有让用户觉得对自己有价值？
是不是功能太复杂，路径太长，用户还没感受到就失去了价值？
功能是否有价值，但与用户预期不符；
解决方案本身有问题，不能满足需求吗？
需求是否根本不存在。
这些都是基于过去的经验或对业务和用户的理解而做出的猜测。
猜想终究只是猜想，需要证实或证伪。接下来，基于这些猜测，给出了相应的解决方案。
因为只是猜测，最好用最小的代价去验证，也就是我们所说的MVP。
如何验证MVP？
猜测验证可以根据影响范围、影响结果的大小、影响的可能性、实现成本等根据性价比进行，最好进行单因素验证，因为因素太多不容易归属。
最后，基于这些推测和数据变化，进行连续优化迭代。
简要总结全文：
发现问题：看趋势，同比和环比；
收敛问题：外部和内部，整个公式被细分为不同的维度；
猜想：基于经验，对业务和用户的理解；
验证猜想：MVP，性价比，单因素验证。
以上是本文的主要内容。欢迎指正，指出并拍砖。
微信官方账号王：产品经理从0到1。每个人都是产品经理的专栏作家。他们喜欢网球和自行车产品。目前，他们在产品的道路上奔跑，他们在和你相互鼓励。
这篇文章最初发表在《人人都是产品经理》上。未经允许禁止转载。
图片来自unsplash，基于CC0协议。
奖励作者，鼓励TA抓紧创作！欣赏