获取访问数据的方法、计算设备和介质与流程

1.本公开概括而言涉及信息采集领域，更具体地，涉及一种获取访问数据的方法、计算设备和计算机可读存储介质。


背景技术：

2.埋点是一种常见的用于对用户在网站上的操作行为数据进行采集的方式。当前业界内的埋点方式大致有三类：(1)无痕埋点：用于无差别收集页面所有信息，包括页面进出、事件点击等等，需要后端进行数据清洗才能获取有用信息；(2)可视化埋点：用于根据生成的页面结构获取埋点点位，单独埋点分析；以及(3)代码埋点：用于根据具体业务需求在业务代码中手动设置埋点代码。
3.无痕埋点和可视化埋点都适合于简单规范的页面场景，无痕埋点无需配置，数据可回溯，但是数据量较大，也不能关联具体业务数据；可视化埋点开发成本低，运营人员可直接进行相关埋点配置，但是也不能关联具体业务数据。代码埋点能够关联特定业务场景，业务数据明确，能够由使用者精准控制，但是需要对每个业务单独进行代码配置，对开发人员的要求比较高，开发成本较高。
4.对于当前的许多复杂的业务场景，在同一业务场景中可能涉及到不同的事件类型。在这种情况下，如果使用单一的埋点方式的话，只有代码埋点能够满足业务需求。然而，使用代码埋点需要对该业务场景中的每种类型的事件单独进行代码配置，开发成本高昂。


技术实现要素：

