如何突破数据分析

哈喽大家好，我是可乐

看到一篇数据分析好文，分享给大家，主要讲数据分析方法论、经验总结以及个人成长。

我是一个数据从业者，很早以前就想把自己在工作和学习中的心得做个总结。一方面是对自己过往经历的一个总结和回顾；一方面最近几年大数据是越来越火了，也希望自己的经验能帮到那些对数据有热情、希望从事数据行业的新人们；还有一方面，也非常重要，是希望借助知乎这个平台跟广大同行们做一个交流，互相帮助，共同成长。

在开写之前，先做下自我介绍。我在企业里从事数据相关的工作已经有11年了，在这些年里，我做过咨询顾问、数据分析师、售前工程师、开发工程师、数据分析经理直至总监。在管理岗上，我带过数据分析、数据挖掘、数据产品、数据仓库等各种团队，其中带数据分析团队时间是最长的。先后就职于国企、传统制造业和互联网企业。总的来说，比较杂。现在想来其实有得有失。缺失的是，在任何一个细分领域上都没有做得特别深入，不算是一个合格的专家；得到更多的是，我对整个数据的产生、处理、分析直至为企业提供价值的过程都有过体会和思考，从而也使我能够站在一个更高的角度上看问题。到底是成为一个专才好还是通才好，我觉得这没有一个确定的答案。个人觉得T型人才是比较受欢迎的，也就是自己的技能和业务面同时要有宽度和深度。当然，到底多宽或多深才合适，取决于个人的职业发展意向。基于我的经验，我分享的更多是对这个行业的理解、做事情的思想和方法论，而不会侧重于具体的实现技术。想学技术的同学请绕行。

后面我预计要分享的内容包括数据分析、产品、仓库、数据团队建设等等。个人经验最多的是数据分析，就从这里开始吧。可能包括以下话题：

• 什么是数据分析？
• 数据分析有哪些分类？
• 如何设定分析目标？
• 怎样才算是一个合格的数据分析师？
• 什么样的企业需要数据分析师？
• 怎样建立一个数据分析师团队？
• 数据分析师团队的价值是什么？如何实现？
• 数据分析师团队的岗位设置及分工合作
• 一篇好的分析报告有什么样的标准？
• 数据分析三元论（势、道、术）

什么是数据分析

一句话定义，数据分析是一个从数据中通过分析手段发现业务价值的过程。这个过程的起点是获取一份数据，这个过程的终点是发现业务价值。过程可以大致为分数据获取——数据清洗——数据处理——数据建模——分析结果呈现——业务价值发现——业务价值实现这几个阶段。

在具体说明每个阶段之前，首先要谈下我对数据和业务价值这两个概念的理解。

• 数据：我认为数据不是简单的数字，换句话说，如果你只告诉我一串数字 170、172、180而没有其他信息，那么这几个数字就仅仅是数字而已，而不是数据。数据除了数字本身之外，还必须包含数字的来源、度量方式、单位、代表的业务场景（即数据产生的上下文环境）等等。其中，我认为场景是最重要的。仍旧拿上面的例子来说，如果你告诉这是三个地区的平均身高，那可以说这是一组有意义的数据了，至于单位，我会猜到是厘米；而来源和度量方式决定了这个数据的可信程度。
• 业务价值：不能服务于业务的数据分析是没有生命力的，不能产生业务价值的数据分析是徒劳无功的。因此，能否实现业务价值决定了这是否是一次成功的数据分析。而分析工作只是实现了这个过程的第一步，它通过分析师的视角将价值呈现于业务人员面前，分析的结果只有被业务人员理解，并最终通过业务人员的努力转化为业务实施（在大多数公司数据分析和业务运营这两种不同的角色会分属不同的部门，增长黑客则是一种新的形式），才可能最终实现价值。

过程的详细说明：

