CN113472858A - 埋点数据处理方法、装置及电子设备 - Google Patents

Abstract

本公开关于一种埋点数据处理方法、装置及电子设备。该埋点数据处理方法应用于客户端，包括：在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，以便向服务端再次上报所述第一埋点数据；其中，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。采用本公开提供的埋点数据处理方法、装置和电子设备，减少丢失埋点数据的数量，降低埋点数据的丢失率。

Description

埋点数据处理方法、装置及电子设备

技术领域

本公开涉及前端技术领域，尤其涉及一种埋点数据处理方法、装置及电子设备。

背景技术

为了能够采集万维网(World Wide Web，Web)应用中客户端的运行情况数据，需要在浏览器的页面进行埋点处理。通过埋点可捕获关注的页面事件，获取页面事件的相关信息，然后通过超文本传输协议(Hypertext Transfer Protocol，HTTP)协议请求将相关信息发送给服务端，从而达到监控客户端的目的。

然而，在异常情况下，例如网络异常、客户端异常、服务端异常以及页面关闭等情况，HTTP请求无法发送成功，从而无法完成埋点数据的采集，并且由于本次埋点数据无法保存，导致本次埋点数据丢失，进而影响埋点数据质量。

发明内容

本公开提供一种埋点数据处理方法、装置、电子设备、计算机可读存储介质以及计算机程序产品，以至少解决相关技术中埋点上报请求发送异常情况下埋点数据丢失的问题。本公开的技术方案如下：

根据本公开实施例的第一方面，提供一种埋点数据处理方法，包括：

在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，以便向服务端再次上报所述第一埋点数据；

其中，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

在一些实施例中，在所述将所述第一埋点上报请求中的第一埋点数据存储在存储区域之后，所述方法还包括：

从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据；

基于所述第二埋点数据生成第二埋点上报请求，并向所述服务端发送所述第二埋点上报请求。

在一些实施例中，所述在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，包括：

在确定所述浏览器页面运行，并且第一埋点上报请求发送失败的情况下，将所述第一埋点上报请求中的第一埋点数据存储在所述失败埋点队列。

在一些实施例中，所述在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，包括：

在确定所述浏览器页面关闭，且未发送第一埋点上报请求或未接收到第一埋点上报请求的返回结果的情况下，将所述第一埋点上报请求中的第一埋点数据存储在本地存储中。在一些实施例中，所述将所述第一埋点上报请求中的第一埋点数据存储在本地存储中，包括：

根据所述第一埋点上报请求中的第一埋点数据，生成与所述第一埋点数据对应的存储标识，所述存储标识包括前缀标识、优先级、客户端时间戳和随机字符串；

将所述存储标识与所述第一埋点数据关联存储在所述本地存储中。

在一些实施例中，在将所述第一埋点上报请求中的第一埋点数据存储在存储区域之前，所述方法还包括：

在存储区域中的埋点数据的数量大于第一阈值的情况下，按照埋点数据的优先级和客户端时间戳，清除存储区域中的埋点数据，以使清除后的存储区域中的埋点数据的数量小于第二阈值，所述第二阈值不大于第一阈值。

在一些实施例中，所述从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据，包括：

在最近一次的埋点上报请求发送成功的情况下，从所述失败埋点队列中的至少一个所述第一埋点数据中读取第二埋点数据。

在一些实施例中，所述从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据，包括：

在检测到所述浏览器页面开启预设时间段并且所述浏览器页面处于开启状态的情况下，从所述本地存储中的至少一个所述第一埋点数据中读取第二埋点数据。

根据本公开实施例的第二方面，提供一种埋点数据处理方法，应用于服务端，包括：

接收第二埋点上报请求，所述第二埋点上报请求携带从所述存储区域中的至少一个所述第一埋点数据中读取的第二埋点数据；

其中，所述存储区域为在第一埋点上报请求发送异常的情况下，所述客户端将所述第一埋点上报请求中的第一埋点数据进行存储的区域，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

在一些实施例中，在所述接收第二埋点上报请求之后，所述方法还包括：

解析所述第二埋点上报请求，得到所述第二埋点数据；

将所述第二埋点数据存储在数据库中。

在一些实施例中，在所述将所述第二埋点数据存储在数据库中之前，还包括：

基于所述第二埋点数据中的目标参数，对所述第二埋点数据进行去重处理，所述目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。

在一些实施例中，所述基于所述第二埋点数据中的目标参数，对所述第二埋点数据进行去重处理，包括：

根据所述目标参数对所述第二埋点数据进行排序；

删除排序后第二埋点数据中重复埋点数据，所述重复埋点数据为与历史埋点数据具有相同的目标参数的第二埋点数据，所述历史埋点数据包括在得到所述第二埋点数据之前存储的埋点数据。

在一些实施例中，所述根据所述目标参数对所述第二埋点数据进行排序，包括：

根据所述设备标识对所述第二埋点数据进行分组，得到分组数据；

在所述分组数据中，将具有相同的产品标识和相同的网页域名的埋点数据按照所述客户端时间戳进行排序；

将排序后的埋点数据按照所述埋点数量标识进行排序。

在一些实施例中，所述数据库用于基于所述第二埋点数据中的目标参数，对所述第二埋点数据进行去重处理，并且存储去重后的埋点数据，所述目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。

根据本公开实施例的第三方面，提供一种埋点数据处理装置装置，应用于客户端，包括：

第一存储单元，被配置为执行在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，以便向服务端再次上报所述第一埋点数据；

其中，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

在一些实施例中，所述装置还包括：

读取单元，被配置为执行从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据；

生成单元，被配置为执行基于所述第二埋点数据生成第二埋点上报请求；

发送单元，被配置为向服务端发送所述第二埋点上报请求。

在一些实施例中，第一存储单元，具体被配置为执行在确定所述浏览器页面运行，并且第一埋点上报请求发送失败的情况下，将所述第一埋点上报请求中的第一埋点数据存储在所述失败埋点队列。

