CN117632740A - 埋点检测方法、埋点管理方法、装置、计算机设备及介质 - Google Patents

Abstract

本申请涉及埋点检测技术领域，公开了埋点检测方法、埋点管理方法、装置、计算机设备及介质，本申请自动接收埋点事件抓取工具透传的多个埋点事件，并对所属项目版本为测试版本的埋点事件依据预设异常埋点校验规则进行自动校验。避免人工根据需求文档对埋点事件进行人工校验，大大提高了埋点检测的效率以及准确性。还可以及时向前端埋点系统发送异常埋点事件的上报状态，便于后续用户通过前端埋点系统查看异常的埋点事件，以及将异常埋点事件的未通过原因发送至异常埋点事件对应的用户终端，用户可以及时了解异常埋点事件的诱发原因，无需人工分析缩短用户发现问题的周期，用户体验友好。

Description

埋点检测方法、埋点管理方法、装置、计算机设备及介质

技术领域

本申请涉及埋点检测技术领域，具体涉及埋点检测方法、埋点管理方法、装置、计算机设备及介质。

背景技术

埋点是数据采集领域，尤其是用户行为数据采集领域的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。埋点后需要进行埋点检测，以判断埋点事件是否符合需求从而进行准确的用户行为分析。

常见的埋点检测的实现方式大多是测试人员根据需求文档判断埋点事件是否符合需求。对于与需求不相符的埋点事件，提交程序错误(bug)，提示研发人员进行修改，研发人员修改后测试人员再进行判断直至所有埋点事件符合需求。但是测试人员人工进行埋点检测的处理效率较低且容易出错。

因此，如何提高埋点检测的处理效率以及准确性已成为目前亟需解决的问题。

发明内容

有鉴于此，本申请提供了一种埋点检测方法、埋点管理方法、装置、计算机设备及介质，以解决如何提高埋点检测的处理效率以及准确性的问题。

第一方面，本申请提供了一种埋点检测方法，该方法由服务端执行，服务端与前端埋点系统通信连接，该方法包括：

接收埋点事件抓取工具透传的多个埋点事件，埋点事件包括事件名、属性名以及属性类型；

确定每一个埋点事件的所属项目版本；

针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果；

解析校验结果，确定校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件，校验未通过是指事件名、属性名以及属性类型中至少一者的校验为校验未通过；

将异常埋点事件的上报状态标记为异常，并发送至前端埋点系统，并将未通过原因发送给异常埋点事件对应的用户终端。

具体地，自动接收埋点事件抓取工具透传的多个埋点事件，并对所属项目版本为测试版本的埋点事件依据预设异常埋点校验规则进行自动校验。避免人工根据需求文档对埋点事件进行人工校验，大大提高了埋点检测的效率以及准确性。还可以及时向前端埋点系统发送异常埋点事件的上报状态，便于后续用户通过前端埋点系统查看异常的埋点事件，以及将异常埋点事件的未通过原因发送至异常埋点事件对应的用户终端，用户可以及时了解异常埋点事件的诱发原因，无需人工分析缩短用户发现问题的周期，用户体验友好。

在一些可选的实施例中，针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果，包括：

根据预设命名规则，分别对第一埋点事件的属性名以及事件名进行命名校验，得到第一校验结果，第一埋点事件为所属项目版本为测试版本的埋点事件中的任一个，预设命名规则包括属性名的命名规范以及事件名的命名规范；

根据预设字段表中埋点事件的属性名以及属性类型，对第一埋点事件的属性名与属性类型进行匹配校验，得到第二校验结果，第一校验结果以及第二校验结果组成第一埋点事件的校验结果，重复以上步骤得到所有所属项目版本为测试版本的埋点事件的校验结果。

具体地，基于预设埋点命名规则以及预设字段表中埋点事件的属性名以及属性类型，自动对所属项目版本为测试版本的埋点事件进行命名校验以及匹配校验，保证每一个埋点事件的命名以及属性名和属性类型均符合规定，无需人工进行埋点检测，提高埋点检测的效率与准确性。

在一些可选的实施例中，若校验结果中存在校验通过的第二埋点事件，方法还包括：

将第二埋点事件的上报状态标记为正常，并发送至前端埋点系统；

在事件库中查询与第二埋点事件匹配的历史埋点事件；

若事件库中不存在历史埋点事件，则将第二埋点事件存储至事件库中，并向第二埋点事件对应的用户终端发送用于指示第二埋点事件上报成功的信息；

若事件库中存在历史埋点事件，则将第二埋点事件存储至历史埋点事件所在的存储区域内。

具体地，如果服务端在事件库中搜索到历史埋点事件，就意味着第二埋点事件不是第一次入库，服务端会将第二埋点事件存储在事件库中历史埋点事件所在的存储区域内。实现了自动将校验通过的埋点事件存储入库，完成埋点事件的自动上报，还可以对第一次入库的埋点事件发送上报成功的信息至对应的用户终端，及时通知用户，用户体验友好。

在一些可选的实施例中，在解析校验结果，确定校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件之后，方法还包括：

向前端埋点系统发送未通过原因，以便于前端埋点系统在接收到异常埋点事件的未通过原因查看请求时，展示异常埋点事件的未通过原因。

具体地，用户可以通过前端埋点系统查看异常埋点事件的未通过原因，可以直接基于未通过原因对异常埋点事件进行修改。无需像传统流程那样人工先分析异常埋点事件的诱发原因，再提交bug报告后才能对异常埋点事件进行修改，节省人力的同时简化了埋点开发流程提高了开发效率。

在一些可选的实施例中，该方法还包括：

在第一预设时间段内，监测预获取的需求文档集合中第一需求文档中规定的所有埋点事件是否均存储至事件库中，第一需求文档为需求文档集合中的任一个需求文档；

若第一需求文档中规定的所有埋点事件均存储至事件库中，将第一需求文档对应的第一埋点需求的上报状态标记为正常，并发送至前端埋点系统，第一埋点需求包括第一需求文档中规定的所有埋点事件；

若第一需求文档中规定的所有埋点事件中存在至少一个埋点事件未存储至事件库中，将第一埋点需求的上报状态标记为异常，并发送至前端埋点系统。

具体地，自动检测需求文件中规定的所有埋点事件是否存储至事件库中，可以避免埋点事件的漏报问题。另外，标记埋点事件的上一级埋点需求的上报状态，使得埋点检测可以关注整个埋点需求的上报状态，对于用户而言也可以通过关注埋点需求的上报状态来迅速了解可能出现异常埋点事件的埋点需求，无需人工对埋点需求下的测试点进行分析，节省大量人力成本，用户体验友好。

第二方面，本申请提供了一种埋点管理方法，该方法由前端埋点系统执行，前端埋点系统与上述任一实施例涉及的服务端通信连接，方法包括：

响应于在第二预设时间段内对第二埋点需求的埋点检测请求，从服务端发送埋点事件的上报状态中，筛选在第二预设时间段内第二埋点需求下所有埋点事件的上报状态，埋点事件的上报状态为服务端基于如上述任一实施例的埋点检测方法确定的埋点事件的上报状态；

在埋点检测页面中展示在第二预设时间段内，第二埋点需求下所有埋点事件的上报状态。

具体地，前端埋点系统响应于埋点检测请求，用户就可以在埋点检测页面中看到在特定时间段内特定埋点需求下所有埋点事件的上报状态，无需用户人工确定埋点事件的上报状态，也无需人工从大量埋点事件中筛选特定时间段内特定埋点需求下的埋点事件，方便批量快速地管理埋点事件，用户体验友好。

在一些可选的实施例中，该方法还包括：

接收对第二埋点需求的埋点事件编辑请求，展示埋点事件的事件编辑页面；

接收对事件编辑页面中目标埋点组件的编辑操作，编辑目标埋点组件的值，目标埋点组件用于指示埋点事件的事件信息集合中的一者或属性信息集合中的一者，事件信息集合包括事件名、显示名、事件上报时机、需求类型、事件类型以及埋点端，属性信息集合包括属性枚举或者含义、属性类型、属性名以及属性显示名称；

接收事件编辑页面的提交请求，根据事件编辑页面中所有埋点组件的值，获取编辑的埋点事件，以便于后续服务端基于如上述任一实施例的埋点检测方法对编辑的埋点事件进行埋点检测。