• 数据获取：这个阶段的输入需要一个分析目标，哪怕不是那么的明确和清晰。为什么需要一个目标？在一个大型企业中，可以获取的数据往往是海量，如果没有一个目标限制，那数据分析往往是无从着手的。这个阶段的输出是一个数据子集，它可以是物理上的货逻辑上的。所谓物理上的，就是把分析中用到的数据单独拷贝到一个地方；而逻辑上就只是定义出可用的数据范围，比如时间周期、维度、指标等。这个阶段的困难之处在于理解相关的数据源，因为数据源文档不完整或者变更的情况经常在业务中发生。数据清洗：通常包括异常数据的处理、缺失数据的处理、数据的一致性变换、编码的替换等
• 数据处理：对数据进行汇总，或者形式上的变换，以便可以适用于后期的建模
• 数据建模：用统计分析或机器学习算法对数据建模，以便描述数据或对未来进行预测。其实大多数分析师在这个阶段只观测数据的同比、环比的趋势上的变化，亦或对指标在不同维度上进行拆分，以观察维度对指标变化的影响。以上三个阶段在很多书籍中都有具体的技术描述，不再赘述。
• 分析结果呈现：通常认为，这个阶段的主要任务是把建模的结果以图、表或者更加复杂的可视化方式呈现出来。但我认为不止于此。首先，呈现结果不是这个阶段的目的，目的应该是让业务人员对分析结果有充分的理解。其次，呈现的手段除了可视化，最重要的应该是沟通。而沟通是双向的，可以保证结果最大程度上被他人理解。业务价值发现：通常数据分析师会在分析结果中提出对业务的价值，但是这个价值只有被业务人员认可才有可能实现。所以，此处的“发现”应该是分析师和业务人员的“共同认知”。
• 业务价值实现：业务价值发现和实现经常不被包含在数据分析过程中。但是，就如同我对数据分析的定义，业务价值才是数据分析的终极目的。因此，我认为价值的实现才是整个过程的最后一个阶段，这个阶段虽然是有业务人员控制的，但是仍然需要分析师的深度参与。因为双方对于分析结果的理解和价值的发现经常出现偏差，需要在实践中逐步达到统一。最后，关于数据分析过程，我认为有几点需要给予非常的重视：

在开始做分析之前，首先要有分析目标！分析目标！分析目标！重要的事情说三遍。

• 过程不是单向的，在后一个阶段中发现问题时可以跳回到前一阶段
• 过程不是一次性，而是不断循环往复的。上一次分析过程的终点，可能是下一次分析过程的起点。我们经常会在业务价值发现和实现阶段发现新的分析主题，并把它作为下一次分析的起点。
• 对于任何一次分析来讲，不是每个阶段都是必需的
• 整个过程中的大多数时间都需要分析师和业务人员的密切合作

数据分析有哪些分类

面对的问题不同：战略、运营

战略分析：是为了解决公司战略方向问题，回答要向哪里去的问题。

• 此类分析通常比较宏观，需要分析者有大局观、有战略思维；
• 所用的数据除了公司内部的数据，还需要竞品数据、行业数据。
• 战略分析的方法：需要从竞品及行业数据中发现行业发展趋势及竞品的战略定位，同时结合公司内部数据，可以发现相对于行业和竞品发展，内部在哪些地方存在不足，以此制定进攻和防守策略

运营分析：不同于战略分析，运营分析以解决实际运营问题为目标，比较微观。

• 需要分析者对公司业务模式、运营细节有深入的了解；
• 使用的数据以公司内部数据为主。
• 此类分析最重要的是，分析结果要能够与运营结合，并能有效落地

服务的部门不同：业务、数据

• 业务分析：此类分析由业务部门发起，提交给分析师执行，最终结果交付给业务部门。此类分析一般在最终的价值发现环节效率较高，问题的针对性较强。
• 数据分析：此类分析由数据部门发起，最终结果视具体情况可能提高给业务部门或者管理层。由于此类分析的视角不同于业务分析，在最终的价值发现和实现环节需要与业务部门的深入沟通。同时，也正是由于视角不同，会经常发现业务部门没有发现或者忽视的问题。

分析的范围不同：行业、公司、部门、业务环节

• 行业分析：目的是总结和预测整个行业的过去和未来的发展趋势，时间窗口一般在1年以上。使用场景较多的是在投资公司中或者很多公司的市场宣传稿中会出现。行业分析的对象是商业模式或者业务形态，关注的是资金、市场格局、用户需求的变化和各企业的应对。最有价值和最难的是要提前预测行业的增长爆发点和衰退的转折点。
• 公司分析：目的是结合行业分析对公司业务发展做出诊断，给公司发展提供决策建议。时间窗口一般在一年以内，在公司战略决策会发挥较大的作用。SWOT等方法适合在公司分析中使用。分析者首先要认清企业的商业模式，要与公司的管理者同步公司的短期和长期目标，了解企业的盈利来源和运作方式，通过公司内外部数据的对比发现运营中的问题和商机。在这个过程中，了解市场和竞品的动态是非常重要的。
• 部门分析：目的是对部门职能范围内的业务发展做出正确的诊断并给出适当的建议。前提是能充分理解部门在整个公司中的角色和地位、该部门与其他部门的协作关系、在工作流程中的上下游关系。基于以上理解，以配合公司业务发展为目的，以提升部门KPI或某个关键任务为分析目标，利用公司和部门运营数据去做分析。此类分析中，理解公司业务、有产品和业务思维很重要，指标的分解、对比，数据变化的归因往往是常用的分析方法。
• 业务环节分析：这是数据分析在业务最细粒度的应用。分析者只需要关注非常具体的某个业务环节，让大家感兴趣的是这个业务环节数据的变化原因和改善方式。此时分析的指标经常是确定的，目标也很直接。但所谓牵一发动全身，这个环节的变化通常是由其他环节的变化引起的。所以万万不能走入一叶障目不见泰山的误区。