在一些实施例中，第一存储单元，具体被配置为执行在确定所述浏览器页面关闭，且未发送第一埋点上报请求或未接收到所述第一埋点上报请求的返回结果的情况下，将所述第一埋点上报请求中的第一埋点数据存储在本地存储中。

在一些实施例中，所述装置还包括：

标识生成单元，被配置为执行根据所述第一埋点上报请求中的第一埋点数据，生成与所述第一埋点数据对应的存储标识，所述存储标识包括前缀标识、优先级、客户端时间戳和随机字符串；

关联存储单元，被配置为执行将所述存储标识与所述第一埋点数据关联存储在本地存储中。

在一些实施例中，所述装置还包括：

清除单元，被配置为执行在存储区域中的埋点数据的数量大于第一阈值的情况下，按照埋点数据的优先级和客户端时间戳，清除存储区域中的埋点数据，以使清除后的存储区域中的埋点数据的数量小于第二阈值，所述第二阈值不大于第一阈值。

在一些实施例中，读取单元，具体被配置为执行在最近一次的埋点上报请求发送成功的情况下，从所述失败埋点队列中的至少一个所述第一埋点数据中读取第二埋点数据。

在一些实施例中，读取单元，具体被配置为执行在检测到所述浏览器页面开启预设时间段并且所述浏览器页面处于开启状态的情况下，从所述本地存储中的至少一个所述第一埋点数据中读取第二埋点数据。

根据本公开实施例的第四方面，提供一种埋点数据处理装置装置，应用于服务端，包括：

接收单元，被配置为执行接收客户端发送的第二埋点上报请求，所述第二埋点上报请求携带从所述存储区域中的至少一个所述第一埋点数据中读取的第二埋点数据，

其中，所述存储区域为在第一埋点上报请求发送异常的情况下，所述客户端将所述第一埋点上报请求中的第一埋点数据进行存储的区域，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

在一些实例中，所述装置还包括：

解析单元，被配置为执行解析所述第二埋点上报请求，得到所述第二埋点数据；

第二存储单元，被配置为执行将所述第二埋点数据存储在数据库中。

在一些实施例中，所述装置还包括：

处理单元，被配置为执行基于所述第二埋点数据中的目标参数，对所述第二埋点数据进行去重处理，所述目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。

在一些实施例中，所述处理单元包括：

排序子单元，被配置为执行根据所述目标参数对所述第二埋点数据进行排序；

删除子单元，被配置为执行删除排序后第二埋点数据中重复埋点数据，所述重复埋点数据为与历史埋点数据具有相同的目标参数的第二埋点数据，所述历史埋点数据包括在得到所述第二埋点数据之前存储的埋点数据。

在一些实施例中，排序子单元，具体被配置为执行根据所述设备标识对所述第二埋点数据进行分组，得到分组数据；

在所述分组数据中，将具有相同的产品标识和相同的网页域名的埋点数据按照所述客户端时间戳进行排序；

将排序后的埋点数据按照所述埋点数量标识进行排序。

在一些实施例中，所述数据库用于基于所述第二埋点数据中的目标参数，对所述第二埋点数据进行去重处理，并且存储去重后的埋点数据，所述目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。

根据本公开实施例的第五方面，提供一种电子设备，所述电子设备包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如第一方面所述的埋点数据处理方法，或者第二方面所述的埋点数据处理方法。

根据本公开实施例的第六方面，提供一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如第一方面所述的埋点数据处理方法，或者如第二方面所述的埋点数据处理方法。

根据本公开实施例的第七方面，提供一种计算机程序产品，所述计算机程序产品包括计算机程序或者指令，所述计算机程序或者指令被处理器执行时实现如第一方面所述的埋点数据处理方法，或者如第二方面所述的埋点数据处理方法。

本公开的实施例提供的技术方案至少带来以下有益效果：

本公开实施例中，在第一埋点上报请求发送异常的情况下，将发送异常的第一埋点数据存储在存储区域，其中，所述存储区域包括失败埋点队列或本地存储。并且根据浏览器页面的运行状态，确定将第一埋点数据存储在失败埋点对列还是本地存储。如此，能够利用客户端存储机制来确保上报异常的埋点数据不丢失，以便后续利用埋点数据重新发送机制来确保埋点数据成功发送，从而能够减少丢失埋点数据的数量，降低埋点数据的丢失率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理，并不构成对本公开的不当限定。

图1是根据一示例性实施例示出的一种埋点数据处理方法的流程图；

图2是根据一示例性实施例示出的另一种埋点数据处理方法的流程图；

图3是根据一示例性实施例示出的一种埋点数据数据处理系统的组成框图；

图4是根据一示例性实施例示出的一种埋点数据处理装置的组成框图；

图5是根据一示例性实施例示出的另一种埋点数据处理装置的组成框图；

图6是根据一示例性实施例示出的一种用于埋点数据处理方法的电子设备的框图。

具体实施方式

为了使本领域普通人员更好地理解本公开的技术方案，下面将结合附图，对本公开实施例中的技术方案进行清楚、完整地描述。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

目前，为了使得web应用更贴合用户，需要对web应用数据进行采集。具体地，Web应用包含基于基于浏览器技术的客户端和基于web服务的服务端。web应用的客户端通过埋点的方式，采集埋点数据，通过HTTP请求的方式发送埋点数据到服务端，最终埋点数据经过卡夫卡系统(Kafka)落到Hive表中。如此，完成了一次埋点数据的采集。

