文章目录 1、什么是埋点2、埋点目的3、埋点流程4、埋点方式4.1、无埋点4.1.1、什么是无埋点4.1.2、无埋点的优点和缺点 4.2、代码埋点4.2.1、什么是代码埋点4.2.2、代码埋点分类4.2.3、代码埋点的优点和缺点 4.3 可视化埋点4.4 埋点方式总结 5 、埋点实现6、埋点测试
1、什么是埋点
使用第三方或自己开发相应的数据系统，进行用户行为数据或其它信息数据的收集。说白点，就是通过技术手段偷偷的监控用户在我们产品上的行为
2、埋点目的 驱动决策：ABtest、漏斗优化、用户增长、bug修复、精准营销、流失用户预警驱动产品智能：智能推荐(千人千面)、场景化提示(私人助理)等驱动安全：风险识别 3、埋点流程埋点是比较耗时的工作，需要业务方提供方案，开发工程师进行埋点，测试团队进行测试，埋点的工作流程大致如下：
埋点的方式主要分为：无埋点、代码埋点和可视化埋点，下面来分别介绍一下
4.1、无埋点 4.1.1、什么是无埋点无埋点又叫全埋点，是前端的一种埋点方式， 在产品中嵌入SDK，最统一的埋点，通过界面配置的方式对关键的行为进行定义，完成埋点采集，一般都是通过第三方统计工具，如：友盟、神策、百度统计、诸葛IO等。
4.1.2、无埋点的优点和缺点优点：
可视化展示宏观指标，满足基础分析需求，如PV，UV，每个控件的点击联系使用和部署较简单，只需要嵌入SDK，避免了很多因为需求变更，埋点错误等导致需要重新埋点用户友好性强，触发埋点之后自动向服务器发送数据，避免人为失误缺点：
只能采集用户交互数据，对于一些关键行为还是需要代码埋点兼容性问题数据采集不全面，传输问题，时效性，数据可靠性 4.2、代码埋点 4.2.1、什么是代码埋点代码埋点也叫手动埋点，即纯手动写代码，调用埋点 SDK 的函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据，像友盟、百度统计等第三方数据统计服务商也大都采用这种方案。
4.2.2、代码埋点分类前端埋点
可以理解为web端，app端等在前端触发相关规则时进行的埋点上报等，主要记录的是用户的操作行为，例如点击了哪个按钮，进入了哪个页面等等。
前端埋点与全埋点类似，也需要嵌入SDK，不同的是对于每个事件行为都需要调用SDK代码，传入必要的事件名，属性参数等等，然后发到后台数据服务器。
前端埋点适用于：其他非关键业务量或不需要请求服务器的行为，能记录用户绝大多数的操作行为
后端埋点
可以理解为当用户进行相关操作触发相关接口请求或相关业务的时候，进行的埋点上报。
后端埋点则将事件、属性通过后端模块调用SDK接口方式发送到后台服务器。
后端埋点适用于：用户需要请求服务器的关键业务量的场景
通过可视化交互的手段，代替上述的代码埋点。将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。缺点就是可以埋点的控件有限，不能手动定制。
可视化埋点听起来比较高大上，实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。比如国外比较早做可视化的是 Mixpanel，国内较早支持可视化埋点的有TalkingData、xsdc，2017年腾讯的 MTA 也宣布支持可视化埋点；相比于手动埋点更新困难，埋点成本高的问题，可视化埋点优化了移动运营中数据采集的流程，能够支持产品运营随时调整埋点，无需再走发版流程，直接把配置结果推入到前端，数据采集流程更简化，也更方便产品的迭代。
可视化埋点中多数基于Xpath的方案，XPath 是一门在 XML 文档中查找信息的语言，XPath 可用来在 XML 文档中对元素和属性进行遍历。
4.4 埋点方式总结 5 、埋点实现很多公司都是采用前端埋点和后端埋点两种方式一起埋点的。后端埋点其实跟常规的接口请求上报服务器的原理是差不多的，这里不做过多的探讨。我们来看看前端埋点的实现：
前端埋点是以 Key–Value 的形式实现的，Key表示某个事件，Value代表相对应的值。比如下图中Key为$eid，代表的是event_id，即事件id，Value则是不同的事件id值：pv、click等
注意事项：
同种属性的多个事件要命名成一个埋点事件id，并以Key–Value 的形式
不同属性的多个事件应命名成多个埋点事件id，尽量不用Key–Value埋点Key–Value 的形式的优点
维护成本低，更加简洁高效：新增时只需要增加一个value参数即可
易理解，减少沟通成本：提高其他业务人员、数据分析师根据埋点日志的查询和分析效率
扩展性好：对未来上线新活动或业务的调整更加灵活，可以很容易在原有基础上进行扩展 6、埋点测试
埋点测试主要关注两方面：
埋点上报
无论是前端埋点还是后端埋点，我们都需要关注其有没有正常按照需求定义的相关规则进行上报，比如上报的时机是否正确、上报的页面覆盖是否完整、上报的事件是否正确、上报事件关联的属性是否完整和正确等
埋点落库
埋点上报完的数据是需要存储到公司数据库或第三方平台系统当中再进行相关的数据统计、分析、归类等等，除了检查埋点上报，还要看最终数据是否正常落库，相关数据字段是否正常
举个后端埋点的例子栗子：
比如产品要求追踪用户在网站的搜索行为，看用户在哪些页面、搜索哪些关键词多，当用户输入关键词时，会额外再请求埋点的接口，该接口需要传送用户id，页面，关键词等参数信息，这就是埋点上报
公司数据库也会新增对应的关键词搜索统计表，前端请求上报后，验证数据库是不是正常落库，用户id，页面，关键词等字段数据存储是否正确，这就是埋点落库
下面以第三方统计工具xwddm介绍一下前端埋点的实现方法、抓包方法和常见bug
【前端埋点的实现方法】
此处以全埋点为例
在每个index页面的源码下方引入sxdmf埋点的js脚本文件，并且把该文件中全埋点字段autoTrack值由默认的false改成ture入下图：
【前端埋点的抓包方法】
web端打开开发者工具F12，选择image(图片)类型的接口，接口路径带web.gif即为诸葛的前端埋点上报请求，其中传参字段event里面的data数组则是我们需要关注的关键信息，我们需要验证上报的时机是否正确、上报的页面覆盖是否完整、上报的事件是否正确、上报事件关联的属性是否完整和正确等
常见的埋点事件有全埋点事件（pv、uv、click等），也有公司根据自己产品的需求而定的自定义事件，常见埋点事件解析：
PV(page view 页面访问量)：即页面浏览量或点击量UV(unique visitor 独立访客)：指访问某个站点或点击某条新闻的不同 IP 地址的人数用户在每一个页面的停留时间用户通过什么入口来访问该网页用户在相应的页面中触发的行为下图是自定义的埋点事件：
下图则是pv埋点事件：
【前端埋点bug举例】
问题描述：有些埋点上报请求会被莫名其妙的取消，导致有些要上报的埋点上报不了
解决方案：在自定义埋点后面加一个回调函数，里面加上跳转代码
zhuge.track(’’,{},function(){ //跳转 })
问题描述：一次点击事件，连续触发了两次重复的埋点上报请求，除了时间戳参数不一样，其他参数完全一致
问题描述：部分页面发送的PV事件请求出现请求状态未知的情况，且此时控制台报错：zhuge is not defined（找不到诸葛的js脚本）
问题原因：大致是在访问该页面时，页面需要加载多个js文件，zhuge.js文件被放在了HTML文件的最底部，当PV事件的埋点请求需要调用zhuge.js文件的代码时，页面还在按顺序加载前面的几个js文件，导致获取不到对应的埋点函数而抛出异常：zhuge is not defined
解决方案：调整zhuge.js文件在HTML文件中的顺序，放在其他js文件之前：
其他常见bug
发送埋点请求时没有按照需求定义的相关规则（上报时机、上报页面、事件名称、属性名称）进行上报，比如漏报，错报或者重复报等
注：
参考资料：埋点测试、埋点接口测试