项目的阶段不同：咨询、实施

• 咨询分析：以前有过跟咨询公司合作的经历。在项目开始阶段，乙方通常需要花很多时间讨论项目立项的必要性、收益等，以此来说服甲方老板，你懂的。但是，我要说的是，即使是公司自行研发的项目，在立项阶段，数据分析需要做的是树立目标。通过数据分析，可以对业务有一个全面的诊断，发现问题，提出项目需要改善的主要指标，并预测出项目上线后的收益。立项是需要管理层批准的，因此这个阶段的分析需要简明扼要、一针见血，分析结果的呈现起着至关重要的作用。
• 实施分析：项目开始后，数据分析需要做的是过程控制。除了项目目标涉及的主要指标需要持续关注之外，还需要关注过程类指标。所谓过程类指标，是指能够反映出项目执行内容的数据。因为主要指标的表现通常是滞后的，而且是若干因素影响的结果，过程指标是为了明确各影响因素的作用效果。比如项目目标是提升使用时长，项目内容可能包括提升新用户和老用户的使用时长，那么则应该把新老用户的时长作为指标单独监控和分析。

综上，根据数据分析的使用场景、业务阶段、服务人群、范围及层次不同，可以分为很多种。以上只是列举出一部分。在每种场景下，数据分析的目标、关注的重点和难点都有所不同，分析师要在分析过程中时刻关注自己有没有偏离目标，并对重点和难点有充分的准备。

如何设定分析目标

从我的经历看，数据分析的目标主要来自两方：一方是业务，一方是数据部门自身。

对于一个具体的数据分析项目来说，可能以上两方的因素都会存在，只是占比多少而已。以下详细说明这两种方式的场景、前提及“坑”。

• 分析目标主要来自业务方：这种场景通常存在于业务方对业务发展有疑问，希望通过数据分析提升业务。业务设定的目标要么是对过去的业务发展做总结和诊断，希望从中发现问题；要么是基于业务的历史预测未来的发展趋势。这里经常存在的问题是，业务方提出目标往往是模糊不清的，并且通常用业务术语而非数据口径来定义。因此，这种情况下，分析师要花较多的精力做需求分析。而要做好需求分析，分析师需要具备一定的产品和业务思维，要从业务视角出发，充分理解业务的处境，才能从最根本上理解业务的需求。同时，需要对数据产生的流程和指标计算的口径对业务人员进行充分的说明。如此不断地迭代沟通，往往分析到最后，却发现已经不是原来的需求了。还有一种情况，业务对数据了解较多，会在需求中说明需要的数据口径，这种需求会被单纯地看做一个数据提取需求。即使是这样，如果希望让这部分数据更有价值，分析师也需要就其业务背景有深入的讨论，然后可以修正该需求。

• 分析目标主要来自数据部门自身：这种场景下，数据部门在组织上是独立于业务部门的。但是独立不意味着可以不考虑数据分析对业务的价值（参见第一章）。如果说实现业务价值是分析的根本原因，那么重要数据指标的变化则是数据分析的直接原因。也就是说，如果数据部门要能够独立提出分析目标，首先要有相对完善的指标监控体系。而指标体系可以分层，并且建立起各指标之间的关联关系。因此，数据部门提出分析目标可以更全面、更客观，而不局限于一隅。但是，这个分析目标的设定对数据部门要求更高：不仅要具备完善的指标监控体系，更要了解业务。经常出现的情况是，数据部门自己费了挺大的劲做出的分析报告，业务部门却无动于衷，其中没有涉及到业务痛点可能是一个重要原因。

总结一下，分析目标的设定是数据分析最初也是最重要的一步。一个合理的分析目标应该具备以下特征：

• 要有业务视角，能折射出业务痛点
• 要有数据支持
• 要量化：“为什么产量下降了”和“为什么产量从1万下降到5千”，显然后者的目标更清晰
• 要能体现在某个或某几个指标上：还是上面的例子，产量只是一个概念而非指标，一个可能的产量指标是：全厂2018年第一季度中产品型号X的生产数量。总之，要做到明确而没有歧义。

怎样才算是一个合格的数据分析师

