发现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、性价比，单因素验证。以上是本文的主要内容，欢迎斧正、指导、拍砖。

以上就是关于发现DAU降低，要从内部和外部进行分析的相关介绍，更多发现DAU降低，要从内部和外部进行分析相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对发现DAU降低，要从内部和外部进行分析有更深的了解和认识。