迄今为止，我尝试过三种埋点收集方案：
1.在业务接口内埋点，将埋点信息作为一个字符串，要求前段加在get或者post参数内，记录在服务器的接口访问日志上，每天将这份日志拷贝到统计服务器上，再对日志进行处理，实现日志的离线计算。
2.自定义埋点的数据结构，要求前段按照指定结构埋点，前端需要跨页面合并日志（实践证明隐患颇多），上传到指定的接口，记录临时文件内，每几分钟启动一次定时脚本消费临时文件并入库，用几分钟的延迟实现准实时。
3.自定义埋点的数据结构，要求前端在固定的节点上和页面的生命周期函数调用指定函数。上传到指定接口，记录在文件内，flume监视文件，做为消息队列的生产者，将消息推送到消息队列上，storm消费消息同时处理跨页面合并日志的问题，实时入库。
下面分析一下各个方式的利弊：
方案1
优点：这个是最简单的收集方式，不需要额外的支撑，用来做项目尝试阶段和初期的数据探查。
缺点：受制于业务变动，如果业务接口存在预加载，分步加载，接口复用，接口变动，缓存等情况会造成数据不准确。一个字符串传递的信息有限，无法实现复杂的统计。只能隔天离线计算。
方案2
优点：解决了方式方案中的接口依赖问题，再也不用追着后端问接口了，结构化的数据可以传递更多的数据。
缺点：前段需要构造一个日志生产和发送的底层，后端需要新的接口来收集，前段需要进行少量的预处理。日志有几分钟的延迟，不能满足实时推荐等需求。
方案3
优点：实时性好。免除了前段的预处理过程，每条日志只关联一个生命周期函数和节点事件，简单清晰，前端的同学都快激动地哭了。
缺点：引入的更长的处理流程和更多的组件，对集群的维护水平和服务器配置提出了更高的要求。
其中
方案1在全站都使用过。
方案2在wap和APP上使用过。
方案3目前在小程序和快应用上使用，其他的平台准备逐步迭代。