CN103246661B - 可视化用户行为收集系统及其方法 - Google Patents

Abstract

本申请涉及一种可视化用户行为收集系统及其方法，所述方法包括以下步骤：S11.在原始页面上对后台管理侧可见的子页面中预设需要收集的用户行为数据的类型，使预设的用户行为数据类型与文档对象模型元素相关联；以及S12.根据所述预设的用户行为数据类型收集用户在所述原始页面上进行操作时产生的用户行为数据。本申请可以让用户很方便地预设需要收集的用户行为数据，且能够将用户行为数据和页面原有的业务内容分离，便于集中管理以及及时对无用或冗余数据进行清理；可以让用户通过不同的方式对用户行为数据进行可视化配置；还可以对用户行为数据的生命周期进行管理。

Description

可视化用户行为收集系统及其方法

技术领域

本申请涉及计算机网络技术领域，尤其涉及一种可视化用户行为收集系统及其方法。

背景技术

近年来，随着计算机网络技术的迅猛发展，互联网已经被广泛地使用。用户可以通过互联网方便、快捷地完成例如获取信息、购物、缴费、预定票务等各种日常所需，这使得用户对互联网的依赖日趋强烈。而对于网站来说，如何在第一时间了解用户的需求以及对产品的关注度，将为网站决策者在制定产品销售和宣传策略方面提供准确、及时的支持。

目前，能够实现对关注度进行统计的方法有很多，例如，可以通过解析网站的日志数据来进行分析，也可以通过直接在网页上添加跟踪代码来进行分析，还可以使用如Google Analytics(用于对目标网站进行访问数据统计和分析)和CNZZ(用于为互联网各类站点提供专业、权威、独立的第三方数据统计分析)等第三方软件来进行分析。在相关技术中，上述方式均属于后置方案，即只能对用户访问之后的网站页面进行访问次数的统计，而无法对页面上的文档对象模型(document object model，dom)元素的访问次数进行统计；此外，相关技术的做法是将需要统计的数据内容直接写入到html代码中，例如，“<a href＝”...”onclick＝”sendData(‘news’)”>新闻</a>”(其中，“news”是需要发送的采集数据，“sendData”是发送数据的javascript函数)，当对无用或冗余统计数据进行清理时，需要在html代码中查找所有“onclick”指向的数据，这会导致清理效率低下、数据无法被统一的、彻底的清理。

此外，相关技术中还存在以下缺陷：dom元素的定位比较困难，通常以自定义属性的方式实现，而该自定义属性的内容是需要页面开发人员和类型设置人员共同约定的；自定义属性的添加需要对原有页面进行改动，因此，有较大的侵入性；此外，没有可视化的操作界面，因此很难验证布点是否正确合理。

发明内容

鉴于上述相关技术的缺陷，本申请的主要目的在于提供一种可视化用户行为收集系统及其方法，以解决相关技术存在的上述问题。

为实现上述目的，本申请的实施例提供了一种可视化用户行为收集方法，所述方法包括以下步骤：S11.在原始页面上对后台管理侧可见的子页面中预设需要收集的用户行为数据的类型，使预设的用户行为数据类型与文档对象模型元素相关联；以及S12.根据所述预设的用户行为数据类型收集用户在所述原始页面上进行操作时产生的用户行为数据。

本申请的实施例还提供了一种可视化用户行为收集系统，所述系统包括：类型设置模块，用于在原始页面上对后台管理侧可见的子页面中预设需要收集的用户行为数据的类型，使预设的用户行为数据类型与文档对象模型元素相关联；以及数据收集模块，用于根据所述预设的用户行为数据类型收集用户在所述原始页面上进行操作时产生的用户行为数据。

综上所述，本申请的可视化用户行为收集系统及其方法可以让用户很方便地定义需要收集的用户行为数据，也就是说，可以让用户通过不同的方式对用户行为数据进行可视化配置，即在可视化界面上把目前已经定义的规则都展现出来，用户可以很容易进行验证是否布点完成。

附图说明

图1为本申请可视化用户行为收集方法的实施例流程图；

图2为本申请可视化用户行为收集系统的实施例结构框图。

