一二八、小程序埋点方案

一. 常用前端埋点方案总结

1. 代码埋点

嵌入代码的形式进行埋点，比如需要监控用户的点击事件，会选择在用户点击时，插入一段代码，保存这个监听行为或者直接将监听行为以某一种数据格式直接传递给server端。此外比如需要统计产品的PV和UV的时候，需要在网页的初始化时，发送用户的访问信息等。

优点
灵活，精准。可以在任意时刻，精确的发送或保存所需要的数据信息。
比较方便地设置自定义属性、自定义事件，传递比较丰富的数据到服务端。

缺点
工作量较大，每一个组件的埋点都需要添加相应的代码
不易维护管理

2.可视化埋点

通过可视化交互的手段，代替代码埋点。将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。例如：GrowingIO、

可视化埋点实际上是用一个系统来实现手动插入代码埋点的过程。

优点
埋点只需业务同学接入，无需开发支持
解决了代码埋点的工作量大和更新代价大问题

缺点
无法做到自定义获取数据，可视化埋点覆盖的功能有限
开发周期长，难度大

3. 无埋点

前端的任意一个事件都被绑定一个标识，所有的事件都记录下来。上传记录文件，配合文件解析，解析出来我们想要的数据传递给server端。

比如从页面的js代码中，找出dom上被绑定的事件，然后进行全埋点。

优点
由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象
减少了沟通成本

缺点
无埋点采集全量数据，给数据传输和服务器增加压力
无法灵活的定制各个事件所需要上传的数据

4. 配置化埋点

结合无埋点+代码埋点，通过配置文件或者特定标示指定需要埋点的元素或者方法，当定位到用户点击的元素或者执行的方法在配置文件中则上传埋点。

优点
可灵活的定制各个事件所需要上传的数据
减轻服务器压力
维护成本低

缺点
需求开发支持配置

二. 配置化埋点实现思路

监听用户点击–>读取埋点配置JOSN或者自定义埋点标识，判断是否需要上报–> 调用上报方法上报数据

1. 小程序监听用户点击行为
   小程序监听页面点击，用户的点击行为都会执行elementTracker方法,通过事件冒泡的方式捕获。
2. 判断点击位置是否落在监听元素中或者读取是否有特定标示
   swan.createSelectorQuery获取当前页面元素信息，selectAll(element)获取配置的元素

通过捕获到的元素长宽，定位和点击位置坐标判断是否出现重叠，以判断是否被点击。

3. 通过配置表声明埋点
   通过配置表的方式将所有埋点信息统一管理，除了方便管理，以后还可以做到自定义配置，或者服务端配置下发到小程序中做动态配置。

4. 对页面方法函数埋点
   除了对页面元素点击埋点，页面函数有些也需要埋点，例如用户下拉刷新的时候，通过配置methodTracks,匹配到配置的函数是进行埋点上报。

遍历当前page中的方法对其包装，执行完成后调用methodTracker判断该方法是否在配置中，如果是则上传埋点

参考文章：
如何搭建一套 “无痕埋点” 体系？
小程序埋点实现