埋点丢失率的计算过程一般是，从目标Hive表中根据产品标识和网页域名取出当天24小时产生的埋点数据，再以设备标识为维度对埋点数据分组，分别将带有该产品标识、网页域名和设备标识的数据按照客户端时间戳从小到大进行排序，排序完成后埋点数量标识无缺失情况下应该是从小到大连续递增的。将埋点数量最大标识设为Max，埋点数量最小标识设为Min，预期埋点总条数设为Total＝Max–Min+1，实际埋点条数为Count这里，Count值可以直接从Hive表中查得，该设备标识下丢失埋点条数为Lost＝Total–Count。通过所有设备标识的Lost的累加值除以所有设备身份标识的Total的累加值，可以得到埋点丢失率。由上述埋点丢失率计算方法可知，埋点丢失的数量影响埋点丢失率的大小，在埋点丢失的数量增多的情况下，埋点丢失率增大。

然而，在埋点数据采集过程中，由于客户端、网络、服务端等异常导致埋点上报失败未成功，或者由于页面关闭，导致未有及时上报埋点数据或者为及接收到请求结果，导致埋点数据未成功落入数据库，使得埋点数据丢失，从而使得埋点丢失率提高，降低埋点数据质量。

有鉴于此，本公开提出一种存储上报失败埋点数据以及重上报失败埋点数据的方案，使得上报失败的埋点数据可以进行存储，并且再次上报，从而避免了埋点数据的丢失。

图1是根据一示例性实施例示出的一种埋点数据处理方法的流程图，如图1所示，埋点数据处理方法用于客户端中，包括以下步骤。

在步骤S11中，在第一埋点上报请求发送异常的情况下，将第一埋点上报请求中的第一埋点数据存储在存储区域，以便向服务端再次上报所述第一埋点数据。

这里，存储区域可以包括失败埋点队列，还可以包括本地存储。其中，失败埋点队列用于在浏览器页面运行时存储第一埋点数据。本地存储用于在所述浏览器页面关闭时存储第一埋点数据。可选地，失败埋点队列可以用“FailedLogQueue”表示。本地存储可以为数据在浏览器中存储在本地的区域。可选地，本地存储可以为超文本标记语言5.0(HyperText Markup Language 5.0，HTML5)中本地存储(localstorage)。

在步骤S11中，客户端检测到第一埋点上报请求发送异常后，从第一埋点上报请求中，获取第一埋点数据。并且根据浏览器页面运行状态，确定是将第一埋点上报请求携带的第一埋点数据存储在失败埋点队列，还是存储在本地存储。从而以便后续从存储区域读取发送异常的埋点数据，并向服务端再次上报异常的埋点数据。

在本公开实施例中，在第一埋点上报请求发送异常的情况下，将发送异常的第一埋点数据存储在存储区域，其中，所述存储区域包括失败埋点队列或本地存储。并且根据浏览器页面的运行状态，确定将第一埋点数据存储在失败埋点对列还是本地存储。如此，能够利用客户端存储机制来确保上报异常的埋点数据不丢失，以便后续利用埋点数据重新发送机制来确保埋点数据成功发送，从而能够减少丢失埋点数据的数量，降低埋点数据的丢失率。

在一些实施例中，在步骤S11中，第一埋点上报请求可以为HTTP协议请求。

在一些实施例中，在步骤S11中，第一埋点数据为发送异常的第一埋点上报请求中携带的埋点数据。

这里，第一埋点数据可以为客户端立即上报的埋点数据，也可以为埋点上报队列中的埋点数据。埋点上报队列可以为浏览器页面运行过程中产生的埋点数据存放的队列。可选地，埋点上报队列可以用“LogQueue”表示。此外，第一埋点数据也可以为本地存储中的埋点数据，还可以为埋点失败队列中的埋点数据。

在一些实施例中，客户端对埋点数据的上报可以采用不同的埋点上报方式。例如，客户端可以采用立即上报(sendImmediately)方式上报埋点数据，或者采用先收集(collect)后批量上报埋点数据。

这里，先采集后批量上报方式具体可以包括以下步骤：客户端收集埋点数据，将收集到的埋点数据存放在埋点上报队列中，在满足批量上报条件的情况下，客户端将埋点上报队列中的埋点数据进行批量上报。

其中，批量上报条件可以为以下任意一种：在埋点上报队列中数据超过预设数量；在第一预设时间内未收集到新的埋点数据；每隔固定的时间段。可选地，第一预设时间为2秒。

在一些实施例中，在步骤S11中，第一埋点上报请求发送异常可以为浏览器运行时，第一埋点上报请求失败。第一埋点上报请求发送异常也可以为浏览器页面异常或者关闭前，未及时发送第一埋点上报请求，第一埋点上报请求发送异常还可以为浏览器页面异常或者关闭前，未接收到服务端发送的第一埋点上报请求结果。

这里，客户端利用埋点上报(sender)，生成携带埋点数据的埋点上报请求，并向服务端发送埋点上报请求。服务端向客户端返回埋点上报请求结果，至此，本次埋点数据上报过程结束。从而客户端可以根据服务端返回的埋点上报请求结果以及是否接收到埋点上报请求结果，来判断第一埋点上报请求是否异常。

由于在浏览器页面关闭后，客户端无法保证能够成功发送埋点数据上报请求，以及及时接收到服务端发送的埋点数据上报请求结果。因此，在浏览器页面关闭后，可能会发生第一埋点上报请求发送异常。

在一些实施例中，在步骤S11中，在浏览器正常运行时，将第一埋点数据存储在失败埋点队列中。在浏览器页面关闭或异常时，将第一埋点数据存储在本地存储中。

在一些实施例中，在步骤S11中，在第一埋点上报请求发送异常的情况下，所述在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，可以包括：

在确定浏览器页面运行，并且第一埋点上报请求发送失败的情况下，将第一埋点上报请求中的第一埋点数据存储在失败埋点队列。

这里，客户端可以通过监听页面运行事件，确定浏览器页面运行。在浏览器页面运行时，客户端接收到第一埋点上报请求结果失败或者超过预设时间未接收到第一埋点上报请求结果，可以确定第一埋点上报请求失败。