可以从分析师的工作目标、工作内容和能力要求三个方面回答这个问题。其中工作目标和工作内容是息息相关的。要说清楚这个问题，我认为除了一些公认的标准之外，还有一些标准是因公司和行业而异的。也就是说，必须把它放在一个具体的公司业务框架之中考虑。

工作目标主要由公司的业务发展阶段决定

一般来说，无论是哪个公司，都希望分析师能有效地利用数据引导和驱动业务发展，实现数据的价值。但是，公司发展的情况不同，对数据分析师的价值定义也会不同。

• 公司整体处于初创阶段，此时分析师的价值在于能通过对行业和竞争对手的分析，为公司的发展方向提出适当的建议；
• 公司如果处于快速发展期，此时分析师的价值在于一方面监控业务取得的成绩，关注增长速度，一方面要健全指标体系，发现被业绩增长所可能掩盖的问题；
• 如果公司处于稳定期，分析师则需要从效率和成本角度，从业务细节入手，为精细化运营提供支持；
• 如果公司发展遇到瓶颈，分析师需要分析市场中供给和需求的变化，关注竞争对手的应对策略，为公司业务发展发现新的增长点。

工作内容主要由公司的数据建设程度决定

参照第一章，分析师的主要工作内容数据获取、数据处理、数据清洗、数据建模、分析结果呈现、数据价值发现及实现。无论分析的目标是什么，大体总要经过这几个阶段。由于数据建设的阶段不同，分析师在这几项工作内容上所花费的时间也不同。在公司数据建设早期，分析师可能在数据获取、数据处理和清洗、指标建设上花费更多的时间；数据建设到达一定阶段之后，分析师的工作更多会在数据建模、呈现和数据价值实现上。

分析师的能力要求

对分析师的能力要求可分为通用能力和技术两部分，同时也可以分为业务和数据两部分。

1. 业务能力：业务要求又可以分为微观和宏观两方面：

• 业务的微观要求：了解业务运营；了解公司发展方向和发展过程中面临的问题
• 业务的宏观要求：把握行业的发展方向，预测未来行业模式的变化；能明确指出公司在行业中的定位和战略方向

2. 数据通用能力：

• 熟悉公司的所有基础数据、来源、数据之间的关系；
• 熟悉公司运营所涉及数据、能建立运营指标和数据之间的相关或因果关系；
• 能根据数据分析结果给出业务改进建议
• 数据价值实现能力。价值实现的过程是指数据分析结果->业务->业务执行->反馈结果->数据分析这样一个不断迭代的过程。在此过程中，演讲（Presentation）能力、沟通能力、影响力、团队协作能力、学习能力、逻辑思维能力、归纳和总结能力、抽象思维能力等都非常重要

3. 数据技术：

• 数据库和数据仓库技术（SQL、Hive等）
• 数据分析算法（统计分析和机器学习）和工具（Excel、Python、R等）
• 数据可视化工具的使用（Excel、R、PPT等）

好的分析师在实际的业务操作中至少会做好三点：

• 大局观：大处着眼，小处着手，全局和细节并重。因为从数据角度看，小数据往往可以反映出大问题。而没有大局观，就不知道该看哪些小数据
• 思维：数据思维与业务思维并重。业务思维容易理解，什么是数据思维？比如：对指标由粗到细的拆解、考虑时间维度上的趋势、注意寻求指标之间的相关关系、直接影响关系、因果关系等。很多人都注重分析师要懂业务，有业务思维，这当然没错，但不能走向极端。因为在实际中，业务是需要不一样的思维的，可以发现他们发现不了的问题，从而为他们在困境中提供解决方案。分析师需要了解业务的思维方式，但不能模仿他们。
• 沟通：要想让分析师的观点被业务方所接受，沟通的作用是举足轻重的。首先，分析师要为沟通找到合适的对象和时机。事先要根据沟通对象的不同设计适合的表达方式、内容和过程。沟通的时机要选在业务最需要的时候。很多时候，事后诸葛亮固然不好，但太超前了也不会有好结果。其次，要有同理心。需要真正站在对方的角度上想问题。再次，需要在沟通中建立互信、发挥影响力。一个好的分析师，能在沟通中恰到好处地展现自己的专业能力和经验，适时的让业务方对人产生信任，从而对分析结果信服。

什么企业需要数据分析师

企业需要数据并不等于需要数据分析师。

如果仅是想看数据，其实有很多企业可以提供这样的服务和工具。比如流量统计工具GA，比如报表工具Tableau。这些工具都可以在不需要分析师的情况下，对业务人员做简单的培训就可以用起来。

分析师承担的是相对复杂的、个性化的、以分析为目的（而不是查询）的任务。

