编辑导语：埋点是数据产品经理必备的工作技能之一，对于实际工作十分重要。本文作者介绍了有关数据埋点的相关内容，从数据采集的流程、埋点方案的类型和选择等展开分析，一起来学习一下吧，希望对你有帮助。

数据是数据产品的根基，而埋点是数据的起点；如果没有埋点，那数据产品则是无源之水。

可以说埋点是互联网行业里遇到的关键且无法绕过的问题。

以下是企业不同位置的同学内心OS：

• 业务产品：埋什么，怎么埋？
• 数据产品：埋点不规范，错埋、漏埋；
• 业务开发：开发成本高，不懂数据，代码冗余；
• 数据分析：埋点规则找不到，数据分析成本高。

业务同学对于埋点是什么都不知道，也不清楚要埋什么；所以往往会做了功能但是没有做埋点，在需要进行数据分析的时候去找数据团队要数据，数据团队会反问：“你们埋点了吗？”

数据产品，因为他们对于业务的认知并不深刻，所以经常会出现漏埋、错埋的情况，导致最后无数可取的结果。

业务开发，本质上他们是解决业务相关问题，数据开发对他们来说一个比较额外的工作，所以他们的开发成本会随着埋点需求而增加，也有可能伴随项目延期的风险；其次过得的埋点开发需求也会导致代码的冗余。

数据分析，他们更多地是用数据，数据埋点的规则找不到，以至于无法很好的通过数据驱动进行分析。

一、数据采集的流程是什么？数据从何而来呢

• 浏览轨迹：用户在使用我们的产品时候，会在页面上产生一个行为路径、交互的动作，比如访问某个页面，点击某个商品等等，那这些数据的核心来源就是我们的埋点代码采集相关行为动作；
• 业务系统：比如订单交易、数据表等，通过数据库同步的方式，将数据同步给下游相关系统进行使用；

外部数据的交互：比如API数据的传输、 数据文件的传输等；目前某平台的大数据标签系统就是通过这种方式传输补齐企业的人群标签等。而数据产品在整个数据链路上来说，基本可以划分为以下流程：

首先数据采集我们要从不同的端采集不同的数据，然后进行数据清洗加工处理（ETL），然后汇总到数据仓库中，供用户分析、用户画像、精准营销等使用；

我们知道数据采集、数据埋点的重要性后，在实际的业务功能需求提出的时候，一定是要提相关埋点需求的，那在做数据采集我们需要遵循怎么样的流程呢？

1. 业务方确认功能，并发起埋点需求：提交包括所在页面、触发控件、触发场景等；
2. 由专门的埋点团队来进行系统校验，确保命名规范、一致性，BI审核埋点申请和统计需求是否合理缺失等；
3. 审核通过后，开发进行埋点采集框架的设计，开发埋点，完成埋点后进行测试；
4. 测试预先编写能够覆盖所有场景的业务场景，测试通过更新需求状态；
5. 业务验证埋点，数据开发和数据分析；

以上环节缺一不可，只有规范的流程，才可以在最后的分析中发现正确的现状问题。

二、如何选择埋点方案呢

现在互联网行业主流的埋点方案主要分为四种：

1. 第一种：代码埋点，代码埋点又分为前端埋点和后端埋点；前端埋点是通过前端的代码埋点来监控用户触发某个页面的数据采集

前端埋点的优点很明显，但是缺点也很明显，由于前端埋点的数据是通过延迟上报的机制，比如用户点击某个页面按钮它不会立刻上报，而是累计到一定的值以后才会按批上班，受限于当前网络情况，如果遇到网络堵塞等问题就会数据丢包，因此前端埋点丢失率比较高，一般在5%~10%。

而且前端埋点如果有漏埋和错埋的情况，那就要通过app发版进行优化，而客户端发版就要很久的时间。

2. 第二种：服务端埋点：在API的接口里植入埋点代码段

优点是在每次用户触发这次请求，都会触发埋点代码进行数据统计，所以无需发版，及时触发及时更新。

缺点是服务端埋点需要依赖服务请求，无法覆盖所有前端交互，以及对于用户路径采集也比较弱。

3. 第三种：全埋点；是目前互联网做用户增资的企业提出的一种埋点思路，通过埋点SDK接入，针对页面所有的采集页面元素的浏览和点击行为做统一的收集，不是按次和需求采集，而是提前全部采集

优点是开发成本高，SDK接入后后期维护成本也低，且埋点流程也很简单；先采集后定义，在一定程度上能避免漏埋错埋。

缺点是数据的冗余，导致很多数据并无用处，且数据采集范围仅仅是页面可见元素，比如像曝光这种就无法采集到；数据准确性也有问题。

4. 第四种：可视化埋点；也是接入埋点SDK，但是并不是随时随地采集，而是按需采集，通过可视化圈选触发埋点采集

优点是操作简单，且按需埋点不会采集无效数据，开发成本比较低；并且数据埋点是可支持撤销操作的，总体来说比全埋点数据量会小很多。

缺点：历史数据是无法恢复的，因为在我们圈选动作之前的数据是无法进行采集的；统计范围仅支持页面前端的动作，比如曝光也是无法采集到的。

三、了解各种埋点方案以后，如何在实际工作中选择埋点方案呢

选择埋点方案的参考主要基于三点：

1. 业务发展阶段：开发投入成本、业务迭代速度
2. 业务属性：交互应用类、业务交易类
3. 分析深度：用户行为分析、业务分析、业务应用

比如我们可以根据业务发展阶段来定，比如说现在业务发展较快，版本迭代速度快、开发投入成本高，那我们做客户端埋点和服务端埋点是不太适合的，因为可能没过多久版本就更新了，所以全埋点和可视化埋点比较适合；

那对于比较强的业务数据分析场景来说，需加上前端客户端埋点；以及需要考虑分析深度，如果仅仅是想看用户前端行为路径的，那全埋点和可视化埋点就能满足需求，但是如果分析业务全流程那一定是需要配合上代码埋点。

我是比较推荐全埋点+代码埋点组合，如何服务端能做，优先服务端做，这样数据准确度会更高。

四、确定埋点选型后，那我们就要开始具体设计埋点了

事件是埋点里最核心的要素，如果我们要清晰的定位埋点，就要从6个维度进行定义，我们可以总结为who、when、where、what、why、How；这几个元素就构建了事件的基本要素。

那对于埋点事件主要可分为三类：

1. 交互事件：浏览、点击、收藏、支付、曝光、关闭；
2. 系统事件：APP启动、APP crash；
3. 业务状态：支付成功、用户续期等（这种强依赖服务端的返回）。

通过以上我们基本就可以判断出我们需要记录用户什么行为，采集什么数据，for后续的什么分析了。

写在最后，在工作生涯中，过往的坑告诉我，一个好的埋点管理平台是多么的重要。

首先流程线上化，我们往往在一封封埋点的邮件中迷失自我，但是如果是线上申请，那需求申请、处理、接入、验证、测试就非常方便和快捷，规避信息沟通中的缺失；

其次可以管理规范，埋点都统一管理，信息集中管理，方便后期的分析和使用；

最重要的是监控实时化，减少漏埋、错埋的问题。

当然如果没有埋点管理平台，确定下规范的埋点流程，选择适合当下业务的埋点方案，我相信你也一定也可以做好埋点以及通过数据完成丰富的场景分析！

作者：Goodnight；专注用户、产品等运营领域。

本文由 @Goodnight. 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议