具体地，在接收到对埋点需求的埋点事件编辑请求后，通过事件编辑页面即可方面用户对埋点事件的事件信息集合以及属性信息集合中的事件名以及属性名等信息进行编辑，并保证编辑的埋点事件可以参与埋点检测，方便用户对埋点需求下埋点事件的管理，还可以实现编辑后的埋点事件可以及时被埋点检测，提高埋点检测的效率。

在一些可选的实施例中，该方法还包括：

接收对第一项目的埋点需求查看请求，展示埋点需求状态页面，埋点需求状态页面中包括第一项目下的所有埋点需求的埋点需求信息，以及第一项目下每一个埋点需求的上报状态。

在一些可选的实施例中，在接收对第一项目的埋点需求查看请求，展示埋点需求状态页面之后，该方法还包括：

接收对埋点需求状态页面中第三埋点需求的查看请求，展示埋点事件列表，埋点事件列表包括第三埋点需求下所有埋点事件的事件信息集合，以及第三埋点需求对应的项目需求信息集合，项目需求信息集合包括项目名称、需求负责人、项目与事务跟踪地址、研发人员、需求名称、上线日期以及测试人员。

具体地，可以在埋点事件列表中展示特定埋点需求下的所有埋点事件以及埋点需求对应的项目需求信息集合，方便用户直观了解埋点需求下的埋点事件以及埋点需求的相关人员，用户体验友好。

在一些可选的实施例中，在埋点检测页面中展示在第二预设时间段内，第二埋点需求下所有埋点事件的上报状态之后，该方法还包括：

接收对埋点检测页面中第一异常埋点事件的未通过原因的查看请求，获取第一异常埋点事件的基础数据，基础数据包括埋点事件的所属工程信息、事件名、属性名、异常发生序号、详细数据以及事件异常时间；

从服务端获取第一异常埋点事件的未通过原因；

在异常数据查询页面展示在第一异常埋点事件的未通过原因以及基础数据。

具体地，在接收到对埋点检测页面中第一异常埋点事件的未通过原因的查看请求时，还可以向用户展示第一异常埋点事件的未通过原因以及包括所属工程信息以及事件名等的基础数据，避免人工从大量埋点事件中筛选并判断特定异常埋点事件的基础数据以及未通过原因，节省埋点检测的时间，还可以及时得到异常埋点事件的相关信息，省略传统埋点检测中测试人员提交bug的流程，提高埋点检测的效率。

第三方面，本申请提供了一种埋点检测装置，该装置由服务端运行，服务端与前端埋点系统通信连接，装置包括：

接收模块，用于接收埋点事件抓取工具透传的多个埋点事件，埋点事件包括事件名、属性名以及属性类型；

确定模块，用于确定每一个埋点事件的所属项目版本；

校验模块，用于针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果；

解析模块，用于解析校验结果，确定校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件，校验未通过是指事件名、属性名以及属性类型中至少一者的校验为校验未通过；

标记模块，用于将异常埋点事件的上报状态标记为异常，并发送至前端埋点系统，并将未通过原因发送给异常埋点事件对应的用户终端。

第四方面，本申请提供了一种埋点管理装置，该装置由前端埋点系统运行，前端埋点系统与第一方面任一实施例涉及的服务端通信连接，装置包括：

筛选模块，用于响应于在第二预设时间段内对第二埋点需求的埋点检测请求，从服务端发送埋点事件的上报状态中，筛选在第二预设时间段内第二埋点需求下所有埋点事件的上报状态，埋点事件的上报状态为服务端基于如第一方面任一实施例埋点检测方法确定的埋点事件的上报状态；

展示模块，用于在埋点检测页面中展示在第二预设时间段内，第二埋点需求下所有埋点事件的上报状态。

第五方面，本申请提供了一种计算机设备，包括：存储器和处理器，存储器和处理器之间互相通信连接，存储器中存储有计算机指令，处理器通过执行计算机指令，从而执行上述第一方面任一实施例埋点检测方法或第二方面任一实施例的埋点管理方法。

第六方面，本申请提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机指令，计算机指令用于使计算机执行上述第一方面任一实施例埋点检测方法或第二方面任一实施例的埋点管理方法。

附图说明

为了更清楚地说明本申请具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的埋点检测方法的一种应用场景示意图；

图2是根据本申请实施例的一种埋点检测方法的流程示意图；

图3是根据本申请实施例的又一种埋点检测方法的流程示意图；

图4是根据本申请实施例的一种埋点管理方法的流程示意图；

图5是根据本申请实施例的埋点检测页面的示意图；

图6是根据本申请实施例的异常数据查询页面的示意图；

图7是根据本申请实施例的又一种埋点管理方法的流程示意图；

图8是根据本申请实施例的埋点需求状态页面的示意图；

图9是根据本申请实施例的事件编辑页面的示意图；

图10是根据本申请实施例的埋点事件列表的示意图；

图11是根据本申请实施例的一种埋点检测装置以及埋点管理装置的结构框图；

图12是本申请实施例的计算机设备的硬件结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1是本申请的埋点检测方法的一种应用场景示意图，在该应用场景中包括前端埋点系统(图中未示出)、开发者侧、埋点事件抓取工具以及服务端。

开发者在开发者侧可以根据前端埋点系统中已录入的埋点事件开发代码，或者根据实际需求开发埋点事件，以将埋点事件添加至埋点事件抓取工具。开发者侧的用户终端可以接收服务侧发送的埋点事件的未通过原因或埋点事件上报成功的信息。

埋点事件抓取工具以埋点SDK(Software Development Kit，软件开发工具包)为例，主要负责对已添加在埋点事件抓取工具中的埋点事件进行抓取，并将抓取的埋点事件透传至服务侧，此时服务端就收到埋点事件上报请求。值得注意的是，埋点事件抓取工具不对埋点事件进行命名校验。

服务端主要负责在接收到埋点事件抓取工具透传的多个埋点事件，也即收到埋点事件上报请求时，判断每一个埋点事件的所属项目版本是否为测试版本。针对所属项目版本不为测试版本的埋点事件就结束流程；针对所属项目版本为测试版本的对埋点事件，就对该埋点事件的事件名、属性名以及属性类型进行校验。如果校验通过就执行事件入库操作，同时判断该埋点事件是否已在事件库存在(具体判断流程在后续实施例中介绍)。如果是，就将该埋点事件存储至事件库后结束流程，如果否，不仅将该埋点事件存储至事件库，还会向用户终端发送埋点事件上报成功的信息。如果埋点事件的校验结果为校验未通过，就向用户终端发送埋点事件上报失败的信息和未通过原因。

可选的，开发者可以在前端系统查看埋点事件的上报状态，以及埋点事件所属埋点需求的上报状态，还可以在前端系统查看上报状态为异常的埋点事件对应的异常原因，异常原因即为未通过原因。

可选的，服务端可以是提供埋点自动监测服务的服务器，服务器可以是由多个物理服务器构成的服务器集群或者是分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等技术运计算服务的云服务器。

可选的，该应用场景还可以包括管理设备，该管理设备用于对该应用场景中的设备进行管理(如管理服务端与前端埋点系统之间的连接状态等)，该管理设备与服务端之间通过通信网络相连。可选的，该通信网络是有线网络或无线网络。

可选的，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网，但也可以是其他任何网络，包括但不限于局域网、城域网、广域网、移动、有限或无线网络、专用网络或者虚拟专用网络的任何组合。在一些实施例中，使用包括超文本标记语言、可扩展标记语言等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层、传输层安全、虚拟专用网络、网际协议安全等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。

根据本申请实施例，提供了一种埋点检测方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本实施例中提供了一种埋点检测方法，该方法由服务端执行，该服务端与前端埋点系统通信连接，服务端可以是计算机、平板电脑或服务器等，图2是根据本申请实施例的一种埋点检测方法的流程图，如图2所示，该流程包括如下步骤：

步骤201，接收埋点事件抓取工具透传的多个埋点事件。

埋点事件抓取工具可以是目前任一个可以抓取埋点事件的工具，例如埋点SDK。埋点事件包括事件名、属性名以及属性类型。埋点事件抓取工具会将抓取的埋点事件透传至服务端，服务端就接收到多个埋点事件。

步骤202，确定每一个埋点事件的所属项目版本。

埋点事件抓取工具会将埋点事件的所属项目版本标识一同透传至服务端，服务端可以基于每一个埋点事件的所属项目版本标识与项目版本的对应关系，确定每一个埋点事件的所属项目版本。所属项目版本标识与项目版本一一对应，所属项目版本标识可以是项目版本的编号，也可以是项目名称，本申请实施例不做具体限制。

步骤203，针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果。