如果企业有如下情况之一，那么可能是需要建立一支分析师队伍了。

• 决策需要数据支持：决策层通常不是只看到数据就可以做出决策的，他们需要知道的是数据变化的原因、预测某个决策可能造成哪些指标及如何变化的结果，这是一个相对复杂的分析任务，不是工具或者非专业人士可以回答。
• 业务规模大、复杂度高：在此情况下，即使只是构造单个指标，也需要经过严密的口径定义、复杂的计算才能得到，且需要经过校验才能保证数据是准确无误的，这样的工作通常由分析师完成。
• 业务发展变化快：在业务稳定的情况下，数据的计算及业务含义不需要经常变化。反之，数据的定义、计算和业务理解则需要不断地适应业务的发展，需要分析师不断地维护这些数据。
• 精细化运营：业务在经历开始阶段的快速增长，达到稳定阶段之后。运营风格会由粗放型转换为精细化。此时，需要对业务指标进行拆分，并分析相关性及数据之间的因果关系。
• 数据统计口径混乱、可信度低：有的企业存在数据孤岛的情况，每个部门掌控着一部分数据，会造成同一个指标，由不同部门出结果不同。此时需要重新梳理指标口径定义、数据采集、计算，找出数据之间的差异。当然，最后要彻底解决问题，则需要解决数据孤岛的问题
• 数据建设的初始阶段：这时候需要分析师梳理业务流程、确认需求、建立指标体系、定义计算口径、整合数据源等
• 业务需求不清晰：业务有需求，但很模糊：比如，我想知道最近某某业务的运营效果如何？但是该看哪些指标则不清楚。此时需要分析师深入了解业务需求的背景和目的，将业务需求指标化。

怎样建立一支分析师团队

从企业层面看，如果要建立分析师团队，要弄清楚几个问题：

1. 建立分析师的目的是什么？
2. 分析师属支持角色，那么他们支持的对象是谁？
3. 分析师的主要工作内容什么？
4. 分析师的规模多大较为合适？
5. 如何评估分析师的绩效？

弄清楚这五个问题之后，就会知道应该招聘具备什么经验的人，招聘多少人，以及对水平的要求有多高，如何考核他们等等。

那么如何思考这五个问题？

1. 建立分析师团队的目的：虽然成立分析师团队的决定通常是由高层做出的，但是主要目的不一定只是为了做决策支持，也许是自底向上产生的需求推动。有很多情况下，管理层觉得他们需要看数据，因此招聘了有决策支持经验、具备宏观思维的分析师，但实际上又安排了分析师去支持具体业务；或者反过来，管理层希望分析师能支持具体的业务，但是他们又安排分析师评价整个公司的运营情况，甚至提出战略方向。这两种情况都会造成人才的浪费。要知道业务分析和决策支持对分析师的要求是不同的。至少，前者需要分析师能关注到细节，而后者要求分析师不拘小节，视野要足够高。
2. 分析师支持的对象：如果目的明确了，通常支持的对象就清晰了。
3. 分析师的主要工作内容：这同样主要取决于团队定位，具体的工作内容可参照《数据分析有哪些分类》
4. 分析师团队的规模：规模取决于多种因素，比如工作内容的复杂程度、业务需求的多少和缓急、能招聘到的人员的技能水平等。
5. 分析师的绩效评估：最直接的评估方法是看分析师产出的数量和质量。如果只看产出的数量是比较容易的，比如可以看完成需求的多少、分析报告的数量等。但由于分析负责的业务线不同，这会忽略工作的难度。需要注意的是，分析师很多工作的投入和产出是不成比例的。比如沟通、业务梳理等基础性的工作占据他们大部分的时间，而这些工作可能只有很少的可见交付物的输出。除了产出量，还需要看产出的质量。最理想的质量评估就是看对业务的贡献，即提升了多少业务价值。但这同样是比较困难的，因为有时候业务价值也很难量化。除了对外的产出，还有一个维度是看对数据团队内部的支持，因为分析师通常是作为联系数据团队和业务团队的桥梁存在。比如，对数据指标体系的建设和数据仓库、数据产品的建设中做出的贡献。但是同样，这些贡献也很难量化。

如何实现数据分析的价值

在之前的章节中已经提到分析的价值在于业务价值，而业务价值实现的最后一步是把分析结论应用于业务中，并反复迭代。

我想从一个例子来说明分析师在整个价值实现链条中的位置和作用。假设我们在考虑如何实现一件工具的价值，这件工具可以是一把钳子，或者更复杂点，比如一部电脑。在这个例子中：

• 数据分析是工具
• 分析师是工具的制造者
• 业务方是工具的使用者
• 工具价值的实现不仅与工具的制造质量及精巧程度有关，还与使用者有关：有人使用电脑设计航天器，有人只是用它玩游戏。