具体实施方式

下面将详细描述本申请的具体实施例。应当注意，这里描述的实施例只用于举例说明，并不用于限制本申请。

本申请的可视化用户行为收集实现方案包括以下三个部分，即后台管理侧、业务系统集成所需的API(Application Programming Interface，应用程序编程接口)以及通用的javascript。

其中，后台管理侧是内容管理系统(Content Manage System，CMS)的一个子集，CMS把一个网站的内容(文字，图片，等等)与网站的组件分离开来，可以将各个页面连接到一起，可以控制页面的显示，通过这个系统可以方便的管理、发布、维护网站的内容，而不再需要硬性的写html代码或手工建立每一个页面；在本申请中，后台管理侧主要用于预设用户行为数据的类型以及该用户行为数据类型所对应的dom元素匹配方式。

这里，dom可以被javascript用来读取、改变html、xhtml以及xml文档，通过javascript，可以重构整个html文档，即可以添加、移除、改变或重排页面上的项目；当要改变页面上的某个内容时，javascript就需要获得对html文档中所有元素进行访问的入口，这个入口，连同对html元素进行添加、移动、改变或移除的方法和属性，都是通过dom来获得的。这里的每个元素都是一个dom元素，通过html解析之后便成为一个树形的数据结构。每个节点都可以看作是一个dom元素，每个dom元素至多有一个父节点，以及零个或多个子节点。

业务系统集成所需的API是指一些预设的函数，目的是提供应用程序与开发人员基于某软件或硬件以访问一组例程(某个系统对外提供的功能接口或服务的集合，其作用类似于函数)的能力，而又无需访问源码，或理解内部工作机制的细节。而API接口则属于一种操作系统或程序接口，有时会将其作为公共开放系统，也就是说，制定自己的系统接口标准，当需要执行系统整合、自定义和程序应用等操作时，所有成员都可以通过该接口标准调用源代码，该接口标准被称之为开放式API。

通用的javascript是指各个页面中均会使用到的相同的javascript代码，当用户点击页面上的某个元素时，能够自动与对应的用户行为数据进行匹配，并发送匹配后的用户行为数据。

图1为本申请可视化用户行为收集方法的实施例流程图。如图所示，所述方法包括以下步骤S11和S12。

在一个实施例中，步骤S11之前还包括以下步骤S10。

S10.抓取原始页面，并在所述原始页面的最末处添加可视化javascript代码，其中，所述代码用于生成所述子页面，并根据所述步骤S11中的预设来生成所述用户行为数据类型与文档对象模型元素相关联的映射关系。

在一个实施例中，首先通过后台管理侧来对原始页面进行抓取并将其完整呈现，这里的原始页面是指需要收集用户行为数据的页面；接着在原始页面的最末处添加可视化javascript代码。需要注意的是，这里对原始页面的抓取和可视化javascript代码的添加都是后台管理侧根据开发人员预设好的程序代码自动完成的，因此，不仅节约了人员成本，也提高了页面抓取的速度和准确性。此外，还需要注意的是，为了将原始页面的代码与需要收集的用户行为数据所产生的代码进行区分，开发人员会在上述预设好的程序代码中添加一些新的代码，使得在通过上述方法对用户行为数据进行收集时，产生的用户行为数据所对应的代码能够自动地插入到原始页面的代码的最末处，这样，可以就很容易地将产生的用户行为数据所对应的代码与原始页面的代码进行区分和隔离，从而使数据的管理更清楚，也使系统的维护更便捷。

S11.在原始页面上对后台管理侧可见的子页面中预设需要收集的用户行为数据的类型，使预设的用户行为数据类型与文档对象模型元素相关联。

