业务数据分析的通用流程

案例背景：

假设你现在是一家在线教育 App 的数据分析师，领导让你分析如何提升 A 课程的销量，你会怎么思考及落地？

先不急着给出答案，你知道解决问题一般的流程是什么吗？

通用的解决问题的流程

几乎所有问题的解决思路都可以用 2W1H 模型，分别是：

What，是什么；
Why，为什么；
How，怎么办。

为什么这个模型所有问题通用呢？因为你只有知道问题是什么，才能分析为什么；也只有分析出了为什么，我们才能知道该怎么办。因此，我们可以套用这个模型对上面的问题进行分析。

这里我也可以提醒下，虽然这个模型的优点是通用，但是缺点也是太通用了。通用的模型适合大多数情况，所以没有很多细节。这个模型如果想具体应用在业务数据分析领域的话，还需要进行一些改造，才能成为数据分析常规流程的专用模型。

下面我们就顺着“是什么、为什么、怎么办”的思路，分析一下如何提升 A 课程销量的问题。

What：是什么

“是什么”，是业务数据分析最基础的一个问题。即要解决的问题是什么？领导问你如何提升 A 课程的销量？这个问题可以简单拆分一下。

首先“如何提升”，也就是说你最后分析出的结果应该是一些落地方案。什么是落地方案？方案包括改进的落地措施、负责人、时间，等等。比如分析完之后你建议某渠道的投放资金提高 30%，预计可以带来 10 万的销售额，这就算是很好地回答了“如何提升”。如果没有具体的落地方案，你只说加大渠道投放，那么这么多渠道，投哪个？投多少？这些没交代清楚，就不算完整地回答“如何提升”。

然后是“销量”。这个销量的定义似乎不是很清晰。你需要搞清楚这个销量到底是按人算，还是按钱算？问题中的词语必须搞清楚定义，避免歧义一错再错。假设案例里是按钱算，那问题也就变成了“如何提升 A 课程的销售额”。经过简单梳理，“是什么”这个问题就清楚多了。

在第一环节“是什么”这里，一定要搞清楚问题是什么，很多同学都没搞清楚问题是什么，就草草分析后给领导报几个数，说哪几个数高了哪几个数低了。其实这种回答属于答非所问，因为我问你如何提升，你告诉我转化率很低，不被质疑才怪。

“是什么”虽然很简单，但非常重要。要记住，认清问题是成功的一半。

Why：为什么

“为什么”，这一环节就有点复杂了。这里我把“为什么”拆分成以下三个问题。

为什么要分析这个问题？
问题的表面原因是什么？
问题的根本原因是什么？

我们针对案例逐一来看。

1. 为什么要分析这个问题？

上一步我们知道了问题是什么——如何提升 A 课程的销售额，但还不能急着马上分析。因为你要先搞清楚：为什么我们要分析这个问题，也就是了解领导希望分析这个问题的目的。

有同学会问，之前的一步不是已经搞清楚问题的目的了吗？就是要提升 A 课程的销售额呀。

这确实是问题的目的，但这只是表面目的，还有深层次的目的需要我们挖掘。

比如领导的目的是想短期冲一波业绩呢，还是希望细细打磨产品？如果是短期冲业绩，而你却以打磨产品的心态分析这个问题，提出了一堆可能效果比较好但见效慢的建议。或者领导的目的是打磨产品，你却提出一些短期见效却有长期隐患的建议。虽然这都解决了如何提升销售额这一个表面问题，但是没有搞清楚根本问题，那么分析结果自然就不受待见了。

因为短期见效的建议相对比较容易，比如降价促销、活动运营之类的，业务人员自己就能凭经验完成。所以这个案例里，我们假设领导想要的是打磨产品，提升产品自身的转化能力。

另外，搞清楚分析的目的，可以评估分析的价值，从而调整分析需求的优先顺序。因为数据分析师的精力是有限的，手上有很多工作，做了 A 课程的销售分析，就没法同时做 B 课程的销售分析，或者产品的留存分析、路径分析等。所以我们必须清楚要分析的问题目的是什么，到底重不重要，是优先做还是等有空了再做。

还有，搞清楚问题的价值，比用什么分析方法更加重要。如果公司目前现金流紧张，急需变现。这时候有两个数据分析师，一个分析师得出一个初步结论——变现过程中 A 产品有较大的潜力。另一个分析师完成了一个深度分析，给出了提升流失用户召回的 N 种落地方案。虽然前者只是给了一个大概方向，但明显前者的业务价值更大。

如果你明白问题的分析价值，即使你不懂分析方法，顶多分析得慢一点或者不够深入，但是有价值的初步结论，远好于没有价值的深入结论。

2. 问题的表面原因是什么？

什么是表面原因，什么是根本原因？如果我们肚子疼，医生检查之后确定是胃疼，“胃疼”就是表面原因。知道胃疼还不足以治疗，我们还得知道为什么会胃疼，导致胃疼的病因才是根本原因。

“为什么”的第二步，我们先找表面原因。一个业务问题我们可以拆分成不同的业务环节，在业务数据分析中，表面原因你可以理解为问题集中在哪个业务环节。

落实到这个案例里，我们先看一下整个用户转化路径是怎么样的。假设 A 课程的用户转化路径如下：

用户看到投放的广告；
用户进入广告推广落地页；
用户在落地页点击购买；
用户付费成功。

