01 业务和数据的闭环
业务和数据，可以理解为映射关系，数据是业务在数字世界里的另一个它。举个例子来说：你衣服鞋子的尺码、喜欢吃什么口味的菜、爱看什么内容的文章、什么时候起床和睡觉等等，所有这些个人的数据都在云端被记录着，它就是你在数字世界里的映射。网上之前流行的一句话很有意思：手机可能比你自己还要了解你。就是因为它里面存储了一个数据的你。
我相信大家都清楚，手机用的越频繁，越多个人的数据被记录，它就会越好用，然后你就会用的更频繁。业务和数据就是这样的闭环促进关系：业务越全面、越深入的被线上化，反过来数据对业务的赋能就会越大。
- 业务数据化
业务线上化，存储业务所产生的数据，记录业务； - 数据业务化
分析收集的业务数据，评估业务状态，指导业务发展，提升效率；
▲图1 业务和数据闭环
02 认知：数据、信息和知识
接下来我们会就其中的数据分析环节展开来讲，在这之前，先宏观的了解一下从数据到决策会经历怎样的一个过程。
我们时刻都在被数据所记录着：年龄、身高、体重、消费金额、运动步数等等，如果只是单纯的去看这些数字是没有意义的，要用心去思考数字背后鲜活的业（灵）务（魂）。业务是有灵魂的！当我们从这些数字中发现业务背后的信息，再将这些数据和信息转化成一组规则来辅助我们决策（知识）的时候，数据就会变得很有价值。这个过程就是：从数据到信息，再到决策（知识）。
跟大家举个生活中的例子：体温39度是单纯的数字，背后的信息是发烧了，做出的决策（知识）就是需要去医院看病。
对于上面总结的从数据到决策的过程，我们往往会说成根据数据分析的结果去做决策，虽然这样的说法没问题，但不够直接，实际上我们是基于业务理解去做决策的，而数据是帮助我们加深业务理解的工具。数据赋能业务一般会经历四个环节：数据表现、业务原因、业务策略和作用方式。最开始我们通过数据去评估业务状态，发现业务表现异常，再全面的分析数据并结合一线的调研反馈，反复的进行猜想和数据验证，弄清楚数据表现背后的业务原因，然后思考解决问题的策略，再落地执行，监控后续效果并不断的迭代，直到问题被解决，业务发展进入正轨。
再就刚才提到的生病发烧的例子详细解释一下数据赋能业务的过程：体温39度是数据表现，背后的身体原因是发烧了（业务原因），医生说需要打点滴退烧（业务策略），之后你就躺在病床上，护士过来给你输液（作用方式），这些流程走完之后，后续还会要求你持续的测量体温（监控落地效果），如果还一直不退烧的话，可能还需要继续去输液吃药（不断的迭代业务策略），直到最后体温恢复正常（问题被解决），身体进入健康状态（业务发展进入正轨）。
03 业务策略的闭环
分析数据定位业务问题，基于业务理解，确定解决策略，到最终正向的影响业务，整个过程中，业务策略存在两个闭环：逻辑闭环和业务闭环。
- 逻辑闭环
数据分析的过程，逻辑上要闭环，论据要能够支持结论的成立； - 业务闭环
策略在业务上的落地执行要闭环，不断的调整迭代；
这两个闭环是互相影响的，首先要做到的就是论证逻辑闭环，保证结论可以站得住脚。等真正落地执行的时候，业务上可能行不通，就需要基于新的业务理解去迭代论证逻辑，形成新的逻辑闭环，再去落地执行，直到在业务上可以跑通。
所以在数据分析过程中会常出现两类问题：
- 逻辑闭环相关
不接地气，指的是策略的逻辑论证没问题，但离业务上跑通还很远； - 业务闭环相关
策略没有落地或者落地反馈周期太长，导致业务理解只停留在当时分析数据的节点，没有得到验证反馈；
那我们在工作中怎么判断业务策略是否接地气呢？主要分成两步：
- 深入思考策略成立的业务假设是什么？
- 调研判断业务假设是否成立？
举个例子：你设计了一套完整的针对B端商家的权益方案，希望牵引商家按平台的方向去做生意，假设权益方案在逻辑上没问题，但要真正落地有效的话，就会涉及到一些业务假设需要成立：
- 平台可以很好的触达商家，商家也能够理解权益方案；
- 权益方案细节，商家真的很在意；
- ……
接着就需要去调研这些业务假设是否真的成立？如果成立的话，那么该策略落地有效的概率就会很大；如果商家理解不了复杂的权益方案，或者商家对权益根本不在意，那说明该业务策略是不接地气的，就需要及时做出调整。当然，策略是否有效的前置调研验证是很有必要的，但有时候调研结果并不能直接推导出策略有效或者无效，那就需要设计好的落地方案，快速验证迭代。
最后也类比过来，判断某个人是否懂业务：如果这个人通篇都在讲数学逻辑，没有业务判断，或者有些业务判断明显是不成立的，那大概率这个人就不太懂业务。要做出正确的决策首先逻辑上要成立，另外在业务上也要行得通。
04 数据分析与指标体系
如今不论是企业还是个人发展，整体都在往数据方向转型，数据变得越来越重要。企业需要数据资产保持行业竞争力、产品需要根据数据分析的结果来迭代、运营需要通过数据来评估活动效果等等，越往后，数据思维、分析能力会逐渐变成横向能力被大家所掌握，人人都会数据分析肯定是未来的趋势。所以我觉得大家在这个窗口期选择数据领域是非常明智的。
建立指标体系是数据分析的第一步。
数据指标中心是规范化开发指标并对其进行管理维护的系统，将指标的组成部分解耦拆分开来，并在逻辑表中进行规范性的定义，在此基础上，后续可以按照一定规则进行自由拼装，实现自定义指标的功能。
在我们日常的数据工作中，指标的重要性毋庸置疑，指标来源于业务的场景化呈现，业务也通过指标来透视出问题，但也正因为如此重要，使用如此频繁，所以导致指标也出现各种混乱、难用、难找等等问题。所以我们必须有一套合理合规的指标治理方法，并将这套方法转化成工具，通过固定流程去约束原本不可控的行为。接下来我们就看看，指标治理的有那些方法论？以及这些方法是如何设计成系统，也就是我们说的——数据指标中心。
05 如何建立指标体系
1、首先定义指标并归集到对应的主题域
指标的本质是量化了的目标，比如常见的例子：
①我们要把用户的盘子做大，那对应的量化指标就是已注册用户数；
②我们要统计今天的销售额，那对应的量化指标就是总支付金额；
③我们要衡量一次活动的效果，那对应的量化指标就是下单率。
从上面的例子我们可以看到，我们比较常用的几个类型的指标就是，存量型指标（已注册用户数）、事务型指标（支付金额）、转化型指标（下单率），其它还有比例型、统计型、排名型等，这些比较不常用，就不在此赘述了。
这些不同类型的指标，分散在我们产品中的不同功能模块中，所以为了更好地规范与管理，我们需要将这些指标也按照主题域的方式归集起来。主题域在“仓库模型中心”进行创建与定义，在这里只需要将对应的指标划归到对应的主题域就行了。
2、然后是拆分原子指标与派生指标
先来看看原子指标跟派生指标这两个概念具体是什么？
①原子指标：是事实表中，某一个字段的统计值（sum、count、max、min、avg），如下单用户数，下单金额等；
②派生指标：是基于原子指标，进行维度组合后产生的指标，如近1天商城下单用户数，本周商城黄金会员下单金额等。
原子指标无业务意义，它只是预定义的代码片段而已。业务中用到的指标基本都是派生指标。
3、接着定义原子指标与派生指标的生产逻辑
在本章的开头有提到这样一句话：“将指标的组成部分解耦拆分开来，并在逻辑表中进行规范性的定义”，这个解耦跟定义的过程，就是把一个派生指标拆解成原子指标、时间周期、限定维度、聚合粒度，然后再重新拼装，生成新的派生指标的过程：
在上面这个例子中可以这样来理解：
①统计周期是这个原子指标进行统计运算的时间范围，在这里是本周；
②聚合粒度是指标的主体，即按照哪个维度来来进行聚合，这里是黄金会员；
③限定维度是限制原子指标的计算范围，这里限定在商城，即只计算商城相关的数据；
④原子指标则是预定义的某个字段计算规则。在这里是下单金额的累加。
4、最后通过指标管理平台对指标进行规范生产
（1）规范化指标命名
命名规范对于后期大量的指标管理来说非常重要，因为当指标多起来的时候，你要找一个指标经常需要用到检索功能，而检索的前提是你对指标有一些前置的认知。这就需要我们对指标的命名进行规范化。
指标命名规范有三个重点：
①简洁明了，易懂：最好是只要看到指标名，不需要看注释就可以知道它的意思，归属等；
②格式统一：每个指标的格式都是一样的，通过组合不同模块的命名拼凑起来；
③生成统一：原子指标与继承自它的派生指标的规范是一致的。
以商城相关的指标为例：
①所有业务下单跟支付指标，默认以主单为统计口径，不用带“主单”相关字眼，如商城下单次数；当统计口径为“子单”时则需要在命名中标出，如：商城子单下单次数；
②所有与人相关指标默认以“注册用户”为统计实体，不需要带“用户”相关字眼，如访问次数；当统计主体为“游客”时则需要在命名中标出，如：游客访问次数；
③无指定业务范围的指标默认为平台指标，不需要带“平台”相关字眼，如近30天支付人数。如果有限定业务范围，则需要加上业务名称，如：商城-近30天支付人数；
④无指定时间周期的指标默认为“近1天”（但需要保存小时粒度，便于后续下钻），不需要带“时间”相关字眼，如注册人数。如果有限定时间范围，则需要加上时间周期：如：近7天注册人数。
完整的命名的规范为：商城（业务板块）+用户（实体）+近7天（统计周期）+新增（业务动作）+子单（类型）+单日（间隔周期）+平均（统计运算规则）+支付金额（原子指标），如：商城-用户近7天新增子单单日平均支付金额（没有的部位可留空，如：商城-汇总支付金额）。
⑵规范化统计口径
当指标主体为实体（名词）：游客、用户、商品等，则只需定义单位为“人/个” 即可。如：游客人数、用户人数、商品个数。
当指标为业务动作（动词）：如点击、支付、下单等，单位除定义为“次数” 外，还需考虑跟这个动作关联的实体的单位，如“商品”时需要定义多一个单位“笔数”；为“用户”时则需要定义多一个“人数”等；所以一个下单动作的指标，会有多个不同的统计口径：下单次数，下单人数，下单笔数，下单金额……
在定义指标名时需要详细列出，避免出现“下单数”这样模糊的指标。
⑶规范化指标等级
我们都知道，随着公司的发展，产品在不断地进行迭代，功能的增删与业务的变化势必也影响着指标的发展，一些旧的指标被不断更新或废弃，而新的指标也不断增加。这时对指标的管理也成了一个问题，哪些指标由谁开发？后续谁来维护……
一个比较好的解决方案就是对指标进行等级划分，可以划分为两个等级：
①一级指标：即原子指标与小部分全平台的核心指标，从各业务部门收集需求后，统一由数据中台来产出，有一套完整规范的开发流程：需求-评审-排期-开发-测试-验收-上线。所有维护管理工作都由中台负责；
②二级指标：即派生指标，由各业务部门自定通过指标中心生成，没有严格的开发流程，各业务部门根据需要自行创建，但需要遵守命名规范。所有维护管理工作由部门内部负责。
06 业务合作与职责边界
指标中心建成后，还需要将在整个数据分析过程中各个角色的职责边界理清楚。公司在追求业务商业价值最大化的过程中，会涉及到多个部门间的合作。
- 业务产品经理：
负责协调研发、测试、设计等部门，从实际业务需求出发，上线产品； - 数据开发工程师：
根据数据产品经理的需求，按模型、按主题等去加工业务数据； - 数据分析师：
建立体系的分析框架评估业务状态，定位业务问题，指导业务的发展； - 数据产品经理：
负责协调数据开发同学将业务数据模块化和体系化，同时将业务分析框架产品化，提升数据赋能的效率； - 运营：
根据业务方向，通过短期的激励活动，引导用户认识到产品的长期价值；
在实际的工作中，涉及的部门会更多，比如还会有算法部门、研发部门、用户研究部门等等，这里就不一一展开跟大家讲了。
具体的合作过程：首先是业务产研团队基于实际需求，上线产品，当业务数据被收集上来以后，会同步到数据仓库，数据开发工程师根据数据产品经理的需求对数据进行加工处理，数据分析师会全面有逻辑的去拆解和分析业务，并同数据产品经理一起合作把分析框架沉淀在数据产品上。数据分析师、数据产品经理和数据开发工程师一起搭建了整个业务的数据体系，然后对外输出：评估业务状态、数据支持运营活动、分析产品迭代效果等等。
