一、埋点之痛

埋点的数据价值是一个数据驱动型的互联网公司需要认真考虑的事情。很多公司都有自己的埋点，但埋点数据却因各种原因用不起来，或者叫很难用好。埋点体系上涉及到的干系人非常多，而每一环又都不可或缺，任何一环的不重视都会导致埋点出问题。我想很多数据从业人员都知道埋点数据价值，但基于各种历史原因和现状却经常会感叹“”埋点数据怎么这么难用”。埋点之痛，不经历过埋点体系的从业者无法感同身受。

就笔者本人而言，从做数据产品开始，自己的日常工作就被埋点占据了大部分，到后面做平台类数据产品之后，发现埋点问题依旧占据很多精力且治理困难，写这篇文章也是跟大家讨论讨论自己做埋点治理的心得，以及深入剖析下为什么埋点质量这么难保障。

做埋点时间长了，越来越觉得埋点并不像自己想象的那么简单，仅仅是开发在自己要统计的业务场景下，写埋点代码、打包上传统计数据就完成工作，从最开始的埋点需求规划，再到最后数据上报，只要有一个环节有坑就会影响数据准确性。而数据准确性估计是每个数据人工作中必须要面对的难题。

下面简单聊聊自己遇到的坑，这些或许仅仅是表述了现象，至于导致此现象发生的本质相信就仁者见仁，智者见智了。

二、埋点小坑总结

1、想要找的埋点找不到

这是最常出现的，我们想找一个数据的埋点，但怎么也找不到，自己也难以确定是没有打过，还是说这个点位在某个角落默默等着人来用。产生这种情况主要有两种：

数据埋点缺乏统一的查询管理平台。

数据埋点字段名不规范 or 中文名不准确。

针对第一点，其实在进行埋点规划的时候，一般都会有一个文档或者平台能够让使用者对打点情况进行查询的。但是在真正执行的时候，因为平台或者文档与实际打点缺乏强绑定性，总会出现点位更新不及时、或者是老点有变动但没有在平台或者文档上更新，导致查询工作变得复杂且困难。

而第二点，也是我个人很想吐槽的一点，在埋点时候缺乏对点位名字的思考，比如首页曝光的打点居然会叫“batch/c10705”（真实案例），请问这种埋点如果不看文档，谁知道它什么意思？体现的是埋点者在埋点前的思维惰性。

2、埋点重复，不知选哪个可信

同样是真实情况中经常出现的情况，同样意义的点位会打上多次，出现的原因有可能是以下两种：

存量埋点Owner离职或者转岗，导致大量僵尸埋点信息，与第一个坑有耦合。

老点因为业务变动导致拓展性差，修复困难，因此通过新点替代，但牵扯之前业务，因此老点也无法现在废除。

而因为查询平台与文档的缺失，导致不知道选哪个可信，以及用不同打点测出来数据值差异较大，应该信哪个，这时候的建议可能是看打点时间，尽量以新的为准，一般来说新的埋点会更适配当下业务情况。

3、埋点杂糅，一个点位什么都打了

对于数据埋点者，一个常犯的错误是将过多的埋点任务放到一个埋点上，并通过子字段进行场景或者行为的区分，这种很多时候是非常不合理的，比如点击的打点，打的是对内容的点击行为，但如果把点赞，转发等行为也记录在内，显然是不合理的。

虽然广义上点赞也是一种点击行为，但很少有在业务上要对两者进行统一统计的情况，更多时候是分开看点击和点赞行为，这样打在一个点位上，除了给数据分析增加不必要的困难，也会让点位的维护变得复杂困难。

4、埋点开发不规范

这个问题也很有意思，数据产品经常有个疑问：为什么我规划好了的埋点，实际开发或上线后根本不符合预期。这个环节共设计到两个角色：数据产品和埋点开发，那么到底是哪一方在沟通理解上出现了问题呢？

数据产品：技术背景较薄弱，针对不同开发环境和生态了解欠缺；

埋点开发：了解开发逻辑，对于未明确的细节用惯用逻辑实现。

大家发现了吗，当埋点场景复杂时，由于两个角色的侧重点不同很容易会出现gap，有人问有什么好的办法去规避吗？

其实除了上面讲的，只能不同角色补齐自己的短板，还有就是两方一定要多沟通，埋点开发在埋点评审时要思考不同实现逻辑和异常场景是否会影响埋点上报，在开发埋点之前尽量把问题暴露出来。

5、错埋、漏埋频发

在数据分析中，很大一个感受就是每次根据一个点位做数据分析对比的时候，总会发现点位存在错埋、漏埋的问题，这让我们数据分析的工作变得滞涩，很多时候都在填之前打点时留下的坑。

很多人都觉得打点需求相对比较简单，写清楚需求文档，验收的时候却不怎么上心，过分相信了rd和qa，这种惰性也让我后续做了多次埋点的补充需求，重复造轮子。

找到负责的rd，仔细过一遍埋点的触发逻辑，点位信息，在和qa一块showcase时测试线上环境下埋点准确性和全面性，相信我，虽然繁琐一点，但一定是良好的工作习惯。

三、埋点避坑指南

（一）规范埋点治理流程

产品和运营作为埋点需求的常见提出方，当新功能或活动上线时会提很多埋点需求。

数据产品在这个环节如果对埋点需求没有明确的提需规范和把控，就会导致埋点需求爆炸，对于开发和维护成本都是压力，并且后续做数据分析的时候经常会发现数据不可用或数据不准确，那其实后续排查问题的成本非常大，所以数据产品一定要对埋点需求有全局把控。

