发现DAU降低，要从内部和外部进行分析

某年某月某一天早上，你打开数据看板看，这个数据曲线不是很好啊，DAU减少了很多啊，怎么办，开始方。不，数据下降并不可怕，可怕的是数据下降不知道，甚至知道下降根本找不到原因。本文想用数据下降的Case来讨论分析思路。文章主要分为两部分，一部分是对DAU下降原因的探索，另一部分是对这个问题的扩展。一、DAU下降了，怎么办？在我们讨论这个问题之前，我们需要明确DAU的定义：一些公司的DAU可能是启动UV，一些公司可能是登录UV，一些公司可能是有特定行为的UV。在讨论数据指标之前，我们需要明确定义或具体的计算规则和统计口径，以避免长期讨论。最后，我们发现这个指标的定义是不同的。为了简单分析，这里使用的定义是启动紫外线，从外部原因和内部原因两个方面进行分析。1.外部原因首先要明确的是数据是否准确，这可能是一个巨大的坑。若数据依赖于客户端埋点报告，则在发送新版本或某些功能修改时，很可能会出现问题。常见问题如埋点缺失、报告数据存储丢失、接口更换等；这种现象一般比较明显，对应的数据基本上是减半水平的异常。如果数据是从BI的某些报表中提取的，字段的增删和数据表的更换可能会导致数据异常，但这些异常通常是显而易见的。二是确定数据是否是周期性波动。有些商业模式会有明显的周期效应，比如有些商业模式是周一-周五的数据低谷，周末是高峰；有些商业模式是周一-周五的数据高峰，周末的数据高峰。在当前周期比较数据几个月后，基本上可以判断是常规波动还是异常波动，有些可能需要比较去年同期的数据。例如，一些商业模式会受到季节的影响。在一些城市，一旦到了雨季，自行车共享应用程序就会受到影响，相应的出租车应用程序也会受到影响。此外，是否有最近的节日，有些节日对业务有积极的影响，有些节日对业务有消极的影响。最后，运营和市场最近是否做了任何活动。数据的下降可能不是真正的下降，也可能只是恢复正常，但之前的数据高于正常水平，所以看起来像是下降。有时到目前为止，主要原因是可以定义的。有时以上可能是正常的，因此需要继续分解。2.有时我们讨论的内部原因是某个功能的DAU，甚至整个业务也是某个应用程序中的一个功能模块。此时，首先要看的是上级的入口流量或整个应用程序的DAU是否发生了变化。在找到原因之前，我们可以通过一个公式或一个过程找到所有相关的因素。一般来说，DAU=DAU新用户 老用户DAU 有时候回流用户DAU可能不会单独拆分回流用户，没关系，只看前两项。将这些因素分成一个或多个层次，以获得以下基本公式。接下来，我们需要调查每个因素，确定异常因素，然后深入挖掘以下层次。假设新用户DAU异常，下一步就需要再往更深层看是数量异常，还是留存率异常。如果数量异常，可以根据渠道拆卸到下一层，看是单渠道异常还是多渠道异常:如果单渠道异常，某个渠道的交付是否有问题；如果多渠道异常，交付预算会减少吗？如果保留率异常，也会根据渠道拆除下一层，看是单渠道异常还是多渠道异常：如果单渠道异常，是某个渠道涉嫌刷，还是渠道交付人群不匹配；如果多渠道异常，是否更换交付策略、交付材料、交付登陆页面等。假设老用户DAU异常，下一步就是看是数量异常，还是留存率异常。假设数量异常，再拆下一层，看看是Android还是iOS异常，还是整体异常，然后根据版本进行拆分，看看最近哪个版本更改了什么。假设保留异常，根据终端(Android，iOS）、进一步拆分版本和手机类型，比较最新版本，看看有没有可能影响的变化。假设回流用户DAU异常，下一步就是看是数量异常，还是留存率异常。假设数量异常，然后查看召回短信、Push数量是否发生变化、触达率和点击率是否发生变化。假设保留异常，看推送策略，推送内容是否有变化，落地页承接是否有变化。经过这样一层一层的拆卸，我们通常可以找到一些异常点，然后我们需要做的是不断地拆分和细分这些异常点；最后，找到一些我们认为可能有影响的点，得到一些猜测，然后进行调整、测试和迭代。第二，回顾问题，扩大我们回顾以下问题，我们是怎么做的，遇到这个通用问题，我们能做什么。我们经历了以上DAU下降的问题:DAU下降-谁下降-为什么下降-我们该怎么办。对应的一般问题是：发现问题-收敛问题-得出猜想-验证猜想。在发现问题的层面上，没什么好说的。每天看数据，看异常趋势变化，看同比变化。收敛问题是缩小问题的范围，直到发现问题。一般先外后内，再整体局部，再细分拆解。外部原因是首先找到会影响当前问题的外部系统元素。有时系统本身可能没有问题，但外部环境发生了变化。对于内部异常数据调查，通常可以先找到一个公式，包含所有相关因素，然后看看哪些因素异常，并结合不同的维度进行更详细的分割。例如，上述DAU=新用户DAU 老用户DAU 回流用户DAU，或材料输送的激活率=曝光率*点击率*下载完成率*安装完成率*启动率*激活率。常用的细分维度如下：渠道、新老用户、用户关键行为次数、性别、年龄、区域、版本、终端等。猜测通常是在一些数据或功能性能差的情况下进行的，如以下猜测：推广渠道、方式、材料是否存在问题，用户发现与预期不一致；功能入口是否太弱，看不见；宣传没有让用户感受到自己的价值；功能是否太复杂，路径太长，用户没有感觉到价值；功能是否有价值，但与用户预期不一致；解决方案本身是否存在问题，不能满足需求；需求是否根本不存在。这些都是基于以往的经验，或者是基于对业务和用户的理解。这些都是基于以往的经验或对业务和用户的理解。猜测毕竟只是猜测，需要证实或伪造。接下来，基于这些猜测，给出相应的解决方案。因为只是猜测，最好用最小的成本来验证，也就是我们所说的MVP。MVP验证怎么样？根据影响的范围、影响的结果大小、影响的可能性和实现成本，最好进行单因素验证。如果因素太多，就不容易归因。最后，基于这些猜想和数据变化，不断优化迭代。简要总结全文：发现问题：看趋势、同比、环比；收敛问题：外部：外部： 内部，整体公式 细分不同维度；猜测:基于经验，对业务和用户的理解；验证猜测:MVP、性价比，单因素验证。以上是本文的主要内容，欢迎斧正、指导、拍砖。