一般而言，所属项目版本为非测试版本的埋点事件已经是经过埋点检测确认符合需求的埋点事件，无需服务端重复进行埋点检测。因此，服务端会针对所属项目版本为测试版本下的埋点事件进行检测。具体的，针对所属项目版本为测试版本的每一个埋点事件，服务端都会校验埋点事件的事件名、属性名以及属性类型是否符合预设异常埋点校验规则，从而得到每一个埋点事件的校验结果。

步骤204，解析校验结果，确定校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件。

其中，校验未通过是指事件名、属性名以及属性类型中至少一者的校验为校验未通过。服务端在校验埋点事件时，针对没用通过校验(也即校验未通过)的埋点事件会记录事件名、属性名以及属性类型不符合预设异常埋点校验规则的详细信息，该详细信息即为未通过原因。服务端针对每一个埋点事件的校验结果，可以确定埋点事件是否校验通过，以及校验未通过时的具体未通过原因，并将校验未通过的埋点事件确定为异常埋点事件。

步骤205，将异常埋点事件的上报状态标记为异常，并发送至前端埋点系统，并将未通过原因发送给异常埋点事件对应的用户终端。

服务端会将异常埋点事件的上报状态标记为异常，并将异常埋点事件的上报状态发送至前端埋点系统，这样方便前端埋点系统在后续展示异常埋点事件以及异常埋点事件的上报状态。服务端还会依据预配置的埋点事件所属埋点需求与用户终端的对应关系，将未通过原因发送给异常埋点事件所属埋点需求对应的用户终端。需要说明的是，埋点事件抓取工具在透传埋点事件时会将埋点事件的所有数据都发送至服务端，所有数据中包括埋点事件的所属埋点需求。服务端在向前端埋点系统发送异常埋点事件的上报状态时，会同时将异常埋点事件的所有数据发送至前端埋点系统，异常埋点事件的所有数据包括但不限于事件名、属性名、属性类型、上报状态、属性详细信息、基础数据以及埋点事件所属埋点需求等数据。

对于校验通过的埋点事件，服务端会将该埋点事件的上报状态标记为正常，并将校验通过的埋点事件以及上报状态发送至前端埋点系统，同时将校验通过的埋点事件存储在事件库中。

本申请实施例中，自动接收埋点事件抓取工具透传的多个埋点事件，并对所属项目版本为测试版本的埋点事件依据预设异常埋点校验规则进行自动校验。避免人工根据需求文档对埋点事件进行人工校验，大大提高了埋点检测的效率以及准确性。还可以及时向前端埋点系统发送异常埋点事件的上报状态，便于后续用户通过前端埋点系统查看异常的埋点事件，以及将异常埋点事件的未通过原因发送至异常埋点事件对应的用户终端，用户可以及时了解异常埋点事件的诱发原因，无需人工分析缩短用户发现问题的周期，用户体验友好。

传统的埋点检测需要人工分析埋点异常的原因，还需要人工判断埋点事件是否与需求相符，不仅效率低准确性不高还会出现埋点事件遗漏的问题。为了提高埋点检测的效率、准确性以及完整性，在本实施例中提供了又一种埋点检测方法，该方法由服务端执行，该服务端与前端埋点系统通信连接，服务端可以是计算机、平板电脑或服务器等，图3是根据本申请实施例的又一种埋点检测方法的流程图，如图3所示，该流程包括如下步骤：

步骤301，接收埋点事件抓取工具透传的多个埋点事件。

步骤302，确定每一个埋点事件的所属项目版本。

步骤303，针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果。

步骤301至步骤303详细请参见图2所示实施例的步骤201至步骤203，在此不再赘述。

步骤3031，根据预设命名规则，分别对第一埋点事件的属性名以及事件名进行命名校验，得到第一校验结果。

其中，第一埋点事件为所属项目版本为测试版本的埋点事件中的任一个，预设命名规则包括属性名的命名规范以及事件名的命名规范。属性名的命名规范包括以下两条规则：(1)属性名只能包含数字、字母以及下划线，并且属性名不能以数字和下划线开头，只能以字母开头；(2)属性名中的关键字不能与已使用的关键字一致。事件名的命名规范包括埋点事件的事件名应当存在于埋点事件所属需求文档中。服务端会基于预设命名规则中事件名的命名规范以及属性名的命名规范分别校验第一埋点事件的事件名与属性名是否符合各自的命名规范，已完成对第一埋点事件的命名校验。如果事件名与属性名均符合各自的命名规范，就确定第一校验结果为校验通过；如果事件名与属性名存在一者不符合各自的命名规范，就记录事件名与属性名具体不符合命名规范的原因并确定第一验结果为校验未通过。

需要说明的是，服务端可以从创建埋点事件的数据分析平台，例如，神策数据分析平台获取已使用的关键字。需求文档中记录有至少一个需求下所有埋点事件的详细信息，详细信息可以包括但不限于埋点事件的事件名、属性以及属性类型等数据。服务端可以从前端埋点系统获得埋点事件所属需求文档，也可以预先将埋点事件所属需求文档配置在服务端。

步骤3032，根据预设字段表中埋点事件的属性名以及属性类型，对第一埋点事件的属性名与属性类型进行匹配校验，得到第二校验结果，第一校验结果以及第二校验结果组成第一埋点事件的校验结果，重复以上步骤得到所有所属项目版本为测试版本的埋点事件的校验结果。

埋点事件除了要符合上述预设命名规则外，还要符合以下规则：(1)属性名的大小写应当与已存在埋点事件的属性名的大小写一致；(2)属性类型应当与已存在埋点事件的属性类型一致。预设字段表会记录已存在的埋点事件的属性名以及属性类型，因此，服务端会在预设字段表中搜索与第一埋点事件的属性名一致的属性名，如果搜索到就意味着第一埋点事件的属性名与已存在的属性名的大小写一致，否则不一致。同时还会在预设字段表中搜索到一致的属性名时，将预设字段表中属性名对应的属性类型确定为第一埋点事件的参考属性类型，并判断第一埋点事件的属性类型是否与参考属性类型一致，如果一致就意味着第一埋点事件的属性类型与已存在埋点事件的属性类型一致，否则不一致。这样服务端就得到第二校验结果，并将第一校验结果与第二校验结果作为第一埋点事件的校验结果。继而对下一个所属项目版本为测试版本的埋点事件重复步骤3031至步骤3032，直到得到所有所属项目版本为测试版本的埋点事件的校验结果。

基于预设埋点命名规则以及预设字段表中埋点事件的属性名以及属性类型，自动对所属项目版本为测试版本的埋点事件进行命名校验以及匹配校验，保证每一个埋点事件的命名以及属性名和属性类型均符合规定，无需人工进行埋点检测，提高埋点检测的效率与准确性。

步骤304，解析校验结果，确定校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件。

步骤304详细请参见图2所示实施例的步骤204，在此不再赘述。

可选的，为了节省人力，提高开发效率，在步骤304之后，还可以向前端埋点系统发送未通过原因，以便于前端埋点系统在接收到异常埋点事件的未通过原因查看请求时，展示异常埋点事件的未通过原因。例如，图6中，事件名为“App_housepicture_big_view”且属性名为“reserveType,value:intelligence，secRoomEmpty”的埋点事件，该埋点事件的属性类型为String，但在检测该埋点事件时，预设字段表中与该埋点事件同属性名的埋点事件的属性类型为“Bi gDecimal”，两者属性类型不相符，服务端会判定该埋点事件未通过校验，而未通过原因为“尝试装换String到BigDecimal异常”。

用户可以通过前端埋点系统查看异常埋点事件的未通过原因，可以直接基于未通过原因对异常埋点事件进行修改。无需像传统流程那样人工先分析异常埋点事件的诱发原因，再提交bug报告后才能对异常埋点事件进行修改，节省人力的同时简化了埋点开发流程提高了开发效率。

步骤305，将异常埋点事件的上报状态标记为异常，并发送至前端埋点系统，并将未通过原因发送给异常埋点事件对应的用户终端。

步骤305详细请参见图2所示实施例的步骤205，在此不再赘述。

步骤306，若校验结果中存在校验通过的第二埋点事件，将第二埋点事件的上报状态标记为正常，并发送至前端埋点系统。

