小案例：数据仓库搭建中的流量日志维度表案例
0x00 前言
我将整理文章分享数据工作中的经验，因为业务内容上的差异，可能导致大家的理解不一致，无法体会到场景中的诸多特殊性，不过相信不断的沟通和交流，可以解决很多问题。前面我们分析了职场基本功、数据指标体系，少量的数据仓库内容，今天我们来就工作中经常遇到的数据维护问题，聊一下流量日志的维度表搭建思考。
历史导读：
以下，Enjoy：
0x01 问题场景描述
0x01 我遇见的问题场景描述
前面文章中我们提到过《基于指标体系的数据仓库搭建和数据可视化》，强调了指标体系对数据数据仓库搭建和数据可视化的必要性和重要性。例如我们的指标体系如下：
表头：
日期、城市、品类、页面、访问人数、订单数、交易金额
在这个指标体系，依然会存在很多问题，以维度“页面”为例，我们知道在遍历枚举页面值的时候，常常因为埋点数据的历史“包袱”和规则的不稳定因素，导致很多意想不到问题的。
场景举例
1.某产品页面 A 最初上线页面埋点
id：page1234
name：x业务频道页
2.x 时间页面 A 迭代优化，由于信息不对称，页面 A 采用新的埋点
id：page2345
name：x频道推荐页
3.在 x+n 时间页面 A 继续迭代优化，复用在不同的终端系统内，再次因为信息不对称，页面 A 的埋点信息再次更新
id：page3456
name：x业务频道推荐页
备注：埋点数据历史id、name不一致，数据可视化中需要做归一处理；
0x02 数据埋点维度表
基于场景问题的存在，通常要专门维护数据埋点维度表，将种种的“数据埋点”问题，以人工的方式“清洗数据”，比如将以上的场景举例问题翻译为维表数据如下：
说明：
1.将历经3次变动更新的埋点映射为统一的“union_page_id”，进行统一的命名规范“x业务频道推荐页”。
2.以快照的形式保持历史记录，例如2018-10-25更新数据数据的时候只有2条保持为快照，后续每次更新保留一次快照，可以最大限度的在数据回溯和数据问题排查的时候起到作用。
采用“人工清洗”数据的方式也存在很大的成本和困难，尤其是面对动辄数千上万的数据埋点信息，这些数据埋点可能已经积累了数年，历经数百人的沉淀。因此，我们在清洗每条数据的时候理解每条埋点的字符串背后的信息是非常很难的，所以“清洗”埋点数据也必将是一个长期的运营方案行为。
0x03 数据埋点“清洗”运营思考
认知层面
读者可能像我一样在数据埋点范围内并不能做到一家之言，因此，我认为在开始数据埋点“标准化清洗”前最重要的是针对当前的埋点问题进行梳理和整理，以报告的形式汇报或是分享，让相关人员产生共识：
埋点的问题严重性和必要性，做与不做之间的问题和收益是什么；
埋点的数据问题非短期项目性、非一次性，需要有长期的运营策略坚持，阶段性的看到受益或者沉淀。
执行层面
在没有充足资源投入情形下，建议以核心的埋点数据为首期目标，以知识库的形式沉淀内容，定期的想消费使用数据的群体“广播”分享。
在这个阶段期望达到2个目的：
解决核心的埋点数据问题，快速让数据消费者受益，拉拢支持方；
让事情跑起来，以实际战斗结论检验方案效果，为后续产品系统化做准备。
如果前期运营的得当，在足够的受益和支持方前提下，最终数据的管理工作还是要推动工具化建设的。很多人会将其理解为埋点元数据管理，再次强调几点格外的注意事项：
管理数据基本强调的是依据标准规范SOP执行动作，数据埋点在此基础上还有多思考怎么搭建内容知识库，首先的根据是让内容从0-1，然后才是从1-9的提升。这个过程“运营”的特点是，避免让少数人参与内容的生成，而是鼓励有能力建设内容的人在日常工作中能够不断的贡献知识点，这方面参照“维基百科”词条的搭建。
高质量内容的建设不是目的，根本的方向还是让人消费“内容”，元数据管理系统基本的受众人群是比较有限的，所以我们在做类似工具的时候，要充分考虑知识的分享渠道和广播场景，怎么能做到将内容广播出去，让人消费是重点。
FAQ
1.上面的提到的维表数据怎么使用？
小姬：数据埋点日志记录了用户访问的page_id等埋点数据信息，以日志中的page_id关联维度表中的page_id，获取union_page_id做去重处理（会关联出多条数据，然后做归一化），最终展示的是union_page_name 。
2.数据埋点维表中需要记录埋点页面的终端或者APP吗？
小姬：不需要，我们记录的iOS，Android，x_app，xx_app以数据埋点的流量日志为准即可，流量日志中实际存在即代表存在，这有利于让我们及时的发现问题，校验数据埋点维表的数据及时性和准确性。
热门文章