在一个实施例中，后台管理侧的操作者在需要收集的用户行为数据上进行操作(如：鼠标右键、双击等)时会弹出设置用户行为数据类型的对话框，其中，该对话框所在的页面即为对后台管理侧可见的子页面，通过在该对话框中进行的增加、修改和删除操作来对需要收集的用户行为数据的类型进行设置，使设置后的用户行为数据类型与dom元素相关联，并将设置后的用户行为数据类型存储在后台管理侧的数据库中。例如，以新浪网为例，假设需要收集访问“新闻”版块中五条不同新闻标题的用户所产生的用户行为数据，那么新浪网的后台管理侧的操作者就要分别为每条新闻标题设置相应的用户行为数据类型，比如将第一条新闻标题对应的用户行为数据的类型设置为“新闻1”，将第二条新闻标题对应的用户行为数据的类型设置为“新闻2”，......，以此类推；此外，也可将五条不同新闻标题对应的用户行为数据的类型均设置为“新闻1”；通过上述设置可以实现用户行为数据类型与dom元素的相互关联。需要注意的是，“用户行为数据”中的“用户”是指访问业务系统(如：新浪网)的用户。

参考上述内容，在一个实施例中，如果需要收集的是用户在“标题”上的操作(如：鼠标右键、单击等)，那么此处抓取到的dom元素就应该是“标题”；需要注意的是，这里不需要对抓取到的原始页面的内容进行存储，而是采取即时抓取的方式，因此，可以节省后台管理侧的存储空间。

在一个实施例中，布点相关javascript代码主要用于将用户行为数据类型与原始页面的dom元素相关联，并为原始页面关联相应的操作，如：鼠标左键点击(onclick)等。当用户进行上述操作后，通过预设的规则将与该dom元素有关的用户行为数据抓取到，并通过javascript请求将该抓取到的用户行为数据发送到数据收集服务器。

接续，在一个实施例中，用户行为数据类型与dom元素相关联的方式主要有四种，即id、class属性、css路径和自定义属性。然而，并不是每种方式都可以直接使用，例如，css路径这种方式在任何页面中都可以使用，而id、class属性和自定义属性则需要预先设置好dom元素。

具体而言，在一个实施例中，通过上述四种方式可以将用户行为数据类型与dom元素相关联。以id方式为例，如果想要收集访问新浪网娱乐版块中某个内容的用户行为数据类型，首先要预先设置好需要收集的娱乐版块中该内容的dom元素，即在新浪网娱乐版块的原始页面中抓取想要收集的内容的dom元素；接着在javascript代码中添加与想要收集的某个内容的dom元素相对应的代码，并将该代码与id进行关联，从而使二者能够一一对应，也就是说，在javascript代码中，id只是dom元素的标识，供其他元素脚本等引用，当需要修改一个标签的属性时会将id作为该标签的唯一标识来进行操作。采用class属性和自定义属性方式的用户行为数据类型与dom元素相关联的方法与采用id的方式相类似，在此不再赘述；而采用css路径方式的用户行为数据类型与dom元素相关联的方法则可在任何页面中使用，这是因为css路径可用于多层级元素，并能够根据文档的上下文关系来确定某个标签的样式，也可以说，css路径是以树形目录的方式自下而上来对dom元素进行查找的，即css路径会对页面中的每个dom元素进行查找，因此，不需要预先设置好dom元素。

此外，上述四种方式的优缺点也是各不相同的。具体而言，在一个实施例中，如果dom元素有id，那么会推荐使用id作为用户行为数据的关键字(key)；如果使用class属性作为key，可能会通过class属性找到多个dom元素，而其中某些dom元素并不是业务系统的操作者所关心的，因此，会导致收集到的用户行为数据与业务系统的操作者实际想要收集的数据不一致；使用css路径作为key的缺点是css路径会随着页面的代码进行调整，因此，有可能发生变化，从而导致稳定性较差；而自定义属性这种方式是最后一种选择，当以上三种方式均不适合时可以采用该方式。相较于传统方式，自定义属性在代码上似乎没有太大的改进，但其优点就是不需要进行频繁的修改，并且当需要修改数据时，还可以通过后台管理侧的操作者来进行配置。

通过以上四种方式，可以很容易地利用css选择器定位到一个或多个dom元素，并为其设置相应的用户行为数据类型；当进行操作时，通过可视化用户行为定位系统，能够自动判断使用上述哪种方式更为适合。此外，也可以通过人工干预的方法来选择更好、更适合的方式。需要注意的是，通常，html中的dom元素是通过css选择器来实现一对一、一对多或者多对一的控制的。

