CN110113392A - 一种监控app客户端埋点采集完整性的方法及设备 - Google Patents

Abstract

本申请提供了一种监控APP客户端埋点采集完整性的方法及设备，该方案首先获取埋点数据的记录信息，其中，所述记录信息包括埋点数据的生成记录信息和上报记录信息，所述生成记录信息用于表示所述客户端采集到埋点数据的行为，所述上报记录信息用于表示所述埋点数据成功发送至服务端的行为，由此基于生成记录信息和上报记录信息，可以判断控数据采集过程中整体的埋点数据丢失情况，同时也可以判断埋点数据丢失的环节是发生与服务端处理过程中还是发生在客户端处理过程中，因此可以对APP客户端的埋点数据采集完整性进行有效的监控预警。

Description

一种监控APP客户端埋点采集完整性的方法及设备

技术领域

本申请涉及信息技术领域，尤其涉及一种监控APP客户端埋点采集完整性的方法及设备。

背景技术

近年来，互联网技术的不断发展，人们已经习惯在各类用户设备上使用APP(application，应用程序)来帮助完成生活和工作中的各种问题，比如聊天、购物、支付等等。对于这些APP的运营开发等相关人员而言，往往需要追踪APP中的用户行为，从而观察页面相关点击数据，关键路径转化率，分析某个事件活动效果等。

目前追踪APP中用户行为的方式主要是通过埋点的方式进行，常见的埋点技术包括：代码埋点、可视化埋点和无埋点。以代码埋点为例，是指在APP开发过程中，在指定按钮等控件的点击代码内插入代码的方式，在用户使用APP的过程中，点击该控件时，会触发该插入代码，从而采集到用户的行为数据，生成埋点数据。在埋点数据生成之后，需要从客户端发送至服务端，并最终放入数据仓库进行数据统计分析。在此过程中，可能会发生埋点数据丢失，导致入库的埋点数据不完整，但是目前没有较好的方式对埋点数据的完整性进行监控。

申请内容

本申请的目的之一是提供一种监控APP客户端埋点采集完整性的方法及设备。

为实现上述目的，本申请的一些实施例提供一种监控APP客户端埋点采集完整性的方法，其中，该方法包括：

获取埋点数据的记录信息，其中，所述记录信息包括埋点数据的生成记录信息和上报记录信息，所述生成记录信息用于表示所述客户端采集到埋点数据的行为，所述上报记录信息用于表示所述埋点数据成功发送至服务端的行为；

根据所述埋点数据的生成记录信息和上报记录信息，确定所述埋点数据的完整性。

本申请的一些实施例还提供了一种监控APP客户端埋点采集完整性的设备，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行所述监控APP客户端埋点采集完整性的方法。

此外，本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现所述监控APP客户端埋点采集完整性的方法。

本申请的一些实施例提供的方案中，获取埋点数据的记录信息，其中，所述记录信息包括埋点数据的生成记录信息和上报记录信息，所述生成记录信息用于表示所述客户端采集到埋点数据的行为，所述上报记录信息用于表示所述埋点数据成功发送至服务端的行为，由此基于生成记录信息和上报记录信息，可以判断控数据采集过程中整体的埋点数据丢失情况，同时也可以判断埋点数据丢失的环节是发生与服务端处理过程中还是发生在客户端处理过程中，因此可以对APP客户端的埋点数据采集完整性进行有效的监控预警。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为本申请实施例提供的一种监控APP客户端埋点采集完整性的方法的处理流程图；

图2为本申请实施例中APP客户端上报埋点数据的处理流程图；

图3为本申请实施例中确定埋点数据的完整性时的处理流程图；

图4为本申请实施例中的系统在实现埋点数据完整性监控过程中的处理流程图；

图5为本申请实施例提供的一种监控APP客户端埋点采集完整性的设备的结构示意图；

附图中相同或相似的附图标记代表相同或相似的部件。

具体实施方式

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

在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本申请实施例提供了一种监控APP客户端埋点采集完整性的方法，该方法基于生成记录信息和上报记录信息，可以判断控数据采集过程中整体的埋点数据丢失情况，同时也可以判断埋点数据丢失的环节是发生与服务端处理过程中还是发生在客户端处理过程中，因此可以对APP客户端的埋点数据采集完整性进行有效的监控预警。同时，本申请的方案对服务端无任何入侵，实施十分方便，并且还可以扩展到其他完全不同异构系统之间数据传输完整性的检测。

