前言
本文仅个人学习总结
- 埋点类型介绍
- 可视化埋点介绍
- 实现方案功能拆分
- 埋点方案对比
- 总结
埋点类型介绍
- 代码埋点:代码埋点主要指在业务代码的事件中增加埋点请求,需要开发人员在代码中植入请求
- 可视化埋点:可视化埋点主要是指提供可视化界面,在指定页面元素上增加埋点事件
- 无埋点:无埋点也叫做全埋点,收集页面上所有控件的信息,在后台进行筛选
可视化埋点介绍
可视化埋点从体验上来说,就是在自己的后台管理页面介入第三方的页面,提供一个可视化的编辑器,能对某些类型的元素,如a链接,button或者是带有click的事件的元素进行特殊处理,当此类元素被点击时,可以出现填写埋点配置的表单,在配置完成后,正常去访问第三方页面,当这些元素被点击触发,即可收集到埋点信息
方案功能拆解
-
SDK植入:
SDK植入的形式介绍 沿用了市面上比较常见的动态插入script标签
-
后台页面输入url:
开关的实现,从后台进入可以编辑的页面中时,向storage中写入参数, 在SDK内部判断storage里的一个标志参数,来决定是否开始编辑器 读取到后加载编辑器,目的是为了安全性考虑 防止web应用被人随意埋点,产生数据干扰
-
标记元素+保存配置:
体验上来说,鼠标经过可以被点击的元素时,元素会被高亮显示,点击时,弹出信息窗口,设置参数,保存
技术上来说,使用了mousemove的事件监听,对三类元素进行高亮 a button 带有click事件的元素 点击时 获取唯一元素路径
getUniqueSelector = function (e, t) { let selector = getSelector(e) if (selector.indexOf('#') != -1 || getTagName(e) === 'body') { t && (selector = selector + ">" + t); return selector } else { selector += ":eq(" + getIndexInParent(e) + ")" t && (selector = selector + ">" + t); return getUniqueSelector(getParent(e), selector) } }如何获取唯一路径的实现方案是采用了jq的选择器的思路
记录了从body到这个元素的完整路径,并且要记录每一个节点是其父元素的第几个亲儿子节点,直观的的讲就是一个记录了这个元素的在dom树中的深度和下标
保存配置上的话就比较简单,存贮配置的参数和这条完整的元素路径
配置下发的样例
[ { "event_name": "hello链接点击", "url": "http://localhost:63342/sa-sdk-javascript/zhuge.html?_ijt=hg3r25mmicg2icf0jtndtaskh7#", "element": [ "body>a:eq(0)" ], "attr": [ { "name": "自定义属性", "selector": "body>p:eq(0)" } ], "app_id": 56070, "platform": 3, "create_date_time": "2017-12-22 16:25:29", "hidden": false, "stop": false, "alias_name": null, "edit_url": "http://localhost:63342/sa-sdk-javascript/zhuge.html?_ijt=hg3r25mmicg2icf0jtndtaskh7#" } ]
4.解析配置+监听上报
即在可视化编辑器关闭的状态或者说正常访问站点的情况,拿到之前配置好的,用来查找元素并增加事件监听,基于一个加载速度的优化考虑,我这边没有引入jqeury,所以将原先的选择器会转化一遍,生成可以让原生querySelector查找的,对原先的元素再增加事件,发送埋点触发的请求,监听上报 采用了iframe的方式 解决跨域无法获取cookie内的参数
- 总结
在js实现上来说,可视化埋点实现还是不难的,主要的要点是实现元素路径的标记获取和解析,它的缺点是在于dom元素结构发生变化后,埋点则会失效,而且可视化埋点并不会去关注上下文或者业务逻辑,只关注元素行为是否被触发,所以其核心在于能便于非开发员配置点位,功能上代码埋点和全埋点都可以对其进行覆盖