用户行为数据采集──埋点，是用户行为分析中非常重要的环节，直接决定数据广度、深度、质量，影响后续所有的环节。就埋点本身来说，技术实现的难度并不高，但是整个埋点的过程可以说十分的复杂繁琐，有非常多细节和流程需要考虑，不同类型客户端如何采集，数据如何统一，哪些信息需要在客户端采集，哪些信息需要在后端采集，如何减少数据上报的延时和漏报，如何对成千上万个埋点进行统一的管理？

这一系列文章基于用户行为分析数据平台一年的工作经验，会对埋点的全过程进行思考和讨论，涉及对埋点基础知识的介绍，讨论如何从 0 到 1 开始用户行为数据采集工作，分享负责项目的埋点方案，介绍埋点管理系统，梳理整个埋点协作流程等方面。

系列文章的第一篇，讨论目前常见的三种埋点方式：代码埋点、全埋点、可视化埋点。

常见的埋点方式主要有三种：代码埋点、全埋点、可视化埋点。

常见埋点方式

代码埋点

代码埋点是最经典埋点方式，实施埋点的研发将埋点代码结合到业务代码中，实现用户行为数据的采集。这种埋点方式能采集到非常复杂的行为，尤其是一些非点击的、不可视的行为，必须用代码埋点来实现。代码埋点按照位置的不同，可以分为前端埋点、后端埋点。前端埋点用来记录用户在客户端的操作行为，后端埋点用来记录客户端进行服务器请求的日志。

前端埋点

前端埋点能够收集更全面、精细的用户数据，尤其是不需要请求服务器的行为数据，如：页面停留时长、页面浏览深度、视频播放时长、用户鼠标轨迹、表单项停留及终止等等，只能通过前端埋点实现。但缺点在于，前端埋点的上报一般存在 15% 左右的延迟上报和漏报(客户端未联网、数据打包上报、用户删除行为数据等原因)。另外，如果客户端是 APP，每次上线新的埋点或者更新埋点时，需要发布新的版本才行，但是会存在部分用户不更新版本情况，影响数据质量。

后端埋点

理论上，只要客户端向服务器发送过请求，服务端埋点能够收集到。相比于前端埋点，能实时采集数据，不存在延时上报，数据很准确；并且，服务端埋点支持与用户身份信息和行为附带属性信息整合；另外，每次上线新的埋点或者更新埋点时，发布后马上生效。

代码埋点适合精细化分析的场景，我们可以将各种细粒度的数据采集下来，后续做深度分析。当然这种埋点方式很低效，需要经历完整的埋点流程，包括业务梳理(产品运营)、埋点设计(产品运营/研发)、实施/测试/上线埋点(研发/测试)。整个过程需要多方协作，且要求产品运营也具备一定的专业水平，如果发生错漏无法快速补救。

全埋点

无埋点、无痕埋点、自动埋点，指的都是全埋点。这种埋点方式想要实现的效果是全自动化埋点，将客户端的用户行为尽可能地全面采集，然后通过界面配置的方式对关键行为进行定义。使用这种方案，每次有用户行为分析的需求，不用再走一次完整的埋点流程，只用在产品中嵌入 SDK，等于做了一个统一的埋点。但是，无埋点也有很明显的弊端。无埋点只能覆盖基本的点击、展示等用户行为；其次，全埋点采集的数据量非常大，随着数据量上升，可能会导致客户端崩溃的概率也会上升。尤其是移动端，更多的数据量意味着更多的电量、流量和内存消耗；第三，即使全部行为数据都被收集回来了，具体分析时也不能避免二次梳理和加工，因为机器无法在采集时按照我们想要的方式对全部事件进行有意义的命名，甚至无法保证采集上来的事件都正好是正确的；第四，现阶段全埋点对于用户身份信息和行为附带的属性信息也几乎无能为力。

可视化埋点

可视化埋点也被称为「无码埋点」，它的理念是降低实施埋点的门槛，以此来提升原工作流程的效率。实施埋点时，无需研发人员介入，产品运营可以直接在网站或移动应用的真实界面上操作埋点，而且埋点之后立即可以验证埋点是否正确，并且，埋点部署到所有客户端也是几乎实时生效的。同样的，可视化埋点也有很多局限。首先，可视化埋点也只是针对点击可见元素的，一些动态页面、不可见的行为是采集不到的；其次，对于点击操作附带的业务属性，比较难实现；第三，为了确保埋点准确性，可视化埋点也逐步整合了更为复杂的高级设置，操作起来也很低效。