有效数据治理的6大原则

如果你常常对数据准确性而烦恼，大部分时间都用于处理数据而不是对业务进行思考分析的话，那么你需要好好对数据进行治理了。

一、为什么要进行数据治理

不知道你是否有这样的感受，看到数据后，一脸懵逼，不知道各个表和字段代表什么意思，再看看别的同事写的SQL，一条SQL语句有几百行，各种表关联，然后问了其中一个同事，他说“别提了，数据都不准，我快被数据折磨死了！”，此时你是不是“想死”！欲哭无泪……

究其背后的原因，是因为负责的人只是问题使然，哪有问题哪里去补，没有整体的统筹规划，一步错，步步错，数据最后是越来越重，查询越来越复杂，数据准确性还没有人敢打保票，同时修复的难度也大大增加。

二、如何进行数据治理

如果要想将数据治理好的话，需要遵循以下六大原则、合理制定数据中间表模型以及埋点采集到应用全流程的把控。

1. 六大原则

原则1：关键概念多方共识

关键概念若涉及多方，比如成交客户的定义，要确保公司内部和客户相关的所有业务人员理解一致。

你或许会说，成交客户还不好理解么，就是购买了我公司产品且签署合同的用户就是一个成交客户，但是实际情况远非如此，笔者当时处理该块的业务时，问不同的业务人员得到的结果都不一样，这样就造成了数据指标统计的歧义甚至数据的不准确。

当一个合同主体变换名称（含工商注册名称变更、更换签约公司等），那么这个客户算一个成交客户吗？

同一个 集团/公司 下，不同的 子公司/业务线/部门 用同一个名字签署多个不同合同，属于单个成交客户还是多个成交客户？

当合同还在「待确认」或未拿到合同编号时，如果客户运营人员已经开始服务客户，那么这个客户算一个成交客户吗？……

原则2：某个类型的值经常发生变动，则需要冗余一个通用字段冗余值

笔者是深受其害，以前每个月底都需要找开发、业务人员对一遍数据，举个例子：

查询原始指标：soure_type为A，B的任务产出的金币数额为消费指标，SQL已针对该指标做了类型筛选。某一天业务运营人 员上线新的任务，C类型的任务会贡献金币流水，但是开发未告知数据人员，导致原来的关键指标数值出现差错。

处理过数据的同学都知道，某个指标的实现可能和其它几个关键指标相关，那么该指标的异常排查就需要逐个检查是哪个相关指标出问题了，查找到原因可能2，3天的时间就没了，但如果事先开发人员冗余了一个通用字段代表该类消费指标，那么后续不管业务人员上线多少个消费类型的任务，都不会对原来的指标产生影响。

原则3：每个实体都有唯一、不变的ID，最好没有实际意义

一是为了实体的唯一性，二是为了表关联或更新时不受业务的影响。

原则4：涉及协作的数据，发现问题要从修改源头做起，保证下一次拿到正确的数据

协作的数据可以说是一个串联的过程，源头的数据会逐层影响下层的数据，不要为了一时方便，只修改目前发现问题的地方，要从修改源头做起，方便他人即方便自己。

原则5：编写操作清单，操作前请三思

数据间存在关联，把数据间的关联关系陈列清楚、注意事项标注清楚，操作前一一核对，小数据量验证无错后，大数据量执行。

原则6：系统工程的方法管理数据，尽可能使用系统，监控数据错误并及时修复。

将使用数据的相关方都画在一张系统循环图中，观察数据错误产生于系统哪个环节，如何影响后续各个环节，避免恶性循环的产生。

2. 合理制定数据中间表模型

一款产品的存在是为了解决某类用户群体的需求痛点，并在此基础上进行盈利；数据分析的存在也是为了辅助挖掘和发现潜在用户需求并进行优化和运营。

而数据的准确性和数据查取的效率依赖于底层的数据采集和中间层的数据中间表的构建。

关于底层的数据采集方法详见：产品经理给开发提埋点需求的正确姿势

用户的需求隐藏在用户行为中，从聚合用户行为的角度构建数据中间表方便数据查询和分析。

用户行为分析模型

以用户观看短视频这个用户行为来说

WHO：即观看视频的人是谁，可以唯一标识用户身份，如设备ID，注册后的用户ID。如果和第三方合作的话，可以对一个用户生成一个唯一标识ID，用户串联设备ID和注册后的用户ID。

WHEN：观看视频发生的实际时间，一般会记录客户端时间和服务端时间。

WHAT：即用户观看视频这个行为。

HOW：记录用户观看视频的方式，如所在频道、观看时长、视频类型等等

WHERE：记录用户在哪个省份、城市、IP下观看视频的，同时还会记录网络类型、应用版本、操作系统等其它环境信息。

构建包含完整用户行为的数据中间表