作者介绍
@edan
前商业数据分析师，现 TMD 数据产品经理。
期望和数据小伙伴一起做些有意思的事情～
1 背景与适用范围
从服务体验出发做数据治理：数据服务于业务，因为业务是在不断的发展，所以当数据建设到了一定阶段的时候，各种问题随之而来，既有底层数据模型过于冗余、链路过于复杂等问题，也有业务侧使用数据时的体验问题。
当大家谈到数据治理时，常常都想从根本出发解决问题，指定一系列指标规范，建模规范，借助元数据管理工具完成强制实施。开发侧做了很多动作，但往往会出现业务侧无感，形成开发同学自嗨的局面。
笔者在实践过程中从用户体验的角度出发，推动数据治理的落地，让业务同学直接体验到数据治理带来的数据服务升级。
由于本文所讲的内容，更多是业务线服务（数据 BP）中沉淀的经验，所以对服务于具体业务线的数据开发/产品更有借鉴意义。
2 方法论
01 现状分析
项目背景：笔者服务的业务对于数据的使用 90% 的场景都基于自助计算，但目前指标维度数据易用性较差，导致业务使用成本高，甚至多次因为指标混乱而取错数。
核心原因主要有两个：一方面建设过程中，对于核心指标体系不清晰，所以拓展了很多阶段性的指标维度；另一方面由于业务经历多年的发展，数仓围绕许多 “昙花一现” 项目做过建设，业务下线后指标维度未做梳理下线。
项目目标：针对业务相关的数据集（基于业务线划分的指标维度集合）做指标维度的治理，降低数据集使用的难度；并沉淀出一套适用业务服务体系的数据集治理 sop 雏形。
2.2 项目过程方法
2.2.1 问题体系化梳理
贴合业务实际使用情况，梳理指标维度当前存在四类问题：
1）大量命名擂台的指标（中体内容量/内容量/中台内容量-去重），从表面完全看不出具体差异。有新老模型的原因，也有不同场景下对应的元数据系统中取数方式不一样的原因；
2）复合指标冗余严重：比如 “新增中台发布态内容量” 类指标非常多，可以考虑通过维度组合核心指标的方案实现（限定「是否当日新增内容」维度下的「中台发布态内容量」）；
3）指标命名不规范（如：信息流_侵入态曝光_七日留存率，并不知道是什么动作到什么动作的留存）；
4）指标注释无法说明其真实意思（中台内容量：“中台内容量（状态不限）”。其实底层是限定了发布态的）。
2.2.2 多方协作出方案
1）商业分析同学基于对业务的理解，归纳出核心指标维度体系；
2）数据产品对出现以上四类问题的指标维度做重点标注说明；
3）业务方根据指标维度的使用热度及业务需要，确认指标是否可以下线；
4）数据开发对于可以简化通过维度组合计算的指标给出建议（比如：「是否当日新增内容」维度 与「中台发布态内容量」指标做出新增内容漏斗，原先的新增指标可以砍掉）。
整个过程由数据产品经理发起主导，其他角色的同学从自己的专业知识上提建议。
2.2.3 由浅及深做落地
优先做指标维度的表层治理，提升业务侧可感知的数据体验，对应不同的情况应用层做三类动作：
1）不规范指标重命名（对于命名不易理解，不规范的指标维度，按照公司标准重新做命名）；
2）无用指标/数据模型下线（部分指标维度不再使用的模型做字段下线；对应所有指标均已经确认可下线的模型做模型下线）；
3）同义不同名维度/维指标做整合（举例：笔者所在团队，造成同义不同名的维度的原因主要是因为前期数据建设不规范，例如对城市名称维度，不同事实表模型接入了不同的城市维度表，而不同维度表中对该字段有不同的命名，我们需要对各事实表模型中用到的维度表做统一即可）。
在指标维度表层治理完成后，数仓进一步展开数据链路的优化工作，做深层的数据治理，更多帮助提升底层数据建设效率、数据生产效率。
2.3 项目效果
项目结束后，业务指标从 200+ 个精简至约 80 个，维度从 150+ 个精简至约 70 个。治理成果上线后业务侧反馈：“确实提效了！再也不用担心点错指标了。同时让其他协同的业务方用数据集的时候也降低了沟通成本”。
3 总结
项目实践中值得总结的思想：
治理实施思路上 “以客户为中心”。由表及里实施治理，先从业务最能感知到的指标维度层做精简操作；其次再提高业务使用过程中的速度体验，从底层根本去治理数仓链路，同时达到长期降低数据开发成本的效果。
协作过程中遵循 “合作共赢” 的原则，协同 ba 及业务方一起思考优化方案，不仅从多角度保证了最终实施成果的可靠性，也能让相关方感知到数据治理这个非常底层的工作。最终才得以让治理项目获得斐然的成果。
一个数据人的自留地是一个助力数据人成长的大家庭，帮助对数据感兴趣的伙伴们明确学习方向、精准提升技能。关注我，带你探索数据的神奇奥秘
1、回“数据产品”，获取<大厂数据产品面试题>
2、回“数据中台”，获取<大厂数据中台资料>
3、回“商业分析”，获取<大厂商业分析面试题>；
4、回“交个朋友”，进交流群，认识更多的数据小伙伴。