此外，客户端检测到以下至少之一的情况，可以确定第一埋点上报请求发送失败：连接服务端和客户端之间的通信网络异常；服务端异常；客户端异常。

具体地，在浏览器页面运行的情况下，客户端确定第一埋点上报请求发送失败，即第一埋点数据上报失败，从而将上报失败的第一埋点数据存储在失败的埋点队列中。

例如，在浏览器页面运行过程中，由于网络异常、客户端异常以及服务端异常等原因导致埋点上报请求(即第一埋点上报请求)失败(包括超期未返回请求结果)，客户端将埋点上报请求失败的埋点数据(即第一埋点数据)存储在埋点失败队列中。

在上述实施例中，在浏览器页面运行的情况下，将上报请求失败的埋点数据存储在失败埋点队列，从而解决了在客户端中上报失败埋点数据丢失的问题。

在一些实施例中，在步骤S11中，在第一埋点上报请求发送异常的情况下，在第一埋点上报请求发送异常的情况下，将第一埋点上报请求中的第一埋点数据存储在存储区域，可以包括：

在确定浏览器页面关闭，且未发送第一埋点上报请求或未接收到第一埋点上报请求的返回结果的情况下，将第一埋点上报请求中的第一埋点数据存储在本地存储中。

这里，第一埋点数据可以为埋点上报队列和失败埋点队列中的埋点数据。客户端通过监听浏览器页面关闭事件，例如pagehide、beforeunload、unload等页面事件，判断浏览器页是否关闭。客户端检测到浏览器页面关闭时，埋点上报队列和失败埋点队列中存在待上报的第一埋点数据，可以确定第一埋点上报请求未及时发送，可以将第一埋点数据存储在本地存储中。可选地，本地存储可以为localstorage。

此外，由于客户端在浏览器页面关闭后，未接收到第一埋点上报请求结果，从而客户端无法判断第一埋点上报请求是否发送成功。因此，将第一埋点数据存储在本地存储中，以便后续重新上报埋点数据，避免埋点数据丢失。

例如，客户端通过监听window的pagehide、beforeunload、unload等事件判断页面即将关闭，如果页面关闭前LogQueue和FailedLogQueue中依然有埋点数据(即第一埋点数据)，则优先通过浏览器的navigator.sendBeacon方法发送埋点数据，同时将埋点数据存储到本地的localStorage(即本地存储)中。

在上述实施例中，在浏览器页面关闭的情况下，将未上报的埋点数据和上报结果未知的埋点数据存储在本地存储中，如此，在浏览器页面关闭的情况下，能够及时保存上报未成功的埋点数据。

在一些实施例中，为保证相同域名下多网页同时操作localStorage的安全性，在步骤S11，将第一埋点上报请求中的第一埋点数据存储在本地存储中之前，该埋点数据处理方法还可以包括以下步骤：

根据第一埋点上报请求中的第一埋点数据，生成与第一埋点数据对应的存储标识。

这里，第一埋点数据携带前缀标识、优先级以及客户端时间戳。第一埋点数据均有唯一的存储标识对应。存储标识包括前缀标识、优先级、客户端时间戳和随机字符串。其中，前缀标识用于标记识别存储的埋点，随机字串用于保证存储标识唯一并且不冲突，优先级为埋点的优先级，客户端时间戳为埋点数据产生的时间。

可选地，生成存储标识的规则可以为：前缀标识+优先级+客户端时间戳+16位随机字符串并以下划线分割，例如：storedlogs_0_161599817905_2027226007EF69AE。

具体地，客户端在将第一埋点数据存储在本地存储之前，根据第一埋点数据携带的前缀标识、优先级以及客户端时间戳，按照生成存储标识生成与第一埋点数据唯一对应的存储标识。

在本公开实施例中，客户端采用localstorge进行本地存储。由于localstorge为标准的键值(Key-Value，简称KV)数据类型。因此，客户端根据第一埋点数据携带的前缀标识、优先级以及客户端时间戳，以及随机字串，生成与第一埋点数据对应的键值(即key值)。这里key值唯一并且不冲突。

在上述实施例中，客户端根据埋点数据携带的前缀标识、优先级以及客户端时间戳，生成与埋点数据唯一对应的存储标识，一方面根据存储标识标识不同的埋点数据，以便后续快速查找埋点数据。另一方面保证相同域名下多网页同时操作localStorage的安全性。

在一些实施例中，为了便于快速查找埋点数据。在步骤S11中，将所述第一埋点上报请求中的第一埋点数据存储在本地存储中，可以包括：

将存储标识与第一埋点数据关联存储在本地存储中。

这里，第一埋点数据与存储标识唯一对应。客户端将存储标识与第一埋点数据关联，并且将存储标识与第一埋点数据存储在本地存储中，如此，便于后续根据存储标识快速查找埋点数据。

例如，客户端采用localstorge进行本地存储。具体地，客户端利用键值对(key＝value)对第一埋点数据进行本地存储。其中，每个key(即存储标识)后面对应着相应的值(即第一埋点数据)。

在一些实施例中，为了保证存储区域的存储空间富裕，以使待存储的埋点数据可以全部存储在存储区域。在步骤S11，将所述第一埋点上报请求中的第一埋点数据存储在本地存储中之前，该埋点数据处理方法还可以包括以下步骤：

在存储区域中的埋点数据的数量大于第一阈值的情况下，按照埋点数据的优先级和客户端时间戳，清除存储区域中的埋点数据，以使清除后的存储区域中的埋点数据的数量小于第二阈值。

这里，第二阈值不大于第一阈值。客户端检测存储区域中的埋点数据的数量是否大于第一阈值。在存储区域中的埋点数据的数量大于第一阈值的情况下，客户端按照埋点数据对应的埋点数据的优先级以及客户端时间戳，丢弃部分埋点数据，从而使得存储区域的埋点数据的数量小于第二阈值，以便存储区域有足够空间存储第一埋点数据。