5.针对上述问题中的至少一个，本公开提供了一种获取访问数据的方案，通过为同一业务场景中的不同类型的事件设置不同的埋点方式和数据上报方式，使得能够在兼顾开发难度和效率的情况下获取该业务场景的全面的访问数据。
6.根据本公开的一个方面，提供了一种获取访问数据的方法。该方法包括，在前端设备处：确定与待获取的访问数据相关联的事件类型；基于所述事件类型设置多种埋点方式中的一种埋点方式；根据所述埋点方式获取所述访问数据；基于所述访问数据的数据量确定所述访问数据的上报方式；以及利用所确定的上报方式向所述前端设备的后端设备上报所述访问数据。
7.根据本公开的另一个方面，提供了一种计算设备。该计算设备包括：至少一个处理单元；以及至少一个存储器，该至少一个存储器被耦合到该至少一个处理单元并且存储用于由该至少一个处理单元执行的指令，该指令当由该至少一个处理单元执行时，使得该计算设备执行根据上述方法的步骤。
8.根据本公开的再一个方面，提供了一种计算机可读存储介质，其上存储有计算机程序代码，该计算机程序代码在被运行时执行如上所述的方法。
9.在一些实施例中，所述多种埋点方式包括代码埋点方式和无痕埋点方式，并且其中基于所述事件类型设置多种埋点方式中的一种埋点方式包括：确定所述事件类型是否是
复杂逻辑事件；如果确定所述事件类型是复杂逻辑事件，为所述事件类型设置代码埋点方式；以及如果确定所述事件类型不是复杂逻辑事件，为所述事件类型设置无痕埋点方式。
10.在一些实施例中，设置代码埋点方式包括：如果确定所述事件类型是复杂逻辑事件，为与所述复杂逻辑事件相关联的所有操作控件分别设置埋点代码，并且所有埋点代码具有相同的事件标识符，并且其中根据所述埋点方式获取所述访问数据包括：在每个操作控件被触发时触发所述复杂逻辑事件；利用为每个操作控件设置的埋点代码采集与所述复杂逻辑事件相关联的访问数据的一部分；以及合并与所述复杂逻辑事件相关联的访问数据的所有部分以作为所述复杂逻辑事件的访问数据。
11.在一些实施例中，设置无痕埋点方式包括：在所述前端设备处设置配置文件，所述配置文件包括感兴趣的操作事件列表，并且其中根据所述埋点方式获取所述访问数据包括：获取所述前端设备的所有或特定类操作事件的访问数据；以及基于所述配置文件从所有或特定类操作事件的访问数据中过滤出属于所述感兴趣的操作事件列表的访问数据作为所获取的访问数据。
12.在一些实施例中，基于所述访问数据的数据量确定所述访问数据的上报方式包括：估计所述访问数据的数据量；确定所述数据量是否小于预定阈值；如果所述数据量小于所述预定阈值，选择无响应实体的第一http请求方式；以及如果所述数据量大于或等于所述预定阈值，选择具有无限制正文长度的第二http请求方式。
13.在一些实施例中，估计所述访问数据的数据量包括：根据与所述访问数据相关联的事件类型来估计所述访问数据的数据量。
14.在一些实施例中，利用所确定的上报方式向所述前端设备的后端设备上报所述访问数据包括：如果所述事件类型是浏览时长事件，以所述第一http请求方式每隔预定时间间隔向所述后端设备发送http请求，该http请求包含所述前端设备的当前浏览时长。
15.利用本公开的方案，在开发的便利性、用户的流量开销以及业务需求的复杂场景这些方面达到了良好的平衡。
附图说明
16.通过参考下列附图所给出的本公开的具体实施方式的描述，将更好地理解本公开，并且本公开的其他目的、细节、特点和优点将变得更加显而易见，其中：
17.图1示出了根据本公开的用于获取访问数据的系统的示意图。
18.图2示出了根据本公开的实施例的系统1的软件架构的示意图。
19.图3示出了根据本公开的一些实施例的用于获取访问数据的方法的流程图。
20.图4示出了根据本公开实施例的用于确定埋点方式的方框的更详细流程图。
21.图5示出了根据本公开一些实施例的确定访问数据的上报方式的方框的更详细流程图。
22.图6示出了可以用来实施本公开的实施例的示例计算设备的示意性框图。
具体实施方式
23.下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方
式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整的传达给本领域的技术人员。
24.图1示出了根据本公开的实施例的用于获取访问数据的系统1的示意图。如图1中所示，系统1包括多个前端设备10和与多个前端设备10通信的后端设备20。这里，前端设备10可以包括各种能够浏览/访问网络页面的终端，包括手机、平板电脑、笔记本电脑等。前端设备10上可以运行有各种应用程序，每种应用程序可以包括一种或多种业务场景，本文中针对一种业务场景包含多种事件类型的情况进行讨论。后端设备20可以是支持应用程序所需的各种处理功能的服务器。前端设备10和后端设备20之间可以通过各种通信方式进行通信，如光纤网络、移动互联网等，并且前端设备10和后端设备20协同实现应用程序的各种功能，如下面结合图2所述。
25.前端设备10可以包括至少一个处理单元和与该至少一个处理单元耦合的至少一个存储器，该存储器中存储有可由该至少一个处理单元执行的指令，该指令在被该至少一个处理单元执行时执行如下所述的方法300的至少一部分。前端设备10的具体结构例如可以如下结合图6所述。
26.图2示出了根据本公开的实施例的系统1的软件架构200的示意图。如图2中所示，系统1的软件架构200可以包括位于前端设备10的展示层210、埋点方式设置层220、埋点上报层230和位于后端设备20的数据存储层240、数据处理层250和访问报表层260。其中，展示层210用于实现应用程序在不同设备或操作系统上的渲染，其呈现形式例如小程序、h5等。埋点方式设置层220用于针对各种不同事件类型设置不同的埋点方式，如代码埋点或无痕埋点等。埋点上报层230用于根据要上报的访问数据的数据量，使用不同的数据上报方式，如http head方式(或者进一步的轮询方式)、http post方式等，来向后端设备20上报所获取的访问数据。数据存储层240用于存储或暂存前端设备10所上报的访问数据。数据处理层250用于针对一个或多个前端设备10上报的访问数据执行不同类型的处理，如实时处理或离线处理等。访问报表层260用于基于处理后的访问数据产生该应用程序的访问情况的报表，如实时报表或离线报表等。
27.图3示出了根据本公开的一些实施例的用于获取访问数据的方法300的流程图。方法300例如可以在图1中所示的系统1中的前端设备10中执行。以下结合图1至图3对方法300进行更加详细的描述。
28.在方框310，前端设备10可以确定与待获取的访问数据相关联的事件类型。这里，事件类型是指为了获取该访问数据所需执行的操作的类型，可以包括视图点击或显示事件、页面事件、复杂逻辑事件(如页面停留时长上报事件)等。例如，在电商业务场景下，所要获取的访问数据可以包括用户的加购物车数据、购买数据、商品浏览数据等。与获取这些访问数据相对应的事件类型可以是控件点击事件(如点击“加入购物车”按钮、点击“提交订单”按钮)、页面曝光事件(如进入和退出一个商品页面)、页面停留时间事件等。
29.在方框320，前端设备10可以基于方框310所确定的事件类型设置多种埋点方式中的一种埋点方式。即，为每种事件类型设置对应的埋点方式。
30.对于涉及不同事件类型的业务场景来说，完全使用代码埋点会使得代码开发业务量过大且不便于版本升级，完全使用无痕埋点会使得前端设备10需要无差别地获取各种埋点数据并将其传送给后端设备20，从而造成数据传输开销和后端设备20对接收到的数据进
行过滤的开销。对此，在本公开中，针对该业务场景中的不同事件类型，设置不同的埋点方式，包括代码埋点方式或无痕埋点方式。更进一步地，在无痕埋点方式中，还可以进一步在前端设备10处设置配置文件以在上报前过滤出感兴趣的事件。由于可视化埋点方式过渡依赖于第三方的sdk(软件开发包)所提供的功能，因此本文中不考虑这种埋点方式。
31.图4示出了根据本公开实施例的用于确定埋点方式的方框320的更详细流程图。在本公开中，从应用程序的业务场景出发考虑，仅为复杂逻辑事件设置代码埋点方式，这些事件的数据不是结构化配置的数据，无法通过可视化埋点或无痕埋点进行上报，为其他事件(例如页面点击事件等，本文中也称为简单事件)设置无痕埋点方式。这里，复杂逻辑事件是指由多个互相关联的操作所触发的事件，其通常并不对应于单个页面上的操作，例如如下所述的浏览时长事件。
32.具体地，如图4中所示，在方框322，前端设备10可以确定方框310所确定的事件类型是否是复杂逻辑事件。
33.如果确定方框310所确定的事件类型是复杂逻辑事件，在方框324，前端设备10可以为该事件类型设置代码埋点方式。
34.更进一步地，在方框324可以为与该复杂逻辑事件相关联的所有操作控件分别设置埋点代码，并且所有操作控件的埋点代码具有相同的事件标识符。也就是说，使用同一标识符来组织该复杂逻辑事件的所有操作。
35.另一方面，如果确定方框310所确定的事件类型不是复杂逻辑事件，在方框326，前端设备10可以为该事件类型设置无痕埋点方式。例如，可以利用微信小程序或者h5提供的页面生命周期函数或者事件，在代码层植入所需的埋点。对于无痕埋点方式，可以简单地为所有操作事件或者特定类的操作事件设置无痕埋点方式。
36.在方框330，前端设备10可以根据方框320确定的埋点方式获取相应的访问数据。对于不同的事件类型，所设置的埋点方式不同，获取访问数据的方式也不同。
37.在一些实施例中，如上所述，对于复杂逻辑事件，为与该复杂逻辑事件相关联的所有操作控件分别设置了埋点代码，并且所有操作控件的埋点代码具有相同的事件标识符。在这种情况下，在方框330中，前端设备10可以在每个操作控件被触发时触发该复杂逻辑事件，利用为每个操作控件设置的埋点代码采集与该复杂逻辑事件相关联的访问数据的一部分，并且合并与该复杂逻辑事件相关联的访问数据的所有部分以作为该复杂逻辑事件的访问数据。
38.如上所述，为简单事件设置了无痕埋点方式。在一些进一步的实施例中，在方框326，还在前端设备10处设置配置文件，该配置文件包括感兴趣的操作事件列表。也就是说，本文中所述的无痕埋点方式不同于常规的无痕埋点方式，而是具有配置文件的无痕埋点方式。
39.在这种情况下，在方框330中，前端设备10可以获取前端设备10的所有简单事件(即，不是复杂逻辑事件的操作事件)的访问数据，并且基于该配置文件从所有简单事件的访问数据中过滤出属于该感兴趣的操作事件列表的访问数据作为所获取的访问数据。通过这种方式，即使对于无痕埋点方式来说，也能够仅将感兴趣的访问数据上报给后端设备20，从而既具有无痕埋点的优点，又避免了过大的数据传输负担，节省了用户流量，同时提高了数据利用率。
40.继续图3，在方框340，前端设备10可以基于方框330获取的访问数据的数据量确定访问数据的上报方式。
41.图5示出了根据本公开一些实施例的确定访问数据的上报方式的方框340的更详细流程图。
42.如图5中所示，方框340可以包括方框342，其中前端设备10可以估计该访问数据的数据量。
43.在一些实施例中，前端设备10可以在获取了访问数据之后对其数据量进行计算。
44.在另一些实施例中，前端设备10可以根据与该访问数据相关联的事件类型来估计该访问数据的数据量。这是因为，同一事件类型的数据量基本上在一个比较固定的范围内，而考虑到冗余，根据数据量来确定上报方式并不需要严格确定实际的数据量，而只需要一个数据量的范围或数量级即可。尤其是，在实际应用中，通常更关注较大数据量的访问数据的上报。
45.在方框344，前端设备10可以确定该数据量是否小于预定阈值。这里，该预定阈值可以是一个确定的数字(例如对于实际计算数据量的情况)，也可以是一个数量级(例如对于通过事件类型估计数据量的情况)。
46.如果该数据量小于该预定阈值，在方框346，前端设备10可以选择无响应实体的第一http请求方式。该第一http请求方式例如可以是http head方式。在这种情况下，避免了需要返回响应体所造成的传输资源浪费，与http post方式相比，在chrome浏览器情况下会有大概10ms的传输优化。
47.另一方面，如果该数据量大于或等于该预定阈值，在方框348，前端设备10可以选择具有无限制正文长度的第二http请求方式。该第二http请求方式例如可以是http post方式。
48.通过根据访问数据的数据量选择不同的上报方式，实现了传输成功率和传输资源消耗之间的完美平衡。例如，如果拼接参数后的请求url长度(其对应于所要上报的数据量)超出了浏览器的限制，将会导致请求失败，并且对于该上报事件，前端设备10需要对其返回数据进行后续处理，则这种情况下就不再适用http head请求方式。例如，对于一般的页面浏览数事件埋点、点击事件埋点、简单业务事件埋点，使用http head请求方式进行上报已经足以满足需要，而对于大数据量的文章分享事件，由于携带比较大量的信息，使用http post请求方式上报才能够满足需要。
49.继续图3，在方框350，前端设备10可以利用方框340所确定的上报方式向后端设备20上报该访问数据。
50.对于一些特殊的事件类型，例如浏览时长事件(其是复杂逻辑事件的一种)，访问数据的数据量并不大，因此可以选择第一http请求方式。例如，对于这种事件类型，常规的方式一般是通过浏览器或者小程序提供的页面初始化事件(onload)和销毁事件(onunload)回调，在其中分别记录页面进入时间t0和页面退出时间t 1，计算出浏览时长t1-t0，并将该浏览时长(例如通过第一http请求方式)上报给后端设备20。这种常规方式在正常的应用或页面关闭流程里是没有问题的，但是针对一些非正常情况，如浏览器/微信小程序/微信闪退或者用户强制关闭应用(杀进程)之类的情况，浏览时长记录会丢失。而对于用户强制关闭应用，或者应用由于内存不足被回收关闭在现实场景中又很常见，例如用户
浏览了一会儿文章之后切换到其他应用处理事务，再切回来应用或者小程序已经因为长时间未响应或者内存不足被回收了。在这种情况下将无法得到准确的浏览时长数据。而浏览时长数据在很多情况下，如在文章分享链路中，又很重要，是判断用户是否是潜在高价值用户的标准，因此这部分数据的概率丢失是不可接受的。虽然可以通过在前端设备10与后端设备20之间建立websocket持久性连接来解决这一问题，但是websocket方案有一定的兼容性问题，在小程序框架内的细节表现与浏览器中有所差异，从开发角度和用户体验角度并不是很好。针对这种情况，在本公开中对于浏览时长事件采用轮询请求的方式来实现长连接。
51.具体地，如果事件类型是浏览时长事件，在方框350，前端设备10可以以该第一http请求方式(例如http head请求方式)每隔预定时间间隔向后端设备20发送http请求，该http请求包含前端设备10的当前浏览时长。例如，前端设备10可以每隔5秒向后端设备20发送一个携带当前浏览时长的http head请求，后端设备20接收到该http head请求后更新浏览时长记录。通过这种方式，无论遇到何种异常场景，浏览时长数据都不会丢失，其最大误差为所设置的预定时间间隔，例如5秒。
52.图6示出了可以用来实施本公开的实施例的示例计算设备600的示意性框图。计算设备600例如可以是如上结合图1至图5所述的前端设备10或后端设备20。如图所示，计算设备600可以包括一个或多个中央处理单元(cpu)610(图中仅示意性地示出了一个)，其可以根据存储在只读存储器(rom)620中的计算机程序指令或者从存储单元680加载到随机访问存储器(ram)630中的计算机程序指令，来执行各种适当的动作和处理。在ram 630中，还可存储设备600操作所需的各种程序和数据。cpu 610、rom 620以及ram 630通过总线640彼此相连。输入/输出(i/o)接口650也连接至总线640。
53.计算设备600中的多个部件连接至i/o接口650，包括：输入单元660，例如键盘、鼠标等；输出单元670，例如各种类型的显示器、扬声器等；存储单元680，例如磁盘、光盘等；以及通信单元690，例如网卡、调制解调器、无线通信收发机等。通信单元690允许计算设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
54.上文所描述的方法300例如可由计算设备600(如前端设备10)的处理单元610执行。例如，在一些实施例中，方法300可被实现为计算机软件程序，其被有形地包括于机器可读介质，例如存储单元680。在一些实施例中，计算机程序的部分或者全部可以经由rom 620和/或通信单元690而被载入和/或安装到计算设备600上。当计算机程序被加载到ram 630并由cpu 610执行时，可以执行上文描述的方法300的一个或多个操作。此外，通信单元690可以支持有线或无线通信功能。
55.以上结合附图对根据本公开的用于获取访问数据的方法300以及可用作前端设备10和后端设备20的计算设备600进行了描述。然而本领域技术人员可以理解，方法300的步骤的执行并不局限于图中所示和以上所述的顺序，而是可以以任何其他合理的顺序来执行。此外，计算设备600也不必须包括图6中所示的所有组件，其可以仅仅包括执行本公开中所述的功能所必须的其中一些组件，并且这些组件的连接方式也不局限于图中所示的形式。例如，在前端设备10是移动终端的情况下，计算设备600可以仅包含其中的一些组件或其等同形式。
56.本公开可以是方法、装置、系统和/或计算机程序产品。计算机程序产品可以包括
计算机可读存储介质，其上载有用于执行本公开的各个方面的计算机可读程序指令。
57.在一个或多个示例性设计中，可以用硬件、软件、固件或它们的任意组合来实现本公开所述的功能。例如，如果用软件来实现，则可以将所述功能作为一个或多个指令或代码存储在计算机可读介质上，或者作为计算机可读介质上的一个或多个指令或代码来传输。
58.本文公开的装置的各个单元可以使用分立硬件组件来实现，也可以集成地实现在一个硬件组件，如处理器上。例如，可以用通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或其它可编程逻辑器件、分立门或者晶体管逻辑、分立硬件组件或用于执行本文所述的功能的任意组合来实现或执行结合本公开所描述的各种示例性的逻辑块、模块和电路。
59.本领域普通技术人员还应当理解，结合本公开的实施例描述的各种示例性的逻辑块、模块、电路和算法步骤可以实现成电子硬件、计算机软件或二者的组合。
60.本公开的以上描述用于使本领域的任何普通技术人员能够实现或使用本公开。对于本领域普通技术人员来说，本公开的各种修改都是显而易见的，并且本文定义的一般性原理也可以在不脱离本公开的精神和保护范围的情况下应用于其它变形。因此，本公开并不限于本文所述的实例和设计，而是与本文公开的原理和新颖性特性的最广范围相一致。