在前端埋点的世界中 是一个体系化的工程,不仅仅担任着对用户行为的准确采集,还要涉及到,对于
为什么做这个项目呢? 传统埋点本身有些弊端,比如像是这个容易漏埋,还有这个错埋点 那么具体是怎么解决这个传统埋点的弊端点呢
埋点是一个体系化的一个工程,单纯一个代码埋点,是无法满足日益复杂的埋点需求的,也无法高质量的收集用户的一个行为数据,尤其在ai时代, 有一个高质量的数据反馈集,是非常重要的, 有了这个可视化埋点补充,并建立了完整的一个公司内的,埋点体系化 首先我们通过自动化埋点,也就是说我参与设计和开发的埋点sdk ,能满足绝大部分的,常规场景 其次,如果需要将功能点和具体的业务场景相绑定,更好的去辅助这个业务决策的时候,那么我就直接通过这个可视化绑定埋点,去解决,最后如果说对于一些复杂行为,这个时候,需要通过代码埋点进行一个兜底,涉及和服务端交互的,还可以配合服务端埋点进行补充,通过这些一些列操作,从而来解决和完善公司的一个埋点体系化.
如果想构建一个完整的一个圈选平台, 从架构层面来
- 一个是这个插件层面 1
- 一个是埋点收集3
- 埋点的圈选绑定,部署层2
从这个插件层,目的: 你想绑定一个埋点,首先得去定位到这个元素,同时还需要满足,稳定,不会随着迭代发生变化,对于同一个元素,其次我需要唯一,不能出现,一个项目中,出现了多个同样的元素,这样的化,就会导致绑定失效, 这一层至关重要,一旦不满足稳定和唯一,就会导致后续绑定工作的返工和错误 我的思路: 传统思路是通过一个叫Xpath的一个技术, 本质上是通过dom等层级路径,来表示,但是很不稳定,稍微变更相对位置,就变化,因为我调研通过这个babel jscodeshift 这一类编译工具,初始的方案我通过这个编译期,获取当前组件的一些属性信息,但是初版接入测试发现,开发者属性的编写,存在不定,难以统一,并且存在一些边界,难处理,因此再思考,从本质上来讲,既然要的是唯一,那么我就去通过这个编译期直接生成短随机id,直接覆写到源代码中,也方便开发者进一步的扩展, 这里涉及到一个技术选项, babel 本质上,是遵循向后兼容,也就是不关注之前的逻辑,所以并没有保留原始代码的位置信息, 因此我采用jsocodeshfit 这种集合风格,同时还保留了原始代码分格,非常便于开发者接入,规避掉很多无效diff代码,提升了接入效率和质量
然后我从这个埋点收集,因为当我圈选了我想要去绑定的具体元素,并且想要将其绑定到这个元素位置信息上,那么我就需要进行功能点和,业务属性的一个绑定, 这里会涉及到这个 圈选sdk 以及平台侧和sdk之间的一个通信的问题. 当绑定完毕后,在通过部署,也支持即时验证,可反向高亮展示已绑定的元素,的各种信息. 也支持即时修正编辑重部署,相比于纯代码埋点,必须进行验证,发版,反馈更加即时和灵活
最后当绑定成功后,会涉及到后续的一个埋点上报,等功能,这块会涉及到,数据的采集层,清洗层,上报层 以上就是相关权限平台的一个完整的设计,开发等全流程
