很多同学总觉数据分析做得不深入，到底该怎么做？今天结合一个具体的例子，分享下如何做一个深入的数据分析项目。
深入级别：0级
某天，你收到一个需求：“看下我司APP新增的A功能，过去5天内累计使用1+次的人有多少（去重）”。这问题太简单了，直接跑个数丢过去即可，“过去5天累计使用人数10000人”搞掂。
但是这种分析完全不深入，甚至压根不能叫“分析”，这就是提个数而已。确实，当需求是很具体的取数指标+统计时间的时候，这就是取个数，第0级深入就是如此。
深入级别：1级
某天，你又收到一个需求：“看下我司APP新增的A功能，过去5天有多少人在用”。
听起来和之前的问题差不多，但注意，“多少人”并不是一个明确的指标，只是个笼统的说法，细分起来，有：
1.5天内累计使用1+次的人（去重）
2.5天内累计有多少人次使用（不去重）
3.5天内，每天有多少人在使用
4.5天内，累计使用5、4、3、2、1天的人有多少
5.5天内，各使用频次人数（1、2、3……10、10+次）
……
好几个指标拼起来，才能把这个多少人说明白。有些同学会觉得，这么搞是不是太麻烦了。我就默认他是看不去重的人次呗。实际上，工作中相当多的重复取数，加班加点，被业务追着屁股催数，就是从“没确认清楚需求，自己默认一个业务不想要的指标”开始的。特别是你问业务：想看哪个口径。业务会说：都看。这时候最好自己先提前想多几个，避免重复返工。
这种主动思考，才是深入分析的起点。因为这几个指标对业务都有用：
- 看去重的人数，可以评估总用户渗透了多少
- 看每天人次，可以看出发展趋势
- 看各类型累计使用天数，可以判断有多少重度用户
- 看各类型累计使用天数，可以判断有多少重度用户
而且，我们发现，第0级的成果，成为第1级产出的一部分。后续也是一样，越深入，设计的指标、维度越多，问题会越复杂。
深入级别：2级
某天，你又收到一个需求：“看下我司APP新增的A功能，过去5天使用的人，付费行为是不是比其他人更好”。
注意，这里也没有明确的数据指标，因此得先拆解问题：
- 主语是：过去5天使用过A功能的用户。那得先知道有多少人在用？第1级深入的数据，这里都需要加上。
- 付费行为：付费行为是个笼统说法。是付费金额，还是频次？没说清就先都拎出来看。
- 比其他人更好：什么是其他人？是全体用户，还是未使用该功能用户。从问题场景上看，应该区分出过去5天内未使用过该功能，并且至少活跃1次的用户，这样才有可比性。
有了这三步拆解。可以把这句不清晰的需求，落地成一个取数需求：
- 过去5天内使用过A功能用户基本情况（人数，使用天数分布，使用频次分布）
- 过去5天内使用过A功能用户付费行为（多大比例，付费人群的5天内累计付费金额，5天内付费频次，人均付费金额，人均付费次数）
- 过去5天内未未使用过A功能，且活跃的用户的活跃天数、付费比例，付费金额，付费频次，人均付费金额，人均付费次数）
这样，两个群体一对比，就能出结论了。然而这么做，很快会引发下一个问题：“为什么使用A的人群比其他群体高/低？”
深入级别：3级
某天，你又收到一个需求：“分析下为啥使用A功能的人付费更好？”注意，先问是不是，再问为什么，是回答问题的基本要求。因此在拆解问题的时候，得先把深入2级功课都做完。做实了“A的付费更好”以后再分析原因。
分析原因的时候，假设很重要。需求既然关注A功能，那A功能到底有没有用就是关键。在分析原因的时候，证伪比证真更容易，所以我们可以先剔除一些明显的错误答案，比如“A功能用户本身都是高付费群体”，这一下就能把“A功能对付费转化有用”直接干掉。
但这样，逻辑上还是站不住，因为：
- 本身消费高，但是用了A功能以后消费更高了
- 本身消费高，但是比不用A的人更高
- 消费低的人，用了A也有提高
- 消费低的人，不用A只会更低
- ……
即使看到数据：A群体消费天然比不用的高，还是有至少这4种可能性要排除。所以得列清楚假设逻辑树，逐一排查可能性。这也是我们说的：验证观点，需要同时找正反两面的例子。
注意，即使这样，还是有反驳观点。因为我们都是基于过去数据分析，很有可能一个反驳观点是：“A功能只能吸引到这一小簇用户，不能做大”或者“A用户只是尝新，过了这段时间就没有效果了”这两个观点，都涉及未来数据情况，因此需要观察一段时间才能有结论。
如果我们等不了那么久，还可以做测试，比如测试：“做不大”这个点，可以主动向其他群体推广A功能，观察A功能增量以及留存效果，如果增量少，或者有增量但是留存差，那就可以推论：确实做不大。想要做深入分析，测试与长期观察是不可少的，好结论需要时间沉淀。
深入级别：4级
某天，你又收到一个需求：“分析下A功能对用户有啥影响？”看起来问题表达更简单了，可要解这个问题却更复杂了。因为从0级到3级，我们只讨论了“付费”这一个影响，实际上还有可能有更多影响，比如活跃、留存、转介绍等等。每个方向都得经历这么漫长的拆分、分析，才能得出综合结果。
到这里，我们的分析已经非常有深度了。有趣的是，我们的问题，反而非常简单。实际上，如果一个问题：
- 有清晰的衡量指标
- 有明确的判断指标好坏的标准
- 有明显的指标间影响逻辑
- 基于封闭的业务场景，容易测试
那这个问题就是很容易解决的。
可现实中的问题，常常是：
- 口语化表达的
- 包含了多个方面的
- 没有清晰判断标准的
- 杂糅了很多影响因素
- 没有时间、场地给我们慢悠悠测试
这时候就能从头开始，一点点梳理。把本篇文章的顺序倒出来，就是从0开始梳理业务问题的场景。
当然，并不是所有的分析都需要这样从头到尾过一遍。
- 有可能提问人自己完全没概念，此时可以先给到1级深度数据，让他建立认知，再给2级深度的数据，引导他关注差异。
- 有可能提问人嘴上说得含糊，但心里有明确的目标，这时候可以进行深入沟通，清晰需求。
- 有可能提问的人不需要严密的论证，有部分证据即打算直接下结论，这时论证其最疑惑的点即可
这时候唯一不要干的，就是不沟通，自己拍脑袋随便仍几个数，或者到网上找所谓“模型”生搬硬套。这样闭门造车，返工、加班、被diss都是经常的事。
如果在某个业务场景下，我们已经做了很多次验证，论证了业务问题的关键指标+判断标准+因果关系，这时候就可以直接套用，这就是我们说的：业务分析模型。不过在沉淀出来之前，还是得多做论证的，特别是因果关系论证，做的不够细致，分分钟被打脸。