当然销售额的来源肯定不只有这一种途径，比如用户可以直接去 AppStore 下载并购买课程；用户也可以通过老用户转介绍购买课程。为了便于你理解这一步的分析思路，我们假设销售额的来源只有用户看到投放广告购买的这一种途径。

找出表面原因最常用的方法就是细分。我们通过把问题按照不同的维度细分，然后对比找出问题最大的细分项。我们可以把业务问题按照并列关系拆分，比如 A 课程的销售额，我们可以按照渠道、用户类型、时段等不同的维度进行拆分。如果我们按照渠道拆分，那不同渠道销售额相加之和就是总销售额。

我们也可以按照用户购买路径拆分，把 A 课程的销售额拆分成转化链路，比如广告曝光、广告点击、进入落地页、点击购买、支付成功这几个步骤，其实就是漏斗转化分析，最后支付成功的金额就是总销售额。

一般来说，就算通过并列关系拆分找到问题点，也要继续按照用户转化路径拆分出不同的业务环节。比如你发现 C 渠道的销售额最低，那么还要继续按照用户转化路径拆分，看看 C 渠道的转化过程中哪一步有问题。

通过这些拆分方法，我们就可以找出问题最严重的环节，这就找到了表面原因。

假设我们通过漏斗分析，发现用户看完落地页，点击购买的转化率比较低。这样我们就可以得出一个结论——销售额低是因为落地页的转化率不高。甚至很多同学把后续的建议都已经想好了——“提高落地页的转化率”。

大部分同学在没有学习这节课之前，做数据分析时，找到表面原因这一步基本就差不多了。不过这种结论很容易会被领导评价为“分析不够深入”，因为你的分析并不能解决问题，找到表面原因只能缩小问题范围，没法得出落地方案。这些同学其实也想再继续深挖，但是因为不懂业务、不懂用户，所以想不出什么好的分析方向。

要想分析够深入，我们就必须得学会找到根本原因。

3. 问题的根本原因是什么？

业务数据分析中的根本原因，你可以理解为用户想要什么。这要用到模块一中，用户思维中关于购买决策模型的一些知识。用户在做出购买决策前，有着一连串需要满足的需求，分别是：引发兴趣、收集信息、评估价值、购买决策。

在上一步，我们梳理出了用户购买时需要经过的四个环节。但是那几个环节只是为了承接用户的一连串的需求，并不是需求本身。用户本身并没有“进入落地页”这样一个需求，用户进入落地页只是为了满足“收集信息”和“评估价值”的需求。

所以上一步，我们发现用户的落地页转化率偏低，那么用户在这一步想要得到什么呢？这节课不涉及太多细节，我直接给出我的思考，用户进入了落地页是为了获得更多的课程信息。

那么，用户在获取课程信息的时候，会因为哪些问题放弃购买呢？我们可以假设以下情况：

可能落地页的信息和广告里提到的不一样，广告里写着“数据分析培训课”，用户进来以后发现是“财务数据分析”，所以很快就走了；

可能落地页的信息排版很不清楚，有用的信息很难找，用户看了一会儿没看懂，失去兴趣就走了；

可能是用户觉得课程还不错，但是价格太贵了就走了。

这些都是用户需求问题的假设，这些假设我们可以用用户的行为数据定位大概的问题方向。

业务数据分析的通用流程

假设，该背景情况下，你通过行为数据发现了转化率低的根本原因，是由于用户对课程主题感兴趣，但是课程介绍不适合自己，那后续改版方向也就呼之欲出了。

至于如何提出假设。你可以站在用户的角度体验一次销售流程，就能提出很多猜想，也可以找同事一起讨论可能的情况。因为我们自己本身也是用户，所以我们自己的感受也是很重要的。如果大家都没什么想法，还有一个笨办法，就是把用户在落地页上的行为日志全部拉出来，然后一个个看。看了几十上百个用户的行为，基本就可以归纳出一些特点，然后我们再用所有用户的行为数据看这些特点是不是普遍的。

通过数据分析找到根本原因对于数据采集的要求很高，采集用户屏幕是否滑动到价格信息这样的数据，没有提前设计是很难办到的。所以如果你的业务这一块比较缺失，那么就要想着如何完善数据采集，而不是对着现有数据绞尽脑汁想着该怎么深挖。巧妇难为无米之炊，没有行为数据，是很难找到根本原因的。

How：怎么办

最后一步是“怎么办”。对于数据分析师来说，这一步就是给领导具体的落地方案了。

经过分析，我们整体把案例背景详细的描述下：你是一家在线教育 App 的数据分析师，领导想让你分析一下“如何提升 A 课程的销量额”。你通过分析数据发现目前销售额不高主要是由于落地页转化效率不高，而转化效率不高的原因大概率是用户虽然对课程主题感兴趣，但是用户在落地页没看到感兴趣的课程内容。

到这一步为止，我们已经找到了问题的根本原因，接下来就是怎么办了。

要想找出解决方案的方法，我们可以先看一下如果问题解决之后是一个什么样的状态。

比如：用户在落地页的转化率低的根本原因，是因为用户对课程主题有兴趣但是课程介绍无法打动用户。那么问题解决之后的状态应该是：用户看到了自己感兴趣的内容。

我们把优化好之后的状态按照“主谓宾”拆分一下：