CN108363657B - 监控app客户端埋点数据采集完整性的方法、设备以及介质 - Google Patents

监控app客户端埋点数据采集完整性的方法、设备以及介质 Download PDF

Info

Publication number
CN108363657B
CN108363657B CN201810072027.XA CN201810072027A CN108363657B CN 108363657 B CN108363657 B CN 108363657B CN 201810072027 A CN201810072027 A CN 201810072027A CN 108363657 B CN108363657 B CN 108363657B
Authority
CN
China
Prior art keywords
data
buried point
point data
client
reported
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810072027.XA
Other languages
English (en)
Other versions
CN108363657A (zh
Inventor
杨宇晓
李全栋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Chenlian Technology Co.,Ltd.
Original Assignee
Shanghai Lianshang Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Lianshang Network Technology Co Ltd filed Critical Shanghai Lianshang Network Technology Co Ltd
Priority to CN201810072027.XA priority Critical patent/CN108363657B/zh
Publication of CN108363657A publication Critical patent/CN108363657A/zh
Application granted granted Critical
Publication of CN108363657B publication Critical patent/CN108363657B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3438—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment monitoring of user actions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/72406—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality by software upgrading or downloading

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Alarm Systems (AREA)

Abstract

本申请提供一种监控APP客户端埋点数据采集完整性的方法、设备以及介质，其中，所述方法包括：获取客户端上报的埋点数据及其记录信息；根据所述埋点数据及其记录信息，判断所述埋点数据是否完整。本申请可以实现监控数据采集过程中整体的埋点数据丢失率，同时也可以监控埋点数据在服务端和APP客户端处理过程中各自的丢失，对APP客户端的埋点数据采集完整性的监控预警。

Description

监控APP客户端埋点数据采集完整性的方法、设备以及介质
技术领域
本申请属于计算机数据处理技术领域，尤其涉及一种监控APP客户端埋点数据采集完整性的方法、设备以及介质。
背景技术
随着互联网和计算机的高速发展，使用APP(application，应用)的客户端越来越普及，例如APP客户端和便携智能设备、传统计算机上安装的各类软件和应用服务。这些APP、软件等产品运营开发等相关人员需要追踪用户的行为，观察页面相关点击数据，关键路径转化率，分析某个事件活动效果。
目前，数据采集的方式根据采集客户端的不同，主要分为网页数据采集、APP数据采集。网页数据的采集主要是使用JavaScript采集，常用的数据分析工具主要是GoogleAnalytics，APP数据采集主要是通过埋点采集。其中，常见的埋点技术包括：代码埋点、可视化埋点和无埋点。
数据采集的广度和质量直接影响后续分析的环节。例如漏报、误报等，会误导产品运营开发等相关人员基于数据的决策。因此，APP客户端的埋点数据采集是否完整以及具体哪个环节造成数据丢失是亟待处理的问题。
发明内容
有鉴于此，本申请实施例提供了一种监控APP客户端埋点数据采集完整性的方法、设备以及介质，用于解决如下技术问题：APP客户端埋点数据采集是否完整以及具体哪个环节造成数据丢失。
本申请实施例采用下述技术方案：
一种监控APP客户端埋点数据采集完整性的方法，包括：
获取客户端上报的埋点数据及其记录信息；
根据所述埋点数据及其记录信息，判断所述埋点数据是否完整。
在上述的方法中，所述埋点数据的记录信息包括：所述埋点数据的生成流水号；
根据所述埋点数据及其记录信息，判断所述埋点数据是否完整，包括：
根据所述埋点数据的生成流水号，判断所述埋点数据是否完整。
在上述的方法中，根据所述埋点数据的生成流水号，判断所述埋点数据是否完整，包括：
判断所述埋点数据的生成流水号是否连续；
若连续，则所述埋点数据是完整的；否则，所述埋点数据不完整。
在上述的方法中，所述方法还包括：
当所述埋点数据不完整时，根据所述埋点数据的记录信息，确定所述埋点数据的总丢失量，并判断所述埋点数据丢失的环节。
在上述的方法中，所述埋点数据的记录信息还包括：所述客户端一次上报的埋点数据的条数、各条埋点数据的上报流水号、以及历史成功上报数据条数数组；
若所述客户端一次上报的埋点数据的条数大于1，所述客户端该次上报的多条埋点信息的上报流水号相同；
根据所述埋点数据的记录信息，判断所述埋点数据丢失的环节，包括：
根据所述客户端一次上报的埋点数据的条数、各条埋点数据的生成流水号和上报流水号、以及历史成功上报数据条数数组，判断所述埋点数据丢失的环节。
在上述的方法中，根据所述埋点数据的记录信息，确定所述埋点数据的总丢失量，包括：
根据以下公式确定所述埋点数据的总丢失量：
Cm＝Ci-CiSeq；
其中，Cm表示所述埋点数据的总丢失量；Ci表示客户端生成的埋点数据的条数的总数；CiSeq表示所述服务端接收到的埋点数据的条数的总数。
在上述的方法中，判断所述埋点数据丢失的环节，包括：
判断所述埋点数据的上报流水号是否连续；
若不连续，则服务端发生数据丢失。
在上述的方法中，当埋点数据的上报流水号不连续时，根据所述历史成功上报数据条数数组中的数据补出所述客户端一次上报的埋点数据的条数。
在上述的方法中，根据所述客户端各次上报的埋点数据的条数、根据所述历史成功上报数据条数数组中的数据补出的一次上报的埋点数据、以及各条埋点数据的生成流水号，确定所述服务端的数据丢失量。
在上述的方法中，确定所述服务端的数据丢失量通过以下公式确定：
Cfsm＝sum(fixedCurCount)-CiSeq；
其中，Cfsm表示服务端埋点数据丢失量；fixedCurCount表示根据历史成功上报数据条数数组中的数据补充后客户端各次上报成功的埋点数据的条数；sum(fixedCurCount)表示根据历史成功上报数据条数数组中的数据补充后客户端上报成功的埋点数据的条数的总和；Ciseq表示所述服务端接收到的客户端上报的埋点数据的条数的总和。
在上述的方法中，还包括：根据所述服务端的数据丢失量确定客户端的数据丢失量，包括：
所述客户端的数据丢失量通过以下公式确定：
Cfcm＝Cm-Cfsm；
其中，Cfcm表示所述客户端的数据丢失量；Cm表示埋点数据的总丢失量；Cfsm表示所述服务端的数据丢失量。
在上述的方法中，若所述埋点数据的上报流水号连续，则执行以下步骤：
确定服务端的数据丢失量；
根据所述埋点数据的总丢失量和所述服务端的数据丢失量，确定所述客户端的数据丢失量；
若所述服务端的数据丢失量大于0，则所述服务端发生数据丢失；否则，所述服务端未发生数据丢失；
若所述客户端的数据丢失量大于0，则所述客户端发生数据丢失；否则，所述客户端未发生数据丢失。
在上述的方法中，所述服务端的数据丢失量根据以下公式确定：
Csm＝sum(curCount)-CiSeq；
其中，Csm表示所述服务端的数据丢失量；curCount表示客户端一次上报的埋点数据的条数；sum(curCount)表示客户端上报成功的埋点数据的条数的总和；Ciseq为服务端接收上报的埋点数据的条数的总和。
在上述的方法中，所述客户端的数据丢失量通过以下公式确定：
Ccm＝Cm-Csm；
其中，Ccm表示所述客户端的数据丢失量；Cm表示埋点数据的总丢失量；Csm表示所述服务端的数据丢失量。
本申请还提供了一种监控APP客户端埋点数据采集完整性的设备，所述设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该设备执行上述的方法。
本申请更提供了一种计算机可读介质，所述介质存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现如上所述的方法。
在本申请提供的一种监控APP客户端埋点数据采集完整性的方法、设备以及介质中，可以实现精确监控数据采集过程中整体的埋点数据丢失率，同时也可以监控埋点数据在服务端处理过程中或者在客户端存储和上报过程中是否有丢失，对APP客户端的埋点数据采集完整性的监控预警。同时本发明对服务端无任何入侵，实施十分方便。本发明还可以扩展到其他完全不同异构系统之间数据传输是否完整的检测。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请的一些实施例提供的监控APP客户端埋点数据采集完整性方法的流程示意图；
图2为本申请的一些实施例提供的埋点数据预置策略一的流程示意图；
图3为本申请的一些实施例提供的埋点数据预置策略二的流程示意图；和
图4为本申请的一些实施例提供的检测上报的埋点数据是否完整的流程示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
以下结合附图，详细说明本申请各实施例提供的技术方案。
图1为本申请的一些实施例提供的一种监控APP客户端埋点数据采集完整性方法的流程示意图，该方法如下所示。首先获取客户端上报的埋点数据及其记录信息，如图1中的步骤S101，根据所述埋点数据及其记录信息，判断所述埋点数据是否完整，如图1中的步骤S102所示。
需要说明的是，图1的详细流程是示例性的，并非对本申请的限定，根据上面的方案详细说明，监控APP客户端埋点数据采集完整性方法可以有不止一种详细流程。
步骤S101，获取客户端上报的埋点数据及其记录信息。
所述APP客户端为运行APP应用程序的终端设备，所述终端设备可以是智能手机，计算机，数字广播终端，消息收发设备，游戏控制台，车载控制台，平板设备，医疗设备，健身设备，个人数字助理等。在一些实施例中，所述APP客户端可以是智能手机APP客户端。所述智能手机可以使用包括但不限于Android、iOS、Windows Phone、Symbian、BlackBerry OS和Windows Mobile等操作系统。
首先，所述APP客户端获取埋点数据。
在本申请的一些实施例中，APP客户端可以获取埋点数据。所述埋点数据至少包括以下一种数据：点击事件、页面事件。例如，点击事件主要描述用户在APP应用内的点击行为，如点击tab、点击按钮等。在一些实施例中，参数事件也被归类为点击事件，如页面描述、试听时长等，把这些参数事件归类为点击事件主要是方便页面事件计算用户APP应用使用时长。再例如，页面事件主要描述用户浏览过的页面，如首页、详情页等，同时通过页面停留时长计算用户APP应用使用时长。
在本申请的一些实施例中，所述获取埋点数据的方法至少包括以下一种方式：通过预置代码获取埋点数据、通过截屏获取埋点数据或者通过控件绑定获取埋点数据。在一些实施例中，可以通过预置代码获取埋点数据。例如，当控件操作发生时，通过预先写好的代码来获取埋点数据。在另一些实施例中，可以通过截屏获取埋点数据。例如，当发生用户点击事件时，利用可视化交互手段，通过可视化界面配置控件操作与点击事件操作发生关系，通过APP应用后台截屏的方式采集埋点数据。在另一些实施例中，可以通过控件绑定获取埋点数据。例如，当用户展现界面元素时，预先跟踪所有的渲染信息，通过控件绑定点击事件，获取埋点数据。
然后，所述APP客户端按照预置策略一存储埋点数据。
具体的，在本申请的一些实施例中，所述预置策略一可以是由开发人员在APP客户端预先配置完成的。在一些实施例中，APP客户端按照预置策略一存储埋点数据时，同时生成“记录流水号(简称iSeq)”。具体的实施方案将在图2中详细描述。
所述APP客户端按照预置策略二向服务端上报其存储的埋点数据。
在本申请的一些实施例中，所述预置策略二可以是由开发人员在APP客户端预先配置完成的。在一些实施例中，APP客户端按照预置策略二上报埋点数据时，还可以生成成功上报所述埋点数据时的“上报流水号(简称uSeq)”、上报成功的“历史成功上报数据条数数组(简称hisCountList)”和准备上报的“一次上报埋点数据条数(简称curCount)”。具体的实施方案将在图3中详细描述。
也就是说，所述埋点数据的记录信息包括但不限于：所述埋点数据的生成流水号iSeq、所述客户端一次上报的埋点数据的条数curCount、各条埋点数据的上报流水号uSeq、以及历史成功上报数据条数数组hisCountList。需要说明的是，若所述客户端一次上报的埋点数据的条数大于1，所述客户端该次上报的多条埋点信息的上报流水号uSeq相同。
图2为本申请的一些实施例提供的埋点数据预置策略一的流程示意图，该流程如下所示。该埋点数据预置策略一的执行主体可以是APP客户端，具体地，可以是APP客户端的本地存储器。
步骤S201：开始保存埋点数据；
在本申请的一些实施例中，所述保存埋点数据可以由APP客户端的本地存储器实现。所述开始保存埋点数据可以包括触发开始保存埋点数据的条件。在一些实施例中，所述触发条件可以为用户点击APP客户端按钮，所述埋点数据为点击事件。所述APP客户端按钮可以是搜索按钮、下载按钮和浏览按钮等。
步骤S202：获取数据流水号iSeq；
在本申请的一些实施例中，所述流水号iSeq可以由APP客户端的iSeq生成器生成。所述iSeq生成器可以是计数器等任何可以产生连续数列(例如十进制数列：1、2、3…等)的程序、应用和逻辑电路等。所述连续数列可以是二进制和十进制等。所述iSeq生成器可以根据用户点击APP客户端按钮直接触发生成iSeq数列，也可以根据本地存储器发出的获取所述iSeq的请求，生成所述iSeq数列。在一些实施例中，所述iSeq生成器可以是全局的。
步骤S203：处理所述iSeq，并将处理后的iSeq添加到埋点数据；
在本申请的一些实施例中，所述iSeq生成器可以对iSeq进行加一处理。例如，初始iSeq可以为0，每当用户点击APP客户端按钮，则触发所述iSeq生成器对所述iSeq加一并保存；或者，每当本地存储器需要从所述iSeq生成器获取iSeq时，所述iSeq生成器对iSeq加一并保存。在一些实施例中，所述iSeq生成器返回所述加一处理后的iSeq，并将处理后的iSeq添加到所述埋点数据中。在一些实施例中，本地存储器保存每一条通过用户点击APP客户端按钮触发的埋点数据时，都会同时在所述埋点数据中存储连续的iSeq。
在本申请的一些实施例中，所述iSeq可以使用终端外加内存作为缓存，优先修改内存中的iSeq，同时由异步线程将埋点数据保存到APP客户端的本地存储器中。这种方式实现的递增的iSeq具有很强的适应能力，在大多场景下都可以使用，包括终端本地存储空间不足情况下依然能够很好的工作。
需要说明的是，图2的详细流程是示例性的，并非对本申请的限定，根据上面的方案详细说明，埋点数据预置策略一可以有不止一种详细流程。
图3为本申请的一些实施例提供的埋点数据预置策略二的流程示意图，该流程如下所示。该埋点数据预置策略二的执行主体可以是APP客户端，具体地，可以是APP客户端的上报器。
步骤S301：开始上报埋点数据，所述埋点数据包括iSeq；
在本申请的一些实施例中，所述上报埋点数据可以由APP客户端的上报器实现。所述上报器可以是APP客户端预置的上报代码。所述开始上报埋点数据可以包括触发开始上报埋点数据的条件。所述触发上报埋点数据的触发条件可以是页面打开触发和程序应用启动触发等，也可以是当所述埋点数据累计到一定数量(例如10条或20条等)触发，从而实现实时上报所述埋点数据。所述埋点数据为本地存储器中带有iSeq标记的埋点数据。在一些实施例中，上报器上报所述埋点数据时，从iSeq值小的埋点数据开始上报，只有iSeq值小的埋点数据上报成功了，才能上报iSeq值大的埋点数据。在一些实施例中，上报器可以根据iSeq值从小到大的顺序逐条上报所述埋点数据，也可以同时上报多条iSeq值连续的埋点数据。
步骤S302：获取上报流水号uSeq、当前上报数据条数curCount和历史成功上报数据条数数组hisCountList；
在本申请的一些实施例中，所述上报流水号uSeq用于记录成功上报所述埋点数据的次数。所述uSeq可以由APP客户端的uSeq生成器生成。所述uSeq生成器可以是计数器等任何可以产生连续数列(例如十进制数列：1、2、3…等)的程序、应用和逻辑电路等生成。所述连续数列可以是二进制和十进制等。在一些实施例中，所述uSeq生成器可以是全局的。在一些实施例中，所述上报过程可以是单线程上报，所述单线程用于上报同一类型的埋点数据。在一些实施例中，如果有多个类型的埋点数据，即有多个上报需求，可以使用多套iSeq生成器和uSeq生成器。
在本申请的一些实施例中，所述历史成功上报数据条数数组hisCountList用于存储历史成功上报埋点数据条数。所述hisCountList可以存储在本地存储器中。在一些实施例中，所述hisCountList拥有指定容量，可以是固定值0或其他任意正整数(一般设置在0-3)，如果hisCountList已经达到指定容量，根据先进先出原则，将时间最早的所述上报埋点数据条数删除。在一些实施例中，所述hisCountList可以由当前上报数据条数curCount更新。所述curCount用于记录当前等待上报的埋点数据条数，埋点数据条数可以是1条、2条或10条等。在一些实施例中，当上报触发条件为累计10条埋点数据上报一次，所述curCount固定为10。
步骤S303：上报成功，更新所述uSeq，并在所述hisCountList中添加所述curCount。
在本申请的一些实施例中，当每一次上报所述埋点数据成功时，所述uSeq生成器对uSeq加一处理，更新所述uSeq，并在所述hisCountList中添加curCount。例如，初始状态时，uSeq为0，存储在本地存储器中的hisCountList为{0，0，0}，等待第一次上报的埋点数据条数curCount为5；当上报埋点数据第一次成功，则所述uSeq生成器对uSeq加一，uSeq更新为1，而hisCountList更新为{5，0，0}，curCount更新为新的待上报数据条数，例如10；类似地，当上报埋点数据第二次成功，则uSeq更新为2，hisCountList更新为{10，5，0}，curCount更新为新的待上报数据条数，依此类推。所述的每一次上报成功，APP客户端都会保存更新后的uSeq和hisCountList，并更新curCount。在一些实施例中，APP客户端可以将所述，更新后的uSeq、hisCountList和curCount添加到所述埋点数据中。
在本申请的一些实施例中，所述uSeq可以使用终端外加内存作为缓存，优先修改内存中的uSeq，同时由异步线程将埋点数据保存到APP客户端的本地存储器中。
在本申请的一些实施例中，APP客户端可以在上报成功，并接收到服务端告知的所述埋点数据接收成功后，清除所述已上报成功的埋点数据。本申请实现的递增的uSeq具有很强的适应能力，在大多场景下都可以使用，包括终端本地存储空间不足情况下依然能够很好的工作。
需要说明的是，图3的详细流程是示例性的，并非对本申请的限定，根据上面的方案详细说明，埋点数据预置策略二可以有不止一种详细流程。
步骤S102：根据所述埋点数据及其记录信息，判断所述埋点数据是否完整。
在本申请的一些实施例中，所述服务端检测上报到服务端的埋点数据是否完整，具体通过检测埋点数据的iSeq是否连续，若iSeq连续，则说明所述上报到服务端的埋点数据完整，若埋点数据不连续则说明所述上报到服务端的埋点数据不完整。
若所述上报到服务端的埋点数据不完整，则进一步检测埋点数据丢失的原因，例如服务端埋点数据丢失和客户端埋点数据丢失等。具体的，进一步判断所述埋点数据的上报流水号是否连续，若连续，则需要进一步判断数据丢失是发生在服务端还是客户端，具体的，分别获取服务端和客户端的数据丢失量，若数据丢失量大于0，则说明发生数据丢失，否则，则说明未发生数据丢失。
具体的，在本申请一实施例中，可以先获取服务端的数据丢失量，当所述服务端的数据丢失量大于0，则所述服务端发生数据丢失；否则，所述服务端未发生数据丢失。然后，再根据所述服务端的数据丢失量，获取客户端的数据丢失量，若所述客户端的数据丢失量大于0，则所述客户端发生数据丢失；否则，所述客户端未发生数据丢失。具体的实施方案将在图4中详细描述。
图4为本申请的一些实施例提供的检测上报的埋点数据是否完整的流程示意图，该流程如下所示。该检测上报的埋点数据是否完整的执行主体可以是服务端。所述上报的埋点数据可以是单个APP客户端向服务端上报的埋点数据。
步骤S401：判断埋点数据丢失量是否等于0。
在本申请的一些实施例中，所述埋点数据丢失量的生成原因可以至少包括以下情况之一：APP客户端丢失和服务端丢失。在一些实施例中，所述APP客户端丢失的原因可以以下至少一种原因之一：APP客户端的采集代码出错、APP客户端所在终端的存储空间不足和APP客户端崩溃等。例如，用户在使用所述APP客户端的过程中，误删相关文件导致的APP客户端出错。
在本申请的一些实施例中，所述埋点数据的总丢失量用于描述埋点数据从所述客户端到服务端之间的总丢失数量，可以定义埋点数据的总丢失量Cm：
Cm＝Ci-CiSeq，(1)，
其中，CiSeq为服务端接收上报的埋点数据的条数的总数，所述埋点数据都带有iSeq标记，因此CiSeq可以通过计算带iSeq的埋点数据的数量获得。在一些实施例中，由于APP客户端会重复上报部分埋点数据，因此所述计算的带iSeq的埋点数据的数量为去重后的带iSeq的埋点数据的数量。例如，服务端接收到的埋点数据中iSeq等于1的埋点数据有2条或者更多，则只保留其中一条埋点数据对iSeq进行计数。Ci为客户端生成的埋点数据的条数的总数，用于计算保存在本地存储器中埋点数据的数量，所述埋点数据都拥有对应的iSeq，因此可以定义预计总埋点数据条数Ci：
Ci＝iSeqmax-iSeqmin+1，(2)，
其中，iSeqmax为服务端接收到的埋点数据中iSeq最大的值，iSeqmin为服务端接收到的埋点数据中iSeq最小的值。
如果Cm等于0，表示没有埋点数据丢失；如果Cm不等于0，说明埋点数据有丢失。则进行步骤S402。
在本申请的一些实施例中，埋点数据丢失数量可以除以预计总埋点数据条数，变成丢失率，这样对埋点数据丢失的监控就有更直观的指导意义。
步骤S402：判断服务端缺失上报次数是否等于0。
在本申请的一些实施例中，所述服务端缺失上报次数用于计算在上报过程中服务端缺失的APP客户端已经成功上报埋点数据的次数，可以定义服务端缺失上报次数Ts：
Ts＝Cu-CuSeq，(3)，
其中，CuSeq为服务端接收上报的埋点数据总次数，所述服务端接收上报的埋点数据总次数为利用uSeq去重后的服务端接收上报的埋点数据总次数；Cu为客户端成功上报次数，定义为：
Cu＝uSeqmax-uSeqmin+1，(4)，
其中，uSeqmax为上报成功的埋点数据中uSeq最大的值，uSeqmin为上报成功的埋点数据中uSeq最小的值。
如果Ts等于0，则进行步骤S403，否则进行步骤S405。
步骤S403：计算服务端埋点数据丢失量。
如果Ts等于0，则可以直接计算服务端埋点数据丢失量，定义服务端埋点数据丢失量Csm：
Csm＝sum(curCount)-CiSeq，(5)，
其中，sum(curCount)为uSeq去重后的curCount总和，CiSeq为服务端接收上报的埋点数据总数。
步骤S404：计算APP客户端埋点数据丢失量。
定义APP客户端埋点数据丢失量Ccm：
Ccm＝Cm-Csm，(6)，
其中，Cm为埋点数据丢失量，Csm为服务端埋点数据丢失量。
步骤S405：补充服务端缺失上报数据所对应的埋点数据条数curCount。
在本申请的一些实施例中，当服务端缺失上报次数Ts不等于0，说明服务端从成功接收到APP客户端上报的埋点数据后，在埋点数据写入数据库的过程中有数据丢失。在一些实施例中，可以借助hisCountList来补充curCount的数据。例如，当前uSeq状态下的hisCountList里中有最近三次上报成功的埋点数据条数，则可以补当前uSeq-1,uSeq-2,uSeq-3对应的三次成功上报埋点数据的curCount；例如，服务端缺失uSeq为3的成功上报的埋点数据，而本地存储器中存储的当uSeq为4的hisCountList中第一个元素为5，表示可以用于补充当uSeq为3时的当前记录条数为5。在一些实施例中，hisCountList的容量越大能够补出的记录就越多。通常，当超过3条连续的uSeq成功上报的埋点数据在服务端写入数据库的过程中丢失，则这个服务端是有严重问题的。
在本申请的一些实施例中，如果对服务端端的埋点数据丢失是零容忍的，那hisCountList大小可以调到0，也就是对于uSeq不连续的情况下的curCount不需要在做补充运算，这样整个计算也可以大大简化。
步骤S406：补充后的服务端埋点数据丢失量。
在本申请的一些实施例中，如果Ts不等于0，则定义补充后的服务端埋点数据丢失量Cfsm：
Cfsm＝sum(fixedCurCount)-Ciseq，(7)，
其中，sum(fixedCurCount)为补充当前待上报埋点数据条数数据后的APP客户端上报成功的埋点数据总数，CiSeq为服务端接收上报的埋点数据总数。
步骤S407：计算补充后的APP客户端埋点数据丢失量。
在本申请的一些实施例中，定义补充后的APP客户端埋点数据丢失量Cfcm：
Cfcm＝Cm-Cfsm，(8)，
其中，Cm为埋点数据丢失量，Cfsm为补充后的服务端埋点数据丢失量。
在本申请的一些实施例中，通过所述iSeq、uSeq，还可以监控终端APP客户端数据清空或者卸载重装导致iSeq、uSeq的重新计算，例如，可以通过检测服务端接收到的iSeq最小为1，并且iSeq为1的记录的客户端生成时间大于iSeq最大的记录的生成时间来区别所述APP客户端数据清空或者卸载重装的终端。
需要说明的是，图4的详细流程是示例性的，并非对本申请的限定，根据上面的方案详细说明，检测上报的埋点数据是否完整可以有不止一种详细流程。
在本申请实施例提供的一种监控APP客户端埋点数据采集完整性的方法、设备以及介质中，可以实现精确监控数据采集过程中整体的埋点数据丢失率，同时也可以监控埋点数据在服务端处理过程中或者在客户端存储和上报过程中是否有丢失，对APP客户端的埋点数据采集完整性的监控预警。同时本发明对服务端无任何入侵，实施十分方便。本发明还可以扩展到其他完全不同异构系统之间数据传输是否完整的检测。
本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备和介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本申请实施例提供的设备和介质与方法是一一对应的，因此，设备和介质也具有与其对应的方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述设备和介质的有益技术效果。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (15)

1.一种监控APP客户端埋点数据采集完整性的方法，其特征在于，包括：
获取客户端上报的埋点数据及其记录信息，所述记录信息包括所述埋点数据的生成流水号、所述客户端一次上报的埋点数据的条数、各条埋点数据的上报流水号以及历史成功上报数据条数数组；
根据所述埋点数据及其记录信息，判断所述埋点数据是否完整；
当所述埋点数据不完整时，根据所述埋点数据的记录信息，确定所述埋点数据的总丢失量，并判断所述埋点数据丢失的环节。
2.权利要求1所述的方法，其特征在于，所述埋点数据的记录信息包括：所述埋点数据的生成流水号；
根据所述埋点数据及其记录信息，判断所述埋点数据是否完整，包括：
根据所述埋点数据的生成流水号，判断所述埋点数据是否完整。
3.根据权利要求2所述的方法，其特征在于，根据所述埋点数据的生成流水号，判断所述埋点数据是否完整，包括：
判断所述埋点数据的生成流水号是否连续；
若连续，则所述埋点数据是完整的；否则，所述埋点数据不完整。
4.根据权利要求1所述的方法，其特征在于，若所述客户端一次上报的埋点数据的条数大于1，所述客户端该次上报的多条埋点信息的上报流水号相同；
根据所述埋点数据的记录信息，判断所述埋点数据丢失的环节，包括：
根据所述客户端一次上报的埋点数据的条数、各条埋点数据的生成流水号和上报流水号、以及历史成功上报数据条数数组，判断所述埋点数据丢失的环节。
5.根据权利要求4所述的方法，其特征在于，根据所述埋点数据的记录信息，确定所述埋点数据的总丢失量，包括：
根据以下公式确定所述埋点数据的总丢失量：
Cm＝Ci-CiSeq；
其中，Cm表示所述埋点数据的总丢失量；Ci表示客户端生成的埋点数据的条数的总数；CiSeq表示服务端接收到的客户端上报的埋点数据的条数的总和。
6.根据权利要求5所述的方法，其特征在于，判断所述埋点数据丢失的环节，包括：
判断所述埋点数据的上报流水号是否连续；
若不连续，则服务端发生数据丢失。
7.根据权利要求6所述的方法，其特征在于，当埋点数据的上报流水号不连续时，根据所述历史成功上报数据条数数组中的数据补出所述客户端一次上报的埋点数据的条数。
8.根据权利要求7所述的方法，其特征在于，根据所述客户端各次上报的埋点数据的条数、根据所述历史成功上报数据条数数组中的数据补出的一次上报的埋点数据、以及各条埋点数据的生成流水号，确定所述服务端的数据丢失量。
9.根据权利要求8所述的方法，其特征在于，确定所述服务端的数据丢失量通过以下公式确定：
Cfsm＝sum(fixedCurCount)-CiSeq；
其中，Cfsm表示服务端的数据丢失量；fixedCurCount表示根据历史成功上报数据条数数组中的数据补充后客户端各次上报成功的埋点数据的条数；sum(fixedCurCount)表示根据历史成功上报数据条数数组中的数据补充后客户端上报成功的埋点数据的条数的总和；CiSeq表示所述服务端接收到的客户端上报的埋点数据的条数的总和。
10.根据权利要求9所述的方法，其特征在于，还包括：根据所述服务端的数据丢失量确定客户端的数据丢失量，包括：
所述客户端的数据丢失量通过以下公式确定：
Cfcmm＝Cm-Cfsm；
其中，Cfcmm表示所述客户端的数据丢失量；Cm表示埋点数据的总丢失量；Cfsm表示服务端的数据丢失量。
11.根据权利要求6所述的方法，其特征在于，若所述埋点数据的上报流水号连续，则执行以下步骤：
确定服务端的数据丢失量；
根据所述埋点数据的总丢失量和所述服务端的数据丢失量，确定所述客户端的数据丢失量；
若所述服务端的数据丢失量大于0，则所述服务端发生数据丢失；否则，所述服务端未发生数据丢失；
若所述客户端的数据丢失量大于0，则所述客户端发生数据丢失；否则，所述客户端未发生数据丢失。
12.根据权利要求11所述的方法，其特征在于，所述服务端的数据丢失量根据以下公式确定：
Csm＝sum(curCount)-CiSeq；
其中，Csm表示所述服务端的数据丢失量；curCount表示客户端一次上报的埋点数据的条数；sum(curCount)表示客户端上报成功的埋点数据的条数的总和；CiSeq为服务端接收到的客户端上报的埋点数据的条数的总和。
13.根据权利要求12所述的方法，其特征在于，所述客户端的数据丢失量通过以下公式确定：
Ccm＝Cm-Csm；
其中，Ccm表示所述客户端的数据丢失量；Cm表示埋点数据的总丢失量；Csm表示所述服务端的数据丢失量。
14.一种监控APP客户端埋点数据采集完整性的设备，所述设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该设备执行权利要求1至13中任一项所述的方法。
15.一种计算机可读介质，所述介质存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现如权利要求1至13中任一项所述的方法。
CN201810072027.XA 2018-01-25 2018-01-25 监控app客户端埋点数据采集完整性的方法、设备以及介质 Active CN108363657B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810072027.XA CN108363657B (zh) 2018-01-25 2018-01-25 监控app客户端埋点数据采集完整性的方法、设备以及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810072027.XA CN108363657B (zh) 2018-01-25 2018-01-25 监控app客户端埋点数据采集完整性的方法、设备以及介质

Publications (2)

Publication Number Publication Date
CN108363657A CN108363657A (zh) 2018-08-03
CN108363657B true CN108363657B (zh) 2021-07-06

Family

ID=63006918

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810072027.XA Active CN108363657B (zh) 2018-01-25 2018-01-25 监控app客户端埋点数据采集完整性的方法、设备以及介质

Country Status (1)

Country Link
CN (1) CN108363657B (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109885475B (zh) * 2018-12-14 2023-10-17 平安壹钱包电子商务有限公司 页面转化率计算方法、装置、计算机设备及存储介质
CN109918276B (zh) * 2019-01-22 2022-11-29 深圳壹账通智能科技有限公司 基于app应用程序的曝光埋点处理方法及相关设备
CN110113392A (zh) * 2019-04-17 2019-08-09 上海连尚网络科技有限公司 一种监控app客户端埋点采集完整性的方法及设备
CN113127336A (zh) * 2020-01-16 2021-07-16 北京沃东天骏信息技术有限公司 数据收集方法和装置
CN111611141A (zh) * 2020-04-30 2020-09-01 广州华多网络科技有限公司 埋点数据的上报验证方法、装置、电子设备及存储介质
CN112230917B (zh) * 2020-10-12 2024-04-30 上海赛可出行科技服务有限公司 一种基于数据和状态的移动应用埋点方法
CN112882891B (zh) * 2021-02-05 2024-04-09 上海识装信息科技有限公司 一种客户端Web访问链路监控的方法
CN113064801B (zh) * 2021-03-10 2022-03-29 深圳依时货拉拉科技有限公司 数据埋点的方法、装置、可读存储介质及计算机设备
CN113419885B (zh) * 2021-06-18 2023-05-26 杭州海康威视数字技术股份有限公司 一种数据完整性处理方法、装置及电子设备
CN114579416B (zh) * 2022-03-09 2024-05-03 北京字节跳动网络技术有限公司 一种指标确定方法、装置、服务器和介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103414822A (zh) * 2013-07-15 2013-11-27 北京中传视讯科技有限公司 一种用于智能终端的用户行为处理方法和装置
CN103716133A (zh) * 2013-10-21 2014-04-09 杨湖 一种防止数据丢失方法
CN106250404A (zh) * 2016-07-21 2016-12-21 柳州龙辉科技有限公司 一种用户操作分析的方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5836733B2 (ja) * 2011-09-27 2015-12-24 沖電気工業株式会社 バッファ制御装置、バッファ制御プログラム及び通信装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103414822A (zh) * 2013-07-15 2013-11-27 北京中传视讯科技有限公司 一种用于智能终端的用户行为处理方法和装置
CN103716133A (zh) * 2013-10-21 2014-04-09 杨湖 一种防止数据丢失方法
CN106250404A (zh) * 2016-07-21 2016-12-21 柳州龙辉科技有限公司 一种用户操作分析的方法

Also Published As

Publication number Publication date
CN108363657A (zh) 2018-08-03

Similar Documents

Publication Publication Date Title
CN108363657B (zh) 监控app客户端埋点数据采集完整性的方法、设备以及介质
CN110661659B (zh) 一种告警方法、装置、系统及电子设备
CN106547420B (zh) 一种页面处理方法和装置
CN110516971B (zh) 异常检测的方法、装置、介质和计算设备
US20180365085A1 (en) Method and apparatus for monitoring client applications
CN111600746B (zh) 网络故障定位方法、装置及设备
CN105260294A (zh) 一种应用程序占用内存的监控方法及装置
CN111124212A (zh) 数据的显示方法及装置、存储介质及处理器
US20170244595A1 (en) Dynamic data collection profile configuration
CN109189677B (zh) 一种针对变量数值更新状态的测试方法及装置
CN104866296A (zh) 数据处理方法和装置
CN111898059A (zh) 网站页面质量评估和监控方法及其系统
CN110113392A (zh) 一种监控app客户端埋点采集完整性的方法及设备
CN111625402A (zh) 数据恢复方法、装置、电子设备及计算机可读存储介质
CN107330031B (zh) 一种数据存储的方法、装置及电子设备
CN113497721B (zh) 网络故障定位方法与装置
CN110058996B (zh) 程序调试方法、装置、设备和存储介质
CN110889065B (zh) 页面停留时长确定方法、装置与设备
CN112559050A (zh) 客户端异步请求信息的并发数的处理方法和装置
CN113868096B (zh) 异步数据传输的监控方法及装置、电子设备、存储介质
CN115659045A (zh) 用户操作的识别方法、装置、存储介质以及电子设备
CN114281648A (zh) 一种数据采集方法、装置、电子设备及存储介质
CN113868005A (zh) 网页异常的监控方法和装置
CN113467867A (zh) 信息处理方法、装置、电子设备及存储介质
CN110020348B (zh) 圈选事件的预警方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20231108

Address after: 200240 building 41, 398 Heqing Road, Minhang District, Shanghai

Patentee after: Shanghai Chenlian Technology Co.,Ltd.

Address before: 200120 2, building 979, Yun Han Road, mud town, Pudong New Area, Shanghai

Patentee before: SHANGHAI LIANSHANG NETWORK TECHNOLOGY Co.,Ltd.