拆解问题：为什么总是拆解出一堆没用的数据？

前文学习了如何定义问题，解决了“是什么”，接下来就要开始分析问题，解决“为什么”。要想找出“为什么”，第一步是找出表面原因，这就需要先拆解问题。

拆解问题看起来很简单，就是把问题用结构化思维拆解成小问题，然后发现问题集中在某一个特定的小问题上，那就大功告成了。这种思想很常见，因为所有的文章和课程，都没有细说过拆解问题的核心思路到底是什么。

很多课程会告诉你一个叫作“多维度分析”的分析方法，然后老师给出一个分析案例，然后看似随意地选择了几个维度拆分问题之后，分析结果出现了，非常地神奇。你会惊呼：数据分析真是太有用了！等到你自己遇到业务问题要拆解的时候，选了 N 种维度拆解问题，最终却得不到想要的结果。

为什么？因为老师只告诉你这样拆可以得出分析结果，但是没告诉你为什么要这么拆，为什么要选这几个维度。

今天我就来讲一下，如何拆解问题。

拆解问题的目标究竟是什么

首先，很多同学不清楚拆解问题究竟要拆到什么程度，所以拆分的时候没什么章法。他们先是选几个维度拆分一下，然后看看有没有什么特点，之后根据这些特点思考一下有没有新的假设，再根据假设拆分一个新的维度。

他们一会儿拆分业务指标，一会儿拆分用户的类型，一会儿拆分行为特点。看起来逻辑很有条理，但整个思考过程没有一个规划，走一步算一步，本质上完全在碰运气。

这个是非常普遍的问题，也不能怪新人分析师，因为确实也没有什么课程会教这个知识。这些同学只知道书上和网上都说拿到分析需求之后，要拆解问题，所以他们就直接开始拆解了。并不了解拆解问题，究竟要拆什么？究竟要拆到什么程度？

所以在拆解问题之前，我们一定要搞清楚，我们拆解问题的目标到底是什么，拆分问题究竟是解决了什么问题。

分析问题的步骤可以拆分成两步：

• 找出表面原因

• 找出根本原因

那到底什么是表面原因呢，什么是根本原因呢？下面用一个贴近业务的例子详细说明。

表面原因，你可以把它理解成能用指标体系找出的原因。

比如销售额下降了，那么表面原因可以是：

• 某个具体的群体、渠道、产品等维度下的销售额下降；

• 当然还可以深挖，找出 A 渠道的 B 产品销售额下降，这个表面原因范围更小，更加精准。

• 也可以是 A 渠道的用户人数下降，因为用户人数是销售额的子指标，依然在指标体系范围之内；

• 甚至是你通过过程指标，拆分出 A 渠道的拉新落地页转化率降低，这依然是表面原因。

在找出 A 渠道的拉新落地页转化率降低的表面原因之后，我们会想要知道“为什么 A 渠道的拉新落地页转化率会降低？”这个问题的回答就是根本原因。

根本原因，是不能用指标体系找出的原因。

比如上面那个问题，可能是因为 A 渠道的拉新落地页上某个图片突然不显示了。这种原因你在设计指标体系的时候是想不到的，每一个业务问题最终的根本原因千奇百怪，没办法为这些千奇百怪的原因设定指标。

所以找出根本原因，相比表面原因会更复杂一些，需要结合实际的业务情况提出假设，这一部分知识将会在后文继续展开中详细讲解。

我们拆解问题的目标，就是要找出的就是表面原因。 了解了这个目标，就能避免按照一些奇怪的维度进行拆解。比如按照用户是否使用过某功能来拆解问题，看使用功能是否会对转化率造成影响。这种拆解已经属于找出根本原因的范畴了，在找到表面原因之前，不要急着拆解这些非常个性化的维度。

分清楚了表面原因和根本原因，之后我们再拆解问题的时候，思路就更加清楚。

具体拆解方法

我们逐一来看，拆解问题具体该怎么做。

第一步 排除数据错误

