时间: 2021-07-30 09:08:09 人气: 43 评论: 0
编辑导语：在数据化管理中，数据指标是业务中的核心内容，然而指标管理中总**出现许多问题。指标管理系统在一定程度上可以帮助实现规范化管理，但是针对不同的业务场景与需求，数据管理还应当灵活应变。本篇文章里，作者对数据化管理、指标管理进行了一定分析，一起来看一下。
数据指标是数据化管理的核心内容之一，从事数据工作的同学相信都经历过以下场景：
指标名称相同，统计口径不一致，缺少命名规范限制。
不同业务仅从自己部门出发，缺少全局视角，如财务口径的营收要严格按照严谨的逻辑计算实收实付的每一分钱，而产品/运营端则更多考虑转化效果，但在各自的KPI监控报表中，都把指标命名为营收。
指标统一逻辑一致，但不同产品命名不一致，不同阶段、或不同业务方/产品经理对指标命名不同，导致在不同数据产品页面，同一指标不同名。
只是同义词再复述一遍，如活跃用户数：访问用户数。
表意不清模棱两可，或过于专业化仅指标创建人才可以懂。例如转化率指标，有创单转化率、成单转化率，直接叫转化率可读性就非常差。
指标口径描述有误，例如UV指标，口径描述为“按照设备ID去重”，实际上不同平台去重逻辑并不一致，如微信小程序按照UnionID去重、APP按照DeviceID去重，PC和H5按照loginkey去重。
数据产品指标数据来源缺少直观的链路追踪能力，指标数据异常问题排查通过翻代码去看数据来源，路径长、耗时久，早上业务反馈指标问题，排查出结论后可能一上午就过去了。
指标管理常见的问题综合在一起，往往**导致业务对数据指标的信任度大打折扣，发现数据波动后，第一反应是先和数据部门确认数据是不是有问题，而不是去考虑业务上有何变动。
指标化管理的概念很多年前就存在，各个互联网公司都在建设自己的管理平台，学习了很多关于指标管理系统建设的文章**发现，做的事情大同小异。主要是围绕指标管理的痛点问题，以阿里的OneData**为方法论依据，相同的事情只要做一遍，剩下的是提供产品化的解决方案，让指标建设、指标复用更加的规范和高效。
主要包括：
1）建立指标生产协同机制，指标的诞生要经过需求申请、审核、数据开发、上线应用流程，收口指标创建过程，避免指标建设的随意性带来的“污染”。
2）制定指标命名、口径说明规范，按照原子指标+业务限定+统计维度的方式，将规则集成到平台内，通过系统规则来把控指标输出。
3）指标字典线上化，解决线下文档（excel）管理指标存在的共享难、更新不及时、权限管控缺失等问题。
4）指标数据逻辑绑定，即除了维护指标的业务元数据外，还要建立指标的技术元数据，指标数据从哪个模型、哪个字段、何种计算逻辑得到。
5）指标输出，指标管理最大的价值还是为数据产品提供数据输出，将Hive层模型同步到MySQL、Greenplumn、Kylin、CK等查询性能更优可以秒级响应的查询引擎，通过接口调用JDBC连接方式直接获取数据。
1）指标字典
目标：指标业务元数据、技术元数据信息查询和检索，在线、共享式的指标字典，方便用户快速找到目标指标，确定统计口径，申请权限，直接复用数据，提供一站式指标应用服务。
指标列表：提供所有公开指标列表展示，元数据不设权限，使用时需获得授权，以促进指标共享、减少重复开发。列表展示最关键信息，列表字段默认展示最关键信息，可以设置表格字段，操作列固定。
指标操作：查看和编辑到指标详情页，查看页面是禁用状态。当有指标权限时，可以直接使用，无权限需要申请权限。更多操作包括：删除、监控、血缘查询等功能。
添加指标：指标开发人员直接进入指标编辑页面，其他角色进入指标需求申请弹窗。开发者角色需要填写指标的业务基础信息，并绑定数据源。
指标应用：指标经过分析/产品验证通过后，即可在指标字典列表中查看，用户可申请权限使用。
指标输出到其他数据产品，由系统拼接每个指标和应用方式对应的查询SQL，生成API接口，应用端每次只需要传入指标标识、Where条件（筛选条件）、GroupBY字段（维度），即可获取对应指标和维度的数据。
2）指标需求流程
要想达到指标口径的统一，还需要建立业务、数据产品、数据开发、数据分析、应用开发的协同机制。
所有业务都可以提交指标需求，但需要经过指标审核进行评审审核，确认指标是否已经存在、需求是否明确。评审通过后，由数据开发进行指标配置。
如果指标所需的数据模型已经存在，可以直接进行配置，否则需要先进行ETL工作，构建模型，数据开发配置指标并自测完成后，交付数据测试人（数据产品兼任或专职QA），确认没问题后，指标上线。业务开发接入应用到数据产品页面。
详细工作流转见下图：
相应地，指标管理平台的用户需要划分为以下几类角色：
3）数据集管理
数据集管理和数仓建设模型管理的区别是：数仓模型建设是面向主题的，而指标管理的数据集模块一般是面向分析的，联系是数仓模型可以作为数据集的数据源，在分析应用时，再进行模型的关联。
指标基于数据集进行逻辑规则配置后，在数据产品端输出，因而在查询性能方面要求更高，因此数据集模块另一个作用就是把Hive层模型推送到MySQL、Clickhouse、Greenplum等适合OALP即席查询分析的引擎。
数据集创建过程支持SQL代码模式和模型可视化配置两种模式，数据集支持权限审批流程设置，默认审批流一般为业务发起，发起方上级审批（确定的确有必要使用），数据集负责人审批。
还有一种场景是数据集是数仓人员为某业务线创建，使用权限的审批该有业务负责人审批，或者加入其它个性化流程，此时选择自定义审批流程可以支持用户自己定义审批节点及审核人。
关联维度：数据集模型用到维度字段枚举值映射操作。即建立模型维度字段与维度表字段映射关系，指标应用到对应维度时，直接获取枚举值。
4）血缘查询
指标血缘是指可以链路追踪指标数据加工的来源，以及输出的报表或API应用，当业务端质疑指标异常或需要确认指标口径时，可以基于血缘工具找到产出表，以及最源头的数据来源。
同时，当数据质量监控测发现数据质量问题时，可以及时反馈到下游应用，应用端对用户进行提醒，避免错误的数据给用户带来负面的决策影响。
通常数据血缘是服务于整个数据中台体系，所以指标平台可以复用公共的血缘查询能力，没必要单独建设，只需要把平台内的模型、数据集、指标、应用的关系数据采集好，反馈给血缘模块，血缘模块进行数据链路扩展即可。
5）系统管理
系统管理提供资源权限管理、用户权限管理、数据权限管理的功能，即通过管理和追踪某一指标有哪些用户有权限，或者某一用户有哪些资源权限，来保证用户只有权限看到相应的数据，以此来保证数据安全。系统管理主要包括：
从指标管理平台提供的解决方案可以看出，主要是指标建设流程的规范化，以及指标生产到应用流程的全链路产品化。流程的规范化涉及一个指标需求在不同工种之间的需求流转，在系统初期指标上线效率整体还是比较低的。
再者就是数据中台的思想是提高数据输出效率，很多数据中台的产品解决方案**包括自主BI数据产品，即产品和运营可以直接基于数据集进行拖拽式的分析和可视化报表配置。规范化和自助化存在交叉和冲突。
不做指标统一管理，指标永远是错综混乱，指标标准化，一定程度又**影响数据分析的时效性，那到底该如何权衡，或者确定好指标管理平台的目标和边界呢？
指标的建设是需要长期地积累和完善的，可能规范化的初期**有一段时间的阵痛期，但随着平台内指标的丰富，新增的需求可能**越来越少，即可以确定的是对于业务条线多的企业是需要将指标统一管理，对于在公共层面的通用指标，必须由指标管理平台统一生产和管理。
而对于一些业务临时性、个性化强的指标或者数据报表需求，可以基于自助BI工具，以及SQL取数工具等，快速自助化获取所需的数据即可。
例如，某运营部门需要对端午节新上线的一个盲盒活动进行数据监控分析，直接基于盲盒数据模型，利用自助分析进行可视化配置的效率远远高于先生产指标，再利用指标的流程。
指标管理平台是可以帮助企业进行指标规范化管理的有效工具，但规范化带来的牺牲就是流程的冗长和效率问题。
对于共用的指标以及缓慢变化的业务，可以基于系统进行管理和维护，而对于小范围的业务条线以及时效性要求更高的业务场景，可以用自助BI等产品加以辅助，但最终的原则一定是公共指标系统化管理、流程化生产。
另外，指标输出应用场景方面，还可以继续扩展如指标波动监控、分析报告自动生成推送等能力，把指标管理平台作为数据中台能力的出口之一，不断完善系统功能。
数据干饭人，微信号公众号：数据干饭人，人人都是产品经理专栏作家。专注数据中台产品领域，覆盖开发套件,数据资产与数据治理，BI与数据可视化，精准营销平台等数据产品。擅长大数据解决方案规划与产品方案设计。
本文原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
