这个时代最重要的技能之一
这里是Z哥的个人公众号
每周五11：45 按时送达
当然了，也会时不时加个餐～
我的第「206」篇原创敬上
大家好，我是Z哥。
首先说明一下，今天不卖课程哈，就单纯聊聊我在做数据分析时的一些经验。
在如今这个数据爆炸的时代，我们每天不管是主动还是被动，都会面对大量的数据扑面而来。
如果有较好的数据分析能力，不管是对你的生活还是工作，都将带来巨大的帮助。因为你比别人拥有更好的“洞察力”，看到别人看不到的信息，这些信息可以帮助你更好地做出决策。
很多人做数据分析的时候经常会遇到一个问题，面前摆着一堆海量的数据，但是不知道怎么分析，从何下手，以此来得到一些有用的结论。
我最开始也深受这个问题的困扰，想了好久才明白这里的问题所在，所以今天我把我思考后的思路分享给你，希望能对你有所帮助。
一个合理的数据分析思路，不但可以帮助你高效地获得对你有价值的信息，还能提高结论的准确性。
我的思路其实是一个构建「点->线->面->体」的过程，主要分为以下六个步骤。
/01 带着目的/
如果你会觉得无从下手，大概率是因为目的不明确，或者说缺少目的。
没有目的，何以解决问题？寄希望于某个牛逼的方法能够“点石成金”？但是，谁来告诉你这个方法呢？靠上帝吗？
这个道理说透了其实很容易明白，但现实却是很多人陷在数据的海洋中无法自拔，认为先收集足够多的数据，然后再分析，就能从中得到一些有价值的结论。这个逻辑其实你细想一下是有问题的，因为不同的人看待同样的数据得出的结论往往是不同的。因此，如果你没有清晰的目的，再多的数据也没有意义。
所以，先确定目的就是先明确「点」，只有有了「点」，我们才能继续延伸去构建我们的「线面体」。
目的一般分为以下两种。
找原因。当前面临一些问题，从数据中找出相关因素。
找规律。从数据中提炼出一些规律，趋势，帮助未来做决策。
所以，不妨先明确一下，你是要找原因？还是找规律？
比如，我们分析网站访问量为什么下滑。很明显，这个目的是「找原因」。
/02 分解目的/
明确了目的，就有了一个大方向，剩下的就是分解目的。
分解目的的方法论有很多，MECE、5W2H 等等都可以。
按照 MECE 法，以「不重叠、不遗漏」的方式将数据分析的目的拆解成多个子问题。
5W2H 法很常见，就是what、why、when、where、who、how、how much。
还有一个我觉得很好用的方法论，从 GrowingIO 那学来的。就是一个「业务目标 * 业务流程 * 业务场景」的三级结构。先列出业务目标，然后展开每个目标的流程，再展开流程上的每一个环节对应的场景（场景中蕴涵着关键指标）。
这个方法其实一次性就把「线面体」的大框架构建完了。
在我们的案例中，影响访问量的因素有很多，对于这个目的的分解用 MECE 方法更合适。我们也可以用思维导图来实现。
/03 验证子问题/
通过 MECE 方法将目标分解完之后，其实就已经把「线和面」构建完了，接下去就是最后一步，构建「体」。
构建「体」的过程其实就是思考如何验证其中的每一个子问题。
怎么验证？先建指标。现代管理学之父彼得·德鲁克说过一句很经典的话：
如果你不能衡量它，那么你就不能有效增长它。
所谓衡量，就是需要建立统一的标准来定义和评价。你认为的不错，别人不一定这么认为，老板可能还认为很糟糕。所以，建立指标的目的其实就是统一口径，使得同一份数据能让更多人得到一致的理解。
建立和使用单一指标是数据分析的第一步，接下来你需要建立指标体系，因为孤立的指标发挥不出数据的价值。
一个还不错的指标体系，至少要满足以下三点：
有三个以内的核心指标。核心指标不仅仅是数字，是所有人需要盯着看去努力的。就像销量和销售额，用户数和活跃用户数，大多数情况下后者都比前者重要。
指标之间存在关联性。
单一指标至少有两个以上维度。（比如，同比、环比等）
指标体系没有放之四海而皆准的模板，不同业务形态有不同的指标体系。移动 APP 和网站不一样，SaaS 和电子商务不一样，低频消费和高频消费不一样。比如婚庆业务不需要考虑复购率指标；互联网金融必须要风控指标；电商领域里的用户需要分为卖家和买家，而且他们的指标各不一样。
对我们上面的案例，摆上指标后大致是这个样子。
/04 清洗数据/
好了，「体」建设完之后，接下来就是把数据填入进去了。但是在复杂的数据分析场景下，我们可能在数据填入之前还要做一件事。
由于在实际的业务场景中，原始数据可能会来自于各个内部以及外部系统。指标口径对不上，总会出现不一致、重复、不完整、存在错误或异常的数据。
因此需要通过一些额外操作对这些数据做清洗，得到符合我们要求的原始数据。我们这里不讲太技术性的东西。从逻辑上主要做以下几件事。
数据清洗：去掉噪声和无关数据
数据聚合：将多个数据源中的数据结合起来存放在一个一致的数据存储中
数据转换：把原始数据转换成为适合做分析的数据格式。
/05 用数据验证/
好了，框架搭好了，原始数据也有了。剩下的就是通过数据来验证猜想了。
怎么验证呢？
这里我又要给出一个大杀器了，就是多用「演绎法」，而不是「归纳法」。
虽然这俩这都属于逻辑思维，但是归纳法有一个很大的问题：因为我们不可能观察到某个事物的所有影响因素，所以归纳法得出的结论是不一定是正确的。
比如，某个指标下降了 5 %，真的是个不好的情况吗？不一定，如果行业下降了 20 %，你才下降了 5 %，这就是一个还不错的结果。
而演绎法的本质是，找到发生变化的原因，如果某个原因在未来还会继续存在，那么可以支撑某个结论。
比如，行业为什么下降了 20 %？导致下降的原因未来是否还会存在？如果这些因素无法消除，那么未来继续下滑是在预期之内的。
/06 保持迭代/
当你形成了一套自己的数据分析体系之后，还不能一劳永逸，需要保持迭代。因为在业务的不同时期，我们关注的点会不同。
比如，在业务的初期，我们会更多关注流量、转化率这些，但到了成长期以及成熟期之后，还需要关注用户活跃度、复购率等等数据指标。
好了，这次就聊这么多。惯例总结一下。
这篇呢，Z 哥和你分享了我在数据分析上的一些经验。
我的思路其实是一个构建「点->线->面->体」的过程，主要分为以下六个步骤。
带着目的
分解目的
验证子问题
清洗数据
用数据验证
保持迭代
希望对你有所帮助
从本质上看，真正要做好数据分析这件事，本身对一个人商业理解、业务能力有很高的要求。因为只有有了这些能力，我们才能知道我需要哪些数据，才能识别出哪些数据是对我有用的，以及我可以如何运用这些数据。这些对数据分析有着事半功倍的效果。
引用一张 GrowingIO 的图，分别展现了数据分析相关工作的投入产出比。
可以看到，看上去越偏技术性的工作，其实产生的单位价值反而更低。所以，你知道该怎么做了吧？
原创不易，如果你觉得这篇文章还不错，就「点赞」或者「在看」一下吧，鼓励我的创作 ：）
也可以分享我的公众号名片给有需要的朋友们。
如果你有关于软件架构、分布式系统、产品、运营的困惑