首先，如果数据和预想的差别很大， 或者几个不同指标的数据交叉比对后发现数据有明显错误，那么就要怀疑是不是数据本身出问题了。这种情况并不常见，但是我们必须要有这个意识，否则做了几天的分析，最后发现原来是数据错了。

数据的产生是一个相对来说比较固定的流程，所以排除数据错误可以顺着这个流程找原因。

比如一般的数据是通过客户端采集，然后传输到服务端，服务端清洗后保存在本地数据库，然后从数据库再次清洗入库到数据仓库中。

那么这个流程可能出现的问题点有：

• 客户端问题：可以排查客户端版本、机型等，排查版本问题、机型适配问题。

• 服务端问题：可以排查不同服务端的日志数量，看是否某个服务器出现了问题。

• 数据仓库问题：排查服务端日志和数据仓库的日志是否能对应上。

经过这样的排查，基本上可以确定数据本身是否存在问题，数据没有问题，再进行下一步的分析。

第二步 缩小问题范围

在确定了数据正确的情况下，我们就进入第二步——缩小问题的范围。

这一步，比较常用的方法就是多维度分析，这又是一个新手分析师犯错的重灾区。

这类同学呢，一般对业务还不太熟悉，所以就拼命在数据层面想办法，他们心里想：“不就是拆分维度找原因嘛，我不懂业务，那我就多拆几个维度，维度多了之后肯定能找出数据上的差异点，最后再把这些差异大的维度组合起来就是问题的原因了。”

所以他们就喜欢堆维度的数量，然后就把数据库里能找到的什么版本、系统、地域、停留时长之类不管什么类型的维度都拆开来看一遍。维度太多看不过来呢，就根据不同维度的区分度自动排序，找出差异最大的几个维度来。

要实现快速跑完所有维度并且排序的话，代码基本功倒是不错，但是出来的结果一点用处都没有，为什么？

因为按照这种方法拆解，最后会发现，好多维度都有区别：地域有差异，手机型号有差异，新老用户也有差异，如果按照这些差异组合起来，那么如果有 5 个维度，每个维度只分 2 类，那么组合起来就有 32 种类型。如果每个维度分 3 类，那么组合起来就有 243 种！这个复杂度相当恐怖，你要配几个业务人员才能搞定这个问题？这个人力成本就决定了不可能实现这样的精细化运营。

正确的做法是什么呢？

首先，我们要选择拆解的维度。 拆解维度的选择是这一步最关键的地方。

维度的类型上，我们可以根据“子指标”和“维度”进行拆分。这里就用到了 03 讲中指标体系的知识，如果你记不太清，建议回到03 讲再回顾一下。

维度的选择上，要符合业务管理模式。所谓业务管理模式，也就是现在公司是如何运作这个业务的。大部分同学拆解问题最终拆除一堆没用的数据，基本上都是因为没考虑到这一点，拆解的维度离业务太远，最终没法落地。

举个例子：

比如某些线下企业，业务管理模式就是各地区设置分公司，由分公司管理该地区的整体运作。这种情况，你在拆分销量问题的时候，可以按地域（分公司）拆解。因为地区维度是这家企业的业务管理模式。

而在互联网企业，地域的区别不是特别大，业务管理模式是对用户进行分层，区分新用户、成长用户、忠实用户、流失用户。这种情况下，地域维度是用户维度，不是业务管理的维度，你再用地域这个维度拆分问题，就非常不合适了。

这主要是考虑到最终拆分出来的维度更容易落地，就算地域维度的差异真的很大，但是要更换一种运营模式，成本也很大，这样落地就很难。所以最好还是用原有的业务管理模式“用户分层”对问题进行拆分。

然后，多个维度组合进行拆解。 经过第一步的维度选择，第二步我们把这些维度组合起来，开始拆解问题。

有些同学在这一步，喜欢先按某一个维度单独拆分，再根据拆分的结果中问题较大的部分再拆分一个新的维度。我这里不建议这种做法，因为有些问题很隐蔽，按照这种做法拆分未必能找到原因。