在一些实施例中，由于不同的存储区域的存储空间大小不同。因此，第一阈值的取值范围也不同。

例如，在存储区域为失败埋点队列的情况下，第一阈值可以为100。在存储区域为本地存储的情况下，第一阈值可以为50。

在一些实施例中，在步骤S11之后，该埋点数据处理方还包括：

从存储区域中的至少一个第一埋点数据中读取第二埋点数据。

基于第二埋点数据生成第二埋点上报请求，并向服务端发送所述第二埋点上报请求。

这里，第二埋点数据可以包括第一数量的埋点数据。其中，第一数量小于一个http清求携带的最大埋点数据量。存储区域可以存储至少一个上报失败的第一埋点数据，第一埋点数据可以包括多条埋点数据。

在本公开实施例中，在确认可以重新发送上报失败的埋点数据的情况下，客户端从存储区域存储的埋点数据中读取预设数量的埋点数据，作为第二埋点数据。客户端基于第二埋点数据，生成携带第二埋点数据的第二埋点上报请求，并向服务端发送第二埋点上报请求。如此，实现了失败埋点数据的再次上报。

在一些实施例中，从存储区域中的至少一个所述第一埋点数据中读取第二埋点数据，可以包括：

在最近一次的埋点上报请求发送成功的情况下，从所述失败埋点队列中的至少一个所述第一埋点数据中读取第二埋点数据。

这里，客户端通过最近一次发送埋点上报请求成功，可以确定客户端、服务端以及通信网络均正常，从而可以保证发送埋点上报请求成功。客户端在最近一次发送埋点上报请求成功后，在确定浏览器页面处于运行状态的情况下，从失败埋点队列中读取预设数量的第二埋点数据，生成第二埋点上报请求，并向服务端发送第二埋点上报请求。

如此，在浏览器页面运行的情况下，通过失败埋点队列，完成上一次上报失败的埋点数据的再次上报，减少丢失上报失败的埋点数据的数量。

在一些实施例中，所述从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据，可以包括：

在检测到所述浏览器页面开启预设时间段并且所述浏览器页面处于开启状态的情况下，从所述本地存储中的至少一个所述第一埋点数据中读取第二埋点数据。

这里，客户端可以通过监听浏览器页面启动事件，确定浏览器页面是否开启。可选地，浏览器页面启动事件可以为加载事件，还可以为web日志初始化事件。

此外，由于浏览器页面打开时，客户端会产生采集大量的日志数据。因此，为了减轻客户端的运行负担以及保证埋点数据的成功上报，客户端在浏览器页面打开一段时间后，从本地存储中读取第一数量的埋点数据，以及上报埋点数据。

可选地，客户端从本地存储区域读取第一数量的埋点数据，可以为客户端遍历本地存储，读取与存储标识对应的埋点数据，根据埋点数据的优先级以及客户端的时间戳，确定上报的第一数量的埋点数据。

在上述实施例中，在浏览器页面打开后，客户端从本地存储中读取上次浏览器页面关闭时存储的埋点数据，生成第二埋点上报请求，并向服务端发送，如此，完成了浏览器页面关闭前采集的埋点数据的上报，减少了丢失埋点数据的数量。

在一些实施例中，为了防止重复上报埋点数据，在基于所述第二埋点数据生成第二埋点上报请求，并向所述服务端发送所述第二埋点上报请求之后，该埋点数据处理方法还包括：

在接收第二埋点上报请求结果为成功的情况下，清除存储区域中预设数量的第二埋点数据。

这里，第二埋点上报请求结果可以为服务端发送的第二埋点上报请求的响应结果。客户端在接收到第二埋点上报请求结果后，判断是否清楚存储区域的第二埋点数据。在第二埋点上报请求结果为成功的情况下，客户端可以确定第二埋点数据上报成功，从而清除存储区域中上报成功的第二埋点数据。

在上述实施例中，客户端在埋点数据上报成功后，及时清除存储区域中上报成功的埋点数据，从而一方面节约了存储空间，以便后续存储埋点数据。另一方面，减少埋点数据的重复上报。

图2是根据一示例性实施例示出的另一种埋点数据处理方法的流程图，如图2所示，埋点数据处理方法用于服务端中，包括以下步骤。

在步骤S21中，接收客户端发送的第二埋点上报请求。

这里，所述第二埋点上报请求携带从所述存储区域中的至少一个所述第一埋点数据中读取的第二埋点数据。存储区域用于在第一埋点上报请求发送异常的情况下，所述客户端将所述第一埋点上报请求中的第一埋点数据进行存储的区域。

在上述实施例中，能够利用客户端存储机制来确保客户端的埋点数据不丢失，并且利用埋点数据重新发送机制来确保埋点数据成功发送，从而能够减少丢失埋点数据的数量，降低埋点数据的丢失率。

在一些实施例中，在步骤S21之后，该埋点数据处理方法还包括：

解析第二埋点上报请求，得到预设数量的第二埋点数据；

将第二埋点数据存储在数据库中。

在一些实施例中，服务端按照固定的报文结构解析第二埋点上报请求，得到上报的第二埋点数据。可选地，固定的报文结构为HTTP请求报文结构。

本公开实施例涉及的“数据库”可以为离线数据库，还可以为实时数据库。例如数据库可以为hive。

可选地，服务端利用消息系统，例如卡夫卡(kafka)系统，将第二埋点数据将第二埋点数据落库到实时数据库和离线数据库中，以便消费侧消费埋点数据。

在一些实施例中，为了提高埋点数据质量，在步骤S23之前，该埋点数据处理方法还可以包括：

基于第二埋点数据中的目标参数，对第二埋点数据进行去重处理。

这里，目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。其中，每产生一条埋点数据时，埋点数量标识增加1。产品标识用于标识web应用，与web应用一一对应。设备标识用于标识埋点设备的通用唯一识别码。域名为当前网页域名。