此外，在一个实施例中，步骤S11之后、步骤S12之前还包括以下步骤S111。

S111.预设需要收集的所述用户行为数据类型的生命周期，并根据所述生命周期执行收集到的所述用户行为数据的自动生效和失效。

具体而言，在一个实施例中，还可以对需要收集的用户行为数据类型的生命周期进行预设，即预先设定好用户行为数据的生效和失效时间，使收集到的用户行为数据可以自动生效和失效。例如，如果想要收集2012年1月1日至2012年1月3日的用户行为数据，那么可预先在javascript代码中添加与用户行为数据类型的生命周期相对应的代码，使该生命周期能够自动在2012年1月1日生效并在2012年1月3日失效，也就是说，在生命周期生效后能够自动收集用户行为数据，而在生命周期失效后则会自动删除收集到的用户行为数据，因此，可以有效地节省后台管理侧的存储空间；此外，也可以通过人工的方式来干预主动上线或下线；这里，需要注意的是，上述操作对其他业务系统都是无侵入的。

由上述技术方案可知，本实施例的收集方法相对于相关技术的收集方法具有以下优点：dom元素的定位不依赖自定义属性，在可视化时，可以先获取需要布点元素的id、class等样式属性，再通过css选择器进行定位；在大部分情况下可以移除自定义属性，所述自定义属性作为最后的选择，也就是在css选择器无法准确定位时使用；能够在可视化界面上将目前已经预设的规则都展现出来，使后台管理侧的操作者可以很容易地对布点是否完成进行验证。

S12.根据所述预设的用户行为数据类型收集用户在所述原始页面上进行操作时产生的用户行为数据。具体而言，在一个实施例中，步骤S12包括：当用户在所述原始页面上进行操作时，通过所述javascript代码并根据所述映射关系来抓取所述用户行为数据。

参考上述内容，在一个实施例中，当用户在原始页面上点击某个dom元素时会通过预设的javascript代码来判断该dom元素是否有对应的用户行为数据类型；如果有，则通过预设的javascript代码来对根据该用户行为数据类型生产的用户行为数据进行抓取，并将抓取到的用户行为数据发送给数据收集服务器；否则，将不会进行抓取。

在一个实施例中，API主要有以下两个作用：一是通过定时或实时访问后台管理侧来获取用户行为数据类型；二是当用户在原始页面上进行操作时，API能够根据从后台管理侧中获取到的用户行为数据类型以及存储在业务系统中的数据来生成需要收集的用户行为数据。

此外，在相关技术中，如果想要把某个页面的公共部分(即公用模板)设置在多个页面，通常可以采用以下两种方法：一种是根据用户的需求开发出相应数量的不同的模块，并将其分别设置在多个页面中；另一种是在用户行为数据中放置一个变量，每个想要引用该模块的地方都会回传一个参数给开发人员，再由开发人员将其添加到用户行为数据中。

具体而言，第一种方法仅仅是根据用户的需求来增加相应的模块，显然这种方法过于原始也不够灵活，而且新增模块的内容与原始模块的内容是完全相同的，因此，会导致相同的数据被重复存储，进而导致大量存储空间被占用，同时也给系统的管理和维护带来很多不便；第二种方法是每个应用都会回传一个变量给模块，再由开发人员将该变量添加到用户行为数据中，这种方法需要开发人员经常对用户的数据进行配置，因此，在即时性方面相对较差，同时在系统维护成本方面也相对较高；综上所述，以上两种方法均不能方便、快捷地实现用户行为数据的收集。

而本申请的收集方法能够对预设的用户行为数据类型进行统一管理和维护，至于想要采用什么样的变量名都可以业务系统的操作者自行设定，开发人员也不需要关心应用方想要收集的是哪些数据，因此，可以很方便地实现用户行为数据的收集，同时也不会产生额外的冗余数据，有利于系统的维护及存储空间的节省。

