编者按：本文来自人人都是产品经理，作者接地气的陈老师（公众号ID：gh_ff21afe83da7），36氪经授权发布。
因为用户相关的话题很多，为了便于大家阅读，这里把各种话题做一个归类如下图，这样看着清楚一些。今天我们来系统的分享一下：用户活跃这个话题。
01 用户活跃常见问题
当然，针对不同目标、不同业务，可以有不同定义。但使用这些定义的前提是口径统一，各个部门得达成共识：有XXX行为的就算活跃了。
而最常见的问题，就是不但没统一口径，而且还不断发明新名词，搞得历史数据前后对不上。最后开起会来鸡同鸭讲。
在讲用户流失分析的时候，我们说过：流失分析的目的不是消灭流失率，而是把流失控制在可控范围内。在用户活跃分析的时候，道理类似：做活跃分析，不是为了逼用户天天来戳一下，而是为付费、转介绍提供稳定的支持。
03 用户活跃分析基本思路
定标准：目前业务需要什么样新增、活跃、付费结构
找规律：常规的活跃走势，该是怎样
查异常：区分常规变化、异常变化
追原因：对异常变化进行追踪，分析
定计划：根据问题轻重缓急，制定应对
最重要的当然是定标准。作为业务方，心理要有判断：我需要多少活跃用户，需要多少活跃率；并且不能割裂看一个指标，要关注AARRR的整体形态。
比如最基础的三大策略（如下图所示）：
请注意，竞争策略才是定标准的核心。比如传统观点认为金融服务是低频业务，可做金融APP时，可完全把财经新闻、理财教育、本地吃喝攻略、电影信息这些和消费有关的东西做进去，把一个低频应用做成高频应用。
因此，一般同类业务特征和发展阶段只是参考。更重要的，是业务内心的声音：“我们要做成一款XXX的应用，相比之市场上的产品，我的目标是XXX”。
这就要求，运营需要有自身业务判断能力，能对自己的方向有清晰的认识。数据分析师只是辅助作用，提供比如业务特征、发展阶段、竞品数据以作参考。
这也是怎么回事陈老师会吐槽，活跃问题是“乱自上做”，确实有很多公司的运营没啥想法，就知道机械完成KPI，只要数据达标就行。数据不达标，就试图把锅甩给数据分析师没洞察、对手刷量了、我们费用不够。这样标准都不清晰，更没法谈后边的分析了。
这些具体的政策、事件、运营动作，才是指标变化的本质原因。因此在分析之前，应该先大量收集内外部事件，拿着事件思考问题。而不是就数论数，说“因为过去三天涨，所以今天涨”“因为之前周五涨、所以这个周五涨”之类毫无逻辑的话。
找到一些明显的规律后，可拿来做定性预测，根据未来要发生的时间，预计指标波动变化，也可拿来做解释。比如发生指标波动的时候，如果有对应事件发生+对应波动形态，那八成就是规律性变化。
这样做，可以节省大量分析时间，而不是做了一堆分析，还被吐槽为：“我早知道了”“它就是这样的呀”。
注意，不是所有的波动都值得追击，大幅度、持续性、非规律、波及其他指标的优先处理。偶尔的波动一下很正常，但是要记录发生时间，观察走势，当问题出现恶化时容易溯源。这样做，不用让数据分析师陷入无休无止的纠结里，更容易找到真正的异常问题。
先判断是哪一型的问题再追原因。追原因的难度是：事件型》系统型》持续型的。一次发生的事件最容易查到源头。
系统型差异，能够最终靠竞品分析得到答案。持续性问题反而最纠结，有可能过着过着自己没了，有很大的可能是一次重大事件的余波，也有一定的可能是深层次的问题。
必须要格外注意，我们常说DAU=DNU+DOU（日活跃用户=每日新用户+每日活跃老用户，一般新注册用户都直接计入活跃）往往系统型问题会影响DNU，在用户注册后T+1，T+2…T+N的时间内没有做好引导，导致用户不活跃甚至流失。
DOU往往与事件有关，比如季节性促销，沉默用户唤醒，新品上市等等。因此在追踪原因时，可以分头观察。对新人关注注册到首次付费流程，对老人打标签，关注老人对活动的响应（如下图所示）
总结
最后再强调一句：好方法是设计出来的，不是算出来的。靠数据分析只能评估过往的方法好坏，最多再预测下用户对XX产品响应率，不能再多了。真正做好落地，还是得靠运营自己多练内功才行。
从头看完，我们会发现：数据分析方法一点不神秘，更多的是：
大量的、细致的收集事件
用数据描述、评估、总结事件
用逻辑推演事件的影响，用数据验证假设。
这是个很枯燥的体力活，却是出成绩的关键。脱离了这些细节，任何 “思维方法”“底层逻辑”“核心法则”都没法起效。只有算命大师才是摇摇铜钱天知地知，做数据分析的人，其实和搬砖工没啥区别。