在实际场景中，该方法的执行主体可以是用户设备、或者用户设备与网络设备通过网络相集成所构成的设备，或者也可以是运行于上述设备的应用程序，所述用户设备包括但不限于计算机、手机、平板电脑等各类终端设备，所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现，可以用于实现设置闹钟时的部分处理功能。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。

图1示出了本申请实施例提供的一种监控APP客户端埋点采集完整性的方法，该方法至少包括以下步骤：

步骤S101，获取埋点数据的记录信息。埋点数据的记录信息由采集埋点数据的APP客户端生成，并与埋点数据一起上传至服务端，然后由服务端写入数据仓库中，本申请的方案是通过从获取数据仓库中埋点数据的记录信息，该记录信息包括了埋点数据的生成记录信息和上报记录信息，所述生成记录信息用于表示所述客户端采集到埋点数据的行为，所述上报记录信息用于表示所述埋点数据成功发送至服务端的行为，通过上述两种记录信息实现埋点数据采集完整性的监控。

其中，所述APP客户端为运行APP应用程序的终端设备，所述终端设备可以是智能手机，计算机，数字广播终端，消息收发设备，游戏控制台，车载控制台，平板设备，医疗设备，健身设备，个人数字助理等。在一些实施例中，所述APP客户端可以是智能手机APP客户端。所述智能手机可以使用包括但不限于Android、iOS、WindowsPhone、Symbian、BlackBerryOS和WindowsMobile等操作系统。

首先，所述APP客户端获取埋点数据。

在本申请的一些实施例中，APP客户端可以获取埋点数据。所述埋点数据至少包括以下一种数据：点击事件、页面事件。例如，点击事件主要描述用户在APP应用内的点击行为，如点击tab、点击按钮等。在一些实施例中，参数事件也被归类为点击事件，如页面描述、试听时长等，把这些参数事件归类为点击事件主要是方便页面事件计算用户APP应用使用时长。再例如，页面事件主要描述用户浏览过的页面，如首页、详情页等，同时通过页面停留时长计算用户APP应用使用时长。

在本申请的一些实施例中，所述获取埋点数据的方法至少包括以下一种方式：通过预置代码获取埋点数据、通过截屏获取埋点数据或者通过控件绑定获取埋点数据。在一些实施例中，可以通过预置代码获取埋点数据。例如，当控件操作发生时，通过预先写好的代码来获取埋点数据。在另一些实施例中，可以通过截屏获取埋点数据。例如，当发生用户点击事件时，利用可视化交互手段，通过可视化界面配置控件操作与点击事件操作发生关系，通过APP应用后台截屏的方式采集埋点数据。在另一些实施例中，可以通过控件绑定获取埋点数据。例如，当用户展现界面元素时，预先跟踪所有的渲染信息，通过控件绑定点击事件，获取埋点数据。

当采集到埋点数据时，APP客户端会为每个埋点数据分配生成记录信息，该生成记录信息用于表示所述客户端采集到埋点数据的行为，例如所述生成记录信息可以包括埋点数据生成时的生成流水号，当客户端通过埋点采集到埋点数据时，会为该埋点数据分配一个生成流水号(记为iSeq)，同时存储埋点数据及其对应的生成流水号。该生成流水号依次递增，用以标记埋点数据的采集顺序，从而区分每个埋点数据。

在本申请的一些实施例中，所述生成流水号iSeq可以由APP客户端的iSeq生成器生成。所述iSeq生成器可以是计数器等任何可以产生连续的流水号(例如1、2、3…等)的程序、应用和逻辑电路等。所述连续的流水号可以是二进制、十进制等。由于APP客户端在采集到埋点数据之后，需要为每个埋点数据分配相应的生成流水号，以区分每次获得的埋点数据，因此iSeq生成器在生成连续的流水号时，可以在每次埋点触发时对当前的iSeq进行累加并保存，从而为按顺序为每次采集到的埋点数据分配连续的生成流水号。例如，在一段时间内，APP客户端采集到了7个埋点数据，可以为每个埋点数据分配的iSeq，可以分别为1、2、3、4、5、6、7，即data1(iSeq＝1)、data2(iSeq＝2)、data3(iSeq＝3)、data4(iSeq＝4)、data5(iSeq＝5)、data6(iSeq＝6)、data7(iSeq＝7)。

