「数据分析基础」课程的学习与思考
背景
去年从一位牛逼的同事那搞了一份「数据分析基础」的课程，没想到最近才有空学习。然后打开课程，发现是 19 年的课程，突然就觉得自己拖了几个月学习也不算长，课程应该还没过时。
为什么要学数据分析基础呢？因为我认为数据思维和分析的逻辑不光是在相关行业可以得到使用，作为一个程序员学学数据分析，在未来的工作中也能提供一些思路上的帮助。之前写过一篇初始「数据分析」，里面仅仅只是了解了数据分析的操作框架，没有实操的环节，甚至都不算入门。而这次学习数据分析基础，可以让我对数据分析有更深入的了解和认识，而这门课程的内容正好特别适合我这种入门级选手。
课程虽然知识很基础，但思考却可以更深入。我从课程的这些基础知识中，做了更深入的总结和思考，本文就是总结和思考的记录。
一、课程内容
课程的内容整体来说比较基础，没有特别难懂的地方，老师讲的也很通俗，结合实战案例，可以说连小白都能轻松理解。
以互联网运营的视角出发
课程面向的学生是互联网运营岗（初学数据分析的那种），所有知识和案例都是以一个运营的视角出发，从发现问题到解决问题，介绍了一些基础概念、市面上常用的工具和一些上手即用的方法论。
课程主题
课程的内容主要包含以下部分：
- 指标建模 - 数据指标所代表的含义，将业务指标变成具体数据的指标。
- 数据工具 - 用于展示和分析的数据工具。
- 数据分析基础 - 介绍对比分析、维度拆解、漏斗等基础分析方法。
- 数据分析进阶 - 介绍用户画像、归因查找等方法和实战问题的解决。
- 数据采集 - 介绍如何埋点，要埋哪些，如何与研发沟通要怎么埋。
以上就是课程主题的简介，这些主题结合起来构成了从制造数据到具体分析解决问题的整条链路，里面还讲了许多现成的工具和系统（GA、Excel、神策数据等），以及这些工具如何使用。
下面开始本文的正文
二、分析的逻辑
数据分析中最重要的当然是分析的逻辑，课程站在运营的视角介绍了许多方法论，但我认为这些方法底层都是基于这些分析的逻辑而来的。
自上而下
就如金字塔一般，「自上而下」的分析逻辑就像解决问题一样。拿到一个具体的业务问题，通过一级一级的拆分，将其从一个业务问题拆分成多个业务指标，再由多个业务指标转化为数据指标，从而基于数据指标进行分析，如图：
自上而下的分析逻辑很容易理解，也是我们经常都会用到的场景。这样的分析方法在有一个具体业务问题的时候适合使用，核心在于拆分。例如业务问题是「这个月的订单量为什么下降了」，那么这个问题的核心就要提出假设，然后根据假设和核心数据指标「订单量」逐级展开，验证假设，根据各项数据指标的表现找出原因。又例如问题是「如何让下个月订单量翻倍」，那么就要根据订单的转化流程做拆分，然后结合业务现状和对应的数据指标，产出方案。
自下而上
「自下而上」的分析逻辑和「自上而下」相反，没有明确顶层的业务问题出发。我们拿到现有的数据指标，通过这些数据指标的表现来找出业务问题，更像是「数据挖掘」。更多用于产品的「健康状况监控」等场景。如下图：
数据指标通过组合和计算，可以得出一个又一个的业务指标。通过对这些数据和业务指标的观察和分析，就可以得到很多价值信息。就如我们所用的「数据透视表」，通过把多个数据指标组合并绘制出图形，就可以获得走势、占比等信息。多维度的组合就是抽象的过程，也是金字塔自下而上的过程。
自下而上的分析逻辑需要较高的数据量和维度作为基础，越好的数据基础能带来的价值就越多。虽然自下而上的分析并不针对某一个特定的问题，但在分析的过程就会不断产出价值，包括业务指标、业务问题和其他的价值信息。
从数据的层面出发
无论是自上而下还是自下而上，更多的是以业务为中心来看，也许你会问怎么区分业务指标和数据指标，他们之间的界线又是什么。
如果以数据为中心的角度来看，就可以解释这个问题。在自动化领域，有一种数据分类的方法将数据分为 L1 - L4 四个等级。他们分别的定义是这样的：
- L1：最底层的数据，一般是时序数据、过程数据、状态数据等，数据量大，无效数据多，一般需要清洗。例如打开 App 的事件，当前的温度等。
- L2：将底层数据经过初步转换和计算后的数据，带有一点业务性。例如当日是否活跃。
- L3：将 L2 层的数据再次转换和计算，带有一定业务属性和价值。例如用户增长率。
- L4：将 L3 层的数据再次转换和计算，富有业务价值的数据。例如北极星指标。
从 L1 - L4，数据量成指数型减少，更像是一个将数据浓缩为价值的过程。这个过程也是分析过程的一种。对一个整体来说，任何一个数据都可以归到 L1 - L4 中的一种，对数据的获取和转换，都可以类比成从 L1 - L4 的转换，每一个数据指标都需要经过这个过程。
至此，也可以回答刚才的问题：业务指标和数据指标的界线是什么？这里并没有明确的界线，L1 - L4 是人根据广义上的数据层级分类。我个人认为，能够解释业务问题的数据指标就可以称之为业务指标，按照这个模型分类，从 L3 开始，就和业务强相关，具备直接解释业务问题的特点，也可以称之为业务指标了。
小结
也许你会问，自上而下、自下而上这样看似简单容易理解的分析逻辑知道了又有什么用呢？
其实我也无法定义具体在哪些场景下有什么用，毕竟实战经验很少。但我认为在实际的分析场景中，这些分析的逻辑可以让分析过程更加清晰，知道自己处在哪个层级。所谓「大道至简」，抽象出来的逻辑是简洁易懂的，也是处处适用的。
三、连接
无论是做产品还是做技术，大家都在谈连接，一会儿平台连接应用，一会儿平台连接商户等等。我仔细想了一下，按照这个规律，市面上任何一个产品、工具、商品都可以说成是在连接。那「数据」自然也是在连接。
连接的是什么
那么数据到底连接的是什么？数据反映的是事实，从而连接业务。所以数据分析的核心就是「业务数据化」和「数据业务化」。通俗一点，就是把数据和业务绑在一起，达到「共创」的目的，理论上连接的最高境界是：「你就是我我就是你」。
纵观整个互联网行业，每个领域都在谈数据，小到一行代码，大到大数据平台；从运营一侧解决运营问题，到机器学习一侧解决脑子的问题。所以作为数据本身而言，连接的业务越多，解决的问题就越多。
数据驱动 - 事实驱动
回到业务的层面，站在公司或产品的视角，聊聊最近比较火的「数据驱动」。
定义
首先是数据驱动的定义，网上看了一下，对数据驱动的定义很多，大家似乎没有达成一致。再看看百度百科的描述：
一种问题求解方法。从初始的数据或观测值出发，运用启发式规则，寻找和建立内部特征之间的关系，从而发现一些定理或定律。通常也指基于大规模统计数据的自然语言处理方法。
emmm，很抽象，说说我个人的理解吧，如果用一句通俗的话来描述数据驱动，我称之为：
使用数据直接产出结论。
数据驱动的输入是数据，输出是结论，中间是将数据转化为结论的模型。数据反映的是事实，所以数据驱动的本质是事实驱动，核心在于两点：
- 如何让数据反应的事实更准确
- 如何让已有的数据变成结论（决策）
玩法
数据驱动一般是怎么玩的呢？驱动的东西不同有不同的玩法，不过都是以「输入->模型->输出」的流程为基础演变的。这里拿驱动产品或运营举例，玩法一般是这样的：
- 提出目标
- 数据建模
- 输入数据
- 模型计算
- 输出结论
- A/B 测试验证
- 再输出结论
对比一下传统模式的玩法，以人或职责驱动的模式：
- 提出目标
- 分析目标
- 调研/讨论
- 输出报告
- 再讨论
- 输出结论
传统的以人或职责驱动的模式，主要依靠主观臆断和个人的经验决策，相比数据驱动这样的决策体系不稳定，不易复制。
后来流程驱动出现了，流程驱动的模式相比人或职责驱动的模式又更进了一步，虽然解决了可复制，不稳定的问题，但在准确性上还是略显不足。
而数据驱动的优势就很明显了：
- 结论更加客观准确
- 步骤简单，支持快速变化以满足其他场景
- 步骤可自动化
步骤支持快速变化和可自动化这两项是数据驱动的核心竞争力。当然，这些优势也伴随着对企业或产品极高的要求：
- 对数据的数量和质量要求较高
- 对企业的数字化能力要求较高
应用
那么面对数据驱动的各种特点，在实际的场景中应该怎么应用呢，毕竟不是每个产品每家公司都具备数据驱动的条件。这里我个人的观点是：「不同时期的产品，应用的方式不同」
如果产品还在孵化期或验证期，那么数据量一定很少，而且质量不高。这时数据只能作为参考因素来辅助决策，有的决策甚至没有相应数据的参考，依然只能靠传统的人来驱动。
到了增长期，产品有一定的数据基础，但依然离数据驱动的要求差得很远，这时就可以将数据作为辅助决策的一部分，人工数据分析结合现有工具来帮助决策。
到了成熟期，产品拥有一定的数据基础，可以开始逐渐尝试依靠丰富的数据基础、数据建模和机器学习的能力来驱动一些业务，形成高响应速度、高决策质量的玩法。
数据驱动是终点吗
上述的应用场景是比较理想的情况。按照这个说法，数据驱动就是企业发展的最终形态吗？
我个人的答案是「不一定」。原因有两点：
- 数据驱动无法一步到位，更像是锦上添花。达成数据驱动必须经过基于人、职能、流程驱动的业务系统，通过系统产生数据达成，当企业真正达到数据驱动的门槛时，其他驱动的方式必然也很成熟了。
- 不是每一个场景都需要高响应速度、高决策质量，需要考虑投入产出。数据驱动的成本和代价是偏高的，相比之下，传统企业或小作坊的玩法不一定不好，适合当下是最重要的。