具体而言，在一个实施例中，以某商务网站搜索的产品搜索和公司搜索为例，假设用户在产品搜索页面中输入“htc”，那么当用户在该页面上点击“求购”时生成的用户行为数据就是从产品搜索这个模块切换过去的，即发送的用户行为数据需要指定是从产品搜索这里切换过去的；同样地，假设用户在公司搜索页面中输入“htc”，那么当用户在该页面上点击“求购”时生成的用户行为数据就是从公司搜索这个模块切换过去的，即发送的用户行为数据需要指定是从公司搜索这里切换过去的；也就是说，虽然用户看到的内容是一样的，但是由于切换的模块不同，因此实际需要收集的用户行为数据是不一样的。需要注意的是，这里的头部(即产品搜索和公司搜索)完全可以共用一个，但需要采集的用户行为数据却是不同的。目前，在相关技术中对这部分不同内容的处理相对来说比较麻烦，代码也不够清楚；而本申请采用的方案可以做到不直接将用户行为数据定义在公共的模板里，而是在每个使用到该模板的地方再将用户行为数据写入，这样，不仅可以使html代码和用户行为隔离，也可以在定义此类公用代码时无需考虑用户行为数据带来的影响，从而使公用的模板最大化。

在一个实施例中，所述步骤S12之后还包括以下步骤S13。

S13.将收集到的所述用户行为数据发送到所述后台管理侧指定的数据收集服务器。

具体而言，在一个实施例中，将上述步骤S12中收集到的用户行为数据发送到后台管理侧指定的数据收集服务器。需要注意的是，这一步骤仅仅是用来将收集到的用户行为数据发送到数据收集服务器，而不需要对收集到的用户行为数据进行统计、分析等操作，也就是说，该步骤仅仅是一个简单的数据转发过程。

由上述技术方案可知，本实施例的收集方法通过可视化方式对需要发送的用户行为数据进行设置，并将该用户行为数据所对应的代码与原始页面的代码进行隔离，通过javascript代码使用户行为数据与原始页面上的dom元素相关联；通过在需要统计的dom元素上布点，使得在点击dom元素时，发送请求数据到数据收集服务器完成统计汇总，而不会影响页面正常的流程。

图2为本申请可视化用户行为收集系统的实施例结构框图。如图所示，本实施例的一种可视化用户行为收集系统，包括类型设置模块11，用于在原始页面上对后台管理侧可见的子页面中预设需要收集的用户行为数据的类型，使预设的用户行为数据类型与文档对象模型元素相关联；以及数据收集模块12，用于根据预设的用户行为数据类型收集用户在原始页面上进行操作时产生的用户行为数据。

在一个实施例中，上述收集系统还包括页面抓取模块10，用于抓取原始页面，并在所述原始页面的最末处添加可视化javascript代码，其中，所述代码用于生成所述子页面，并根据所述类型设置模块中的预设来生成所述用户行为数据类型与文档对象模型元素相关联的映射关系。

具体而言，在一个实施例中，首先通过后台管理侧的页面抓取模块10来对原始页面进行抓取并将其完整呈现，这里的原始页面是指需要收集用户行为数据的页面；接着在原始页面的最末处添加可视化javascript代码。需要注意的是，这里对原始页面的抓取和可视化javascript代码的添加都是后台管理侧根据开发人员预设好的程序代码自动完成的，因此，不仅节约了人员成本，也提高了页面抓取的速度和准确性。此外，还需要注意的是，为了将原始页面的代码与需要收集的用户行为数据所产生的代码进行区分，开发人员会在上述预设好的程序代码中添加一些新的代码，使得在通过上述方法对用户行为数据进行收集时，产生的用户行为数据所对应的代码能够自动地插入到原始页面的代码的最末处，这样，可以就很容易地将产生的用户行为数据所对应的代码与原始页面的代码进行区分和隔离，从而使数据的管理更清楚，也使系统的维护更便捷。

在一个实施例中，可视化用户行为收集系统主要通过对用户行为数据进行类型设置、数据收集以及将收集到的用户行为数据传输到数据收集服务器来实现对该用户行为数据的收集。