在采集并保存埋点数据之后，APP客户端可以根据一定的触发条件向服务端上报这些埋点数据。所述触发上报埋点数据的触发条件可以是页面打开触发和程序应用启动触发等，也可以是当所述埋点数据累计到一定数量(例如10条或20条等)触发，从而实现实时上报所述埋点数据。在上报埋点数据时，为待上报的埋点数据分配上报水流号(sSeq)，每次进行上报时可以根据顺序逐条上报所述埋点数据，也可以同时上报多条埋点数据。

sSeq可以由APP客户端的sSeq生成器生成。所述sSeq生成器可以是计数器等任何可以产生连续的流水号(例如1、2、3…等)的程序、应用和逻辑电路等。所述连续的流水号可以是二进制、十进制等。由于该上报水流号用于表示埋点数据成功发送至服务端的行为，因此sSeq生成器在生成连续的流水号时，可以在确定每次上报行为成功后(例如接收到服务端返回的接收成功的消息)，对当前的sSeq进行保存，从而为按顺序为每次发送的埋点数据分配连续的上报流水号。

例如，对于前述APP客户端采集到了7个埋点数据，若每次上报两条埋点数据，其上报时的处理流程如图2所示，包括以下步骤：

步骤S201，取出存储的前两条埋点数据data1(iSeq＝1)、data2(iSeq＝2)，为其添加上报水流号sSeq，若sSeq的初始值为0，则为data1和data2分配的sSeq分别为1和2，添加至其记录信息中，由此可得data1(iSeq＝1，sSeq＝1)和data2(iSeq＝2，sSeq＝2)。然后，向服务端上传携带有记录信息的两条埋点数据，在接收服务端返回的成功消息之后，确认上报成功，更新sSeq为当前值2。在实际场景中，也可能出现上报不成功的情况，此时将无法收到服务端返回的成功消息，若未在预设时间内未收到服务端返回的成功消息，可以尝试再次发送，直至成功。

步骤S202，然后取出存储的后续两条埋点数据，在正常情况下，即为data3(iSeq＝3)和data4(iSeq＝4)。在本申请实施例中，若data3(iSeq＝3)处于某个原因在客户端的存储过程中丢失，此时本步骤中取出的后续两条埋点数据即为data4(iSeq＝4)和data5(iSeq＝5)。相应地，为其分配的sSeq分别为3和4，由此两条埋点数据即为data4(iSeq＝4，sSeq＝3)和data5(iSeq＝5，sSeq＝4)。向服务端上传携带有记录信息的两条埋点数据，在接收服务端返回的成功消息之后，确认上报成功，更新sSeq为当前值4。

步骤S203，接着取出后续两条埋点数据data6(iSeq＝6)和data7(iSeq＝7)，为其添加sSeq之后，即为data6(iSeq＝6，sSeq＝5)和data7(iSeq＝7，sSeq＝6)。向服务端上传并确认上报成功后，更新sSeq为当前值6。

服务端在接收到客户端上报的埋点数据之后，对将其写入数据仓库，以用于数据分析。在实际场景中，服务端可以在每次接收到上报的埋点数据后就将其写入数据仓库，也可以在接收到预设数量的埋点数据之后一起写入。例如，在本申请实施例中，每次接收到两条上报的埋点数据之后，就将其写入数据仓库，若在此过程中，服务端在向数据仓库写入data4(iSeq＝4，sSeq＝3)和data5(iSeq＝5，sSeq＝4)时由于发生异常造成数据丢失，由此造成了最终数据仓库中仅有4个埋点数据即data1(iSeq＝1，sSeq＝1)、data2(iSeq＝2，sSeq＝2)、data6(iSeq＝6，sSeq＝5)和data7(iSeq＝7，sSeq＝6)。

步骤S102，根据所述埋点数据的生成记录信息和上报记录信息，确定所述埋点数据的完整性。

对于前例中数据仓库中的4条埋点数据data1～4，其生成记录信息分别为生成流水号iSeq＝1、iSeq＝2、iSeq＝6、iSeq＝7，其上报记录信息分别为上报流水号sSeq＝1、sSeq＝2、sSeq＝5、sSeq＝6。根据所述埋点数据的生成流水号和上报流水号，即可确定所述埋点数据的完整性，其中，所述完整性的内容至少包括所述埋点数据是否有丢失以及发生埋点数据丢失的环节。

由此，在根据所述埋点数据的生成流水号和上报流水号，确定所述埋点数据的完整性时，可以采用图3所示的处理步骤：