服务端会将校验通过的第二埋点事件的上报状态标记为正常，并将第二埋点事件的上报状态均发送至前端埋点系统，这样方便前端埋点系统在后续展示第二埋点事件以及第二埋点事件的上报状态。需要说明的是，服务端在发送第二埋点事件的上报状态时，会将包括上报状态在内的第二埋点事件的所有数据也发送至前端埋点系统。也即服务端针对每一个确定了上报状态的埋点事件，都会将埋点事件的所有数据发送至前端埋点系统。

步骤307，在事件库中查询与第二埋点事件匹配的历史埋点事件。

对于校验通过的第二埋点事件，服务端还会执行埋点事件入库操作，将第二埋点事件存储在事件库中，已完成对第二埋点事件的上报操作。具体的，服务端会现在事件库中搜索与第二埋点事件的事件名以及属性名一致的历史埋点事件。

步骤308，若事件库中不存在历史埋点事件，则将第二埋点事件存储至事件库中，并向第二埋点事件对应的用户终端发送用于指示第二埋点事件上报成功的信息。

如果服务端在事件库中没有搜索到历史埋点事件，就意味着第二埋点事件是第一次入库，服务端除了会将第二埋点事件存储至事件库中外，还会依据预配置的埋点事件所属项目与用户终端的对应关系，将用于指示第二埋点事件上报成功的信息发送给第二埋点事件所属项目对应的用户终端。

步骤309，若事件库中存在历史埋点事件，则将第二埋点事件存储至历史埋点事件所在的存储区域内。

如果服务端在事件库中搜索到历史埋点事件，就意味着第二埋点事件不是第一次入库，服务端会将第二埋点事件存储在事件库中历史埋点事件所在的存储区域内。实现了自动将校验通过的埋点事件存储入库，完成埋点事件的自动上报，还可以对第一次入库的埋点事件发送上报成功的信息至对应的用户终端，及时通知用户，用户体验友好。

可选的，为了避免遗漏埋点事件，提高埋点检测的完整性，该埋点检测方法还可以包括如下步骤A1至步骤A3：

步骤A1，在第一预设时间段内，监测预获取的需求文档集合中第一需求文档中规定的所有埋点事件是否均存储至事件库中。

其中，第一需求文档为需求文档集合中的任一个需求文档。可以在服务端预先配置需求文档集合，也可以在前端埋点系统配置需求文档集合，服务端在埋点检测前从前端埋点系统中获取需求文件集合。第一预设时间段可以自行设置，例如，一周、三天或一月等。服务端会将第一需求文档中每一个埋点事件的事件名与属性名，分别与在第一预设时间段内存储在事件库中的埋点事件的事件名与属性名进行比对。

步骤A2，若第一需求文档中规定的所有埋点事件均存储至事件库中，将第一需求文档对应的第一埋点需求的上报状态标记为正常，并发送至前端埋点系统。

其中，第一埋点需求包括第一需求文档中规定的所有埋点事件。如果第一需求文档中每一个埋点事件的事件名与属性名均可以从事件库在第一预设时间段内存储的埋点事件中找到一致的事件名与属性名，则确定第一需求文档中规定的所有埋点事件存储至事件库中。此时服务端会将包括第一需求文档中规定的所有埋点事件的第一埋点需求的上报状态标记为正常，并将第一埋点需求的上报状态发送至前端埋点系统。前端埋点系统就可以展示埋点需求的上报状态。

步骤A3，若第一需求文档中规定的所有埋点事件中存在至少一个埋点事件未存储至事件库中，将第一埋点需求的上报状态标记为异常，并发送至前端埋点系统。

如果第一需求文档中存在至少一个埋点事件的事件名以及属性名中的至少一者，与在第一预设时间段内存储在事件库中的埋点事件中的事件名与属性名均不一致，则意味着第一需求文档中规定的所有埋点事件中存在至少一个埋点事件未存储至事件库中。此时服务端会将第一埋点需求的上报状态标记为异常，并将第一埋点需求的上报状态发送至前端埋点系统。前端埋点系统就可以展示埋点需求的上报状态。

自动检测需求文件中规定的所有埋点事件是否存储至事件库中，可以避免埋点事件的漏报问题。另外，标记埋点事件的上一级埋点需求的上报状态，使得埋点检测可以关注整个埋点需求的上报状态，对于用户而言也可以通过关注埋点需求的上报状态来迅速了解可能出现异常埋点事件的埋点需求，无需人工对埋点需求下的测试点进行分析，节省大量人力成本，用户体验友好。

在一种应用场景中，以埋点SDK为埋点开发工具，北极星系统为服务端为例，测试人员可以基于前端埋点系统管理埋点需求与埋点事件，并通过前端埋点系统将埋点需求提交至埋点研发人员。埋点研发人员进行埋点事件的开发将埋点需求中的埋点事件添加至埋点SDK中，埋点SDK自动抓取埋点事件(可以理解的是该应用场景中的埋点事件的所属项目版本均为测试版本)上报至北极星系统。

埋点事件上报后，北极星系统自动对比上报埋点事件中的事件名和需求文档中的事件名是否一致，自动识别埋点事件是否已经完成上传(也即，上否均存储在事件库中)。北极星系统还会自动对比上报埋点事件的属性名和需求文档中的属性名是否一致，自动识别埋点事件的属性是否已经完成上传，以及自动对比上报的埋点事件的属性的值和需求文档中规定的属性取值范围是否相符(也即，自动判断上报埋点事件的属性名以及事件名是否符合预设命名规范，以及在预设字段表中是否存在与埋点事件的属性名以及属性类型一致的埋点事件)，自动识别埋点事件是否正确上报。通过系统自动比对的方式，规避了因为人员疏忽导致的测试遗漏问题。针对异常情况(也即异常埋点事件)，自动发送异常信息(也即未通过原因)，通知埋点研发人员，无需测试人员人工检测以及提交bug后埋点研发人员才明确异常情况，对埋点事件进行修改，简化了埋点检测流程提高效率。

针对埋点需求中所有埋点事件完全符合需求的情况，也即，需求文档中所有埋点事件均正确上报且均上传完成的情况，给出明确的状态展示，也即将埋点需求的上报状态标记为正常，并发送至前端埋点系统，前端埋点系统展示该上报状态。测试人员只需要关注整个埋点需求的上报状态即可。对于埋点需求中的几十，甚至几百个埋点事件，无需人工检测，节省大量人力。

本申请实施例中，对于抓取到的所属项目版本为测试版本的埋点事件，基于预设埋点命名规则以及预设字段表中埋点事件的属性名以及属性类型，自动对所属项目版本为测试版本的埋点事件进行命名校验以及匹配校验，可以保证事件库中每一个埋点事件的命名以及属性名和属性类型均符合规定，保证埋点事件的正确存储。并自动检测需求文件中规定的所有埋点事件是否存储至事件库中，可以避免埋点事件的漏报问题。另外，标记埋点事件的上一级埋点需求的上报状态，使得埋点检测可以关注整个埋点需求的上报状态，对于用户而言也可以通过关注埋点需求的上报状态来迅速了解可能出现异常埋点事件的埋点需求，无需人工对埋点需求下的测试点进行分析，节省大量人力成本，用户体验友好。

本申请实施例还提供一种埋点管理方法，该方法由前端埋点系统执行，该前端埋点系统与上述任一实施例中执行埋点检测方法的服务端通信连接，以通过系统录入的方式在埋点检测前后或埋点检测的过程中管理埋点需求。前端埋点系统可以是安装计算机、平板电脑或服务器等设备上，图4是根据本申请实施例的一种埋点管理方法的流程图，如图4所示，该流程包括如下步骤：

步骤401，响应于在第二预设时间段内对第二埋点需求的埋点检测请求，从服务端发送埋点事件的上报状态中，筛选在第二预设时间段内第二埋点需求下所有埋点事件的上报状态。

埋点事件的上报状态为服务端基于上述任一实施例的埋点检测方法确定的埋点事件的上报状态。第二预设时间段内可以自行设置，例如，一周或五天等。前端埋点系统响应于在第二预设时间段内对第二埋点需求的埋点检测的埋点检测请求(该埋点检测请求可以是用户输入的，也可以是前端埋点系统基于定时任务触发的)，从服务端已发送的所有埋点事件的上报状态中，基于所有埋点事件的所属埋点需求，查找在第二预设时间段内，属于第二埋点需求的所有埋点事件的上报状态。

步骤402，在埋点检测页面中展示在第二预设时间段内，第二埋点需求下所有埋点事件的上报状态。

前端埋点系统可以基于得到第二埋点需求下所有埋点事件的上报状态在埋点检测页面中展示在第二预设时间段内，第二埋点需求下所有异常埋点事件的上报状态。