在一个实施例中，后台管理侧的操作者在需要收集的用户行为数据上进行操作(如：鼠标右键、双击等)时会弹出设置用户行为数据类型的对话框，通过在该对话框中进行的增加、修改和删除操作来对需要收集的用户行为数据的类型进行设置，使设置后的用户行为数据类型与dom元素相关联，并将设置后的用户行为数据类型存储在后台管理侧的数据库中，需要注意的是，这里定义的仅仅是用户行为数据的类型，而并非真正需要收集的用户行为数据。例如，以新浪网为例，假设需要收集访问“新闻”版块中五条不同新闻标题的用户所产生的用户行为数据，那么新浪网的后台管理侧的操作者就要分别为每条新闻标题设置相应的用户行为数据类型，比如将第一条新闻标题对应的用户行为数据的类型设置为“新闻1”，将第二条新闻标题对应的用户行为数据的类型设置为“新闻2”，......，以此类推；此外，也可将五条不同新闻标题对应的用户行为数据的类型均设置为“新闻1”；通过上述设置可以实现用户行为数据类型与dom元素的相互关联。需要注意的是，“用户行为数据”中的“用户”是指访问业务系统(如：新浪网)的用户。

参考上述内容，在一个实施例中，如果需要收集的是用户在“标题”上的操作(如：鼠标右键、单击等)，那么此处抓取到的dom元素就应该是“标题”；需要注意的是，这里不需要对抓取到的原始页面的内容进行存储，而是采取即时抓取的方式，因此，可以节省后台管理侧的存储空间。

接续，在一个实施例中，布点相关javascript代码主要用于将用户行为数据类型与原始页面的dom元素相关联，并为原始页面关联相应的操作，如：鼠标左键点击(onclick)等。当用户进行上述操作后，通过预设的规则将与该dom元素有关的用户行为数据抓取到，并通过javascript请求将该抓取到的用户行为数据发送到数据收集服务器。

在一个实施例中，类型设置模块11进一步用于：根据id、class属性、css路径和自定义属性中的任一方式，通过自动解析在原始页面中定位一个或多个所述文档对象模型元素。参考上述内容，在一个实施例中，用户行为数据类型与dom元素相关联的方式主要有四种，即id、class属性、css路径和自定义属性；然而，上述四种方式并非每种都可以直接使用，例如，id、class属性和自定义属性都需要预先设置好dom元素，而css路径这种方式则在任何页面中都可以使用。

此外，在一个实施例中，类型设置模块11还包括生命周期预设单元111，用于预设需要收集的用户行为数据类型的生命周期，并根据生命周期执行收集到的用户行为数据的自动生效和失效。

具体而言，在一个实施例中，还可以通过生命周期预设单元111对需要收集的用户行为数据类型的生命周期进行预设，即预先设定好用户行为数据的生效和失效时间，使收集到的用户行为数据可以自动生效和失效，也就是说，在生命周期生效后能够自动收集用户行为数据，而在生命周期失效后则会自动删除收集到的用户行为数据，因此，可以有效地节省后台管理侧的存储空间；此外，也可以通过人工的方式来干预主动上线或下线；这里，需要注意的是，上述操作对其他业务系统都是无侵入的。

接续，在一个实施例中，数据收集模块12进一步用于：当用户在所述原始页面上进行操作时，通过所述javascript代码并根据所述映射关系来抓取所述用户行为数据。具体而言，在一个实施例中，当用户在原始页面上点击某个dom元素时会通过预设的javascript代码来判断该dom元素是否有对应的用户行为数据类型；如果有，则通过数据收集模块12来对根据该用户行为数据类型生产的用户行为数据进行抓取；否则，将不会进行抓取。

在一个实施例中，上述收集系统还包括数据传输模块13，用于将收集到的用户行为数据发送到后台管理侧指定的数据收集服务器。

具体而言，在一个实施例中，收集到的用户行为数据会通过数据传输模块13发送到后台管理侧指定的数据收集服务器上。需要注意的是，数据传输模块13仅用来将收集到的用户行为数据发送到数据收集服务器，而不需要对收集到的用户行为数据进行统计、分析等操作，也就是说，数据传输模块13仅具有数据转发的功能。

由上述技术方案可知，本实施例的收集系统相对于相关技术的收集系统具有结构简单、配置灵活等特点，能够方便、快捷地实现用户行为数据的类型设置、数据收集和数据传输。

