1、前言
开始正文前先介绍一下埋点的概念～，（熟悉的朋友可以略过）
前端埋点： 是一种手段，它的目的是上报相关行为数据，相关人员以数据为依据来分析产品在用户端的使用情况，根据分析出来的结果辅助产品优化、迭代。
BI：商业智能，公司内部做数据分析相关的部门。
2、背景
在流量红利逐渐消失的现在，数据的采集、分析和精细化的运营显得更加重要，所以埋点的需求在互联网产品中是很常见的，目的上面也提到了。我们的追求就是又快又好的做好埋点工作，但是现实却不那么美好；目前我们团队在前端埋点方面存在一些痛点：
在构造埋点字段的时候需要根据 BI 的规则，把4，5个字段构造成一个。这样费时费力还有错误的风险；
一些曝光场景下的点不好打比如：分页列表、虚拟列表；他们的的曝光埋点实现较为繁琐；
逻辑复用问题：特别是曝光相关的点需要在业务代码里面做额外的处理，所以逻辑复用比较弱；
所以我们需要一种适合我们的埋点方案解决我们目前的问题，提升我们的开发效率、获得感，不再为埋点而困扰
3、常见前端埋点方案
我们对目前市场上几种埋点方案进行了一些调研，常规有3种方案：
手动代码埋点：用户触发某个动作后手动上报数据
优点：是最准确的，可以满足很多定制化的需求。
缺点：埋点逻辑与业务代码耦合到一起，不利于代码维护和复用；
可视化埋点：通过可视化工具配置采集节点，指定自己想要监测的元素和属性。核心是查找dom然后绑定事件，业界比较有名的是 Mixpanel
优点：可以做到按需配置，又不会像全埋点那样产生大量的无用数据
缺点：比较难加载一些运行时参数；页面结构发生变化的时候，可能就需要进行部分重新配置
无埋点：也叫“全埋点”，前端自动采集全部事件并上报埋点数据，在后端数据计算时过滤出有用数据
优点：收集用户的所有端上行为，很全面
缺点：无效的数据很多、上报数据量大
4、方案选择
在调研完这些方案后，我们认为上述方案并不完全适合我们，我们需要的方案是把之前不好打，不能打的点给打上。同时也要把埋点的代码与业务逻辑解耦，而且我们的mobile站可以相对平滑的迁移到我们新的埋点库上面来。结合我们目前埋点现状和运营、产品侧的需求我们决定采用 声明式的组件化埋点 + 缓冲队列 方案，走一条适合我们自己的路; 这里说一下我们的思路。
为了处理埋点代码与业务逻辑耦合的问题，我们认为可以在视图层做掉，埋点抽象可以归纳为两大类，点击与曝光。我们可以抽象出两个组件分别处理这两种场景。
在一些场景下快速滑动、频繁点击会在短时间打出大量的点，造成频繁的接口调用，这在mobile端是要避免的，针对这种常见的场景我们引入了缓冲队列，针对不同类型的点应用对应的上报频率
目前对于一些字段采用的是人工拼接，比如 BI 定义的_mspm2等字段，类似这种我们完全可以在库统一处理，既不容易出错，也方便后期拓展。
对于页面曝光，我们约定在埋点库的初始化的配置文件中定义 viewstart、viewend 后，埋点库会自动注册关于页面曝光的相关事件，不需要我们再去考虑。
以页面为维度管理埋点数据，一是这样更加清晰便于管理、二是我们之前也是这样管理的，迁移成本更小。
5、开发
5.1 流程梳理
整个埋点库大致的工作流程；
view： 在写jsx的时候，用相应的埋点组件 TrackerClick、TrackerExposure 包裹需要打点
8080
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