步骤S301，根据所述埋点数据的生成流水号计算所述埋点数据的生成流水号中缺失的流水号数量。例如，对于data1(iSeq＝1，sSeq＝1)、data2(iSeq＝2，sSeq＝2)、data6(iSeq＝6，sSeq＝5)和data7(iSeq＝7，sSeq＝6)这4个埋点数据，其生成流水号中缺失的流水号数量为3个，即为iSeq＝3、iSeq＝4、iSeq＝5。本申请实施例中提供了一种快速计算所述埋点数据的生成流水号中缺失的流水号数量的方法，即根据以下公式进行计算：

totalRecordMissCount＝expectTotalRecordCount-count(distinct iSeq)

其中，expectTotalRecordCount为埋点数据的总预期获取数量，根据最大的生成流水号max(iSeq)以及最小的生成流水号min(iSeq)确定，具体可以采用如下的公式计算：expectTotalRecordCount＝max(iSeq)–min(iSeq)+1，例如对于前例中几个埋点数据的生成流水号，max(iSeq)＝7，min(iSeq)＝1，由此计算得到expectTotalRecordCount＝7-1+1＝7。而count(distinct iSeq)为埋点数据的实际获取数量，通过统计所获取的埋点数据的生成流水号去重后获得，由于前例中几个埋点数据的生成流水号分别为iSeq＝1、iSeq＝2、iSeq＝6、iSeq＝7，去重后确定count(distinct iSeq)＝4。由此可以确定埋点数据的生成流水号中缺失的流水号数量totalRecordMissCount＝7-4＝3。

步骤S302，根据所述埋点数据的上报流水号计算上报流水号中缺失的流水号数量。对于data1(iSeq＝1，sSeq＝1)、data2(iSeq＝2，sSeq＝2)、data6(iSeq＝6，sSeq＝5)和data7(iSeq＝7，sSeq＝6)这4个埋点数据，其上报流水号中缺失的流水号数量为2个，即为sSeq＝4、sSeq＝5。本申请实施例中提供了一种快速计算所述埋点数据的上报流水号中缺失的流水号数量的方法，即根据以下公式进行计算：

serverMissCount＝expectServerCount-count(distinct sSeq)

其中，expectServerCount为来自服务端的埋点数据的预期获取数量，根据最大的上报流水号max(sSeq)以及最小的上报流水号min(sSeq)确定，具体可以采用如下的公式计算：expectServerCount＝max(sSeq)–min(sSeq)+1，例如对于前例中几个埋点数据的上报流水号，max(sSeq)＝6，min(sSeq)＝1，由此计算得到expectServerCount＝6-1+1＝6。而count(distinct sSeq)为埋点数据的实际获取数量，通过统计所获取的埋点数据的上报流水号去重后获得，由于前例中几个埋点数据的上报流水号分别为iSeq＝1、iSeq＝2、iSeq＝5、iSeq＝6，去重后确定count(distinct sSeq)＝4。由此可以确定serverMissCount＝6-4＝2。

在实际场景中，上述步骤S301与步骤S302之间并无先后执行的逻辑依赖顺序，两个步骤之间的处理过程相互独立，也可以同时执行或者先执行步骤S302。

步骤S303，根据所述埋点数据的生成流水号中缺失的流水号数量，以及上报流水号中缺失的流水号数量，确定所述埋点数据是否有丢失以及发生埋点数据丢失的环节。其中，在本申请的实施例中，发生埋点数据丢失的环节主要包括两个，即服务端发生埋点数据丢失以及客户端发生埋点数据丢失。若埋点数据丢失是发生在服务端接收到数据至写入数据仓库的过程中，则认为埋点数据丢失的环节是服务端丢失，若埋点数据丢失是发生客户端采集到埋点数据至上报服务端的过程中，则认为埋点数据丢失的环节是客户端丢失。

在本申请的一些实施例中，可以采用如下的方式判断埋点数据采集的完整性：

1、若所述埋点数据的生成流水号中缺失的流水号数量大于零，确定所述埋点数据有丢失。例如，在前例中埋点数据的生成流水号中缺失的流水号数量totalRecordMissCount＝3＞0，由此可以确定有埋点数据丢失。反之，若所述埋点数据的生成流水号中缺失的流水号数量等于零，则可以认为没有埋点数据丢失。

2、若所述埋点数据的上报流水号中缺失的流水号数量大于零，确定服务端发生埋点数据丢失。在前例中，所述埋点数据的上报流水号中缺失的流水号数量serverMissCount＝2＞0，由此可以确定服务端发生埋点数据丢失。反之，若所述埋点数据的上报流水号中缺失的流水号数量等于零，则可以认为服务端没有发生埋点数据丢失。

