用于发现有求助服务部署需求的页面的方法及装置与流程

1.本说明书实施例涉及计算机技术领域，具体地，涉及用于发现有求助服务部署需求的页面的方法及装置。


背景技术：

2.随着互联网不断发展和成熟，相应的互联网产品应运而生，并且被广泛应用。用户在使用互联网产品的过程中难免会遇到各种各样的问题，比如，产品的某个应用模块的入口找不到，产品使用过程中出现系统崩溃等。当用户遇到问题时需要联系相关的产品方或运营方来解决，否则会严重影响用户体验。
3.随着用户体验越来越被重视，为了用户能够及时反馈产品使用过程中的问题以确保用户体验，目前的一种普遍做法是在产品中部署求助渠道，当用户在产品使用过程中遇到问题时，可以通过求助渠道来反馈所遇到的问题。


技术实现要素：

4.鉴于上述，本说明书实施例提供了用于发现有求助服务部署需求的页面的方法及装置。通过本说明实施例提供的技术方案，能够实时地发现需要部署求助服务的页面，以使得这些需要部署求助服务的页面在影响用户体验之前能够及时地部署求助服务，以解决用户发起的求助。
5.根据本说明书实施例的一个方面，提供了一种用于发现有求助服务部署需求的页面的方法，包括：获取页面访问数据，所述页面访问数据包括业务、用户以及页面三个维度中的至少一个维度的数据；根据所述页面访问数据确定待评估页面；针对各个待评估页面，根据该待评估页面所部署的求助渠道对应的历史求助数据来计算该待评估页面的求助率；以及根据所述各个待评估页面的求助率来确定待部署求助服务的页面，所述求助服务用于解决用户发起的求助。
6.根据本说明书实施例的另一方面，还提供一种数据获取单元，获取页面访问数据，所述页面访问数据包括业务、用户以及页面三个维度中的至少一个维度的数据；第一页面确定单元，根据所述页面访问数据确定待评估页面；求助率计算单元，针对各个待评估页面，根据该待评估页面所部署的求助渠道对应的历史求助数据来计算该待评估页面的求助率；以及第二页面确定单元，根据所述各个待评估页面的求助率来确定待部署求助服务的页面，所述求助服务用于解决用户发起的求助。
7.根据本说明书实施例的另一方面，还提供一种电子设备，包括：至少一个处理器，与所述至少一个处理器耦合的存储器，以及存储在所述存储器上的计算机程序，所述至少一个处理器执行所述计算机程序来实现如上述任一所述的用于发现有求助服务部署需求的页面的方法。
8.根据本说明书实施例的另一方面，还提供一种计算机可读存储介质，其存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的用于发现有求助服务部署需求
的页面的方法。
9.根据本说明书实施例的另一方面，还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上任一所述的用于发现有求助服务部署需求的页面的方法。
附图说明
10.通过参照下面的附图，可以实现对于本说明书实施例内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。
11.图1示出了根据本说明书实施例的用于发现有求助服务部署需求的页面的方法的一个示例的流程图。
12.图2示出了根据本说明书实施例的根据用户维度数据来确定待评估页面的一个示例的流程图。
13.图3示出了根据本说明书实施例的根据用户维度数据来确定待评估页面的另一个示例的流程图。
14.图4示出了根据本说明书实施例的根据业务维度数据来确定待评估页面的一个示例的流程图。
15.图5示出了根据本说明书实施例的根据页面访问数据来确定待评估页面的另一个示例500的流程图。
16.图6示出了根据本说明书实施例的用于发现有求助服务部署需求的页面的装置的一个示例的方框图。
17.图7示出了根据本说明书实施例的用于实现页面发现方法的电子设备的方框图。
具体实施方式
18.以下将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本说明书实施例内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。
19.如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。
20.随着互联网不断发展和成熟，相应的互联网产品应运而生，并且被广泛应用。用户在使用互联网产品的过程中难免会遇到各种各样的问题，比如，产品的某个应用模块的入口找不到，产品使用过程中出现系统崩溃等。当用户遇到问题时需要联系相关的产品方或运营方来解决，否则会严重影响用户体验。
21.随着用户体验越来越被重视，为了用户能够及时反馈产品使用过程中的问题以确
保用户体验，目前的一种普遍做法是在产品中部署求助渠道，当用户在产品使用过程中遇到问题时，可以通过求助渠道来反馈所遇到的问题。
22.然而，求助渠道仅能供用户反馈问题，而并不能对用户提出的问题进行解决，从而导致用户求助的问题得不到及时解决，同样会导致用户体验差，甚至导致用户弃用该互联网产品。
23.鉴于上述，本说明书实施例提供了用于发现有求助服务部署需求的页面的方法及装置。在该方法中，获取页面访问数据，该页面访问数据包括从业务、用户以及页面三个维度中的至少一个维度的数据；根据页面访问数据确定出待评估页面；针对各个待评估页面，根据该待评估页面所部署的求助渠道对应的历史求助数据来计算该待评估页面的求助率；以及根据各个待评估页面的求助率来确定待部署求助服务的页面，求助服务用于解决用户提出的求助。通过本说明实施例提供的技术方案，能够实时地发现需要部署求助服务的页面，以使得这些需要部署求助服务的页面在影响用户体验之前能够及时地部署求助服务，以解决用户发起的求助。
24.下面结合附图对本说明书实施例提供的用于发现有求助服务部署需求的页面的方法及装置进行说明。
25.图1示出了根据本说明书实施例的用于发现有求助服务部署需求的页面的方法的一个示例100的流程图。
26.如图1所示，在110，可以获取页面访问数据。
27.页面访问数据包括针对用户已访问的页面的相关历史数据，可以包括业务、用户以及页面三个维度中的至少一个维度的数据。
28.以页面为维度的数据(以下称为页面维度数据)可以包括已访问的页面。在一个示例中，可以对已访问的页面进行有条件筛选，筛选的条件可以自定义，比如，可以筛选指定的页面，从而页面维度数据可以包括已访问的指定页面。
29.以用户为维度的数据(以下称为用户维度数据)可以包括各个用户访问的页面、访问页面的时间以及各个用户在页面上发起的求助等。在用户维度数据中，页面和所发起的求助可以关联存储，每个求助可以与该求助的发起页面相关联，从而可以通过一个页面确定出该页面上发起的各个求助。
30.以业务为维度的数据(以下称为业务维度数据)可以包括按照各个业务类型进行分类的多组业务维度数据，每个业务类型对应的业务维度数据可以包括该业务对应的产品信息、页面信息、与该业务相关的用户信息等，与该业务相关的用户信息可以包括用户维度数据，比如，用户访问的页面以及在页面上发起的求助等，业务维度数据中包括的用户维度数据可以按照用户进行分类。在一个示例中，可以对业务维度数据进行有条件筛选，筛选的条件可以自定义，比如，可以筛选指定业务的业务数据，从而所获取的业务维度数据可以包括指定业务对应的业务维度数据，而非指定业务的业务维度数据不会被包含在所获取的业务维度数据中。
31.在一个示例中，可以从页面访问后台数据系统中获取页面访问数据。页面访问后台数据系统可以用于存储各个用户通过终端设备访问页面的相关数据以及每条数据的存储时间等。在该示例中，可以将从页面访问后台数据系统中直接获取的页面访问数据作为本说明书实施例中所获取的页面访问数据，还可以是从页面访问后台数据系统中获取页面
访问数据后，对所获取的页面访问数据进行筛选，将筛选后的页面访问数据作为本说明书实施例中所获取的页面访问数据。
32.在一个示例中，可以获取指定范围内的页面访问数据，指定范围可以包括指定时间段、指定业务范围以及指定页面范围等中的至少一种。在获取指定时间段内的页面访问数据时，所获取的页面访问数据都属于该指定时间段内生成的数据。在获取指定业务范围内的页面访问数据时，所获取的页面访问数据包括指定业务的业务维度数据。在获取指定页面范围内的页面访问数据时，所获取的页面访问数据包括指定页面。
33.在一个示例中，可以以电子表单的方式来获取页面访问数据。在该示例中，电子表单可以与页面访问后台数据系统对接，从而电子表单可以直接从页面访问后台数据系统中获取页面访问数据。此外，电子表单可以被配置有数据筛选条件，数据筛选条件可以自定义设置。例如，数据筛选条件可以包括指定业务、指定页面、指定时间段等中的至少一个条件。
34.在该示例中，通过电子表单便于从页面访问后台数据系统中自动地获取页面访问数据，并且，电子表单的数据筛选条件能够筛选出符合自定义条件的页面访问数据，从而利用自定义条件的页面访问数据能够更精确地发现待部署求助服务的页面。
35.在120，可以根据页面访问数据确定待评估页面。
36.在本说明书实施例中，不同维度的页面访问数据可以采用不同的方式来确定出待评估页面。所确定的待评估页面可以用于后续根据页面的求助率来进一步地筛选出待部署求助服务的页面，即，待部署求助服务的页面是待评估页面中的部分页面。
37.在一个示例中，在页面访问数据包括页面维度数据时，可以将页面维度数据中包括的各个页面确定为待评估页面。在另一个示例中，在页面访问数据包括页面维度数据时，可以将页面维度数据包括的各个页面中的指定页面确定为待评估页面。
38.图2示出了根据本说明书实施例的根据用户维度数据来确定待评估页面的一个示例200的流程图。
39.如图2所示，在1211，在页面访问数据包括用户维度数据时，可以根据用户维度数据中由用户发起的求助来确定求助用户。
40.在该示例中，用户维度数据可以包括用户访问的页面以及用户发起的求助，从而可以从用户维度数据中筛选出用户发起的求助，每个求助可以关联发起该求助的用户，还可以关联该求助被发起时用户访问的页面。从而，根据求助可以确定发起各个求助的求助用户。
41.在一个示例中，可以根据所筛选出的所有求助来确定出该所有求助对应的求助用户。
42.在另一个示例中，可以从用户维度数据包括由用户发起的求助中筛选出一部分求助，然后可以将发起该一部分求助的用户确定为求助用户。
43.在一种筛选方式中，可以根据求助的数量来筛选。具体地，用户发起的求助可以包括多种类型，可以对用户维度数据中的各个求助按照求助类型进行归类，并确定每种求助类型包括的求助数量，然后可以筛选出数量排在前第一指定位的求助类型的求助。在一个示例中，可以按照每种求助类型包括的求助数量对各种求助类型进行排序，以得到求助类型序列，然后按照从多到少的顺序将前第一指定位的求助类型对应的求助筛选出。
44.在上述示例中，通过筛选出数量较多的求助，在减少数据处理量的同时，能确保用
户发起的较集中的求助能够有较大的概率在相应的页面上部署求助服务。
45.在1213，根据用户维度数据包括的求助用户所访问的页面来确定待评估页面。
46.在一个示例中，可以将用户维度数据中求助用户所访问的所有页面都确定为待评估页面。
47.在另一个示例中，可以根据指定业务、指定页面以及指定的页面访问时长阈值等中的至少一个筛选条件，从用户维度数据包括的求助用户所访问的页面中筛选出待评估页面。
48.在筛选条件包括指定业务时，可以将用户维度数据包括的求助用户所访问的页面中的与该指定业务相关的页面筛选出作为待评估页面，从而所筛选出的待评估页面均是指定业务相关的页面。在该示例中，与指定业务相关的页面可以包括指定业务对应的具有业务属性的页面等。
49.在筛选条件包括指定页面时，可以将用户维度数据包括的求助用户所访问的页面中的指定页面确定为待评估页面。
50.在该示例中，所获取的页面访问数据还可以包括针对每个页面的访问时长。在筛选条件包括指定的页面访问时长阈值时，可以将用户维度数据包括的求助用户所访问的页面中访问时长大于指定的页面访问时长阈值的页面确定为待评估页面。
51.在该示例中，可以认为访问时长较短的页面是无效访问页面，比如，用户点错进入的页面。对于无效访问页面，用户可能没有仔细浏览甚至没有浏览，因此，通过设置页面访问时长阈值，可以过滤掉访问时长较短的无效访问页面，从而提高待评估页面的质量。
52.在该示例中，在筛选条件包括有多个时，可以利用每个筛选条件分别从用户维度数据包括的求助用户所访问的页面中进行筛选，然后可以将各个筛选条件对应筛选出的待评估页面进行合并，以作为确定出的待评估页面。
53.图3示出了根据本说明书实施例的根据用户维度数据来确定待评估页面的另一个示例300的流程图。
54.如图3所示，在1221，在页面访问数据包括业务维度数据时，可以根据该业务维度数据来确定与指定业务相关的用户。
55.针对每个业务的业务维度数据可以包括：与该业务相关的各个用户以及该各个用户对应的用户维度数据、各个用户针对该业务的操作信息、该业务对应的具有业务属性的页面等。
56.与业务相关的用户可以包括咨询过业务的用户、使用业务的用户、登录业务对应的页面的用户等。业务维度数据中的各个用户对应的用户维度数据包括该各个用户访问的页面，在一个示例中，业务维度数据中包括的各个用户访问的页面可以包括该用户访问的与业务相关的页面。在另一个示例中，业务维度数据中包括的各个用户访问的页面可以包括该用户访问的与业务相关的页面以及与业务不相关的页面。
57.操作信息可以包括点击、滑动等各种操作类型的操作、求助的问题、输入信息、访问时间以及访问时长等。具有业务属性的页面是能够呈现业务属性、且能够在页面上执行相关业务操作的页面。
58.在1223，在业务维度数据中可以根据所确定出的用户来确定待评估页面。
59.在一个示例中，在业务维度数据中筛选所确定出的各个用户所访问的页面，将所
筛选出的页面确定为待评估页面。在一个示例中，在业务维度数据中所筛选出的各个用户访问的页面可以包括该各个用户访问的与对应业务相关的页面。在另一个示例中，在业务维度数据中所筛选出的各个用户访问的页面可以包括该各个用户访问的与对应业务相关的页面以及与对应业务不相关的页面。
60.在一个示例中，在确定出与指定业务相关的用户后，可以在业务维度数据中筛选由所确定出的用户发起的求助，然后，从所筛选出的求助中进一步地筛选数量排在前指定位的求助。再根据进一步筛选出的求助确定求助用户。接着，根据业务维度数据包括的求助用户所访问的页面来确定待评估页面。该示例中的操作可以参照图2所示的示例的操作说明。
61.图4示出了根据本说明书实施例的根据业务维度数据来确定待评估页面的一个示例400的流程图。
62.如图4所示，在1231，在页面访问数据包括业务维度数据时，可以根据业务维度数据来确定指定业务对应的具有业务属性的业务页面。
63.在一个示例中，当业务维度数据仅包括指定业务的业务维度数据时，可以将业务维度数据中所有业务对应的页面确定为指定业务对应的业务页面。在另一个示例中，当业务维度数据包括指定业务和非指定业务的业务维度数据时，可以从业务维度数据中筛选出指定业务对应的业务页面。
64.在1233，可以根据所确定出的业务页面来确定待评估页面。
65.在一个示例中，可以将所确定出的所有业务页面都确定为待评估页面。
66.在另一个示例中，可以将所确定出的业务页面中的一部分业务页面确定为待评估页面。在一个示例中，可以在业务维度数据中检测在所确定出的业务页面上所发起的求助，对所检测到的求助进行聚合以及筛选，以筛选出数量排在前指定位的求助，将发起所筛选的求助的用户确定为求助用户。然后，可以根据业务维度数据中包括的求助用户所访问的页面来确定待评估页面。该示例中的操作可以参照图2所示的示例的操作说明。
67.图5示出了根据本说明书实施例的根据页面访问数据中的用户维度数据来确定待评估页面的另一个示例的流程图。
68.如图5所示，在1241，在页面访问数据包括用户维度数据和/或业务维度数据时，可以从页面访问数据中筛选出由用户发起的数量排在前第二指定位的求助。
69.在一个示例中，可以从页面访问数据中提取由用户发起的所有求助，对所提取的求助按照求助类型进行分类，以确定每种求助类型包括的求助数量。然后，对各个求助类型按照所包括的求助数量进行排序，得到求助类型序列，将求助类型序列中数量排在前第二指定位的求助问题筛选出。
70.在1243，针对所筛选出的每个求助，从页面访问数据中确定该求助出现的次数排在前第三指定位的页面。
71.针对所筛选出的每个求助，在页面访问数据中筛选各个求助被发起时的页面，每个求助可以对应一组页面，每个求助对应的一组页面包括发起该求助最多的第三指定数量的页面。例如，前第三指定位是前5位，则第三指定数量是5，从而每个求助对应的一组页面包括发起该求助最多的5个页面。
72.在1245，将所筛选出的各个求助对应确定出的页面进行交叉比对，以确定求助集
中页面。
73.可以将每个求助对应确定出的一组页面作为一个页面组，每个页面组可以包括至少一个页面。针对一个页面，可以存在发起的多个求助，则该页面可以出现在多个求助对应的页面组中。
74.对各个求助对应的页面组进行交叉比对，以确定出每个页面上所发起的求助，然后可以将求助相对较多的页面确定为求助集中页面。在求助集中页面的一种确定方式中，可以根据每个页面上所发起的求助的数量来对各个页面进行排序，然后可以将求助问题的数量在前指定位的页面确定为求助集中页面。
75.在1247，将求助集中页面确定为待评估页面。
76.回到图1，在确定出待评估页面后，在130，针对各个待评估页面，根据该待评估页面所部署的各个求助渠道对应的历史求助数据来计算该待评估页面的求助率。
77.在本说明书实施例中，求助渠道是为用户提供反馈问题的方式，页面部署的求助渠道可以包括：自助求助、ivr语音求助、热线人工求助以及在线人工求助等。不同的页面所部署的求助渠道可以不同。在用户访问页面过程中，当遇到需要求助的问题时，用户可以自定义选择求助渠道进行求助。基于此，同一页面上部署的不同求助渠道对应的求助数量可以不同。
78.在本说明书实施例中，各个求助渠道对应的历史求助数据可以包括利用该求助渠道进行求助的用户以及用户总数、各个用户使用该求助渠道的时间和求助的问题等中的至少一种。在一个示例中，各个求助渠道的历史求助数据可以来自于所获取的页面访问数据。在另一个示例中，各个求助渠道的历史求助数据可以是根据所获取的页面访问数据的数据范围重新获取的，数据范围可以包括数据所属的时间段范围等。
79.页面的求助率可以表示该页面上发生求助的比例。在一个示例中，求助率可以是发生求助次数的比例。在另一个示例中，求助率可以是发起求助的用户的比例。
80.在一个示例中，针对各个待评估页面，可以根据该待评估页面所部署的各个求助渠道对应的历史求助数据来计算各个求助渠道在该待评估页面上对应的单渠道求助率。
81.在求助率是发生求助次数的比例时，针对每个待评估页面上部署的每个求助渠道，可以从该求助渠道对应的历史求助数据中统计用户使用该求助渠道进行求助的求助次数，此外还可以从该评估页面对应的历史访问数据中统计该评估页面被访问的访问次数。然后，将求助次数除以访问次数所得到的百分比确定为该求助渠道在该待评估页面上对应的单渠道求助率。
82.在求助率是发起求助的用户的比例时，针对每个待评估页面上部署的每个求助渠道，可以从该求助渠道对应的历史求助数据中统计使用该求助渠道进行求助的求助用户数量，此外还可以从该待评估页面对应的历史访问数据中统计访问该待评估页面的访问用户数量。然后，可以将求助用户数量除以访问用户数量所得到的百分比确定为该求助渠道在该待评估页面上对应的单渠道求助率。
83.针对每个待评估页面，在计算得到该待评估页面上部署的各个求助渠道对应的单渠道求助率后，可以根据各个求助渠道的单渠道求助率计算该待评估页面的求助率。
84.在一个示例中，可以将各个求助渠道的单渠道求助率进行求和运算，并将所得到的各个单渠道求助率之和确定为该待评估页面的求助率。
85.在另一个示例中，可以根据各个求助渠道的单渠道求助率以及每个求助渠道对应的求助成本系数和/或求助衰减系数来计算该待评估页面的求助率。
86.在该示例中，求助成本系数用于表示求助渠道的成本高低，求助渠道的成本越高，则相应的求助成本系数越大；求助渠道的成本越低，则相应的求助成本系数越小。例如，页面上设置的自助求助渠道，仅需要用户在页面上进行点击便能够进行求助。热线人工求助渠道需要用户拨打页面上提供的求助号码来向人工进行求助，可见，热线人工求助渠道的求助成本明显高于自助求助渠道的求助成本，因此，热线人工求助渠道的求助成本系数高于自助求助渠道的求助成本系数。
87.求助渠道的求助成本系数可以反映出用户的求助需求高低以及解决问题的倾向性，当用户使用求助成本系数越高的求助渠道时，可以反映该用户的求助需求越高，解决问题的倾向性更强。当用户使用求助成本系数越低的求助渠道时，可以反映该用户的求助需求越低，解决问题的倾向性更低。
88.求助衰减系数可以用于对求助的异常增长进行衰减，以平衡页面上求助的异常增长，从而减小求助的异常增长对求助率的影响。求助的增长越异常，则对应的求助衰减系数越大；相应地，求助的增长的异常程度越低，则对应的求助衰减系数越小。例如，由于临时活动导致活动对应的页面的访问量增大，相应的求助量增加，从而导致求助增长异常，从而可以设置对应的求助衰减系统以对异常增长的求助量进行衰减。
89.在一个示例中，求助衰减系数可以设置为0到1之间的数值，对于正常状况下的求助，可以将对应的求助衰减系数设置为1。
90.在求助衰减系数的一种确定方式中，可以统计在正常状态下的第一页面浏览人数，以及统计在求助异常增长的状态下的第二页面浏览人数，第一页面浏览人数与第二页面浏览人数所统计的时间段相同，该时间段可以是由求助异常增长的时间所确定的。比如，所针对的时间段是一天，则统计正常状态下的一天内的第一页面浏览人数，以及求助异常增长状态下的一天内的第二页面浏览人数。
91.在本说明书实施例中，求助成本系数和求助衰减系数可以都作为求助渠道的权重。针对每个求助渠道，可以将该求助渠道的单渠道求助率与作为权重的该求助渠道对应的求助成本系数和/或求助衰减系数进行相乘，以得到修正后的单渠道求助率。然后，可以将各个求助渠道对应的修正后的单渠道求助率进行求和计算，以得到对应的待评估页面的求助率。
92.在140，根据各个待评估页面的求助率来确定待部署求助服务的页面。
93.在本说明书实施例中，求助服务可以用于对用户提出的求助问题进行解决。在一个示例中，求助服务可以通过服务模块的形式嵌入到页面中，服务模块在被求助的用户触发后，可以跳转至客服入口，由客服对用户求助的问题进行解决。在另一个示例中，求助服务设置有知识问答，在求助服务被嵌入到页面中后，当页面中的求助服务被触发时，求助服务根据用户求助的问题从知识问答中匹配相应的答案，并将所匹配到的答案反馈给求助用户以解决用户的问题。
94.在本说明书实施例中，可以将求助率最高的指定数量的待评估页面确定为待部署求助服务的页面。在一个示例中，可以按照求助率对各个待评估页面进行排序，以得到待评估页面序列，待评估页面序列可以按照求助率从大到小的顺序排列，还可以是按照求助率
从小到大的顺序排列。然后，将待评估页面序列中求助率最大的前指定位的待评估页面确定为待部署求助服务的页面。
95.在确定出待部署求助服务的页面后，可以将所确定出的页面输出下游的技术人员，以使技术人员对输出的各个页面进行求助服务部署。
96.通过本说明实施例提供的技术方案，能够实时地发现需要部署求助服务的页面，以使得这些需要部署求助服务的页面在影响用户体验之前能够及时地部署求助服务，以解决用户发起的求助。
97.图6示出了根据本说明书实施例的用于发现有求助服务部署需求的页面的装置(以下称为页面发现装置600)的一个示例的方框图。
98.如图6所示，页面发现装置600包括：数据获取单元610、第一页面确定单元620、求助率计算单元630和第二页面确定单元640。
99.数据获取单元610，被配置为获取页面访问数据，页面访问数据包括业务、用户以及页面三个维度中的至少一个维度的数据。
100.在一个示例中，数据获取单元610还可以被配置为：以电子表单的方式获取页面访问数据，其中，电子表单与页面访问后台数据系统对接，电子表单被配置有数据筛选条件。
101.第一页面确定单元620，被配置为根据页面访问数据确定待评估页面。
102.在一个示例中，第一页面确定单元620还可以被配置为：在页面访问数据包括用户维度数据时，根据用户维度数据中由用户发起的求助确定求助用户；以及根据用户维度数据包括的求助用户所访问的页面来确定待评估页面。
103.在一个示例中，第一页面确定单元620还可以被配置为：从用户维度数据包括由用户发起的求助中筛选出数量排在前第一指定位的求助；以及将发起所筛选的求助的用户确定为求助用户。
104.在一个示例中，第一页面确定单元620还可以被配置为：根据指定业务、指定页面以及指定的页面访问时长阈值中的至少一个筛选条件，从用户维度数据包括的求助用户所访问的页面中筛选出待评估页面。
105.在一个示例中，第一页面确定单元620还可以被配置为：在页面访问数据包括业务维度数据时，根据业务维度数据来确定与指定业务相关的用户；以及在业务维度数据中根据所确定出的用户来确定待评估页面。
106.在一个示例中，第一页面确定单元620还可以被配置为：在页面访问数据包括业务维度数据时，根据业务维度数据来确定指定业务对应的具有业务属性的业务页面；以及根据所确定出的业务页面来确定待评估页面。
107.在一个示例中，第一页面确定单元620还可以被配置为：在页面访问数据包括用户维度数据和/或业务维度数据时，从页面访问数据中筛选出由用户发起的数量排在前第二指定位的求助；针对所筛选出的每个求助，从页面访问数据中确定该求助出现的次数排在前第三指定位的页面；将所筛选出的各个求助对应确定出的页面进行交叉比对，以确定求助集中页面；以及将求助集中页面确定为待评估页面。
108.求助率计算单元630，被配置为针对各个待评估页面，根据该待评估页面所部署的求助渠道对应的历史求助数据来计算该待评估页面的求助率。
109.在一个示例中，求助率计算单元630还可以被配置为：针对各个待评估页面，根据
该待评估页面所部署的各个求助渠道对应的历史求助数据来计算各个求助渠道在该待评估页面上对应的单渠道求助率；以及根据各个求助渠道的单渠道求助率计算该待评估页面的求助率。
110.在一个示例中，求助率计算单元630还可以被配置为：根据各个求助渠道的单渠道求助率以及每个求助渠道对应的求助成本系数和/或用于对求助的异常增长进行衰减的求助衰减系数来计算该待评估页面的求助率。
111.第二页面确定单元640，被配置为根据各个待评估页面的求助率来确定待部署求助服务的页面，求助服务用于解决用户发起的求助。
112.以上参照图1到图6，对根据本说明书实施例的用于发现有求助服务部署需求的方法及装置的实施例进行了描述。
113.本说明书实施例的用于发现有求助服务部署需求的装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将存储器中对应的计算机程序指令读取到内存中运行形成的。在本说明书实施例中，用于发现有求助服务部署需求的装置例如可以利用电子设备实现。
114.图7示出了根据本说明书实施例的用于实现页面发现方法的电子设备700的方框图。
115.如图7所示，电子设备700可以包括至少一个处理器710、存储器(例如，非易失性存储器)720、内存730和通信接口740，并且至少一个处理器710、存储器720、内存730和通信接口740经由总线750连接在一起。至少一个处理器710执行在存储器中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。
116.在一个实施例中，在存储器中存储计算机可执行指令，其当执行时使得至少一个处理器710：获取页面访问数据，该页面访问数据包括业务、用户以及页面三个维度中的至少一个维度的数据；根据页面访问数据确定待评估页面；针对各个待评估页面，根据该待评估页面所部署的求助渠道对应的历史求助数据来计算该待评估页面的求助率；以及根据各个待评估页面的求助率来确定待部署求助服务的页面，求助服务用于解决用户发起的求助。
117.应该理解，在存储器中存储的计算机可执行指令当执行时使得至少一个处理器710进行本说明书的各个实施例中以上结合图1-6描述的各种操作和功能。
118.根据一个实施例，提供了一种例如机器可读介质的程序产品。机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本说明书的各个实施例中以上结合图1-6描述的各种操作和功能。
119.具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。
120.在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。
121.本说明书各部分操作所需的计算机程序代码可以用任意一种或多种程序语言编写，包括面向对象编程语言，如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb、
net以及python等，常规程序化编程语言如c语言、visual basic 2003、perl、cobol2002、php以及abap，动态编程语言如python、ruby和groovy，或者其他编程语言等。该程序编码可以在用户计算机上运行，或者作为独立的软件包在用户计算机上运行，或者部分在用户计算机上运行另一部分在远程计算机运行，或者全部在远程计算机或服务器上运行。在后一种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(lan)或广域网(wan)，或连接至外部计算机(例如通过因特网)，或者在云计算环境中，或者作为服务使用，比如软件即服务(saas)。
122.可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如cd-rom、cd-r、cd-rw、dvd-rom、dvd-ram、dvd-rw、dvd-rw)、磁带、非易失性存储卡和rom。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。
123.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
124.上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。
125.在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。
126.以上结合附图详细描述了本说明书的实施例的可选实施方式，但是，本说明书的实施例并不限于上述实施方式中的具体细节，在本说明书的实施例的技术构思范围内，可以对本说明书的实施例的技术方案进行多种简单变型，这些简单变型均属于本说明书的实施例的保护范围。
127.本说明书内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本说明书内容。对于本领域普通技术人员来说，对本说明书内容进行的各种修改是显而易见的，并且，也可以在不脱离本说明书内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本说明书内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。