本文内容基于自己从事支付领域从0到1搭建支付业务数据分析实战经验。如果你对写代码念念不忘，可以看我的历史文章，有很多代码相关的内容。
从一个小白接触支付业务，毫无章法胡乱看数据，到开始有点门道看表层数据，再到此篇文章输出的成体系的数据分析系列篇章，前后经历了2年多时间。
此篇文章内容皆为当前阶段认知，后续肯定会持续做迭代更新。
01
为什么需要数据分析
数据分析的重要性不言而喻，没有数据，就是感性呀。
你说你做完这个功能可以获得什么价值回报，没有数据支撑，太过苍白无力，没人信服你。但是只要你说，你做完这个项目，可以提升订单转化率多少个点，并且信誓旦旦讲，那没有人不会不理你。毕竟，这是赤裸裸的钱，谁不爱钱呢。
数据不会被观点打败，数据只能被数据打败。人家拿数据得出的结论，跟你的直觉再对不上，你心里再不服气，想反驳，也必须拿数据说话。
我们现在妥妥地已经进入了数据时代。
互联网公司，无一例外地强调自己的数据驱动决策；传统企业，现在最重要的战略就是数字化转型。
相信今天你能感觉得到，数据在我们的工作和生活中，已经成了空气和水一样的存在。
数据思维或者数据分析能力已经成为这个时代的必须，不是可选。
那么数据分析为何如此重要呢，我从以下4点来阐述。这些场景也是日常发生在我实际工作中的，我们用数据每天来做各种分析、洞察或者决策。
1. 量化IT投资成效，以数据驱动决策
无论哪家公司开发资源永远不够，每个产品经理都想争取开发资源做自己的项目，说自己项目更有价值。如何评估优先级，数据来说话。
站在公司或者决策者角度，数据最本质的作用，是作为资源调配的裁判，帮我们用最客观的方式将资源投到最有价值的事情上。
目前我所在公司运转方式为：年初制定年度KPI，如转化率或者用户满意度，那么接下来一年内所有产品经理运行的项目将按照这个指标来。
产品经理A和产品经理B同时启动了自己的项目，那么IT资源投到谁的项目上，A和B需要去做项目 ROI 的论述。谁的ROI更高，业务总负责人就同意将资源调配到哪个项目上，这样A和B都没什么话说，IT资源也将被用在刀刃上，减少资源浪费。
产品经理在论述项目价值时，采用自下而上的论证方式。比如说这个项目要完成哪些功能，功能1、功能2、功能3……每个功能带可以带来多大的价值，如转化率可以提升多少，这些都来自数据。
有时候我们以为的很大项目价值经这种层层灵魂拷问，最后验证预估价值不大，在早期就能减少资源浪费，而不是真的要等到功能上线才发现对业务价值帮助不大，那时候开发资源已被浪费。
如果你一直抱着项目上线后看真实数据反馈，除非你家开金矿的，可以容忍不断做尝试创新类实验。运气好成功了，大家都开心；运气不好，大家失败了，不怕，反正家里开金矿，大不了重头再来。但是，我想这应该是个伪命题。
今日头条系产品为何能快速发展？它们的产品方法论是什么？
今日头条是一家流量运作公司，对流量ROI的运用纯熟度与效率非常高。依赖强大的数据和算法系统，通过AB test 同时运行几千条功能测试，用最短的时间去找出最有价值的业务方向，得到结论后，快速推出市场，抢占先机。
中国互联网已经进入到一个获取流量成本很高的时代，企业并没有那么多容错机会给到大家不断尝试试错。要提高决策准确性，主要依赖数据论证。
2. 通过数据分析验证产品成效
你在面试时，你说你牛逼。如何叫人信服你？你说你牛逼，你就真牛逼？
相信大家已经习惯了小套路，说自己曾经做的某个项目转化率提高了多少个点之类的。
实际上，在我们做的每个项目或者功能中，都应该用数据来验证产品成效。
电商网站的收银台大家耳熟能详，比如以下：
参照国内竞品调研和产品交互设计师自以为的产品目标：给用户传递安全感——通过增加底部“确认支付”按钮来实现。
实际上线效果却不尽如意，新版本比老版本跌了3个点左右。
事后我们反思了整个过程，得到一些启发：
支付需要用户冲动型消费，不需要用户那么理性思考。按钮操作，让用户有种仪式感，反而增加了用户犹豫心理。
比如淘宝换成了指纹支付，或者刷脸支付，转化率会提高。我作为用户，使用了淘宝指纹支付后，下单支付快了很多。我也有同事，一不小心刷脸支付后，就懒得再发起退款了~
支付产品的核心是：安全和快捷。如果品牌背书，用户已经觉得安全，那么接下来就是快 ！去掉按钮才是让用户有快速支付的感觉。
于是，我们又花了一些时间，去掉底部“确认支付”按钮，用户选择支付方式就可以进到支付环节，转化率竟然又提升了！
去掉了底部“确认支付”按钮
整个团队从这个案例中都得到较大感触，充分体现了我们自以为更好的方案对用户或者从业务角度并不是最好的。如果没有数据来验证，我们还会一直停留在自己觉得设计很好的功能中自嗨！
用AB test 测功能，用数据来验证功能成效是最有说服力的手段。
3. 通过数据分析洞察用户
用户研究是产品经理必须要去做的一件事，懂用户，挖痛点，给方案。
用户研究常用的方法除了用户访谈、调查问卷等定性研究外。从已存数据中发现用户的行为偏好，建立数据与用户画像之间的关联，针对不同人群需求或者痛点给出合理的产品解决方案也是数据驱动决策的手段。
比如从历史订单数据中，挖掘新老用户购买商品的偏好，可以针对新老用户群体做个性化的商品推荐，这也是大家能够感知到的电商产品推荐。你去逛淘宝首页，是不是会觉得淘宝比自己还懂自己？给自己推荐的大部分商品是自己喜欢的。
通常对用户历史行为数据收集越详细，越是能够了解用户，为用户做出合理的产品设计。
为什么人们总说作为电商平台和支付平台的阿里有最完整的行为数据乃至最完整的人群画像，那是因为根据生活消费的商品和服务，几乎能够推断一个人全部的特征，而越是习惯网上购物的用户，衣食住行都用同一个支付手段的用户，就越能够被电商和支付平台完整描述。
产品在做产品功能设计时，并不只是单纯为用户提供功能和服务就可以，理所当然以为用户会来使用。定要对用户需求或者痛点挖掘地足够深，才能精准提供服务。从过去已存数据中挖掘用户行为偏好或者痛点，是产品设计的第一步。
这里借用《产品思维》一书中提到的例子。
我们是一个创业小团队，正在做一个P2P（个人对个人）金融产品。平台上已经有了一定量的用户，他们购买了我们的理财产品。我们正在考虑要不要增加VIP（贵宾）套餐服务，定位高价值用户，定向提供理财顾问服务。
我们会请许多专家，提供很多额外的分析工具，让这些用户享受高端服务，赢利方式就是VIP年费。单拿这个服务来看，肯定是没有什么问题的。
“许多类似的产品都有这样的服务。”也许老板就会这么跟你说。但这不能成为我们就一定要提供VIP套餐服务的理由，我们还是要看看我们的用户是什么样的。
可以先统计下当前用户购买理财产品的行为数据，看看大部分买的额度有多大。其实，额度背后代表的是这些用户的收入水平和对理财的态度。
比如粗暴一点假设，我们看用户的行为，过去99%的用户都是奔着投资5万元，锁定期6个月，年化收益率5%的产品去的。
这些行为代表什么呢？从生活经验判断，对年化收益率要求不高，对流动性也要求不高，对安全性要求比较高的人，应该都是普通的上班族。这些人在理财方面非常保守，而且还比较年轻，理财额度并不高。
具体的验证可以通过访谈和调研来完成。假如结果显示，这些用户群体基本都是毕业三年内的职场新人，理财行为非常保守，而且还比较年轻，理财额度并不高。
这时回过头来看，这个VIP套餐服务的吸引力就特别有限了。仅从用户特征来看，几乎就可以给这个创意判死刑了。
从已存数据中分析用户需求或者痛点，找到用户行为偏好，精细化用户群体，了解用户，才能判断业务模式的可行性。而不是理所当然觉得用户会使用这个功能。
4. 通过数据分析找到机会点
在刚做支付业务时，首先就对Top10、各端做了支付成功率分析，很快就发现某些国家的转化率是低于其他国家的，自此这些国家被列为重点和困难国家。我们的机会点也是优先提高这些国家的支付转化率。
再比如做商城购物流程优化项目时，首先拉取了商详页-购物车-结算页-收银台-支付成功 发现商详页和结算页转化率两个环节在整个路径中转化率最低，因此马上定出了事项优先级，优先解决这两个页面的转化问题。
职场中如何价值最大化？可不就是发现最严重的问题，找到最大的机会点，把资源用在刀刃上。
5. 结语
管理大师德鲁克说：“不能衡量，就无法管理。”
产品经理完拍脑袋、凭感觉、凭经验做决策的时代已经过去了。如果你还没有数据思维或者数据分析相关的能力，被时代淘汰真的是，早晚的事！
产品经理不需要成为数据分析方面的专家，但什么时候分析数据、分析哪些数据、如何分析数据、如何用数据辅助决策、如何用数据驱动业务，这些问题是产品经理必须要回答的。
02
数据分析的框架
我以支付业务为例来讲解。
用户来到支付收银台后，在页面上有很多点击行为，比如选择各种支付方式，微信支付、ApplePay 支付等最后完成支付，也有可能点击左上角返回键或者右上角订单中心离开当前页面。
这个过程会产生很多数据，从数据大类上分成：用户数据、行为数据和业务数据。
谁（用户数据）做了什么（行为数据）结果如何（业务数据）？
用户数据指用户本身的特性，如用户画像，使用你产品的用户男性多还是女性多，年龄多大等。
行为数据指用户使用产品在页面上的各种点击行为，在页面上停留时长等。
业务数据指用户行为之后，实际产生的结果，业务数据会落库业务数据表。分析业务数据的意义，可以衡量商业价值，是业务最终呈现结果，用以推动公司业务的发展。
用户数据和行为数据通常可以从第三方数据工具，如友盟、Google Analytics 直接获取，业务数据一般要内部建设。
今天重点讲业务数据搭建完整过程，以阿里云的Quick BI为例。
在整个数据分析的框架中，分为五大层次，依次是：数据生成、获取数据、数据建模、数据分析和数据应用。
1. 数据生成
还是以支付业务为例，用户选择支付方式完成支付后，落库核心的两张业务表：订单表和交易表。一个订单会对应多笔交易（每选择一种支付方式生成一笔交易，一笔订单可以使用多个支付方式尝试支付），其实还会产生其他表，比如收货地址表等。
2. 获取数据
通常使用第三方工具如ETL将业务系统的数据经过抽取（Extract）、清洗转换（Transform）之后加载（Load）到数据仓库的过程，数据呈现在BI的数据源。
3. 数据建模
所有数据进到数仓以后，需要根据实际想要看的业务数据进行数据建模，建模后的数据呈现在数据集。数据集作为数据源和可视化展示的中间环节，承接数据源的输入，并为可视化展示输出数据表。
4. 构建数据模型
数据建模是什么含义呢？
底层的业务数据表其实很多，几十张上百张都有，但到了业务数据分析阶段，当需要分析的数据存储在不同的表，可以通过数据关联，把多个表连接起来，形成模型进行数据分析。
比如上述的业务底层订单表到了数据分析阶段衍生的订单表字段发生变化，name 和 city 是从业务地址表取来的数据。
总的来说，数据模型是完全面向数据分析的业务场景形成的新表。以支付业务为例，我构建的数据模型有：用户表、订单表和交易表。
5. 设计维度和度量指标
对数据字段可以进行下一步分类：
- 维度（Dimensions）
- 度量（Measures）
在统计学中，单一数据字段可以被分为离散和连续。离散通常是维度，比如城市名称、用户名字，特征是有限数量的值；连续通常是度量，比如销量、利润或成功率，特征是不可罗列，可能为任一数值。维度和度量中有许多灰色区域，比如金额，可以做维度，也可以做度量。
在上述订单表中，device、city 等是维度，对order_id 计数的总订单数、对status = success 计数的成功订单数是度量。
度量可以再分原子度量和派生度量。
原子度量指从维度里直接获取到，上表中的总订单数和成功订单数。
派生度量并不能直接从数据表中获取，而需要基于已有数据进行加工处理得到，上表中的订单成功率是成功订单数/总订单数得到。
6. 数据分析
有了维度和度量的概念后，接着引入聚合概念。对于数据分析来说，往往关心的并不是最底层一行一行的的明细数据，更注重分析数据的角度，关心的是数据的总体特征。
聚合，简单讲就是数据源里的多行数据按照一定的标准计算成一个数据，不管数据集里有1行还是多行，视图里的数据都是聚合后的结果，一行数据也是要聚合的，当然一行数据聚合的结果是一样的。实际上，维度为数据聚合提供依据，而度量是依据维度聚合得到的结果。
配置了聚合计算的计算字段，将根据配置的维度自动进行聚合运算。
如：
- 求和：SUM([字段])
- 计数：COUNT([字段])
- 计数去重：COUNT(DISTINCT [字段])
- 求平均值：AVG([字段])
表述的业务含义为时间周围为2021.3.1 ~ 2021.3.15 范围内pc端的订单成功率为0.5。
计算过程：根据created_at=2021.3.1 ~ 2021.3.15 和device =pc ，SUM([总订单数])= 2，SUM([成功订单数])=1，SUM([成功订单数])/SUM([总订单数])=1/2=0.5。
Quick BI 提供电子表格和仪表盘两种可视化工具做以上分析。
电子表格：
仪表盘：
通过可视化的图标去分析数据，找出机会点或者异常。
7. 数据应用
通过可视化的图表去分析数据，找出机会点或者异常。可以说，前面1、2、3、4 所有的工作都在为了第5部分数据应用上。
数据从用户中来，通过一系列的数据沉淀、处理和分析找出机会点做决策再回到用户中去，提升用户体验，带动业务增长，此即数据驱动业务。
8. 结语
本Part介绍了分析数据的数据框架拆解、数据处理加工过程。
但是海量数据怎么看，看哪些？度量指标应该怎么设计，度量指标中什么是业务的北极星指标等此文还没提到，在第三部分数据指标体系设计中讲解。
03
数据分析 | 数据指标体系设计
接着来讲数据指标体系设计，是整个数据分析篇章中最核心的内容。
在上文中讲到，我把数据分为：用户数据、行为数据和业务数据，再往下又分了维度和度量两个概念。
尽管如此，维度也好，度量也罢，都会产生很多散落的数据，你并不知道数据与数据之间的关联性，也不知道众多数据中什么是最核心的，什么最能表示业务最终呈现效果或者哪个数据指标表示目标达到。
数据与数据之间的关联性或者相关逻辑性称作数据指标体系。指标体系指将零散单点的具有相互联系的指标，系统化的组织起来，通过单点看全局，通过全局解决单点的问题。
说白了就是找个框架把所有的数据以一定的逻辑性组装起来，框架也即数据模型。此篇文章针对用户数据、行为数据和业务数据分别给出代表性模型，用以各自领域的数据分析。
1. 用户数据之AARRR模型
提到用户本身，马上会想到经典的AARRR 模型，即获取用户（Acquisition）、提高活跃（Activation）、提高留存率（Retention）、获取营收（Revenue）和自传播（Referral）。
每个环节都有这个环节应该关注的指标，这些环节并不一定遵循严格的先后顺序。
- 获取（Acquisition）：用户如何发现（并来到）你的产品？
- 激活（Activation）：用户的第一次使用体验如何？
- 留存（Retention）：用户是否还会回到产品（重复使用）？
- 收入（Revenue）：产品怎样（通过用户）赚钱？
- 传播（Refer）：用户是否愿意告诉其他用户？
AARRR模型是非常经典的用户分析模型，且需要结合具体业务展开来讲，这里不做过多描述。
2. 行为数据之UJM OSM模型
UJM即User-Journey-Map，用户旅程地图模型；OSM分别指目标、策略和衡量，Objective-Strategy- Measurement。
UJM OSM，通过拆分用户使用产品的阶段性行为，从中挖掘用户的需求，在每个阶段确定能够提升的指标，将用户旅程和业务目标结合起来。
目标（ Objective）指业务目标。业务或者产品，存在的目的是什么、能够解决用户什么问题、满足用户什么需求？如上述业务目标为购买转化率，购买转化率越高，说明用户体验越佳，商业价值越高。
策略（Strategy）指为了达到业务目标，应当采取什么策略。如上述为了提升用户首页-商详转化，策略1可以为视觉提升、策略3可以为交互流程改善等。策略1的视觉提升可以进一步拆解为页面整体颜色、卡片样式等。
衡量（Measurement）：用来衡量策略的有效性，反映策略执行是否能达成业务目标的度量指标。如上述首页转化率可以为进到首页用户数转化到商品详情页的用户数，转化率越高，说明用户对首页青睐度越高，首页的产品呈现内容越有效。
基于用户的行为路径来拆解目标，对于每个子目标找到最终可落地的方案，启动项目需求，通过用户功能满足达到最终的业务目标。
如购买转化率目标为提升15%，那么估算首页改版项目提升的目标为8%，商详改版项目提升的目标为5%，下单结算改版项目提升的目标为3%，收银支付改版项目提升的目标为2%。
按照价值从高到低依次投入开发资源去实现目标，项目上线后再复核业务目标是否达成，若未达成，进行差距分析。
3. 业务数据之指标分层
谈到业务数据时开始涉及角色的问题，业务和产品的角色分工，不同的角色在不同的场景下关注的指标并不相同。
基于此，一开始就把指标进行分层级，分为业务、产品和流程三个层级，业务关注业务的，产品关注产品的。不同层级的指标有不同的思考维度和分析方法。
以支付业务为例，先明确指标层级后，根据指标设计原则，去做关键指标的拆解，一级指标可以拆解到二级指标，二级指标还可以继续拆解到三级指标等等。
业务层级的指标用来衡量商业层面的客户发展、增长与获利、竞争力与盈利能力等。
业务从用户那里挣钱，需要通过产品作为载体或媒介，互联网产品的使命是利用技术赋能业务，帮助企业降本增效。所以谈到产品，需要去思考产品定位、产品能提供的核心价值、产品带给用户的产品使用体验、产品如何实现业务目标。
进一步细化，一个产品往往有着很多功能，承载着不同的用户交互步骤或操作流程。梳理并整理出整个转化流程中各个关键节点，去实现产品的核心指标。
从业务模式，到根据产品的价值与体验，再分解到具体流程的步骤效率。这提供了一种纵向的，自上而下、由粗到细的分析模型，在每一个层级上，又会有不同关注点和类别的指标。以数据为基础，主导产品布局，拆解流程步骤，赋能业务增长。
4. 结语
本Part从用户数据、行为数据和业务数据三方面介绍了3个数据指标体系模型。特别说明的是，文中提到的AARRR模型、UJM OSM模型、指标分层3个数据模型仅举例说明，实际还有更多模型，如PLC、HEART、GSM、PTECH模型等等，需在不同场景下评估综合使用。
但不管什么数据模型，核心都在于找到数据与数据之间的关联性，从海量数据中找出最核心的数据指标用以衡量目标是否达到，以系统和结构化视角思维来看数据分析。
04
数据呈现之数据分析方法
今天来讲数据分析的第四篇文章数据呈现之数据分析方法，是整个数据分析篇章中最后一部分内容。
在前面第二部分、第三部分文章中，我们讲了数据生成-获取数据-数据建模-数据指标搭建这样漫长的数据加工处理过程，到最后一步便是数据呈现和从数据中挖掘出来的问题或者机会点的数据应用。
有句话调侃讲，辛苦干活儿一年还比不过一个做PPT的，同样适用数据分析。如果前面做了大量数据加工处理工作，但是最后不会做数据分析和数据呈现，挖掘不到问题和机会点，那么前面的工作将白费。
（或者说前面的工作皆属于打地基，最后一步也就是本篇文章讲述的内容是收获果实。）
通过数据呈现，把分析的结果完整呈现出来，为决策者提供科学、严谨的决策依据，供决策者参考以做出决策。
好的数据呈现，需要有一个好的方式展现数据间的关系和规律，让人一目了然，这是接下来要说的数据分析方法。常见的漏斗分析、多维拆解、趋势分析、对比分析、帕累托分析和交叉分析等。
上篇讲的数据指标体系设计是从宏观层面指导如何进行数据分析，本章讲的数据分析方法主要从微观角度指导如何进行数据分析。从宏观到微观是不断细化的过程。
1. 漏斗分析
漏斗分析能够科学反映用户行为状态，以及从起点到终点各业务流程的用户转化率情况，是一种重要的流程式数据分析方法。
比如：对于电商产品来说，最终目的是让用户购买商品，但整个流程的转化率由每一步的转化率综合而定。这时，我们就可以通过漏斗分析模型进行监测。
如下图所示，我们可以观察用户在每一个环节上的转化率，寻找转化路径的薄弱点，优化产品，提升用户体验，最终提升整体的转化率。
所有互联网产品、数据分析都离不开漏斗，无论是注册转化漏斗，还是电商下单漏斗。需要关注两点，第一是关注哪一步流失最多；第二是关注流失的人都有哪些行为。转化率最低的环节，往往是ROI 价值最大的地方。
2. 多维拆解
我自己本身是做支付业务的，日常呈现数据最多的形式便是多维拆解。（多维的意思是从多个维度拆解度量指标，如果对维度和度量不太了解的可以去看第三部分的内容。
- 首先呈现整体支付成功率，其次按照商户维度分别去看各商户支付成功率；
- 每个商户下有很多个国家，再按照国家维度去看支付成功率；
- 每个国家有很多个支付端，再按照各个端维度去看支付成功率；
- 每个端上有很多个支付方式，再按照各支付方式维度去看支付成功率。
至此，拆到最小颗粒度。
在分析数据时，若整体支付成功率发生异常，按照此路径拆解到最小颗粒度的支付方式，基本可以锁定发生问题的原因。
3. 趋势分析
建立趋势图表可以迅速了解市场、用户或者产品特征的基本表现，便于进行迅速迭代。趋势分析通常按时间维度的小时天周月看度量指标的变化情况（像我每天早上来第一件事是看昨天的支付成功率有无异常）。
趋势分析有两大作用：趋势预测和数据监测。比如我现在正在做的项目业务数据监控，就是基于支付成功率在过去一段时间内的数据表现来预判当前支付成功率是否异常。如下图中的7月和8月明显低于其他月份，可判定这两个月数据发生了异常，需要去寻找原因。
4. 对比分析
同一维度还常常做度量指标的对比分析，主要用于对比同维度间的差异性。比如我做支付业务，会去对比Top 国家的支付成功率，看哪个国家是我重点要关注的国家。
同漏斗分析类似，对比分析也可以快速找出最需要关注的维度指标，把资源用在刀刃上。
比如我印象很深，我的leader第一次做数据分析报告时，按Top国家做了国家维度的对比分析，大家很快知道哪些国家需要花资源重点解决，从此改变大家对支付业务的认知。以前大家可能以为支付需要持续接入新支付服务商，但是大家现在知道可以分重点国家差异性改善，不仅仅是无脑接入新支付服务商
另外，在对比应用中，现在流行A/B test，A/B test的关键就是保证两组中只有一个单一变量，其他条件保持一致，实验组和对照组也是对比分析。
除了跟别人比，也可以自己跟自己比，统计学中的环比和同比便是自己跟自己比的经典应用。（比如到年底，我会做支付业务的复盘，会把连续几年的订单量和支付成功率做对比，看今年的整体情况）
5. 帕累托分析
帕累托分析，平常也称之为二八定律。在任何一组东西中，最重要的只占其中一小部分，其余尽管是多数，却是次要的。
帕累托模型即是以二八定律为基础原理构建出的商品分析模型，这个模型最大的好处是可以对商品或者产品进行分类，按照投入产出比的优先次序原则，将自己的资源尽量投入到头部产品当中，以期产生最大的效益。
其核心思想就是少数项目贡献了大部分价值。以款式和销售量为例：男士服饰、运动服装及用品、儿童服装、女士皮鞋占总体销售额的70%以上。
6. 交叉分析
交叉分析法就是将对比分析从多个维度进行交叉展现，进行多角度的结合分析，从中发现最为相关的维度来探索数据变化的原因。
如下图，从APPPC 端的维度结合漏斗做对比分析，可以发现APP在每一步转化率更好。
以上掌握了基本的数据分析方法，如何撰写一份分析报告增加它的可读性呢？
逻辑清晰。数据是怎么来的；发现了什么问题；总结问题发生的原因；如何解决这种问题；给出结论和解决方案。这样一个简单明了强逻辑关系的分析报告就能让绝大多数人接受。
报告图表化。用图表代替大量堆砌的数字会有助于人们更形象更直观地看清楚问题和结论，更容易做到有理有据。
规范化。整篇文档的图表风格统一、名词统一。数据有来源，口径有说明。（特别是第一次引入数据统计口径时，要额外说明）
至此，数据分析文章系列全文完。
五、结语
在最后，我想说的点是：数据分析重在思路，更多在实践中训练自己数据思维，要有数据意识。
尽管写了此篇文章10000多字，也只是数据分析的一点点方法论，是工具层面的皮毛。到目前为止，我仍然有业务上的数据问题无法解开，可见，就算是成体系的所谓方法论也无法解决所有的实践问题。
想加以强调的是，无论是看了我的文章还是别处学习了其他知识&技能，都需要在自己实际业务场景下去应用，否则信息就只是信息，永远无法内化为自己的知识。
任何东西都不会学到即停止，它会被一直迭代和更新。
- EOF -