需要说明的是，在本公开实施例中，web客户端在产生埋点数据时，会在埋点数据中增加目标参数。

服务端根据第二埋点数据中的目标参数，判断出是否存在重复的埋点数据。在存在重复的埋点数据的情况下，服务端清除重复的埋点数据。

在上述实施例中，服务端根据埋点数据的目标参数，对埋点数据进行去重处理，从而去除重复的埋点数据，提高埋点数据质量。

在一些实施例中，为了便于提高去重处理的效率。基于所述第二埋点数据中的目标参数，对所述第二埋点数据进行去重处理，可以包括以下步骤：

根据目标参数对第二埋点数据进行排序；

删除排序后第二埋点数据中重复埋点数据。

这里，重复埋点数据为与历史埋点数据具有相同的目标参数的第二埋点数据。历史埋点数据包括在得到第二埋点数据之前存储的埋点数据。

在上述实施例中，服务端按照第二埋点数据对应的目标参数对第二埋点数据进行排序，如此，可以将目标参数类似的第二埋点数据分配在一起，便于查看是否有重复的埋点数据。服务端比较第二埋点数据与历史埋点数据的目标参数是否一致。若一致，服务端可以确定第二埋点数据为重复埋点数据，清除第二埋点数据，从而去除重复上报的埋点数据，提高埋点数据质量。

在一些实施例中，根据所述目标参数对第二埋点数据进行排序，可以包括：

根据设备标识对第二埋点数据进行分组，得到分组数据；

在分组数据中，将具有相同的产品标识和相同的网页域名的埋点数据按照客户端时间戳进行排序；

将排序后的埋点数据按照埋点数量标识进行排序。

这里，服务端可以以设备标识为维度对埋点数据进行分组。对于每个分组，服务端将具有相同的产品标识和相同的网页域名的埋点数据按照客户端时间戳进行排序。可选地，服务端可以按照客户端时间戳从小到大的顺序对埋点数据进行排序。最终，服务端对排序后的埋点数据按照埋点数量标识再次进行排序。可选地，服务端按照埋点数量标识从小到大的顺序对埋点数据进行排序。

需要说明的是，埋点数据的排序方式有多种，例如先根据产品标识进行分组，然后将具有相同的设备标识和网页域名的埋点数据分配在一起，再根据客户端时间戳以及埋点数量标识进行排序。在本公开实施例中，对于埋点数据的排序方式不做限制。

在一些实施例中，为了提高埋点数据质量，数据库用于基于第二埋点数据中的目标参数，对第二埋点数据进行去重处理，并且存储去重后的埋点数据。

这里，目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。数据对第二埋点数据进行去重处理的方法与前述实施例中服务端对第二埋点数据进行处理方法相同，为简要起见，这里不再赘述。

在上述实施例中，数据库在存储埋点数据之前，可以进行去重处理，从而避免存储重复的埋点数据，进而提高埋点数据质量，降低埋点丢失率。

在实际应用中，发明人在桌面web端验证上述埋点数据处理方法，通过多次统计数据库中的埋点数据，发现能够将埋点丢失率从1％降低到0.5％。

为了进一步理解本公开实施例提供的埋点数据处理方法，本公开实施例还提供另一种埋点数据处理系统。图3是根据一示例性实施例示出的一种埋点数据数据处理系统的组成框图。如图3示，埋点数据处理系统30包括：客户端31和服务端32。

客户端31，被配置为执行在浏览器页面运行过程中，获取埋点数据；还被配置为执行调用不同的上报方法对埋点数据进行上报；还被配置为执行根据待上报的埋点数据，生成埋点上报请求，并向服务端32发送。

服务端32，被配置为执行响应埋点上报请求，返回请求结果。

在一些实施例中，上报方法可以包括立即上报，还可以包收集上报。

在一些实施例中，客户端31，被配置为执行在上报方法为收集上报的情况下，将收集到的埋点数据存储在LogQueue(即埋点上报队列)中。

在一些实施例中，客户端31，被配置为执行在满足埋点上报队列中埋点数据超过100条或者2秒内没有新的埋点数据存储的条件下，从埋点上报队列中读取批量的埋点数据，将批量的埋点数据进行上报。

在一些实施例中，客户端31，被配置为执行在服务端32返回请求结果为失败或者超期未返回请求结果，并且浏览器页面处于运行状态的情况下，将上报失败的埋点数据(即第一埋点数据)存储在FailedLogQueue(即失败埋点队列)。

在一些实施例中，客户端31，被配置为执行在将上报失败埋点数据存储在FailedLogQueue之前，检测FailedLogQueue中埋点数据的数量是否超过100。在埋点数据的数量超过100的情况下，按照埋点优先级以及先进先出的规则，丢弃埋点数据，以便存储新的埋点数据。

由于浏览器页面处于运行状态时，服务端32返回请求结果为失败或者超期未返回请求结果可能是由于网络异常、客户端异常或者服务端异常导致的。因此，为了提高重新上报埋点数据的成功率，客户端需要在网络、客户端和服务端正常的情况下，重新上报失败的埋点数据。

在一些实施例中，客户端31，被配置为执行在最近一次埋点上报成功之后，立即批量上报失败埋点数组中的埋点数据；在接收到请求结果为成功的情况下，清空FailedLogQueue中的埋点数据；在接收到请求结果为失败的情况下，继续保留FailedLogQueue埋点数据。

在一些实施例中，客户端31，被配置为执行通过监听window的pagehide、beforeunload、unload等事件，判断浏览器页面即将关闭；在浏览器关闭前，LogQueue和FailedLogQueue中存有埋点数据，将埋点数据存储到本地的localStorage(即本地存储)中。