3、若所述埋点数据的生成流水号中缺失的流水号数量与上报流水号中缺失的流水号数量之间的差值大于零，确定客户端发生埋点数据丢失。在前例中，埋点数据的生成流水号中缺失的流水号数量与上报流水号中缺失的流水号数量之间的差值可以采用如下公式计算：

clientMissCount＝totalRecordMissCount-serverMissCount

由于，totalRecordMissCount＝3，serverMissCount＝2，可以计算得到两者的差值clientMissCount＝3-2＝1＞0，由此可以确定客户端发生埋点数据丢失。反之，若所述埋点数据的生成流水号中缺失的流水号数量与上报流水号中缺失的流水号数量之间的差值等于零，则可以认为客户端没有发生埋点数据丢失。

在本申请的一些实施例中，还可以进一步地确定在服务端丢失埋点数据的数量以及在客户端丢失埋点数据的数量，从而获取更加详细的关于埋点数据采集完整性的信息，以便于更加准确地定位问题。确定在服务端丢失埋点数据的数量，可以根据所述埋点数据的上报流水号中缺失的流水号数量，即所述埋点数据的上报流水号中缺失的流水号数量等于在服务端丢失埋点数据的数量。例如，在前例中，埋点数据的上报流水号中缺失的流水号数量serverMissCount＝2，由此可知在服务端丢失埋点数据的数量即为2，即在服务端丢失了2条埋点数据。

确定在客户端丢失埋点数据的数量时，则可以根据所述埋点数据的生成流水号中缺失的流水号数量与上报流水号中缺失的流水号数量之间的差值，即该差值即为客户端丢失埋点数据的数量。在前例中，所述埋点数据的生成流水号中缺失的流水号数量与上报流水号中缺失的流水号数量之间的差值clientMissCount＝1，由此可知在客户端丢失埋点数据的数量即为1，即在客户端丢失了1条埋点数据。总计丢失的埋点数据的数量即为totalRecordMissCount＝3。

由此，本申请实施例的方案基于生成记录信息和上报记录信息，可以判断控数据采集过程中整体的埋点数据丢失情况，同时也可以判断埋点数据丢失的环节是发生与服务端处理过程中还是发生在客户端处理过程中，因此可以对APP客户端的埋点数据采集完整性进行有效的监控预警。进一步地，还可以准确检测到每个环节所丢失的埋点数据的具体数量，由此可以计算埋点数据的丢失率等扩展信息，便于更加准确地定位问题。

本申请实施例还给出了前述监控APP客户端埋点采集完整性的方法的一种应用场景，即系统中使用了本申请实施例提供的方法以实现埋点数据的完整性监控。该系统包括APP客户端、服务端、数据仓库以及监控设备，其中，所述数据仓库以及监控设备可以部署于所述服务端中，利用所述服务端的资源实现相应的功能，或者也可以使用独立的设备。该系统中埋点数据的数据存储、数据上报以及数据分析的过程如图4所示，包括如下的处理步骤：

步骤S401，APP客户端生成埋点数据，即通过各类埋点方式采集到埋点数据。

步骤S402，APP客户端获取生成流水号iSeq添加到埋点数据。例如，可以通过iSeq生成器给出iSeq，然后分配给新生成的埋点数据，作为其一项记录信息。

步骤S403，APP客户端保存埋点数据到本地存储。

步骤S404，APP客户端开始上报数据。

步骤S405，APP客户端获取上报流水号sSeq添加到埋点数据。例如，可以通过sSeq生成器给出sSeq，然后分配给待上报的埋点数据，作为其另一项记录信息。

步骤S406，APP客户端确认上报成功后，更新sSeq。服务端在收到上报的埋点数据之后，会写入到数据仓库，在此过程中可能发生埋点数据的丢失。

步骤S407，监控设备取出数据仓库中埋点数据进行分析。

步骤S408，监控设备判断总丢失量是否等于0，该总丢失量可以是前述的totalRecordMissCount。若为是，表示没有埋点数据丢失，结束。若为否，则表示存在数据丢失，执行步骤S409。

步骤S409，监控设备计算服务端丢失量，丢失量即为serverMissCount的值，若大于0，则表示服务端发生了埋点数据丢失。

步骤S410，监控设备计算客户端丢失量，丢失量即为clientMissCount的值，若大于0，则表示客户端发生了埋点数据丢失。

此外，在本申请的另一些实施例中，还提供了一种监控APP客户端埋点采集完整性的设备，该设备的结构如图5所示，包括用于存储计算机程序指令的存储器510和用于执行计算机程序指令的处理器520，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行前述监控APP客户端埋点采集完整性的方法。

