背景
关于埋点，作为用户行为过程数据采集的一种方式，被广泛用于各公司的站点中。它不仅可以收集页面浏览量，还能对访问用户的时间、地点、操作路径等用户行为进行多维度记录。通过这些数据，可以更好得了解用户的使用习惯，并根据用户的行为习惯来优化业务流程，为用户提供更优质的服务。
埋点的重要性毋庸置疑，每个公司都会搭建自己的一套埋点体系来服务业务。由于业务的分离及管理等原因，甚至公司内不同产品线和平台也会有各自的埋点体系。一个埋点体系包含前端或服务端发送、数据清洗、数据分类及数据查询统计等流程。目前公司内部就有多个埋点系统，分别面向58与安居客，不同埋点系统的埋点接入方式也有差别。
随着部门垂直业务的调整，部门内运营活动需要在公司内多平台同时上线，而不同的平台的埋点类型是不同的，同平台APP与WEB的埋点类型相同，而发送方式也有可能是不同的，这就导致同一个运营活动页面在不同平台需调用不同类型埋点的SDK文件，并调用不同的埋点方法。接下来主要从前端角度对多平台（1）多类型（2）埋点的接入方式的统一进行的一次实践。
名词解释：
（1） 多平台：指公司业务（58、安居客）展现的不同端（APP、M、PC等）
（2） 多类型：指公司内不同的埋点系统（58埋点系统、安居客埋点系统等）
导致问题
1、学习及开发成本高 开发人员想在一个页面上加入多种类型的埋点，首先需了解所有埋点类型的接入方法和埋点发送方法，还要了解每个埋点类型的参数设置类型，无疑学习成本是很大的。
页面开发时，开发者想要在一个页面实现多种埋点类型的发送，引入埋点sdk文件有两种方法：
1） 在开发时将所有类型埋点相应sdk文件提前引入，但会增加不同平台页面必要加载文件数量；
2） 判断平台进行动态引入sdk文件，但需要平台及环境的一个判断方法，开发成本高；
在业务事件中调用相应的埋点发送方法进行埋点的发送时，也需要进行平台及环境的判断，虽然判断方法可以提取出来，但不同项目支持环境不同时，判断条件也会不一样，跨项目无法完全复用。2、埋点与业务耦合，维护困难 由于活动页面中的埋点以点击埋点为主，埋点的开发方式也是在业务事件函数中进行手动埋点。多类型埋点开发时，首先要对平台及端进行判断，然后调用对应类型埋点的方法。由于方法及参数都不相同，页面埋点过多就会造成代码比较混乱。无论是新增还是修改埋点参数，都需要去业务代码中查找维护，非常困难。 3、多类型埋点测试困难 一个平台内埋点测试流程是：测试人员根据业务流程对页面进行操作，同时对发送的埋点参数进行验证，多个页面关联的时候，流程走一遍就需要几十分钟甚至一两个小时，而多平台多类型埋点更是需要走多遍流程，埋点测试耗时长。4、埋点测试数据无法验证正确性 由于测试环境埋点数据量大，且对于分析用户行为无意义，因此测试环境的埋点数据会被清洗，数据组想要对项目的埋点数据进行统计分析，只有等项目上线后才能进行，而有些埋点参数错误也只有等项目上线后才能被发现，哪怕此时修正也会有部分数据无法正常统计到最后结果中，无疑增加了数据统计风险。
方案设计
基于以上几点问题，我收集了前端组不同项目的埋点需求，整理了单类型埋点发送流程的八个步骤：
1） 产品报备埋点，并将报备数据给到相应开发及数据人员；
2） 前端了解此类型埋点加载及发送方法；
3） 开发页面引入相应sdk文件；
4） 配置此类型埋点所需必要参数；
5） 在相应业务事件中加入埋点发送方法；
6） 开发完成，埋点测试；
7） 项目上线，埋点数据统计分析；
8） 埋点维护。不同类型埋点流程可能存在步骤3与步骤4颠倒的情况。
从以上单埋点发送流程可以看出，步骤1由产品人员执行，步骤2-5以及步骤8由前端开发人员执行，步骤6由测试人员执行，步骤7由数据人员执行。如果页面有N种类型埋点的发送，那就需要重复所有步骤N遍。
要提升多类型埋点发送过程的开发效率，首先要从前端开发人员的步骤入手：
1） 首先要解决对于平台及环境的自动识别问题，同时需要一个埋点分发层根据环境及配置动态加载对应类型埋点SDK文件；
2） 其次要解决埋点与业务耦合严重，埋点难维护的问题，需要将埋点配置及业务埋点数据与业务代码分离开；
3） 想要保持业务代码的整洁以及开发人员的学习成本，还需要对不同类型埋点的初始化和发送方法进行统一；
4） 另外要解决埋点测试耗时问题与测试环境埋点正确性验证问题，还需要一个线上页面，可以根据埋点配置文件自动生成。
基于以上几点思考，多类型埋点接入方案整体设计如下图所示。
方案设计图
1、埋点解耦 无论想提升埋点的可维护性，还是统一多类型埋点的调用方法，都需要将埋点进行分离，并设计统一配置格式。而每一种类型的埋点数据都可分为初始配置和业务埋点发送数据两种，初始配置具有公用性，参数可能会变化（例如城市信息），埋点发送数据具有单一性，且参数大部分不变，我们将其分开配置，便于开发人员理解与管理。
1） 埋点初始配置设计
不同类型的埋点配置字段是不相同，而且差距非常大，我们无法将这些配置字段进行统一，因为这些字段在埋点申报时对应的含义完全不同，因此为了便于理解，此部分的字段名称保持原名称及含义，只不过将关键字段抽离出来放到对应类型的配置字段中。
A：xxConfig：将不同类型埋点（xx）关键设置参数分离出来，作为一个配置字段。例如有埋点类型为wb，那此字段为wbConfig，内容包含wb类型埋点的所有必要配置，json格式。例如：有A类型埋点，对应的关键参数为a1，a2，则我们需要在此进行设置：
多种埋点类型则对应多个此种参数；
B、commonParam：公参配置字段，会带入所有埋点自定义参数中。例如来源参数from；
C、trackHost：平台发送埋点类型自定义字段，假如目前有两个平台M和N，那么我们可以配置平台M发送A类型，平台N发送B类型，如果单平台支持发送多类型埋点，亦可同时配置。
D、autoShow：是否自动展现埋点，默认为true；
这些字段就组成一个大的埋点配置json文件trackConfig。以支持A、B两种埋点类型为例：
2） 业务埋点数据设计 为了业务埋点数据的配置与业务分离开，也需要对业务埋点数据格式进行统一设计。想要一次调用可以在不同环境发送不同类型的埋点，就要以埋点业务为维度进行区分。单个业务埋点中可能包含一个或多个类型埋点的数据，并以唯一key作为与业务事件耦合的标志。单个业务埋点数据设计，具有唯一key值（json格式）
A、xx：将不同类型埋点（xx）发送参数分离出来，作为一个配置字段。例如有埋点类型为wb，那此字段名为wb，内容包含wb类型埋点的所有埋点参数，json格式。例如：此业务埋点需支持A类型埋点的发送，A类型埋点的主参数为aa等，并加入自定义字段param。我们可以这样配置：
多种埋点类型则对应多个此参数；
B、desc：单个埋点描述字段 ；
假如有业务埋点——banner点击，以支持A、B两种埋点类型为例：
多个埋点数据组成一个大的埋点数据json文件tracklogs。 2、埋点插件 有了上边的两个埋点文件后，接下来设计开发了一个埋点插件，充当埋点分发层的职责。不同类型埋点的初始化及发送方法各不相同，而我们想要做统一，就需要将各类型埋点的方法做统一处理，根据埋点的流程，我将不同类型埋点作为抽象类，并对外抛出相同的三个方法：config()、show()、send()，而整个插件也是对外抛出这三个方法。原理如下图：
插件原理图
整个埋点插件在不同平台发送埋点的类型是由当前平台及trackHost中设置的对应埋点类型来决定的，那么页面初始化的时候首先需要一个平台及环境的判断，部门正好有公用插件（Flib）具有此功能，因此我们将此埋点插件与Flib结合在一起，动态加载所需的埋点sdk文件，并进行初始化。这样开发人员无需关心环境及加载sdk问题，也无需关心调用不同发送方法及传参问题，统一调用sendLog方法，并将埋点数据文件中的一个埋点（例如bannerClick）作为参数即可。与flib结合后的插件整体的流程如下图所示：
分发层插件原理
而且再有其他类型的埋点接入，只需要插件中定义此埋点类，抛出统一的config()、show()、send()方法就可以了。 3、埋点测试 针对埋点测试的问题，我开发了一个埋点测试生成页面（如下图），此页面可以根据独立出来的埋点文件trackConfig与tracklogs，自动生成适用于不同平台的测试页面链接及二维码，便于测试人员在不同平台进行测试。
页面的生成原理是这样的：将埋点文件储存在缓存服务器中，设置30分钟有效，并生成对应key值，放入测试页面链接的url中。测试页面通过此key值可取得对应的埋点配置文件内容，以及对应的插件生成埋点测试页面。
埋点测试生成页
点击链接或移动端扫码可以进入一个测试页面（如下图），测试页面会根据设置的埋点数据生成对应的按钮，点击可以发送对应平台类型的埋点。由于这个页面是线上页面，所有这些埋点在项目上线之前就可以进行测试，有问题也可以在上线前进行修正。为了提升测试效率，还增加了“一键发送所有”功能，在页面埋点过多时，可以大大提升测试人员的埋点测试效率。
埋点测试页
总结
多平台埋点接入方案目前已在本部门前端十多个项目中运用，对埋点开发及测试效率都得到较大提升。目前埋点接入流程中比较费时的节点就是由产品给出的埋点文档转换为埋点开发文件的过程，后续会开发相应页面进行自动转换。
3290
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
