前端埋点笔记

现有埋点三大类型   

手动埋点(代码埋点)   可视化埋点  无埋点

思考几个问题：

1.  采集什么数据
2. 业务方通过什么方式来调用我们的采集脚本
   
3. 手动埋点：SDK 需要封装一个方法给业务方进行调用，传参方式业务方可控
   
4. 无埋点：考虑到数据量对于服务器的压力，我们需要对无埋点进行开关配置，可以配置进行哪些5元素进行无埋点采集
   
5. 用户标识：游客用户和登录用户的采集数据怎么进行区分关联
   
6. 设备Id：用户通过浏览器来访问 web 页面，设备Id需要存储在浏览器上，同一个用户访问不同的8业务方网站，设备Id要保持一样，怎么实现
   
7. 单页面应用：现在流行的单页面应用和普通 web 页面的数据采集是否有差异
   
8. 混合应用：app 与 h5 的混合应用我们要怎么进行通讯
   

一般采集的  用户打开数量 参与量 停留时长 跳出率 退出率...

• 手动埋点（代码埋点）

手动代码埋点比较常见，需要调用埋点的业务方在需要采集数据的地方调用埋点的方法

1.  命令埋点，前端代码中需要监控的地方插入监控逻辑

     // 页面加载时发送埋点请求
   $(document).ready(function(){
    // ... 这里存在一些业务逻辑
    sendRequest(params);
   });
   // 按钮点击时发送埋点请求
   $('button').click(function(){
      //  这里存在一些业务逻辑
      sendRequest(params);
   });
   复制代码

优点：控制发送数据时间，事件自定义属性详细记录

页面加载传参给后台记录，按钮点击传参给后台记录 ........

2. 声明式埋点

在dom元素上增添埋点信息，如下 

// key表示埋点的唯一标识；

act表示埋点方式

 埋点 

遍历dom树，找到[data-stat]元素的节点，绑定click事件，

将[data-stat]上的信息发送给服务器  

缺点： 1.遍历DOM树的时机问题，一个简单的例子，一个表格的行数据是通过异步加载，而表格行中的操作按钮需要埋点，那么在DOM ready的时候去遍历，显然是无法找到的 2.绑定埋点事件次数的问题，怎样保证埋点事件不会被重复绑定到元素上，一次操作发了N个埋点请求 重复工作很多，还要处理冒泡。

• 可视化埋点
  

利用可视化交互手段，通过可视化界面配置控件操作与事件操作发生关系。通过后台截屏的方式采集数据。 可是化埋点是近今年的埋点趋势，很多大厂自己的数据埋点部门也都开始做这块。通过埋点配置后台，将元素与要采集事件关联起来，可以自动生成埋点代码嵌入到页面中。

优点：成本低，速度快 

 缺点：行为记录信息少，支持的分析方式少，技术上推广和实现起来有点难（业务方前端代码规范是个大前提）

• 无埋点

无埋点则是前端自动采集全部事件，上报埋点数据，由后端来过滤和计算出有用的数据

优点是 前端只要一次加载埋点脚本。无需埋点，方便快捷 

缺点是 流量和采集的数据过于庞大，服务器性能压力山大，行为记录信息少，传输压力大 

可以根据自己的业务内容确定埋点方案 如60%全埋点+40%手动埋点之类

自己学习的时候记录的笔记，仅供自己学习

转载于:https://juejin.im/post/5c63d74951882562993857ec