埋点是很多公司在做数据收集和数据分析时经常使用的一种方法。常见的前端埋点方法都有哪些类型呢？主要有手动代码埋点、可视化埋点、无埋点这几种类型。

　　1.简介

　　前端埋点：一种采集产品数据的方法。 其目的是报告相关的行为数据。 相关人员以数据为依据，分析产品在用户端的使用情况，并根据分析结果辅助产品优化迭代。

　　2.背景

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

　　通常，我们在完成了基本的业务需求之后，还需要开发完成嵌入式需求。 所以我们追求的是简单快速的做好埋点工作，不会占用我们太多的精力。 但现实并非如此美好。 目前我们团队在前端埋点有一些痛点：

　　构建埋点字段时，需要按照BI规则将多个字段拼接为一个，费时费力，且存在出错风险；

　　一些暴露场景下的点不容易打字，比如：分页列表，虚拟列表; 它们的暴露埋点实施起来比较麻烦；

　　逻辑复用问题：尤其是曝光相关的点需要在业务代码中做额外的处理，所以逻辑复用非常困难，对已有代码的入侵也很严重；

　　因此，我们需要一个适合我们的方案来解决我们目前的问题，提高我们的开发效率，不再为埋点而烦恼。

　　3.常见的前端埋点方案

　　我们对目前市面上的几种埋点方案进行了研究，常规的方案有以下三种：

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

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

　　缺点：内嵌逻辑与业务代码耦合，不利于代码维护和复用。

　　可视化埋点：通过可视化工具配置采集节点，指定需要监控的元素和属性。 核心就是找到dom，然后绑定事件。 Mixpanel在业界比较出名。

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

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

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

　　优点：收集了用户所有端到端的行为，非常全面。

　　缺点：无效数据较多，上报数据量大。

　　4.掩埋方案

　　在研究了这些解决方案之后，我觉得上面的解决方案并不完全适合我们。我们需要的是准确快速的埋点，同时把埋点的代码和业务逻辑解耦，我们的银界手机站可以比较顺利的迁移到我们新的埋点库中。结合我们目前的技术栈React，以及运营和产品的现状和需求，我们决定采用声明式组件化埋点+缓冲队列的方案。这是我们的总体思路。

　　为了解决嵌入式代码与业务逻辑的耦合问题，我们认为可以在视图层进行处理。嵌入点可以分为两类，点击嵌入点和暴露嵌入点。我们可以抽象出两个组件来分别处理这两种场景。

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

　　目前部分字段采用手动拼接，如BI定义的_mspm2等相关公共字段。这类字段我们可以在库中统一处理，不容易出错，也方便后期扩展。对于页面级别的曝光，我们可以在埋点库初始化后自动注册页面曝光的相关事件，用户无需关心，以上是常见的前端埋点方法。