可选的，为了提高对埋点事件的管理效率，该埋点管理方法还可以包括从服务端发送埋点事件的上报状态中，筛选第二埋点需求下服务端未在第二预设时间段内发送上报状态的未上报埋点事件，并在埋点检测页面内展示未上报埋点事件。具体的，前端埋点系统可以将从服务端发送埋点事件的上报状态中，筛选出的在第二预设时间段内第二埋点需求下所有埋点事件，与第二埋点需求的所有埋点事件进行比对，确定第二埋点需求下服务端未在第二预设时间段内发送上报状态的未上报埋点事件；在埋点检测页面内展示确定出的未上报埋点事件。无需人为确定埋点需求下服务端未上报的埋点事件，提高了对埋点事件的管理效率。

可选的，为了加快埋点事件的研发效率，还可以响应于对埋点检测页面中已展示的埋点事件的筛选请求，从已展示的埋点事件中筛选并展示与筛选请求对应的埋点事件的上报状态。筛选请求包括筛选目标机型、目标设备标识以及目标用户标识中至少一者下埋点事件。可以理解的是，服务端发送的埋点事件的所有数据中包括埋点事件所属机型、所属设备标识以及所属用户标识，前端埋点系统就可以基于已展示的埋点事件的基础数据以及筛选请求中涉及的目标机型、目标设备标识和目标用户标识，筛选出与筛选请求对应的埋点事件，以展示其上报状态。这样一来用户可以明确不同筛选条件下埋点事件的具体上报状态，从而快速明确异常埋点事件对应的筛选条件，并对异常埋点事件作出修改，无需人工从大量的埋点事件中对异常埋点事件进行分类再对异常埋点事件做出修改，加快了埋点事件的研发效率。

在一种应用场景中，埋点检测页面如图5所示，页面中“时间”选项对应的时间段即为第二预设时间段，“某项目测试”为埋点需求以及埋点事件所属的项目，“某项目测试”中的“测试”指明所属项目版本为测试版本。“App_sharelease_continue_click”等字段为第二埋点需求下埋点事件的事件名，每个事件名下的“2023-04-04 16：28：26”为埋点事件的上报时间，“popType:3，hintType:2”为埋点事件的触发条件，“点击查看错误原因”即为点击查看未通过原因，“无上报记录”在表明其所在事件名对应埋点事件在第二预设时间段内未被上报，也即“App_sharelease_invitepopover_view”对应埋点事件为未上报埋点事件。

图5中的机型、设备ID以及用户ID即为目标机型、目标设备标识以及目标用户标识，图5中机型、设备ID以及用户ID后的输入框中的文字分别为“请选择”以及“请输入”，这意味着，当前没有对该埋点检测页面中已展示的埋点事件进行筛选。

步骤403，接收对埋点检测页面中第一异常埋点事件的未通过原因的查看请求，获取第一异常埋点事件的基础数据。

基础数据包括埋点事件的所属工程信息、事件名、属性名、异常发生序号、详细数据以及事件异常时间。用户可以在埋点检测页面中输入对第一异常埋点事件的未通过原因的查看请求，该查看请求中可以包括第一异常埋点事件的事件名以及所属项目，前端埋点系统可以根据第一异常埋点事件的事件名以及所属项目从服务端发送的埋点事件的所有数据中查找到第一异常埋点事件的基础数据。

步骤404，从服务端获取第一异常埋点事件的未通过原因。

前端埋点系统在接收到服务端发送的异常埋点事件的未通过原因时，会将异常埋点事件会与未通过原因进行关联存储。这样前端埋点系统在查找到第一异常埋点事件的基础数据时可以获取到第一异常埋点事件关联的未通过原因。

步骤405，在异常数据查询页面展示在第一异常埋点事件的未通过原因以及基础数据。

前端埋点系统会在异常数据查询页面显示第一异常埋点事件的未通过原因以及基础数据。例如，如图5所示，用户点击“App_sharelease_continue_click”下的“点击查看错误原因”，前端埋点系统就可以接收到未通过原因的查看请求，并展示异常数据查询页面。展示的异常数据查询界面中显示有事件名器“App_sharelease_continue_click”的埋点事件的的所属工程信息、事件名、属性名、异常发生序号、详细数据、事件异常时间以及未通过原因。

可选的，前端埋点系统可以利用异常数据查询页面提供异常埋点事件的查询服务，以方便用户查询不同项目的不同埋点事件在特定时间段下的未通过原因，提高对埋点事件的管理效率。具体的，接收从异常数据查询页面输入的对目标埋点事件的异常数据查询请求；根据异常数据查询请求中的第三预设时间段、目标埋点事件的事件名以及目标埋点事件所属项目，从服务端发送的所有埋点事件中查询在第三预设时间段内目标埋点事件的所有未通过原因以及目标埋点事件的基础数据；在异常数据查询页面展示在第三预设时间段内目标埋点事件的基础数据以及所有未通过原因。第三预设时间段可以自行设置。

在一种应用场景中，前端埋点系统展示的异常数据查询页面如图6所示，图中展示了事件名为“App_housepicture_big_view”的埋点事件的未通过原因以及基础数据。用户可以分别页面顶端的“项目”、“事件”以及“日期”后的输入框中选择不同的项目、埋点事件以及时间段(该时间段即为第三预设时间段)，点击“查询”按钮前端埋点系统就可以接收从异常数据查询页面输入的对目标埋点事件的异常数据查询请求，也即图6中事件名为“App_housepicture_big_view”的埋点事件的异常数据查询请求。并在异常数据查询页面中展示该埋点事件在2023-04-04至2023-04-10这段时间内的所有未通过原因，通过图中表格中的“序号”(也即异常发生序号)下的数字可知该埋点事件共有3次被服务端确定为异常埋点事件，且每次的未通过原因也即异常信息都是“尝试装换StringBigDecimals异常，丢弃该事件，属性名称reserveType.value:intelligence.secRoom Empty”。图中表格中的“日期”以及“事件发生时间”组成事件异常时间，“数据详细信息”下的数据即为埋点事件的详细数据，埋点事件在不同的时间内的详细数据可以不同，图中表格中的事件指示埋点事件的事件名。

本申请实施例中，前端埋点系统响应于埋点检测请求，用户就可以在埋点检测页面中看到在特定时间段内特定埋点需求下所有埋点事件的上报状态，无需用户人工确定埋点事件的上报状态，也无需人工从大量埋点事件中筛选特定时间段内特定埋点需求下的埋点事件，方便批量快速地管理埋点事件，用户体验友好。在接收到对埋点检测页面中第一异常埋点事件的未通过原因的查看请求时，还可以向用户展示第一异常埋点事件的未通过原因以及包括所属工程信息以及事件名等的基础数据，避免人工从大量埋点事件中筛选并判断特定异常埋点事件的基础数据以及未通过原因，节省埋点检测的时间，还可以及时得到异常埋点事件的相关信息，省略传统埋点检测中测试人员提交bug的流程，提高埋点检测的效率。

为了加快埋点事件的研发效率，前端埋点系统除了可以通过埋点检测页面以及异常数据查询页面中任一者管理埋点事件外，还可提供埋点需求的管理服务，并向用户展示整个埋点需求的上报状态，具体流程可如图7所示，图7是根据本申请实施例的又一种埋点管理方法的流程图，如图7所示，该流程包括如下步骤：

步骤701，接收对第一项目的埋点需求查看请求，展示埋点需求状态页面。

其中，埋点需求状态页面中包括第一项目下的所有埋点需求的埋点需求信息，以及第一项目下每一个埋点需求的上报状态。埋点需求信息包括埋点需求的需求名称、上线日期、创建人、更新时间以及所属项目。埋点需求的上报状态为服务端基于上述任一实施例的埋点检测方法，根据预获取的需求文档集合中任一个需求文档中规定的所有埋点事件是否均存储至事件库中，确定该需求文档对应埋点需求的上报状态。

前端埋点系统可以在展示了至少一个埋点需求的上报状态的埋点需求状态页面中，接收对第一项目的埋点需求查看请求，更新埋点需求状态页面中的展示内容，将第一项目下的所有埋点需求，以及第一项目下每一个埋点需求的上报状态展示在该页面中。