也就是说，数据分析的价值除了分析师这个因素之外，还受到其他因素的影响。比如：

• 数据分析结果的交付质量、可视化及可理解性（类比：工具本身的质量、设计及易用性）
• 数据分析结果使用者的素质（类比：工具使用者的素质，对工具的了解程度，工具使用的相关知识背景）
• 数据分析结果使用的场景（类比：工具使用的场景是否符合工具设计者的初衷） 环境因素，比如不可抗力、趋势（类比：台式机的价值在移动化办公的趋势下会变小）

呃。。。是不是漏了点什么？分析师哪里去了？其实分析师的作用正在于对上述因素形成过程中的影响：

• 提高数据的质量、展示水平，让数据结果变得更容易理解
• 教育和培训数据使用者，往往会达到事倍功半的效果
• 从根本上理解数据需求，打破砂锅问到底
• 最后，对于不可抗拒的因素，分析师能做的就是。。。调整心态。反抗不了的话，就学会接受吧。

数据分析师团队的分工与合作

个人感觉分析师团队很不好带，数据分析师团队最大的三个痛点是：

1. 散：在公司级别的团队中表现尤其显著。由于支持的业务多，而各业务的发展目标不同，导致无法设立一个统一的业务目标，只能按人去设定目标，管理效率很低。

2. 乱：正是由于业务目标散乱，造成分析师之间的工作无法统一和协同。很多时候都是各自为战，没有配合，甚至出现目标冲突的情况。

3. 弱：不能影响业务，不能建立话语权。这个在上文中已经说过，此处不再赘述。

这里面的关键是解决“散”的问题。很显然，如果把眼光放在部门级的业务上，是无法解决这个问题的。因此，需要把视野扩展到全公司。基于公司统一的发展目标，建立一个统一的分析框架。正如数据分析是服务业务的，分析框架也要基于业务模型来建立。业务模型的标准是：

• 业务模型要高度抽象化，它是从业务模式中抽取出来的，而不是反应部门职能。
• 业务模型要能反应实际业务的运营规律、要素和目标。甚至，这个业务模型可以放之行业而皆准。

有了业务模型，现在需要建立分析模型。我的经验是对着业务模型提问题。首先是公司级的：公司的发展目标是什么？需要哪些要素来完成这个目标？各要素之间如何互相促进？然后将上述问题分解到部门级。最后可以将问题归类，可以分为：目标分析、运营分析、要素分析等。这些分类好的问题就是分析师分工的基础。

传统的分工方式是分析师按支持业务部门分工，或者按支持的业务模块分工。

这种分工方式的结果是：

第一、分析师对业务的了解如同盲人摸象，每个人都只能了解到部分业务，不能也不会从整体考虑业务问题，对问题的定位缺乏深度；

第二、分析师的工作是割裂的，自己的分析结果不容易被其他分析师采用。

以电商平台模式举例，运用上面的方法：

1. 建立业务分析模型：用户、商品两个主要要素。链接这两个要素的是用户购物体验。用户自身会有用户生命周期，商品自身会有商品生命周期。还可以进一步细化：用户购物体验包括查找商品信息、下单、配送、付费、售后等体验。商品生命周期可以包括采购、仓储、上下架等。商品要素包括定价、分类、功能、用户评价等。

2. 提问：公司的发展目标？假设公司的发展目标就是追求销售利润最大化（实际上很多电商平台不是通过这个模式来盈利的）。要素？利润的大部分通常是由高净值人群和高毛利商品贡献的。要不断发展壮大高净值人群和提升高毛利商品的销量。各要素之间如何促进？高净值人群不会只买高毛利商品，平台也不可能只卖高毛利商品。链接这两者的是用户体验。分析师可以根据分析主题分成两个大组：一组的分析任务包括识别高净值人群、分析高净值人群的购物体验、分析高净值人群的生命周期；二组的分析任务包括识别高毛利商品、分析用户对高毛利商品的购物体验、分析高毛利商品的生命周期。当然，还可以把购物体验单独作为一组或者在上述基础上进一步细分。比如高净值人群分为A、B、C等几个不同特征的人群，如果其特征差异很显著，可以基于人群分组做进一步划分。

这样分工的好处是：

第一、分析师是基于分析模型的分组，组内目标一致，组内分析结果是可以共享和互相借鉴的；

第二、组内大目标的设定可以较为宏观，促使分析师从整体考虑问题

第三、组内对大目标的分解最终会落实到具体业务上，不会太虚