综上所述，本申请的可视化用户行为收集系统及其方法可以让用户很方便地预设需要收集的用户行为数据，且能够将用户行为数据和页面原有的业务内容分离，因此，便于集中管理以及及时对无用或冗余数据进行清理；可以让用户通过不同的方式对用户行为数据类型进行可视化配置，即在可视化界面上把目前已经预设的规则都展现出来，用户可以很容易进行验证是否布点完成；此外，还可以对用户行为数据的生命周期进行管理，即设定用户行为数据的生效和失效时间，使用户行为数据可以自动生效和失效，同时也可以人工干预主动上线或下线，而这些操作对其他业务系统都是无侵入的。

虽然已参照典型实施例描述了本申请，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本申请能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施例不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (10)

1.一种可视化用户行为收集方法，所述方法包括以下步骤：

S11.在原始页面上对后台管理侧可见的子页面中预设需要收集的用户行为数据的类型，使预设的用户行为数据类型与文档对象模型元素相关联；以及

S12.根据所述预设的用户行为数据类型收集用户在所述原始页面上进行操作时产生的用户行为数据。

2.根据权利要求1所述的可视化用户行为收集方法，其中，

所述步骤S11之前还包括：

S10.抓取所述原始页面，并在所述原始页面的最末处添加javascript代码，其中，所述代码用于生成所述子页面，并根据所述步骤S11中的预设来生成所述用户行为数据类型与文档对象模型元素相关联的映射关系；以及

所述步骤S12包括：

当用户在所述原始页面上进行操作时，通过所述javascript代码并根据所述映射关系来抓取所述用户行为数据。

3.根据权利要求1所述的可视化用户行为收集方法，其中，所述步骤S12之后还包括：

S13.将收集到的所述用户行为数据发送到所述后台管理侧指定的数据收集服务器。

4.根据权利要求1所述的可视化用户行为收集方法，其中，所述步骤S11中使预设的用户行为数据类型与文档对象模型元素相关联包括：

根据id、class属性、css路径和自定义属性中的任一方式，通过自动解析在所述原始页面中定位一个或多个所述文档对象模型元素。

5.根据权利要求1所述的可视化用户行为收集方法，其中，所述步骤S11之后、所述步骤S12之前还包括：

S111.预设需要收集的所述用户行为数据类型的生命周期，并根据所述生命周期执行收集到的所述用户行为数据的自动生效和失效。

6.一种可视化用户行为收集系统，所述系统包括：

类型设置模块，用于在原始页面上对后台管理侧可见的子页面中预设需要收集的用户行为数据的类型，使预设的用户行为数据类型与文档对象模型元素相关联；以及

数据收集模块，用于根据所述预设的用户行为数据类型收集用户在所述原始页面上进行操作时产生的用户行为数据。

7.根据权利要求6所述的可视化用户行为收集系统，其中，

所述系统还包括：

页面抓取模块，用于抓取所述原始页面，并在所述原始页面的最末处添加可视化javascript代码，其中，所述代码用于生成所述子页面，并根据所述类型设置模块中的预设来生成所述用户行为数据类型与文档对象模型元素相关联的映射关系；以及

所述数据收集模块进一步用于：

当用户在所述原始页面上进行操作时，通过所述javascript代码并根据所述映射关系来抓取所述用户行为数据。

8.根据权利要求6所述的可视化用户行为收集系统，其中，所述系统还包括：

数据传输模块，用于将收集到的所述用户行为数据发送到所述后台管理侧指定的数据收集服务器。

9.根据权利要求6所述的可视化用户行为收集系统，其中，所述类型设置模块进一步用于：

根据id、class属性、css路径和自定义属性中的任一方式，通过自动解析在所述原始页面中定位一个或多个所述文档对象模型元素。

10.根据权利要求6所述的可视化用户行为收集系统，其中，所述类型设置模块包括：

生命周期预设单元，用于预设需要收集的所述用户行为数据类型的生命周期，并根据所述生命周期执行收集到的所述用户行为数据的自动生效和失效。