一、指标体系
指标，实际上就是一种度量。大到用于监控和评估商业进程的状态，小到衡量某个功能模块的情况，或者是自己的活动效果。
从运营角度来看，一个好的指标，需要具备四个特点：业务层面是有价值；可衡量业务真实情况；简单可执行；大家都共同认可。
从技术层面来看，一个好的指标，统一具备四个特点：容易收集快速衡量；准确度高；可被多维度分解；单一数据源。就像我们经常使用的衡量APP产品启动人数，使用UID或者是COOKIE往往比使用IP更加准确。但很多时候，因为技术或者是业务自身的原因，我们往往很难找到很完美的指标。那么这个时候我们最重要的就是统一口径进行分析，更多地观察数据的波动情况。
在产品和运营的工作中，我们会接触不同的数据、不同的指标。很多时候我们做的数据，都是针对单个点的层面去做，而最终显示出来的数据往往比较零散，无法串联起来，发现全局的问题。
而指标体系化，则是将零散的数据串联起来，让你通过单点看到全局，通过全局解决单点的问题。
非体系化的指标往往是单点分析，分析不出来之后需要重新分析另外一个点，而无法串联进行全局分析。
而体系化的指标往往是结合用户的场景来进行分析，并且多个不同的指标和维度是可以串联起来进行综合分析。就像排序（如价格）因素里面的某个维度，可以分析页面转化率，也可以分析商品的售出率等。通过相同维度的分析可以更快地找到问题的原因。
二、搭建指标体系的工作流程
数据指标的定义（阿里的指标模板设计，可试用其他行业）
我们在梳理公司的数据指标时发现每个部门对同一个指标定义的不一致，就好比交易额这个指标在电商产品中就是一个模糊的指标，是下单金额、还是支付金额（无包含优惠）、或者有效金额（剔除退款），这样没有一个统一的标准，就很难对部门间做横向的对比。甚至部门间对同一个指标的口径也存在不一样的情况，更不用说整个指标的开发要涉及运营同事、产品同事、技术同事等，只要一个环节出问题，指标计算就会不准确。我们采用阿里的一套针对指标的规范定义，也是业界比较常用的定义方式，在一个标准下看数据消除歧义。
业务板块：面向业务的大模块，不会经常变。除非有很多业务模块的产品线。
数据域：数据属于哪个主题的，如交易，注册，渠道，
业务过程：如电商业务中的下单、支付、退款等都属于业务过程。
时间周期：就是统计范围，如近30天、自然周、截止到当天等。
修饰类型：比较好理解的如电商中支付方式，终端类型等。
修饰词：除了维度意外的限定词，如电商支付中的微信支付、支付宝支付、网银支付等。终端类型为安卓、IOS等
原子指标：不可再拆分的指标如支付金额、支付件数等指标
维度：常见的维度有地理维度（国家、地区等）、时间维度（年、月、周、日等）
维度属性：如地理维度中的国家名称、ID、省份名称等。
派生指标：原子指标+修饰词+时间周期就组成了一个派生指标。
三、这套流程的实施过程
比如当时我们业务提了一个比较有指导意义的数据指标叫APP上的订单支付成功率，我们以支付成功率来说一下每个步骤实施的流程和涉及的角色。
第一步：要确定指标的业务口径
业务口径应该由数据的产品经理主导，找到提出该指标的负责人沟通。首先要问清楚指标是怎么定义的。
这里需要注意几点：
1.缺乏时间维度，需求方需要查看所有订单的支付成功率还是某一时间段的支付成功率
2.支付成功后的订单发起退款，是否计算在内？
3.支付的商品种类包含哪些？全部商品都算?还是计算部分专场的商品
最终确定计算公式：全商品种类的任意时间维度下的 支付成功率=成功支付次数（不含退款）/发起支付的次数（以后端服务器为准）
第二步：要确定指标的技术口径
技术口径是由建模工程师开发，此时数据产品经理要和模型设计师沟通整个指标的业务逻辑，另外就是要协调业务方的技术开发人员和我们的建模工程师一起梳理数据库层面需要用到表结构和字段，一定要精确到字段。这些字段都确定好后，就能初步定下来这个指标能不能统计，如果不能统计这时产品经理应该主动协调运营告知，并且还要告诉运营同事做了哪些功能才能统计这些指标，接下来就是协调业务方产品经理讨论是不是要做这些功能。
第三步：原型设计和评审
由数据产品经理设计原型，对于支付成功率来说我们要一方面要展示他们的支付订单数量，另外一方面要实时展示支付成功率的每日变化趋势，加上商品类型的支付转化率就可以综合判断这个商品类型的支付质量也可以侧面看出该类型是否是畅销品。
内部评审要拉上我们的架构师、建模工程师、数据开发工程师、后端开发工程师、前端开发工程师、UI，一起说明整个功能的价值和详细的操作流程，确保大家理解的一致。接下来就要和我们的运营根据原型最终确定问题。比较重要的功能要发邮件让我们的运营进一步确认，并同步给所有的运营同事保证大家的口径一致。
第四步：模型设计
一般采用三层建模（不一定三层，取决实际业务需求和大数据的计算能力）的方式把数据更加科学的组织存储。分为 ODS（操作数据层），DWD(明细数据层)、DWS（汇总数据层）、DM （数据集市曾），这是业务对数据分层常用的模型。之后会专门总结下数据建模的个人笔记
第五步：数据开发
首先要和数据建模工程师沟通好技术口径明确好我们计算的指标都来自于那些业务系统，他们通过数据同步的工具例如Sqoop将数据同步到模型工程师设计的ODS层，然后就是一层一层的通过SQL计算到DW*层，一层一层的汇总，最后形成可直接服务的数据.
另外大数据开发工程另外一个比较重要的工作就是设置调度任务（如YARN），什么时候计算提前写好的计算脚本如T-1每天凌晨处理上一天的数据，随着业务的增长，运营会对实时数据的需求越来越大，还有一些实时计算任务（spark streaming）的配置也是由大数据开发工程师完成。
第六步：后端开发
后端开发工程师基于产品经理的功能定义输出相应的接口给前端开发工程师调用，数据开发工程师将数据注入常规的关系型数据库，此时后端开发工程师更多的是和产品经理沟通产品的功能、性能方面的问题，以便给使用者更好的用户体验。
第七步：前端开发
原型出来后产品经理会让UI设计师基于产品功能的重点设计UI，UI设计师经过反复的设计，UI最终定型后，会给我们的前端开发工程师提供切图。前端开发工程师基于UI的切图做前端页面的开发。
第八步：联调
此时数据开发工程师、前端开发工程师、后端开发工程师都要参与进来。此时会要求大数据开发工程师基于历史的数据执行计算任务，数据开发工程师承担数据准确性的校验。前后端解决用户操作的相关BUG保证不出现低级的问题完成自测。
第九步：测试
测试工程师在完成原型评审后就要开始写测试用例，那些是开发人员自己要自测通过才能交上来测试的，那些是自己要再次验证的都在测试用例写清楚。此时有经验的产品经理会向运营人员要历史的统计数据来核对数据，不过运营人员的数据不一定准确，只是拿来参考。最终测试没问题产品经理协调运营人员试用，试用中发现的一些问题再回炉重新修改，此时整个研发过程就结束了。
第十步：上线
运维工程师会配合我们的前后端开发工程师更新最新的版本到服务器。此时产品经理要找到该指标的负责人长期跟进指标的准确性。重要的指标还要一定的周期再次验证，从而保证数据的准确性。