第四、不同分组间的分析师虽然目标不同，但是使用的数据维度基本一样，很多的基础性工作是可以共建的，且分析结果也可以互相借鉴。

一篇好的分析报告有什么样的标准

写分析报告应该是每个分析师的必做功课之一，不管是简单的或者复杂的，正式的或者非正式的。

什么是分析报告？我定义为有特定的主题、分析过程和结论的都可以算作分析报告，而不拘泥于表现形式。

那么怎么才算是一篇好的分析报告？相信每一个分析师都会有自己的标准。比如：对业务有意义、数据准确、逻辑严密等。这些都没有错，但是报告是给人看的，而每个人的背景和需求不同，那么从报告读者的角度出发去衡量报告的好坏会更加客观。

既然要从读者出发，那么首先就要对读者分类。从我的经验出发，我们可以把报告的读者按职级不同简单分为决策层、执行层；按对业务的了解程度不同分为了解和不了解两类。那么读者可以细分为四类：

我将从选题、数据选择、分析过程、结论、报告结构、可视化这几个方面去说明对不同类别的读者，一篇好的分析报告的标准是什么。

• 对于A类读者：由于他们对业务了解，视野又有一定的高度，所以选题应该以相对宏观且能反应业务痛点的主题。比如对公司或一级部门KPI目标完成度的剖析、相对于竞品主要业务指标的表现分析。数据应该选择较大的、粒度较粗的指标数据，不能用那种多个维度交叉且口径定义很复杂的指标。分析过程应简单明了，逻辑推理尽可能把数据变化和业务解读结合起来，同时一定需要关注时间维度上的变化。结论应清晰明了，包括对业务方向性的诊断和预判。在发布报告时，结论前置较为合适，对业务背景的描述不需要太多。可视化方面，以趋势性的图表为主。

• 对于B类读者：一般是经理及以下的运营人员。选题方面应侧重具体的运营问题，范围限定在二级或三级部门的职责范围内。选择某个业务线环节及上下游的微观数据，分析过程中要将统计方法或机器学习方法与业务规则结合，发现各指标之间的因果关系。报告结构的重心在于分析过程和结论，可视化方面要注重细节数据的呈现。

• 对于C类读者：选题偏重业务诊断和监控，选择宏观的、KPI或目标相关的重点指标，可以包含行业的、竞争对手的相关数据。分析方法以对比和预测为主。结论以对业务方向的定性总结为好。报告结构应在业务背景介绍、选题的依据、结论建议等多花些笔墨，过程可以简略。报告呈现以精简为好。

• 对于D类读者：通常是新人或者新业务。选题偏重业务发展细节中的痛点或瓶颈。数据选择微观的但较为简单的指标，分析过程中着重在于指标的历史趋势、相关指标之间的对比和变化，结论侧重于发现和定义业务问题。报告结构侧重于业务背景的描述、数据选择和指标定义。可视化需要在业务逻辑的展示上多花些功夫。

总结下，我认为报告选题、数据选择、分析过程、结论、报告结构、可视化是影响一篇报告质量的主要因素。但是分析报告如同一件艺术品，没有放之四海而皆准的标准，只有是否迎合和满足的受众的需求。因此，分析师必须清楚谁会看你的报告、你的读者希望从你的报告中得到什么、读者的背景（包括业务和数据方面的知识）是怎样的、读者对你和数据的信任度如何。如果分析师要写出一篇好的分析报告，需要了解的不只是数据和业务。

数据分析三元论：势、道、术

势

有个成语叫“大势所趋”，顺应趋势、迎合潮流的事情做起来总是事半功倍的。

在做数据分析之前，我们要问一问：在这个时代、行业、公司做数据分析是大势所趋吗？

要回答这个问题，首先要搞清楚哪些因素构成了数据分析的“势”。我列举如下几个：

• 行业：我以为只有那些能够产生大量数据、且市场需求和业务模式变化较快、竞争较为充分的行业更适合做数据分析。大量数据是基础和原材料；市场需求和竞争压力是内在的驱动力。比如To C的电商行业，数据量已经到了一定量级，而人的需求往往是变化较快的，且这个行业没有形成事实上的垄断。虽然阿里、京东的电商平台已经占据了很大的市场份额，但是他们之间仍然存在竞争，而且像严选、考拉、网红电商等垂直电商也还有生存空间。再比如电信和金融行业，也能满足以上几个条件。但是有些行业，看起来业务规模大，但实际上不适合去做数据分析。比如家装、餐饮，这两个行业虽然古老，但除了某些巨头之外，信息化做的相对较差，数据采集都是问题，更谈不上做数据分析了。再比如能源行业，也能够产生大量的数据，但是因为市场需求相对稳定，且基本形成了国家垄断，没有做数据分析的内在需求。
• 公司的数据环境：数据环境包括信息化水平、数据文化、老板对数据的重视程度等。这几个因素是很好理解的。信息化水平决定了数据的量和质量，消除数据不一致、清洗脏数据要花多少时间和精力，做过的人都知道。。。数据文化包括数据相关的流程、规章、制度，公司内部对数据认知和利用的程度等。最后，我向来认为数据是一把手工程，由于数据从采集到价值产出，都是涉及多个部门的利益，没有老板的支持，做好数据是天方夜谭。

