埋点|为什么埋点治理这么难？

编辑导语：数据埋点并没有看上去的那么容易，若没有做好埋点治理，后续的业务数据准确性则可能受到影响，从而降低业务处理效率。那么，导致埋点治理困难的原因有哪些？本篇文章里，作者就埋点治理困难这一现象的背后缘由做了分析，一起来看一下。

文章插图
从做数据产品开始，自己的日常工作就被埋点占据了大部分，到后面做平台类数据产品之后，发现埋点问题依旧占据很多精力且治理困难，写这篇文章也是跟大家讨论讨论自己做埋点治理的心得，以及深入剖析下为什么埋点质量这么难保障。
做埋点时间长了，越来越觉得埋点并不像自己想象的那么简单，仅仅是开发在自己要统计的业务场景下，写埋点代码、打包上传统计数据就完成工作，从最开始的埋点需求规划，再到最后数据上报，只要有一个环节有坑就会影响数据准确性。而数据准确性估计是每个数据人工作中必须要面对的难题。
下面简单聊聊自己遇到的坑，这些或许仅仅是表述了现象，至于导致此现象发生的本质相信就仁者见仁，智者见智了。
一、埋点混乱且缺少管控产品和运营作为埋点需求的常见提出方，当新功能或活动上线时会提很多埋点需求。
数据产品在这个环节如果对埋点需求没有明确的提需规范和把控，就会导致埋点需求爆炸，对于开发和维护成本都是压力，并且后续做数据分析的时候经常会发现数据不可用或数据不准确，那其实后续排查问题的成本非常大，所以数据产品一定要对埋点需求有全局把控。
1. 明确埋点要统计哪些指标数据产品在评审埋点需求的时候很重要的一点就是：明确埋点要统计哪些指标。
【埋点|为什么埋点治理这么难？】埋点统计是服务于指标的，如果对埋点需求没有管控放任提需，经过几个版本的迭代就会发现埋点维护很难，而且这样也能反推运营和产品思考自己到底关注哪些核心指标，对后期的数据统计和复盘都是有帮助的。
2. 明确埋点提需规范埋点需求规范的价值是帮助业务方和数据产品拉齐对即将开发的埋点认知一致，所以在设计埋点提需规范时不仅仅要让业务方标明要统计哪些指标、事件如何规划、触发时机，最好能写出每个自定义参数的触发时机、参数打在哪个层级、是否需要透传等，对于刚起步做埋点治理的阶段可以先将精力focus在提需规范的设计和落实上。
划重点：埋点提需规范越详细越好，可以帮忙拉齐各方对埋点的认知。
3. 埋点需求评审会及设定需求接口人埋点需求评审就不具体展开了，大体说就是将业务方、开发、测试、数据产品等组织起来对埋点需求进行评审。我想多说说需求接口人这个角色。
进了大厂发现需求接口人很重要，没有接口人的话仅靠数据产品跟业务对接在大体量和复杂业务场景的公司里是不现实的，所以接口人的定位是埋点需求master甚至是数据需求master。
划重点：建议接口人可以考虑经常对接埋点需求的业务或是有开发背景的业务方，这样沟通起来会方便一些。
二、埋点设计环节缺少整体性思考规划埋点是数据产品的基本工作，但真正能做好埋点规划很难，我觉得这个环节的痛点在于：很难以全局视角规划埋点并且具有可扩展性，所以为了后续的可扩展性，我简单列几条可参考的tips。
1. 埋点设计要具有简洁性这里的简洁性是指同类场景下的埋点是否能合并成一个埋点规划，比如“点击支付按钮”事件，该事件在很多页面都可以触发，那么就可以把这个事件规划为一个埋点，在不同的页面点击时将页面名称或页面ID作为参数传递。