这里，由于操作相同的key值时会产生线程竞争，数据存储会与预期不。因此，为了保证相同域名下多网页同时操作localStorage的安全性，将存储的key根据以下命名规则生成：前缀标识+优先级+客户端时间戳+16位随机字符串并以下划线分割，如storedlogs_0_1615998179052_2027226007EF69AE。其中，前缀标识用来标记识别存储的埋点，优先级和时间戳用于处理本地存储的埋点key数量超过50时的丢弃的顺序，随机字串保证key唯一不冲突。

由于浏览器页面打开的时候，会产生较多的日志，因此，为了减轻客户端的运行负担，客户端可以在页面开启一端时间后进行埋点数据的上报。

在一些实施例中，客户端31，被配置为执行通过监听load事件或web日志初始化，确定浏览器页面打开预设时间段后，读取本地存储中的埋点数据进行批量上报。可选地，预设时间段可以为3秒。

这里，读取本地存储中的埋点数据过程可以为遍历localStorage，读取符合命名规则的key，从而得到埋点数据。具体地，在下次同域名页面打开时，客户端可以根据前缀标识读取本地存储的埋点数据，再根据埋点的优先级以及客户端时间戳进行埋点数据上报。

此外，客户端可以控制批量上报的埋点数据的数量和时间间隔。例如，批量上报的数量为100条，时间间隔为1秒。

在一些实施例中，在客户端支持navigator.sendBeacon方法的情况下，客户端，还被配置为执行在浏览器关闭前，LogQueue和FailedLogQueue中存有埋点数据，通过浏览器的navigator.sendBeacon方法发送埋点数据。

由于存在上报的埋点数据可能因为关闭前未得到返回结果等情况，客户端31不确定埋点是否上报成功。因此，客户端31会将埋点存到本地存储中，并且再次上报。如此，可能导致埋点数据会重复上报，进而降低埋点数据质量。

在一些实施例中，服务端32，被配置为执行对埋点数据进行比对，并且去除重复的埋点数据(即去重处理)。

在一些实施例中，埋点数据处理系统30还包括数据库33。

数据库33，被配置为执行存储埋点数据。

可选地，数据库可以为数据仓库hive。

在一些实施例中，数据库33，被配置为执行对接收的埋点数据进行进行比对，并且去除重复的埋点数据(即去重处理)。

这里，服务端32或者数据库33，根据产品标识、域名、设备标识、客户端时间戳、埋点数量标识对数据进行排序。在至少两个埋点数据的产品标识、域名、设备标识、客户端时间戳、埋点数量标识完全相同的情况下，可以确定这两个埋点数据是重复数据，保留一个埋点数据。

上述实施例中，一方面，客户端利用不同的存储方法存储上报失败以及未及时上报的埋点数据，从而确保客户端不丢失埋点数据。并且通过埋点数据重新上报的机制，以便提高埋点数据上报的成功率，有利于服务端和数据库存储埋点数据，有助于降低埋点丢失率。另一方面，服务端或者数据仓库对埋点数据进行去重处理，从而去除重复的埋点数据，有助于提高埋点数据质量。

图4是根据一示例性实施例示出的一种埋点数据处理装置的组成框图。如图4所示，该装置40应用于客户端，包括第一存储单元41。

该第一存储单元41，被配置为执行在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，以便向服务端再次上报所述第一埋点数据。

这里，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

在一些实施例中，该装置40还包括生成单元和发送单元。

读取单元，被配置为执行从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据。

生成单元，被配置为执行基于所述第二埋点数据生成第二埋点上报请求。

发送单元，被配置为向服务端发送所述第二埋点上报请求。

在一些实施例中，第一存储单元41，具体被配置为执行在确定所述浏览器页面运行，并且第一埋点上报请求发送失败的情况下，将所述第一埋点上报请求中的第一埋点数据存储在所述失败埋点队列。

在一些实施例中，第一存储单元41，具体被配置为执行在确定所述浏览器页面关闭，且未发送第一埋点上报请求或未接收到所述第一埋点上报请求的返回结果的情况下，将所述第一埋点上报请求中的第一埋点数据存储在本地存储中。

在一些是实施例中，该装置40还包括：

标识生成单元，被配置为执行根据所述第一埋点上报请求中的第一埋点数据，生成与所述第一埋点数据对应的存储标识，所述存储标识包括前缀标识、优先级、客户端时间戳和随机字符串。

关联存储单元，被配置为执行将所述存储标识与所述第一埋点数据关联存储在本地存储中。

在一些实施例中，该装置40还包括：

清除单元，被配置为执行在存储区域中的埋点数据的数量大于第一阈值的情况下，按照埋点数据的优先级和客户端时间戳，清除存储区域中的埋点数据，以使清除后的存储区域中的埋点数据的数量小于第二阈值，所述第二阈值不大于第一阈值。

在一些实施例中，读取单元，具体被配置为执行在最近一次的埋点上报请求发送成功的情况下，从所述失败埋点队列中的至少一个所述第一埋点数据中读取第二埋点数据。

在一些实施例中，读取单元，具体被配置为执行在检测到所述浏览器页面开启预设时间段并且所述浏览器页面处于开启状态的情况下，从所述本地存储中的至少一个所述第一埋点数据中读取第二埋点数据。

图5是根据一示例性实施例示出的另一种埋点数据处理装置的组成框图。如图5所示，该装置50应用于服务端，包括接收单元51。

该接收单元51，被配置为执行接收客户端发送的第二埋点上报请求，所述第二埋点上报请求携带从所述存储区域中的至少一个所述第一埋点数据中读取的第二埋点数据。

其中，所述存储区域为在第一埋点上报请求发送异常的情况下，所述客户端将所述第一埋点上报请求中的第一埋点数据进行存储的区域，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

在一些实施例中，该装置50还包括：

解析单元，被配置为执行解析所述第二埋点上报请求，得到所述第二埋点数据。

第二存储单元，被配置为执行将第二埋点数据存储在数据库中。

在一些实施例中，该装置50还包括：

处理单元，被配置为执行基于所述第二埋点数据中的目标参数，对所述第二埋点数据进行去重处理，所述目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。