1. 明确埋点要统计哪些指标

数据产品在评审埋点需求的时候很重要的一点就是：明确埋点要统计哪些指标。

埋点统计是服务于指标的，如果对埋点需求没有管控放任提需，经过几个版本的迭代就会发现埋点维护很难，而且这样也能反推运营和产品思考自己到底关注哪些核心指标，对后期的数据统计和复盘都是有帮助的。

2. 明确埋点提需规范

埋点需求规范的价值是帮助业务方和数据产品拉齐对即将开发的埋点认知一致，所以在设计埋点提需规范时不仅仅要让业务方标明要统计哪些指标、事件如何规划、触发时机，最好能写出每个自定义参数的触发时机、参数打在哪个层级、是否需要透传等，对于刚起步做埋点治理的阶段可以先将精力focus在提需规范的设计和落实上。

埋点提需规范越详细越好，可以帮忙拉齐各方对埋点的认知。

3. 埋点需求评审会及设定需求接口人

埋点需求评审就不具体展开了，大体说就是将业务方、开发、测试、数据产品等组织起来对埋点需求进行评审。我想多说说需求接口人这个角色。

进了大厂发现需求接口人很重要，没有接口人的话仅靠数据产品跟业务对接在大体量和复杂业务场景的公司里是不现实的，所以接口人的定位是埋点需求master甚至是数据需求master。

建议接口人可以考虑经常对接埋点需求的业务或是有开发背景的业务方，这样沟通起来会方便一些。

（二）埋点设计环节整体性思考

规划埋点是数据产品的基本工作，但真正能做好埋点规划很难，我觉得这个环节的痛点在于：很难以全局视角规划埋点并且具有可扩展性，所以为了后续的可扩展性，我简单列几条可参考的tips。

1. 埋点设计要具有简洁性

这里的简洁性是指同类场景下的埋点是否能合并成一个埋点规划，比如“点击支付按钮”事件，该事件在很多页面都可以触发，那么就可以把这个事件规划为一个埋点，在不同的页面点击时将页面名称或页面ID作为参数传递。

但这些还是比较初阶的埋点设计方案，当很多业务属性以参数形式传递时，如何管理及规划这些参数，让数据RD看到埋点日志时很容易就能理解这条埋点携带了哪些信息，那么就引出来我要讲的下一点。

2. 埋点设计要具有规范性

其实规范性这个词很宽泛，我们通篇也都在探讨如何基于埋点治理的痛点制定规范。上面讲到我们如何管理埋点日志里的参数，我觉得可以按照性质和层级给这些参数进行个简单划分：

公共参数：每条买点日志都要上报的参数，包含设备信息、上报时间、IP地址等信息（这里不具体讲，大家可以参考第三方数据分析工具如神策、GrowingIO等公共参数的采集）。

那么数据产品对于公共参数的设计和管理体现在要规划号公共参数并协调各个埋点端上报格式一致，降低数仓解析成本。

私有参数：也叫自定义参数，每条买点在不同场景、不同操作、不同逻辑下会触发并传递不同参数，此类参数叫做私有参数。

这里的层级指的是埋点日志的json层级，如果能做好json层级的划分，那么对于不同角色的RD可以按照自己关注的参数去解析，大大降低了解释成本。

1）公共信息层：如果读了上面的公共参数，那么会很好理解什么叫公共信息层：顾名思义就是存放公共参数层。

2）业务信息层：里面存放自定义参数，针对同类或同场景的采集信息可以抽象成一个对象，在对象里存放这些信息，例如上面提到的“点击支付按钮”事件，可以把页面信息存放到一个对象里、位置信息存放到一个对象里。

3）策略信息层：里面存放为策略服务的参数，之所以把它单独划分一层是因为策略多变且灵活，最好还是规划在同一层级下管理。

4）透传信息层：这种后端透传前端的参数也建议单独规划，便于后续做链路追踪等应用。

当埋点设计形成了规范，那么其实也完成了埋点最难的高度抽象的部分，接下来就是基于抽象好的规范甚至是数据模型来复用到后续的埋点规划中，抽象的思路可以先关注重点场景：先设计核心指标有关的核心点位或者场景复杂的点位。

3. 埋点设计要具有可扩展性

埋点设计的可扩展性与上面的规范性密不可分，当规范建立好数据产品要思考是否具有较强的扩展性，还有后面规范的新增和变更该如何管理和维护。要知道埋点不仅仅只是服务于指标统计，想要全面的规划埋点还要设计分析产品性能、使用体验的埋点，比如上报启动时间、崩溃事件、页面加载时间等事件。

（三）利用IT工具提升埋点工作质量和效率

一个埋点统一管理的平台，能够在你后续进行埋点查询，数据分析的时候节省至少50%的人力和精力。

有一个优秀的埋点平台也是不够的，还需要在打点变动时能够在平台上进行更新，而众所周知，不论是rd还是pm总是缺乏动力去做这个事情的，而且容易忘记，因此应该有一种机制来确保两者能对应，不然久而久之，平台查询的不准，大家对于平台的使用也不能做到放心，丧失其本身的意义。

      针对“埋点开发不规范”问题，埋点平台可以实现自动化生成开发代码和开发指引，帮助开发人员规范开发插码工作，提升开发效率。

针对“错埋、漏埋频繁”问题，埋点平台可以定义好验证规则，测试人员可以用平台工具自动测试和验证埋点数据，抛弃传统的手工查数或抓包方式，效率将大大提升，准确度也比人工测试更高。