可选的，前端埋点系统除了可以从项目的维度确定埋点需求状态页面的展示内容外，还可以从用户或埋点需求的维度确定埋点需求状态页面的展示内容。例如，图8所示的埋点需求状态页面，该页面展示了甲乙丙3个项目下的部分埋点需求的埋点需求信息。图中“项目”下内容即为埋点需求所属项目，例如需求名称为“删除订单/注销埋点”的埋点需求，其所属项目为项目1。该页面中“我的”的按钮被选中时，可以展示所有由某登录用户负责的埋点需求的埋点需求信息以及埋点需求的上报状态。图中的“全部”按钮被选中，则该埋点需求状态页面中展示所有项目下所有被服务端确定了上报状态的埋点需求，其中“×”表示异常的上报状态，“√”表示正常的上报状态。

若该页面顶端的“需求名称”被输入特定的需求名称，则前端埋点系统可以使该埋点需求状态页面仅展示该特定的需求名称对应埋点需求的上报状态以及埋点需求信息。前端埋点系统可以通过该埋点需求状态页面顶端的下拉选框接收特定的项目，图中下拉选框中的文字为“全部”，表明该埋点需求状态页面中展示有所有项目下所有被服务端确定了上报状态的埋点需求。前端埋点系统还可以在该埋点需求状态页面顶端的“请输入内容”所在文本框中被输入的项目名称时，接收对输入的项目名称的埋点需求的查看请求。

可选的，前端埋点系统还通过埋点需求状态页面提供埋点需求管理服务，埋点需求管理服务包括但不限于埋点需求的创建、查看以及删除等服务。例如，图8所示埋点需求状态页面中前端埋点系统接收“+创建”按钮的点击操作，就确定接收到埋点需求的创建请求，展示埋点需求编辑界面，用户可以在埋点需求编辑界面中编辑埋点需求的需求名称、所属项目、上线时间以及埋点需求下的埋点事件等内容。方便用户对埋点需求的管理。

可选的，前端埋点系统还可以提供录入方式的埋点需求管理服务，方便对埋点需求的细节尤其是埋点需求下的埋点事件进行编辑与管理，该埋点管理方法还可以包括如下步骤B1至步骤B3：

步骤B1，接收对第二埋点需求的埋点事件编辑请求，展示埋点事件的事件编辑页面。

前端埋点系统在接收到对第二埋点需求的埋点事件编辑请求时，就会展示埋点事件的事件编辑页面。

步骤B2，接收对事件编辑页面中目标埋点组件的编辑操作，编辑目标埋点组件的值。

目标埋点组件用于指示埋点事件的事件信息集合中的一者或属性信息集合中的一者，事件信息集合包括事件名、显示名、事件上报时机、需求类型、事件类型以及埋点端，属性信息集合包括属性枚举或者含义、属性类型、属性名以及属性显示名称。埋点事件的需求类型用于指示埋点事件是已埋事件还是新增事件。

可选的，前端埋点系统还可以仅提供对埋点事件的属性进行编辑的服务，具体流程与步骤B1至步骤B3类似，只不过前端埋点系统会接收对目标埋点事件的埋点事件编辑请求，展示的事件编辑页面中目标埋点事件的事件信息集合中的任一者都不可编辑，仅可以编辑目标埋点事件的属性信息集合中的任一者。例如，前端埋点系统接收到对埋点需求“【搜索大卡版】停不下来的找房列表”下事件名为“clickFavoritesHouse”的埋点事件的埋点事件编辑请求，展示如图9所示“埋点需求/需求详情”页面也即事件编辑页面。图9展示的事件编辑页面中包括埋点事件的事件信息集合、属性信息集合以及埋点需求的项目需求信息集合，项目需求信息集合中的内容在后续实施例中介绍。

图9展示页面中事件英文名(也即事件名)、显示名、事件上报时机、需求类型、事件类型以及埋点端后的内容均不可编辑。埋点事件“clickFavoritesHouse”的属性枚举或者含义、属性类型、属性名以及属性显示名称均可以进行修改，图中“类型”字段下的新增以及修改用于指示属性名的编辑类型。从图9中可以看出“searcglist2”为新增的属性名，“invNo”为修改后的属性名。

可选的，每一个属性名有各自对应的属性显示名称、属性枚举或者含义以及属性类型。例如，图9中属性名pageName的属性显示名称为pageName，属性类型为字符串(String)，属性枚举或者含义为埋中文名称，共以下8个：想看相关页面取的是frompage或source；列表页：1.“列表页(二级页面)”；二级页：2.“合租”3.“整租”4.“整租1居室”5.“整租2居+”6.“想看列表”7.“想看推荐”8.房源详情页9.曼舍图集页。

用户还可以通过图9中“已上报枚举值”下的“查看”按钮查看埋点事件中已被存储至事件库中的属性枚举或者含义的信息。前端埋点系统通过事件编辑页面中提供埋点检测服务，例如，用户点击图9所示页面中的“埋点检测”按钮后，前端埋点系统可以在埋点检测页面中展示目标埋点事件(图9中即为埋点事件“clickFavoritesHouse”)在默认时间段内的上报状态。

可选的，前端埋点系统还可以通过事件编辑页面提供埋点事件的属性、埋点事件的已关联属性以及埋点事件的已关联预置属性的查看服务，例如，图9中事件属性下内容即为埋点事件的属性，“查看已关联属性、查看已关联预置属性以及查看全部预置属性”按钮即可提供查看埋点事件的已关联预置属性以及已关联属性的服务。

步骤B3，接收事件编辑页面的提交请求，根据事件编辑页面中所有埋点组件的值，获取编辑的埋点事件，以便于后续服务端基于上述任一实施例的埋点检测方法对编辑的埋点事件进行埋点检测。

前端埋点系统可以将获取的埋点事件添加至埋点事件抓取工具中，埋点事件抓取工具可以在抓取到编辑的埋点事件时，将编辑的埋点事件透传至服务端，服务端就可以基于上述任一实施例的埋点检测方法对编辑的埋点事件进行埋点检测。

可选的，研发人员也可以从前端埋点系统中查看编辑的埋点事件，人工将埋点事件研究至埋点事件抓取工具中。

在接收到对埋点需求的埋点事件编辑请求后，通过事件编辑页面即可方面用户对埋点事件的事件信息集合以及属性信息集合中的事件名以及属性名等信息进行编辑，并保证编辑的埋点事件可以参与埋点检测，方便用户对埋点需求下埋点事件的管理，还可以实现编辑后的埋点事件可以及时被埋点检测，提高埋点检测的效率。

步骤702，接收对埋点需求状态页面中第三埋点需求的查看请求，展示埋点事件列表。

其中，埋点事件列表包括第三埋点需求下所有埋点事件的事件信息集合，以及第三埋点需求对应的项目需求信息集合，项目需求信息集合包括项目名称、需求负责人、项目与事务跟踪地址、研发人员、需求名称、上线日期以及测试人员。

例如，在图8的埋点需求状态页面中点击“【搜索大卡板】停不下来的找房列表”后的查看按钮，前端埋点系统就接收到对需求名称为“【搜索大卡板】停不下来的找房列表”的埋点需求的查看请求，展示如图10所示的埋点事件列表，图10中的事件英文名即为事件名，“Jira地址”为项目与事务跟踪地址。埋点事件列表还可以包括埋点检测周期内新增事件以及已埋事件的个数，以及可以查看需求变更的按钮，也即图中的“查看变更日志”按钮。图10中列举出埋点需求“【搜索大卡板】停不下来的找房列表”下的八个埋点事件的事件信息集合，以及埋点需求的项目需求信息，该埋点需求在某个埋点开发周期内有4个新增事件和8个已埋事件。

可选的，前端系统可以还可以接收埋点事件列表中输入的返回请求，展示包括第三埋点需求的埋点需求状态页面。例如，点击图10中“返回列表”的按钮，前端埋点系统返回展示图8所示的埋点需求状态页面。

可选的，前端埋点系统可以通过埋点事件列提供埋点检测服务，可以接收埋点事件列表中输入的埋点需求的埋点检测请求，从服务端发送埋点事件的上报状态中，筛选在默认时间段内该埋点需求下所有埋点事件的上报状态，埋点事件的上报状态为服务端基于上述任一实施例的埋点检测方法确定的埋点事件的上报状态；在埋点检测页面中展示在默认时间段内，该埋点需求下所有埋点事件的上报状态。默认时间段可以自行设置，本请求实施例不做具体限制。例如，用户在如图10所示的埋点事件列表中点击“埋点检测”按钮，前端埋点系统就接收到对需求名称为“【搜索大卡板】停不下来的找房列表”的埋点需求的埋点检测请求。