另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据程序指令运行的计算机设备的工作存储器中。

此外，本申请的一些实施例还提供了一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

综上所述，本申请实施例提供的方案能够基于生成记录信息和上报记录信息，判断控数据采集过程中整体的埋点数据丢失情况，同时也可以判断埋点数据丢失的环节是发生与服务端处理过程中还是发生在客户端处理过程中，因此可以对APP客户端的埋点数据采集完整性进行有效的监控预警。同时，本申请的方案对服务端无任何入侵，实施十分方便，并且还可以扩展到其他完全不同异构系统之间数据传输完整性的检测。

需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (10)

1.一种监控APP客户端埋点采集完整性的方法，其中，该方法包括：

获取埋点数据的记录信息，其中，所述记录信息包括埋点数据的生成记录信息和上报记录信息，所述生成记录信息用于表示所述客户端采集到埋点数据的行为，所述上报记录信息用于表示所述埋点数据成功发送至服务端的行为；

根据所述埋点数据的生成记录信息和上报记录信息，确定所述埋点数据的完整性。

2.根据权利要求1所述的方法，其中，所述生成记录信息包括生成流水号，所述上报记录信息包括上报流水号，所述；

根据所述埋点数据的生成记录信息和上报记录信息，确定所述埋点数据的完整性，包括：

根据所述埋点数据的生成流水号和上报流水号，确定所述埋点数据的完整性。

3.根据权利要求2所述的方法，其中，根据所述埋点数据的生成流水号和上报流水号，确定所述埋点数据的完整性，包括：

根据所述埋点数据的生成流水号计算所述埋点数据的生成流水号中缺失的流水号数量，以及根据所述埋点数据的上报流水号计算上报流水号中缺失的流水号数量；

根据所述埋点数据的生成流水号中缺失的流水号数量，以及上报流水号中缺失的流水号数量，确定所述埋点数据是否有丢失以及发生埋点数据丢失的环节。

4.根据权利要求3所述的方法，其中，根据所述埋点数据的生成流水号计算所述埋点数据的生成流水号中缺失的流水号数量，包括：

根据以下公式计算所述埋点数据的生成流水号中缺失的流水号数量：

totalRecordMissCount＝expectTotalRecordCount-count(distinct iSeq)

其中，expectTotalRecordCount为埋点数据的总预期获取数量，根据最大的生成流水号以及最小的生成流水号确定，count(distinct iSeq)为埋点数据的实际获取数量，通过统计所获取的埋点数据的生成流水号去重后获得。

5.根据权利要求3所述的方法，其中，根据所述埋点数据的上报流水号计算上报流水号中缺失的流水号数量，包括：

根据以下公式计算所述埋点数据的上报流水号中缺失的流水号数量：

serverMissCount＝expectServerCount-count(distinct sSeq)

其中，expectServerCount为来自服务端的埋点数据的预期获取数量，根据最大的上报流水号以及最小的上报流水号确定，count(distinct sSeq)为埋点数据的实际获取数量，通过统计所获取的埋点数据的上报流水号去重后获得。

6.根据权利要求3至5中任一项所述的方法，其中，根据所述埋点数据的生成流水号中缺失的流水号数量，以及上报流水号中缺失的流水号数量，确定所述埋点数据是否有丢失以及发生埋点数据丢失的环节，包括：

若所述埋点数据的生成流水号中缺失的流水号数量大于零，确定所述埋点数据有丢失；

若所述埋点数据的上报流水号中缺失的流水号数量大于零，确定服务端发生埋点数据丢失；

若所述埋点数据的生成流水号中缺失的流水号数量与上报流水号中缺失的流水号数量之间的差值大于零，确定客户端发生埋点数据丢失。

7.根据权利要求6所述的方法，其中，该方法还包括：

根据所述埋点数据的上报流水号中缺失的流水号数量，确定在服务端丢失埋点数据的数量。

8.根据权利要求6所述的方法，其中，该方法还包括：

根据所述埋点数据的生成流水号中缺失的流水号数量与上报流水号中缺失的流水号数量之间的差值，确定在客户端丢失埋点数据的数量。

9.一种监控APP客户端埋点采集完整性的设备，其中，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备执行权利要求1至8中任一项所述的方法。

10.一种计算机可读介质，其上存储有计算机程序指令，所述计算机可读指令可被处理器执行以实现如权利要求1至8中任一项所述的方法。