道

所谓“道”，主要指分析体系和框架、目的和价值。

而这些主要受公司的业务模式和业务需求的影响。说白了，业务模式越简单、越清晰，数据分析越容易出成果。因为简单的业务模式能显著减少数据分析师学习业务的成本。分析体系和框架也会简单明了，在分析时需要考虑的影响因素就越少。而价值链短业务模式更容易让分析主题直接与业务收益挂钩，更容易让数据分析成果变现。而分析需求越稳定，就可以给分析师更多的时间深入研究下去，不断迭代，最终产出更大的价值。分析需求越清晰，花在需求讨论中的时间就越少，最终分析成果被转化的可能性就越大。

术

所谓“术”，是指数据分析的方法和过程，其中分析思维和分析技术对分析结果的影响。

正如我在开篇所述，数据分析所涉及技术体系非常庞大，而且学习资料也很多，不在本专栏范围之内。我重点想说说我经验中的一些分析技巧（包括思维和方法）：

• 分析主题的定性与定量：设计分析主题中的重要一步，是要确定分析的目的是定性或是定量。如果是定性，通常只要考虑有关或无关，正面影响或负面影响。定量分析是很受业务方欢迎的，分析也更加复杂和困难，通常要通过机器学习模型解决。

• 发现分析主题的两个切入点：指标监控与业务问题。在《如何设定分析目标》一节讲过，数据部门更适合从指标监控中发现问题，业务部门更适合从业务中发现问题。但对于一个成熟的数据部门，把指标监控和业务监控深度结合，对于发现分析主题更有利。

• 数学建模：我对数学建模技术了解并不深。但是如果能把业务问题转化为一个数学模型，对于确定分析思路会很有帮助。

• 指标创新：指标其实是数据分析师分析业务问题的武器。因为无论你用什么分析方法，总要用到一些数据，而这些数据的计算方法、范围会很大程度上影响分析结果。且不说任何一个建模过程中的特征选择都非常重要，即使只是对业务的简单监控，一个好的指标往往能准确无误地反映出问题。对于互联网，PV、UV、时长、留存、点击率、退出率这些是大家很常用的。用来监控整体业务是没有问题的，但是对于某个小的业务板块就不太够了。比如，作为内容平台，我想衡量一次曝光的用户体验如何，应该用什么指标？有人会建议用点击率，但是点击率会受到标题党的影响，此时高的点击率并不代表好的用户体验。比较好的选择是把点击率、阅读时长、阅读进度等合成一个指标。

• 整体与个体：大处着眼，小处着手。无论是数据还是业务，都不是孤立存在的，系统性思维对于分析师非常重要。所以在看到一个小问题的时候，要知道它绝对不会影响这一小块业务；而看到大的目标出现问题的时候，要能意识到可能是一些小的业务环节出了岔子。在动手层面，对于数据分析来说，微观分析更容易获取实验数据，也更容易找到因果关系。所以要不断地对问题分解和细化。

• 分析维度的引入：在低维空间上解决不了，在高维空间上就不是个事（想到三体了吗）。比如SVM，低维空间上无法做到线性可分的数据样本，在高维空间上就可以。所以如果你在某个分析问题中费了牛劲也找不到答案，也许正是因为你忽略了某个重要的因素。当然也不是维度越多越好，因为维度越多，解释起来就越困难，不要忘了，结果是给人看的。

• 大胆假设，小心求证：试想求解一个方程式，我把某个解代入方程验证是否正确，要比我从空间中求解容易得多。同理，由于在现实世界中可能影响业务的因素太多，选择其中最有可能的因素去验证无疑是一条捷径。这个假设怎么去做？首先要对业务有足够的敏感度。是的，业务老鸟就是比新手能更快地“嗅”出问题的根源；其次要对数据有足够的敏感度，数据之间都是有关系的，某个相关的指标变化也许就能告诉我们答案。究竟这个假设是不是问题的答案，最终取决于数据验证。“小心”的意思是，一定要保证在验证过程中不受其他因素的干扰，AB测试无疑是个很好的方法。还有，在求证过程中要保持逻辑的严密。