结合图1至图10，服务端执行的埋点检测方法和前端埋点系统执行的埋点管理方法可以将埋点事件的整体开发流程从研发--埋点系统--测试--bug系统--研发--测试回归六个环节，缩短为研发--前端埋点系统以及服务端埋点检测--研发三个环节，缩短用户发现异常埋点事件以及异常埋点事件发生异常的原因的时间，大大提高埋点事件的开发效率。

本申请实施例中，在埋点需求状态页面展示特定项目下整个埋点需求的上报状态，这样就可以将上报状态为异常的埋点需求确认为存在异常埋点事件的埋点需求，方便用户快速划定异常埋点事件的存在范围，无需用户关注每一个埋点事件的上报状态，并避免传统埋点检测中用户等待测试人员人工检测埋点事件并提交的bug报告才能明确异常埋点事件的流程，加快了埋点事件的研发效率。用户通过埋点需求状态页面就可以查看埋点需求的上报状态无需人工进行埋点检测，提高埋点检测的准确性。还可以在埋点事件列表中展示特定埋点需求下的所有埋点事件以及埋点需求对应的项目需求信息集合，方便用户直观了解埋点需求下的埋点事件以及埋点需求的相关人员，用户体验友好。

在本实施例中还提供了一种埋点检测装置以及一种埋点管理装置，装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

如图11所示，埋点检测装置由服务端运行，服务端与前端埋点系统通信连接，该装置包括：

接收模块11A1，用于接收埋点事件抓取工具透传的多个埋点事件，埋点事件包括事件名、属性名以及属性类型；

确定模块11A2，用于确定每一个埋点事件的所属项目版本；

校验模块11A3，用于针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果；

解析模块11A4，用于解析校验结果，确定校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件，校验未通过是指事件名、属性名以及属性类型中至少一者的校验为校验未通过；

标记模块11A5，用于将异常埋点事件的上报状态标记为异常，并发送至前端埋点系统，并将未通过原因发送给异常埋点事件对应的用户终端。

在一些可选的实施例中，校验模块包括：

命名校验单元，用于根据预设命名规则，分别对第一埋点事件的属性名以及事件名进行命名校验，得到第一校验结果，第一埋点事件为所属项目版本为测试版本的埋点事件中的任一个，预设命名规则包括属性名的命名规范以及事件名的命名规范；

匹配校验单元，用于根据预设字段表中埋点事件的属性名以及属性类型，对第一埋点事件的属性名与属性类型进行匹配校验，得到第二校验结果，第一校验结果以及第二校验结果组成第一埋点事件的校验结果，重复以上步骤得到所有所属项目版本为测试版本的埋点事件的校验结果。

在一些可选的实施例中，若校验结果中存在校验通过的第二埋点事件，埋点检测装置还包括：

标记模块，还用于将第二埋点事件的上报状态标记为正常，并发送至前端埋点系统；

查询模块，用于在事件库中查询与第二埋点事件匹配的历史埋点事件；

存储模块，用于若事件库中不存在历史埋点事件，则将第二埋点事件存储至事件库中，并向第二埋点事件对应的用户终端发送用于指示第二埋点事件上报成功的信息；

存储模块，还用于若事件库中存在历史埋点事件，则将第二埋点事件存储至历史埋点事件所在的存储区域内。

在一些可选的实施例中，在解析校验结果，确定校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件之后，埋点检测装置还包括：

标记模块，还用于向前端埋点系统发送未通过原因，以便于前端埋点系统在接收到异常埋点事件的未通过原因查看请求时，展示异常埋点事件的未通过原因。

在一些可选的实施例中，埋点检测装置包括：

监测模块，用于在第一预设时间段内，监测预获取的需求文档集合中第一需求文档中规定的所有埋点事件是否均存储至事件库中，第一需求文档为需求文档集合中的任一个需求文档；

标记模块，还用于若第一需求文档中规定的所有埋点事件均存储至事件库中，将第一需求文档对应的第一埋点需求的上报状态标记为正常，并发送至前端埋点系统，第一埋点需求包括第一需求文档中规定的所有埋点事件；

标记模块，还用于若第一需求文档中规定的所有埋点事件中存在至少一个埋点事件未存储至事件库中，将第一埋点需求的上报状态标记为异常，并发送至前端埋点系统。

如图11所示，埋点管理装置由前端埋点系统运行，前端埋点系统与第一方面任一实施例涉及的服务端通信连接，该装置包括：

筛选模块11B1，用于响应于在第二预设时间段内对第二埋点需求的埋点检测请求，从服务端发送埋点事件的上报状态中，筛选在第二预设时间段内第二埋点需求下所有埋点事件的上报状态，埋点事件的上报状态为服务端基于如第一方面任一实施例埋点检测方法确定的埋点事件的上报状态；

展示模块11B2，用于在埋点检测页面中展示在第二预设时间段内，第二埋点需求下所有埋点事件的上报状态。

在一些可选的实施例中，埋点管理装置还包括：

展示模块，还用于，用于接收对第二埋点需求的埋点事件编辑请求，展示埋点事件的事件编辑页面；

编辑模块，用于接收对事件编辑页面中目标埋点组件的编辑操作，编辑目标埋点组件的值，目标埋点组件用于指示埋点事件的事件信息集合中的一者或属性信息集合中的一者，事件信息集合包括事件名、显示名、事件上报时机、需求类型、事件类型以及埋点端，属性信息集合包括属性枚举或者含义、属性类型、属性名以及属性显示名称；

第一获取模块，用于接收事件编辑页面的提交请求，根据事件编辑页面中所有埋点组件的值，获取编辑的埋点事件，以便于后续服务端基于如上述任一实施例的埋点检测方法对编辑的埋点事件进行埋点检测。

在一些可选的实施例中，埋点管理装置还包括：

展示模块，还用于接收对第一项目的埋点需求查看请求，展示埋点需求状态页面，埋点需求状态页面中包括第一项目下的所有埋点需求的埋点需求信息，以及第一项目下每一个埋点需求的上报状态。

在一些可选的实施例中，在接收对第一项目的埋点需求查看请求，展示埋点需求状态页面之后，埋点管理装置还包括：

展示模块，还用于接收对埋点需求状态页面中第三埋点需求的查看请求，展示埋点事件列表，埋点事件列表包括第三埋点需求下所有埋点事件的事件信息集合，以及第三埋点需求对应的项目需求信息集合，项目需求信息集合包括项目名称、需求负责人、项目与事务跟踪地址、研发人员、需求名称、上线日期以及测试人员。

在一些可选的实施例中，在埋点检测页面中展示在第二预设时间段内，第二埋点需求下所有埋点事件的上报状态之后，埋点管理装置还包括：

第二获取模块，用于接收对埋点检测页面中第一异常埋点事件的未通过原因的查看请求，获取第一异常埋点事件的基础数据，基础数据包括埋点事件的所属工程信息、事件名、属性名、异常发生序号、详细数据以及事件异常时间；

第三获取模块，用于从服务端获取第一异常埋点事件的未通过原因；

展示模块，还用于在异常数据查询页面展示在第一异常埋点事件的未通过原因以及基础数据。

上述各个模块和单元的更进一步的功能描述与上述对应实施例相同，在此不再赘述。

本实施例中的埋点检测装置以及埋点管理装置是以功能单元的形式来呈现，这里的单元是指ASIC(Application Specific Integrated Circuit，专用集成电路)电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。

本申请实施例还提供一种计算机设备，具有上述图11所示的埋点检测装置以及埋点管理装置。

请参阅图12，图12是本申请可选实施例提供的一种计算机设备的结构示意图，如图12所示，该计算机设备包括：一个或多个处理器10、存储器20，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相通信连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在计算机设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在一些可选的实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个计算机设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图12中以一个处理器10为例。

处理器10可以是中央处理器，网络处理器或其组合。其中，处理器10还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路，可编程逻辑器件或其组合。上述可编程逻辑器件可以是复杂可编程逻辑器件，现场可编程逻辑门阵列，通用阵列逻辑或其任意组合。

其中，所述存储器20存储有可由至少一个处理器10执行的指令，以使所述至少一个处理器10执行实现上述实施例示出的方法。

存储器20可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据计算机设备的使用所创建的数据等。此外，存储器20可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些可选的实施方式中，存储器20可选包括相对于处理器10远程设置的存储器，这些远程存储器可以通过网络连接至该计算机设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

存储器20可以包括易失性存储器，例如，随机存取存储器；存储器也可以包括非易失性存储器，例如，快闪存储器，硬盘或固态硬盘；存储器20还可以包括上述种类的存储器的组合。

