前言背景

在前端页面的开发过程中，埋点不仅是获取用户行为数据的关键途径之一，也是产品优化和决策制定的重要依据。随着埋点需求的逐渐增多，保证埋点的正确性和完整性是我们需要解决的一个问题。

历史测试方案

在古茗以往的前端开发实践中，埋点测试的常见方式是通过查看抓包工具中的请求数据或上线后的埋点日志，来与产品文档进行比对。这种方法的好处是直观，但问题也显而易见：

人工比对易出错：手动检查难免会出现大小写错误、字段遗漏等问题，导致数据不可用。测试流程繁琐：埋点测试往往是后置流程，且如果代码有变动，很容易忘记进行回归测试。

为了解决这些问题，我们希望通过实时校验埋点数据来提升测试效率和准确性。在确定方案之前，我们调研了几款常见的埋点工具，看看它们是如何解决这个问题的。

常见埋点工具的测试流程微分析

在小程序中，微分析提供了一种简单便捷的测试方式；在添加埋点代码后，点击上报列表中的测试按钮并选择被测试者的微信号即可开始测试。测试结果会在一分钟内显示，并标注错误数据。

缺点：

阿里云的QuickTracking支持App、小程序和Web端的埋点验证。通过扫码或修改验证页面URL，即可快速建立点对点链接进行测试。同时QuickTracking还能生成一份验证报告，查看埋点是否有错误等信息，快速定位错误的埋点。

缺点:神策

神策支持Debug模式，能够实时查看埋点数据，并根据来源、应用版本、事件名进行检索。在官方文档中，仅有服务端和App的Debug模式的开始方式，服务端需要手动修改代码传入参数，App则是需要开启调试模式并扫码二维码配对设备。

缺点：埋点测试方案

在古茗的开发实践中，埋点场景多，涵盖了PC页面、H5页面、小程序、电子菜单、POS等。不同设备的操作方式不同，比如电子菜单无法扫码、POS无法替换链接等。为了统一测试流程，减少开发和测试的心智负担，我们制定了以下方案：

关联测试设备：

因为是内容工具，因此可以确定每次上报时都有通用的字段可以用来区分使用人、店铺等；因此可以参考微分析，通过选择userId、sessionId、shopId等字段，并输入对应的值来关联设备/测试人。

实时数据分析：

参考神策的方案，实时展示埋点信息，并对异常埋点进行提示。

实时通信埋点数据

确定了测试交互之后，接下来需要解决的问题就是如何去解决“实时”的问题。

web页面的前端和后端服务的通信自然是通过websocket来进行通信，但是web的后端服务如何获取需要实时查看的埋点信息是一个问题。

从我们可以知晓，现流程所有的埋点都会过kafka再对数据进行分流，后面不同的应用来监听kafka的消息，我们可以仍旧复用这个流程，但是通过消费kafka再推送埋点数据给前端会有几秒至几小时的延迟，这对于实时的埋点测试是不可接受的，我们期望从客户端上报的数据可以实时的展现到前端的界面上。

考虑到测试时的流量其实非常小，我们的解决方案与神策的Debug逻辑类似，需要实时查看的埋点不再走kafka的流程，而是gateway直接将对应埋点的信息传递给 web 页面的 后端服务，再由后端服务处理需要检查的埋点并返回前端，因此整体流程如下 ：

指定测试服务

在本地测试环境下，这样的一个流程已经可以闭环了，但是实际的生产环境中，我们的每个服务都不是单台的机器，同时每个服务也会启用多个进程；而建立websocket时，我们只对某个机器的某个进程进行了连接，因此当我们开始埋点测试时，除了需要测试的id等元数据还需要将当前服务的ip、端口与进程号等一起发送消息，埋点网关收到需要测试的埋点时，也同样往对应的服务发送消息。

当埋点后端服务接口到网关发送的消息后，会向所有的进程广播测试消息，每个进程都会判断当前的测试消息的进程号是否匹配，若匹配才会向对应的 web页面 发送测试结果。

总结

不同的业务场景可能导致埋点测试实现的差异。我们的解决方案并不一定比神策或微分析更好，但在古茗的场景下，已经能够有效地提升埋点测试的效率和准确性。感谢这些平台为我们提供了宝贵的思路，帮助我们更好地应对前端埋点的挑战。