在一些实施例中，处理单元包括：

排序子单元，被配置为执行根据目标参数对第二埋点数据进行排序；

删除子单元，被配置为执行删除排序后第二埋点数据中重复埋点数据，重复埋点数据为与历史埋点数据具有相同的目标参数的第二埋点数据，历史埋点数据包括在得到所述第二埋点数据之前存储的埋点数据。

排序子单元，具体被配置为执行根据设备标识对所述第二埋点数据进行分组，得到分组数据；在分组数据中，将具有相同的产品标识和相同的网页域名的埋点数据按照客户端时间戳进行排序；将排序后的埋点数据按照所述埋点数量标识进行排序。

在一些实施例中，数据库用于基于所述第二埋点数据中的目标参数，对第二埋点数据进行去重处理，并且存储去重后的埋点数据。目标参数包括产品标识、域名、设备标识、客户端时间戳和埋点数量标识。

关于上述实施例中的装置，其中各个单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图6是根据一示例性实施例示出的一种用于埋点数据处理方法的电子设备的框图。例如电子设备可以包括客户端或者服务端。如图6所示，电子设备60可以包括以下一个或多个组件：处理组件61，存储器62，电力组件63，多媒体组件64，音频组件65，输入/输出(I/O)的接口66，传感器组件67，以及通信组件68。

处理组件61通常控制电子设备60的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件61可以包括一个或多个处理器610来执行指令，以完成上述任一实施例中所述的埋点数据处理方法的全部或部分步骤。此外，处理组件61可以包括一个或多个模块，便于处理组件61和其他组件之间的交互。例如，处理组件61可以包括多媒体模块，以方便多媒体组件64和处理组件61之间的交互。

存储器62被配置为存储各种类型的数据以支持电子设备60的操作。这些数据的示例包括用于在电子设备60上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器62可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电力组件63为电子设备60的各种组件提供电力。电力组件63可以包括电源管理系统，一个或多个电源，及其它与为电子设备60生成、管理和分配电力相关联的组件。

在示例性实施例中，还提供了一种包括指令的计算机可读存储介质，例如包括指令的存储器62，上述指令可由电子设备60的处理器610执行以完成上述任一实施例中所述的埋点数据处理方法。可选地，计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在本公开一些实施例中，还提供了一种计算机程序产品，当计算机程序产品中的指令由电子设备的处理器执行时，使得处理器能够执行上述任一实施例所述的埋点数据处理方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (10)

1.一种埋点数据处理方法，其特征在于，应用于客户端，包括：

在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，以便向服务端再次上报所述第一埋点数据；

其中，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

2.根据权利要求1所述的方法，其特征在于，在所述将所述第一埋点上报请求中的第一埋点数据存储在存储区域之后，所述方法还包括：

从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据；

基于所述第二埋点数据生成第二埋点上报请求，并向所述服务端发送所述第二埋点上报请求。

3.根据权利要求1所述的方法，其特征在于，所述在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，包括：

在确定所述浏览器页面运行，并且第一埋点上报请求发送失败的情况下，将所述第一埋点上报请求中的第一埋点数据存储在所述失败埋点队列；

或者，在确定所述浏览器页面关闭，且未发送第一埋点上报请求或未接收到第一埋点上报请求的返回结果的情况下，将所述第一埋点上报请求中的第一埋点数据存储在本地存储中。

4.根据权利要求2所述的方法，其特征在于，所述从所述存储区域中的至少一个所述第一埋点数据中读取第二埋点数据，包括：

在最近一次的埋点上报请求发送成功的情况下，从所述失败埋点队列中的至少一个所述第一埋点数据中读取第二埋点数据；

或者，在检测到所述浏览器页面开启预设时间段并且所述浏览器页面处于开启状态的情况下，从所述本地存储中的至少一个所述第一埋点数据中读取第二埋点数据。

5.一种埋点数据处理方法，其特征在于，应用于服务端，包括：

接收第二埋点上报请求，所述第二埋点上报请求携带从所述存储区域中的至少一个所述第一埋点数据中读取的第二埋点数据；

其中，所述存储区域为在第一埋点上报请求发送异常的情况下，所述客户端将所述第一埋点上报请求中的第一埋点数据进行存储的区域，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

6.一种埋点数据处理装置，其特征在于，应用于客户端，包括：

第一存储单元，被配置为执行在第一埋点上报请求发送异常的情况下，将所述第一埋点上报请求中的第一埋点数据存储在存储区域，以便向服务端再次上报所述第一埋点数据；

其中，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

7.一种埋点数据处理装置，其特征在于，应用于服务端，包括：

接收单元，被配置为执行接收客户端发送的第二埋点上报请求，所述第二埋点上报请求携带从所述存储区域中的至少一个所述第一埋点数据中读取的第二埋点数据；

其中，所述存储区域为在第一埋点上报请求发送异常的情况下，所述客户端将所述第一埋点上报请求中的第一埋点数据进行存储的区域，所述存储区域包括失败埋点队列或本地存储，所述失败埋点队列用于在浏览器页面运行时存储第一埋点数据，所述本地存储用于在所述浏览器页面关闭时存储第一埋点数据。

8.一种电子设备，其特征在于，包括：

处理器；

用于存储所述处理器可执行指令的存储器；

其中，所述处理器被配置为执行所述指令，以实现如权利要求1至4中任一项所述的埋点数据处理方法，或者如权利要求5所述的埋点数据处理方法。

9.一种计算机可读存储介质，当所述计算机可读存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行如权利要求1至4中任一项所述的埋点数据处理方法，或者如权利要求5所述的埋点数据处理方法。

10.一种计算机程序产品，包括计算机程序或者指令，其特征在于，所述计算机程序或者指令被处理器执行时实现如权利要求1至4中任一项所述的埋点数据处理方法，或者如权利要求5所述的埋点数据处理方法。

Images