该计算机设备还包括通信接口30，用于该计算机设备与其他设备或通信网络通信。

本申请实施例还提供了一种计算机可读存储介质，上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可记录在存储介质，或者被实现通过网络下载的原始存储在远程存储介质或非暂时机器可读存储介质中并将被存储在本地存储介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件的存储介质上的这样的软件处理。其中，存储介质可为磁碟、光盘、只读存储记忆体、随机存储记忆体、快闪存储器、硬盘或固态硬盘等；进一步地，存储介质还可以包括上述种类的存储器的组合。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现上述实施例示出的方法。

虽然结合附图描述了本申请的实施例，但是本领域技术人员可以在不脱离本申请的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (14)

1.一种埋点检测方法，其特征在于，所述方法由服务端执行，所述服务端与前端埋点系统通信连接，所述方法包括：

接收埋点事件抓取工具透传的多个埋点事件，所述埋点事件包括事件名、属性名以及属性类型；

确定每一个所述埋点事件的所属项目版本；

针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果；

解析所述校验结果，确定所述校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件，所述校验未通过是指事件名、属性名以及属性类型中至少一者的校验为校验未通过；

将所述异常埋点事件的上报状态标记为异常，并发送至前端埋点系统，并将所述未通过原因发送给异常埋点事件对应的用户终端。

2.根据权利要求1所述的方法，其特征在于，所述针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果，包括：

根据预设命名规则，分别对第一埋点事件的属性名以及事件名进行命名校验，得到第一校验结果，所述第一埋点事件为所属项目版本为测试版本的埋点事件中的任一个，所述预设命名规则包括属性名的命名规范以及事件名的命名规范；

根据预设字段表中埋点事件的属性名以及属性类型，对所述第一埋点事件的属性名与属性类型进行匹配校验，得到第二校验结果，所述第一校验结果以及所述第二校验结果组成所述第一埋点事件的校验结果，重复以上步骤得到所有所属项目版本为测试版本的埋点事件的校验结果。

3.根据权利要求1或2所述的方法，其特征在于，若所述校验结果中存在校验通过的第二埋点事件，所述方法还包括：

将所述第二埋点事件的上报状态标记为正常，并发送至所述前端埋点系统；

在事件库中查询与所述第二埋点事件匹配的历史埋点事件；

若所述事件库中不存在所述历史埋点事件，则将所述第二埋点事件存储至所述事件库中，并向所述第二埋点事件对应的用户终端发送用于指示所述第二埋点事件上报成功的信息；

若所述事件库中存在所述历史埋点事件，则将所述第二埋点事件存储至所述历史埋点事件所在的存储区域内。

4.根据权利要求1或2所述的方法，其特征在于，在解析所述校验结果，确定所述校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件之后，所述方法还包括：

向所述前端埋点系统发送所述未通过原因，以便于所述前端埋点系统在接收到所述异常埋点事件的未通过原因查看请求时，展示所述异常埋点事件的未通过原因。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

在第一预设时间段内，监测预获取的需求文档集合中第一需求文档中规定的所有埋点事件是否均存储至事件库中，所述第一需求文档为所述需求文档集合中的任一个需求文档；

若所述第一需求文档中规定的所有埋点事件均存储至事件库中，将所述第一需求文档对应的第一埋点需求的上报状态标记为正常，并发送至前端埋点系统，所述第一埋点需求包括所述第一需求文档中规定的所有埋点事件；

若所述第一需求文档中规定的所有埋点事件中存在至少一个埋点事件未存储至事件库中，将所述第一埋点需求的上报状态标记为异常，并发送至前端埋点系统。

6.一种埋点管理方法，其特征在于，所述方法由前端埋点系统执行，所述前端埋点系统与权利要求1至5任一项涉及的服务端通信连接，所述方法包括：

响应于在第二预设时间段内对第二埋点需求的埋点检测请求，从所述服务端发送埋点事件的上报状态中，筛选在所述第二预设时间段内所述第二埋点需求下所有埋点事件的上报状态，所述埋点事件的上报状态为所述服务端基于如权利要求1至5任一项所述的埋点检测方法确定的埋点事件的上报状态；

在埋点检测页面中展示在所述第二预设时间段内，所述第二埋点需求下所有埋点事件的上报状态。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

接收对所述第二埋点需求的埋点事件编辑请求，展示埋点事件的事件编辑页面；

接收对所述事件编辑页面中目标埋点组件的编辑操作，编辑所述目标埋点组件的值，所述目标埋点组件用于指示埋点事件的事件信息集合中的一者或属性信息集合中的一者，所述事件信息集合包括事件名、显示名、事件上报时机、需求类型、事件类型以及埋点端，所述属性信息集合包括属性枚举或者含义、属性类型、属性名以及属性显示名称；

接收所述事件编辑页面的提交请求，根据所述事件编辑页面中所有埋点组件的值，获取编辑的埋点事件，以便于后续所述服务端基于如权利要求1至5任一项所述的埋点检测方法对编辑的埋点事件进行埋点检测。

8.根据权利要求6或7所述的方法，其特征在于，所述方法还包括：

接收对第一项目的埋点需求查看请求，展示埋点需求状态页面，所述埋点需求状态页面中包括所述第一项目下的所有埋点需求的埋点需求信息，以及所述第一项目下每一个埋点需求的上报状态。

9.根据权利要求8所述的方法，其特征在于，在接收对所述第一项目的埋点需求查看请求，展示埋点需求状态页面之后，所述方法还包括：

接收对所述埋点需求状态页面中第三埋点需求的查看请求，展示埋点事件列表，所述埋点事件列表包括所述第三埋点需求下所有埋点事件的事件信息集合，以及所述第三埋点需求对应的项目需求信息集合，所述项目需求信息集合包括项目名称、需求负责人、项目与事务跟踪地址、研发人员、需求名称、上线日期以及测试人员。

10.根据权利要求8所述的方法，其特征在于，在埋点检测页面中展示在所述第二预设时间段内，所述第二埋点需求下所有埋点事件的上报状态之后，所述方法还包括：

接收对所述埋点检测页面中第一异常埋点事件的未通过原因的查看请求，获取所述第一异常埋点事件的基础数据，所述基础数据包括埋点事件的所属工程信息、事件名、属性名、异常发生序号、详细数据以及事件异常时间；

从所述服务端获取所述第一异常埋点事件的未通过原因；

在异常数据查询页面展示在所述第一异常埋点事件的未通过原因以及所述基础数据。

11.一种埋点检测装置，其特征在于，所述装置由服务端运行，所述服务端与前端埋点系统通信连接，所述装置包括：

接收模块，用于接收埋点事件抓取工具透传的多个埋点事件，所述埋点事件包括事件名、属性名以及属性类型；

确定模块，用于确定每一个所述埋点事件的所属项目版本；

校验模块，用于针对所属项目版本为测试版本的每一个埋点事件，根据预设异常埋点校验规则，对埋点事件的事件名、属性名以及属性类型进行校验，得到校验结果；

解析模块，用于解析所述校验结果，确定所述校验结果中校验未通过的埋点事件以及未通过原因，将校验未通过的埋点事件确定为异常埋点事件，所述校验未通过是指事件名、属性名以及属性类型中至少一者的校验为校验未通过；

标记模块，用于将所述异常埋点事件的上报状态标记为异常，并发送至前端埋点系统，并将所述未通过原因发送给异常埋点事件对应的用户终端。

12.一种埋点管理装置，其特征在于，所述装置由前端埋点系统运行，所述前端埋点系统与权利要求1至5任一项涉及的服务端通信连接，所述装置包括：

筛选模块，用于响应于在第二预设时间段内对第二埋点需求的埋点检测请求，从所述服务端发送埋点事件的上报状态中，筛选在所述第二预设时间段内所述第二埋点需求下所有埋点事件的上报状态，所述埋点事件的上报状态为所述服务端基于如权利要求1至5任一项所述的埋点检测方法确定的埋点事件的上报状态；

展示模块，用于在埋点检测页面中展示在所述第二预设时间段内，所述第二埋点需求下所有埋点事件的上报状态。

13.一种计算机设备，其特征在于，包括：

存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行权利要求1至5中任一项所述的埋点检测方法或权利要求6至10中任一项所述的埋点管理方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机指令，所述计算机指令用于使计算机执行权利要求1至5中任一项所述的埋点检测方法或权利要求6至10中任一项所述的埋点管理方法。