现有埋点三大类型
手动埋点(代码埋点) 可视化埋点 无埋点
思考几个问题：
- 采集什么数据
- 业务方通过什么方式来调用我们的采集脚本
- 手动埋点：SDK 需要封装一个方法给业务方进行调用，传参方式业务方可控
- 无埋点：考虑到数据量对于服务器的压力，我们需要对无埋点进行开关配置，可以配置进行哪些5元素进行无埋点采集
- 用户标识：游客用户和登录用户的采集数据怎么进行区分关联
- 设备Id：用户通过浏览器来访问 web 页面，设备Id需要存储在浏览器上，同一个用户访问不同的8业务方网站，设备Id要保持一样，怎么实现
- 单页面应用：现在流行的单页面应用和普通 web 页面的数据采集是否有差异
- 混合应用：app 与 h5 的混合应用我们要怎么进行通讯
一般采集的 用户打开数量 参与量 停留时长 跳出率 退出率...
- 手动埋点（代码埋点）
手动代码埋点比较常见，需要调用埋点的业务方在需要采集数据的地方调用埋点的方法
- 命令埋点，前端代码中需要监控的地方插入监控逻辑
// 页面加载时发送埋点请求 $(document).ready(function(){ // ... 这里存在一些业务逻辑 sendRequest(params); }); // 按钮点击时发送埋点请求 $('button').click(function(){ // 这里存在一些业务逻辑 sendRequest(params); });
优点：控制发送数据时间，事件自定义属性详细记录
页面加载传参给后台记录，按钮点击传参给后台记录 ........
2. 声明式埋点
在dom元素上增添埋点信息，如下
// key表示埋点的唯一标识；
act表示埋点方式
<button data-stat="{key:'111', act: 'click'}">埋点</button>
遍历dom树，找到[data-stat]元素的节点，绑定click事件，
将[data-stat]上的信息发送给服务器
缺点： 1.遍历DOM树的时机问题，一个简单的例子，一个表格的行数据是通过异步加载，而表格行中的操作按钮需要埋点，那么在DOM ready的时候去遍历，显然是无法找到的 2.绑定埋点事件次数的问题，怎样保证埋点事件不会被重复绑定到元素上，一次操作发了N个埋点请求 重复工作很多，还要处理冒泡。
- 可视化埋点
利用可视化交互手段，通过可视化界面配置控件操作与事件操作发生关系。通过后台截屏的方式采集数据。 可是化埋点是近今年的埋点趋势，很多大厂自己的数据埋点部门也都开始做这块。通过埋点配置后台，将元素与要采集事件关联起来，可以自动生成埋点代码嵌入到页面中。
优点：成本低，速度快
缺点：行为记录信息少，支持的分析方式少，技术上推广和实现起来有点难（业务方前端代码规范是个大前提）
- 无埋点
无埋点则是前端自动采集全部事件，上报埋点数据，由后端来过滤和计算出有用的数据
优点是 前端只要一次加载埋点脚本。无需埋点，方便快捷
缺点是 流量和采集的数据过于庞大，服务器性能压力山大，行为记录信息少，传输压力大
可以根据自己的业务内容确定埋点方案 如60%全埋点+40%手动埋点之类