举个例子，比如我们先按子指标拆分，再按照指标维度拆分，会有这样的情况：假设某业务的用户来源有 A、B、C 三个渠道，其中 A 渠道的人数很少，但是客单价非常高，如果某一天 A 渠道的人数下降了 10%，会导致总体销售的下降。

如果你先按照销售额的子指标拆分，你会发现：

• 用户数没有明显变化。因为 A 渠道人数很少，减少 10% 在总体上看丝毫不明显；

• 转化率也没有明显变化，原因和上面相同；

• 客单价下降很厉害。

然后你觉得是客单价出现了问题，你再对客单价按照渠道的维度拆分会发现，三个渠道的客单价基本都是稳定的。

这样拆分问题，就找不出原因到底在哪。

所以我们还不如一次性把这些维度全部放到一个表格里，这样就能很清楚地直接找出问题。

你可能会说，这样一个表格，只有两个维度，会不会不够？

其实，你拆解问题的时候，不用追求维度“多”，而要追求“精”。一般维度不用太多，控制在三个之内就行了。因为业务管理模式本身就那么几种，可选择的范围也不多。再来就是两维或三维的模型兼顾了复杂度和精细化，更容易落地。比如你注意观察日常工作中最常见的模型，往往都不会超过三个维度，想两维的矩阵、九宫格，三维的 RFM 模型等。

因为三个维度以内的模型，复杂度还可以接受，更容易操作，超过三个的模型复杂度太高，要被团队所有人理解非常困难，很容易玩崩。

缩小问题范围的正确做法就是这两个步骤，先找出拆解的维度，然后再用这些维度组合起来拆解问题。

第三步 找出具体环节

缩小了问题范围之后，我们还可以找出问题出现的具体环节。这个步骤主要通过拆分过程指标来实现，这个部分在 03 讲指标体系中有介绍过，这边就不多介绍了。

这里要说的是，拆解问题的时候，这一步可以进一步缩小问题范围，但是这一步并不是必需的。为什么呢？

• 第一个原因是某些问题没有过程指标，或无法获取过程指标。比如某些渠道投放的时候，只有一个投放金额，和最终引流的人数，中间广告曝光、广告点击等数据都无法获取，所以就无法拆分过程指标。

• 第二个原因是某些问题的业务流程本身就不合理。如果本身是一个不合理的业务流程，你定位到了其中某个环节，最终的分析反而会走进死胡同。比如在 07 讲 用户思维中提到的案例，一个落地页点击购买按钮之后，进入的是另一个落地页，那么这个流程就是有问题的，你再怎么优化第二个落地页，效果也不会太好。

所以找出具体环节这一步，根据情况决定是否需要拆分。如果业务流程成熟，可以拆分到过程指标。如果业务流程还在磨合阶段，那么不一定需要拆解到这一步。

小结

很多新人拆解问题这一步做不好，拆解出一堆没用的数据。这是因为他们知道该拆解问题，但是不知道按照什么维度拆解。他们都是看别人一路拆下来看起来非常顺利，但到了自己拆解时就没有思路，完全凭感觉拆解，导致最后的分析结果之间没有什么关联，对业务也没有参考意义。

其实拆解维度的选择，符合指标体系以及业务管理模式就可以了，说起来非常的简单。所需要的知识在前面的内容中都有提到，但是有知识未必会用，缺的就是有人告诉你如何把这些知识点应用起来，把知识变成能力。这就是如何使用知识的知识，本文希望能帮助你快速提升这方面的能力。

本文强调这样几个关键点。

• 拆解问题的目标是为了找到表面原因，表面原因是能用指标体系找出来的原因。

• 拆解问题的分三步：排除数据错误、缩小问题范围、找出具体环节。

• 缩小问题范围时，拆解维度可以从指标体系的子指标和维度中选择。

• 拆解维度必须符合业务管理模式。

• 拆解维度求精不求多，尽量不要超过三个维度。