认识达内从这里开始

埋点是许多企业在做数据收集和数据分析的时候会经常用到的一个方法，而本文我们就通过案例分析来简单了解一下，常见的前端埋点方法都有哪些类型。

1、前言

前端埋点：一种收集产品数据的方式，它的目的是上报相关行为数据，相关人员以数据为依据来分析产品在用户端的使用情况，根据分析出来的结果辅助产品优化、迭代。

2、背景

在流量红利逐渐消失的现在，数据的采集、分析和精细化的运营显得更加重要，所以埋点在互联网产品中是很常见的，它可以更好的辅助我们去迭代、完善产品功能。

平时我们在完成基础的业务需求之后，还需要开发完成埋点需求。所以我们追求的是简单快捷的做好埋点工作，且不会占用我们太多的精力。但是现实却不那么美好，目前我们团队在前端埋点方面存在一些痛点：

在构造埋点字段的时候需要根据BI的规则，把若干个字段拼接成一个，这样费时费力还有错误的风险;

一些曝光场景下的点不好打比如：分页列表、虚拟列表;他们的的曝光埋点实现较为繁琐;

逻辑复用问题：特别是曝光相关的点需要在业务代码里面做额外的处理，所以逻辑复用很困难，对现有代码的侵入也很严重;

所以我们需要一种适合我们的埋点方案解决我们目前的问题，提升我们的开发效率，不再为埋点而困扰。

3、常见前端埋点方案

我们对目前市场上几种埋点方案进行了一些调研，常规有3种方案：

手动代码埋点：用户触发某个动作后手动上报数据

优点：是准确的，可以满足很多定制化的需求。

缺点：埋点逻辑与业务代码耦合到一起，不利于代码维护和复用。

可视化埋点：通过可视化工具配置采集节点，指定自己想要监测的元素和属性。核心是查找dom然后绑定事件，业界比较有名的是Mixpanel

优点：可以做到按需配置，又不会像全埋点那样产生大量的无用数据。

缺点：比较难加载一些运行时参数;页面结构发生变化的时候，可能就需要进行部分重新配置。

无埋点：也叫“全埋点”，前端自动采集全部事件并上报埋点数据，在后端数据计算时过滤出有用数据

优点：收集用户的所有端上行为，很全面。

缺点：无效的数据很多、上报数据量大。

4、埋点方案

在调研完这些方案后，我认为上述方案并不完全适合我们，我们需要的方案是准确、快速埋点，同时把埋点的代码与业务逻辑解耦，并且我们的音街移动站可以相对平滑的迁移到我们新的埋点库上面来。结合我们目前的技术栈React，以及现状和运营、产品侧的需求我们决定采用声明式的组件化埋点+缓冲队列方案，这里阐述一下我们的大致思路。

为了解决埋点代码与业务逻辑耦合的问题，我们认为可以在视图层处理，埋点可以归纳为两大类，点击与曝光埋点。我们可以抽象出两个组件分别处理这两种场景。

在一些场景下快速滑动、频繁点击会在短时间打出大量的点，造成频繁的接口调用，这在移动端是要避免的，针对这种场景我们引入了缓冲队列，产生的点位信息先进入队列，通过定时任务分批次上报数据，针对不同类型的点也可以应用不同的上报频率。

目前对于一些字段采用的是人工拼接，比如BI定义的_mspm2等相关通用字段，类似这种我们完全可以在库统一处理，既不容易出错，也方便后期拓展。

对于页面级曝光，我们可以在埋点库初始化后自动注册关于页面曝光的相关事件，不需要使用者关心。

以页面为维度管理埋点配置

我们的站点是同构应用，跟我们的架构比较契合

更加清晰，便于维护

目前也是采用这种方案管理，迁移成本会更小

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei456学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。