活动量数据获取方法、装置、电子设备及存储介质与流程

1.本技术涉及金融科技技术领域，尤其涉及一种活动量数据获取方法、装置、电子设备及存储介质。


背景技术：

2.银行内部需要对业务经理进行业绩指标的考核，因此需要建立相关平台进行活动量数据的记录。业务经理进行业务活动时常会在不同的场景中进行，为使得记录的数据更加有序，在平台中对每个业务场景均构建单独的子系统，然后分别进行活动量数据的统计。然而，随着银行业务的横向发展，业务经理进行业务活动时的涉及到的场景也会越来越多，当前在每构建一个新业务场景时均需要从头开始对业务规则进行编写和设置，但多套代码的逻辑大同小异，使得开发效率较低，新业务场景的上线时间也会拉长，不利于业务经理的业务开展，且分别开发使得各业务场景下的活动量数据也较为紊乱，使得管理复杂。
3.因此，当前在获取活动量数据过程中存在业务场景开发效率较低且数据管理复杂的技术问题，需要改进。


技术实现要素：

4.本技术实施例提供一种活动量数据获取方法、装置、电子设备及存储介质，用以缓解当前获取活动量数据过程中业务场景开发效率较低且数据管理复杂的技术问题。
5.为解决上述技术问题，本技术实施例提供以下技术方案：
6.本技术提供一种活动量数据获取方法，包括：
7.接收场景配置操作，根据所述场景配置操作在规则引擎中建立多个业务场景；
8.接收规则配置操作，根据所述规则配置操作在所述规则引擎中分别生成各业务场景的业务规则；
9.接收目标业务场景下的活动量数据的获取请求；
10.响应于所述获取请求，从总接触历史数据中获取所述目标业务场景对应的目标接触历史数据；
11.调用所述规则引擎基于所述目标业务场景的目标业务规则对所述目标接触历史数据进行处理，得到所述目标业务场景下的活动量数据。
12.同时，本技术实施例还提供了一种活动量数据获取装置，包括：
13.第一接收模块，用于接收场景配置操作，根据所述场景配置操作在规则引擎中建立多个业务场景；
14.第二接收模块，用于接收规则配置操作，根据所述规则配置操作在所述规则引擎中分别生成各业务场景的业务规则；
15.第三接收模块，用于接收目标业务场景下的活动量数据的获取请求；
16.获取模块，用于响应于所述获取请求，从总接触历史数据中获取所述目标业务场景对应的目标接触历史数据；
17.处理模块，用于调用所述规则引擎基于所述目标业务场景的目标业务规则对所述目标接触历史数据进行处理，得到所述目标业务场景下的活动量数据。
18.本技术还提供一种电子设备，包括存储器和处理器；所述存储器存储有应用程序，所述处理器用于运行所述存储器内的应用程序，以执行上述任一项所述的活动量数据获取方法中的步骤。
19.本技术实施例提供一种计算机可读存储介质，计算机可读存储介质存储有多条指令，指令适于处理器进行加载，以执行上述活动量数据获取方法中的步骤。
20.有益效果：本技术提供一种活动量数据获取方法、装置、电子设备及存储介质，该方法先接收场景配置操作，根据场景配置操作在规则引擎中建立多个业务场景，然后接收规则配置操作，根据规则配置操作在规则引擎中分别生成各业务场景的业务规则，再接收目标业务场景下的活动量数据的获取请求，响应于获取请求从总接触历史数据中获取目标业务场景对应的目标接触历史数据，最后调用规则引擎基于目标业务场景的目标业务规则对目标接触历史数据进行处理，得到目标业务场景下的活动量数据。本技术通过设置规则引擎，实现了业务规则与业务决策的分离，在建立业务场景和业务规则时仅需要在规则引擎中进行简单的配置即可，不需要更改相关的业务代码，因此开发效率较高，且实现了业务规则的统一化配置，对业务规则的维护和新增也较为简单；此外，当需要获取目标业务场景下的活动量数据时，也可在规则引擎中直接根据预先配置好的目标业务规则进行客户活动量的统计，实现了活动量数据的统一化管理，降低了管理难度，因此本技术的活动量数据获取方法有利于新业务的迅速上线、有利于整个系统的业务拓展，且有利于对活动量数据的标准化管理。
附图说明
21.下面结合附图，通过对本技术的具体实施方式详细描述，将使本技术的技术方案及其它有益效果显而易见。
22.图1是本技术实施例提供的活动量数据获取方法的应用场景示意图。
23.图2为本技术实施例提供的活动量数据获取方法的流程示意图。
24.图3为本技术实施例提供的活动量数据获取方法的整体架构图。
25.图4为本技术实施例中规则引擎的工作示意图。
26.图5为本技术实施例提供的活动量数据获取装置的结构示意图。
27.图6为本技术实施例提供的电子设备的结构示意图。
具体实施方式
28.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
29.本技术实施例提供一种活动量数据获取方法、装置、电子设备和计算机可读存储介质，其中，该活动量数据获取装置可以集成在电子设备中，该电子设备可以是服务器，也可以是终端等设备。
30.请参阅图1，图1为本技术实施例所提供的活动量数据获取方法应用的场景示意图，该场景可以包括终端以及服务器，终端之间、服务器之间、以及终端与服务器之间通过各种网关组成的互联网等方式连接通信，该应用场景中包括用户终端11和服务器12；其中，用户终端11可以是具有人机交互功能的设备；服务器12包括本地服务器和/或远程服务器等。
31.用户终端11和服务器12位于无线网络或有线网络中，以实现两者之间的数据交互，其中：
32.工作人员先在用户终端11的相关界面上执行场景配置操作，服务器12根据该场景配置操作在规则引擎中建立多个业务场景，然后工作人员再在用户终端11的相关界面上执行规则配置操作，服务器12根据规则配置操作在规则引擎中分别生成各业务场景的业务规则，从而实现了业务系统的搭建，该业务系统具有多个业务场景，每个业务场景均具有各自的业务规则。然后，工作人员在用户终端11的相关界面上发起对目标业务场景下的活动量数据的获取请求，服务器12响应于该获取请求，从总接触历史数据中获取目标业务场景对应的目标接触历史数据，并调用规则引擎基于目标业务场景的目标业务规则对目标接触历史数据进行处理，得到目标业务场景下的活动量数据。通过上述过程，可以对业务经理的活动量数据进行标准化管理，实现对业务经理的业绩监管。
33.需要说明的是，图1所示的系统场景示意图仅仅是一个示例，本技术实施例描述的服务器以及场景是为了更加清楚地说明本技术实施例的技术方案，并不构成对于本技术实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统的演变和新业务场景的出现，本技术实施例提供的技术方案对于类似的技术问题，同样适用。以下分别进行详细说明。需说明的是，以下实施例的描述顺序不作为对实施例优选顺序的限定。
34.请参阅图2，图2为本技术实施例提供的活动量数据获取方法的流程示意图，请参阅图3，图3为本技术实施例提供的活动量数据获取方法的整体架构图。结合图2和图3，该方法具体包括：
35.s1：接收场景配置操作，根据场景配置操作在规则引擎中建立多个业务场景。
36.本技术的活动量数据获取方法适用于金融科技技术领域，具体为银行的业务场景管理系统，该业务场景管理系统用于对业务经理与客户的接触历史数据及相关活动量数据进行管理。业务场景是指业务经理以营销为目与客户产生接触和交流的场景，接触历史数据是指在各业务场景下由对应的服务记录的原始接触数据，活动量数据是指对按照一定的业务规则，对各业务场景下业务经理与客户的接触历史数据进行筛选、处理、统计等过程得到的有效接触数据。
37.如图3所示，在本技术实施例中，业务场景可以包括随身电话外呼访问客户场景、ai语音外呼访问客户场景、智能电话外呼访问客户场景、企业微信访问客户场景、微企视频访问客户参考、手机短信访问客户场景、宣讲会访问客户场景、传单访问客户等多个业务场景，每个业务场景的活动量数据需要单独管理，因此需要为每个业务场景开发对应的子管理系统。
38.本技术的业务场景管理系统包括规则引擎，规则引擎是是一种嵌入在应用程序中的组件，其可以实现将业务决策从应用程序的代码中分离出来，并使用预定义的语义模块编写业务决策。规则引擎具体执行可以分为接受数据输入、解释业务规则、根据业务规则做
出业务决策几个过程，在本技术中，输入的数据为接触历史数据，作出的业务决策为某个输入数据是否参与活动量数据的统计。
39.在构建每一个业务场景时，均需要执行场景配置操作，对业务场景对象、业务场景名称、业务场景相关描述等信息进行配置，规则引擎通常会提供可视化的配置界面，可在该界面中进行配置，配置完成后在规则引擎中可实现一个新业务场景的建立。
40.s2：接收规则配置操作，根据规则配置操作在规则引擎中分别生成各业务场景的业务规则。
41.在规则引擎提供的可视化配置界面中执行规则配置操作，对业务场景中接触历史数据到活动量数据的相关过滤条件进行配置，配置完成后在规则引擎中可生成一个新业务场景的业务规则。
42.对每个业务场景，其对应的业务规则通常包括条件过滤器和相应地动作，条件过滤器可以包括至少一个过滤条件，基于业务规则对接触历史数据处理的过程，也即将接触历史数据输入至条件过滤器的过程，对每个输入数据，在条件过滤器计算得到的值为真的情况下，会对输入数据执行对应的动作。因此，业务规则可理解为：设置一个或多个条件，当满足这些条件时会触发一个或多个操作；而规则引擎可以理解为：解释这些业务规则并执行业务规则得到业务决策的引擎。在本技术实施例中，业务规则中的条件具体是指对接触历史数据的过滤条件，相应地动作具体是指参与活动量数据的统计或者不参与统计。
43.例如，以业务场景为人工外呼访问客户场景为例，接触历史数据可包括各业务经理每天/每周/每月与客户的外呼语音数据，具体可以包括：每通语音电话对应的打电话对象和接电话对象、每通语音电话对应的客户电话号码、每通语音电话的通话起始时刻和通话结束时刻、每通语音电话的具体语音内容等。在该业务场景下，对应的业务规则中过滤条件可包括：打电话对象和接电话对象类型需要满足预先定义的类型编号10和34；通话时长要不少于40秒；同一业务经理给同一客户的通话每日限制1次；同一业务经理无客户号码的通话每日限制5次；排除自接触；强制校验管护人。在某一通语音电话同时满足了上述过滤条件后，对应的业务规则中动作为：将该通语音电话作为有效接触数据参与到活动量数据的统计中。
44.在一种实施例中，s2具体包括：接收规则配置操作，根据规则配置操作得到各业务场景的规则数据；通过规则引擎对各规则数据进行编译，生成各业务场景的业务规则；将多个业务规则存储至规则引擎数据库中。
45.规则配置操作在规则引擎的可视化配置界面中进行，配置后得到的每个业务场景下的规则数据，被规则引擎中的语义模块编译为特定格式的规则脚本，然后将这些规则脚本作为业务规则保存在规则引擎数据库中。
46.当系统中引入规则引擎后，业务规则将不再以程序代码的形式驻留在系统中，而是存储在规则引擎数据库中，完全独立于程序。业务人员可以像管理数据一样对业务规则进行管理，比如查询、添加、更新、统计、提交业务规则等，当需要应用某个业务规则时，调用规则引擎来加载和解释该业务规则。而当系统运行过程中出现需要对业务规则进行新增或者修改的情况时，由于业务规则通过规则引擎来实现，则可以直接利用规则引擎对业务规则进行增加和修改，不需要关注具体的代码，从而实现业务规则的随需应便。
47.s3：接收目标业务场景下的活动量数据的获取请求。
48.当需要得到其中某个业务场景下业务经理的活动量数据时，需要先向该目标业务场景发出活动量数据的获取请求，该获取请求可以是在目标业务场景的查询界面上触发查询控件来发出。
49.s4：响应于获取请求，从总接触历史数据中获取目标业务场景对应的目标接触历史数据。
50.在接收到获取请求后，先获取目标业务场景对应的目标接触历史数据。在本技术实施例中，所有已建立的业务场景的接触历史数据形成中接触历史数据并统一存储，则响应于获取请求，仅从总接触历史数据中获取目标业务场景对应的目标接触历史数据。
51.在一种实施例中，在s3之前还包括：接收接触渠道配置操作，根据接触渠道配置操作，在多个接触渠道对应的服务与规则引擎数据库之间建立连接；接收总接触历史数据的保存请求；响应于保存请求，从多个接触渠道对应的服务中分别获取接触历史数据，并保存至规则引擎数据库，得到总接触历史数据。
52.如图3所示，多个业务场景的接触历史数据是通过不同渠道进行获取的，如电访渠道、面访渠道、短信渠道、微信渠道等，在不同的渠道上可以包括多个业务场景，如电访渠道可包括随身电话外呼访问客户场景、ai语音外呼访问客户场景、智能电话访问客户场景等，在不同场景下又是通过不同的服务来获取的，如ai语音外呼场景的接触历史数据由ai语音外呼服务来统计，而企业微信场景的接触历史数据由企业微信服务来统计。在业务场景管理系统中，可以执行接触渠道配置操作，对接触历史数据的获取来源进行配置，配置后在各接触渠道对应的服务与规则引擎数据库之间建立连接。当需要获取所有已配置接触渠道中的总接触历史数据时，先向业务场景管理系统发出总接触历史数据的保存请求，然后响应于该保存请求，从多个接触渠道对应的服务中分别获取接触历史数据，并通过规则引擎数据库的统一保存接口保存至规则引起数据库，得到总接触历史数据。最后，规则引擎数据库向外提供统一的查询接口，通过调用该查询接口可实现对总接触历史数据的查询。
53.当前在银行内部，不同接触渠道的数据分布在不同的业务系统中，且各业务系统之间相互独立，在想要查询全业务场景的接触历史数据时，需要到各业务系统中分别进行查询，使得查询工作较为繁琐和困难。而在本技术实施例中，通过设置统一的保存接口，将多个接触渠道对应的服务中的接触历史数据通过统一的保存接口保存在规则引擎数据库中，则既可以单独对某个单独业务场景下的接触历史数据进行查询，又可以对某个接触渠道下的多个业务场景的接触历史数据进行查询，还可以对全业务场景的总接触历史数据进行查询，解决了当前查询工作困难的痛点，给银行相关工作人员的业务办理提供了很大帮助。
54.s5：调用规则引擎基于目标业务场景的目标业务规则对目标接触历史数据进行处理，得到目标业务场景下的活动量数据。
55.如图4所示，在得到了目标接触历史数据后，调用规则引擎从规则引擎数据库中取出目标业务场景的目标业务规则，将其加载到内存中，并对这些目标业务规则进行解析，然后输入目标接触历史数据至规则引擎中，规则引擎执行目标业务规则中，对是否满足各过滤条件进行计算和判断，得到对应的业务决策，也即是否参与到统计，最后得到并输出目标业务场景下的活动量数据。
56.如图3所示，在得到活动量数据后，同样将其保存至规则引擎数据库中，并提供统
一的查询接口，则后续可以在规则引擎数据库中实现单独业务场景的活动量数据查询和全业务场景的活动量数据查询，给银行相关工作人员的业务管理提供有效参考。在进行活动量查询时，可以设置按照每日/每周/每月来查询和展示活动量数据，则每次获取目标接触历史数据时也会按照对应的时间段来获取，实现按需展示。
57.在一种实施例中，目标接触历史数据包括多条目标接触记录，s5具体包括：调用规则引擎将每条目标接触记录依次与目标业务规则进行匹配，判断每条目标接触记录是否满足目标业务规则；统计所有满足目标业务规则的目标接触记录，得到活动量数据。
58.目标接触历史数据加载至内存的队列管理器中，规则引擎按照预设的顺序，依次取出每一条目标接触记录，将其输入至目标业务规则的条件过滤器中，当条件过滤器计算得到的值为真，则执行对该条目标接触记录的统计动作，当条件过滤器计算得到的值为假，则从内存中去除该条目标接触记录。依次对每条目标接触记录执行与目标业务规则的匹配和判断操作，直至所有目标接触记录均得到对应的业务决策。所有满足目标业务规则的目标接触记录均参与统计，最终可得到目标业务场景下的活动量数据。
59.具体地，仍然以业务场景为人工外呼访问客户场景为例，该业务场景下包括20条目标接触记录，也即20条语音电话记录，每条目标接触记录中均记载了打电话对象和接电话对象、客户电话号码、通话起始时刻和通话结束时刻、每通语音电话的具体语音内容等信息。业务规则中的过滤条件包括打电话对象和接电话对象类型需要满足预先定义的类型编号10和34；通话时长要不少于40秒；同一业务经理给同一客户的通话每日限制1次；同一业务经理无客户号码的通话每日限制5次；排除自接触；强制校验管护人。对20条语音电话记录均进行处理，发现其中5条通话时长少于40秒，3条为自接触，2条角色类型不满足，则最终得到的业务决策为仅有10条语音电话记录为有效记录，则最终得到的活动量数据为：xx业务经理在x日总共与客户进行了10个有效电话。
60.在一种实施例中，在s5之后还包括：接收复合业务场景的生成请求，复合业务场景包括规则引擎中的至少两个历史业务场景；响应于复合业务场景生成请求，获取各历史业务场景的历史业务规则；通过规则引擎对各历史业务规则进行编译和组合，生成复合业务场景的复合业务规则。
61.对于一些复杂的业务场景，如通过微信联系客户并进一步进行了面访的场景，根据管理需求，可以单独在两个业务场景中分别进行活动量数据的统计，则得到的是单独的微信访问活动量数据和面访活动量数据，但如果想要将其视为一个完整活动，则单独统计得到的两份活动量数据无法直观地反映完整的接触情况，则基于更进一步的管理需求，可以建立复合业务场景并生成复合业务场景的复合业务规则。
62.在本技术中，由于设置了规则引擎，可以直接向业务场景管理系统发送复合业务场景的生成请求，请求建立一个新的复合业务场景和对应的复合业务规则，该复合业务场景由业务场景管理系统中已经建立且具有对应历史业务规则的至少两个历史业务场景构成，响应于该请求，在规则引擎中自动建立一个复合业务场景，同时自动从规则引擎数据库中获取这些历史业务场景的历史业务规则，并通过规则引擎将这些历史业务规则进行编译和组合，得到新的规则脚本，将其作为复合业务规则存储于规则引擎数据库中。
63.通过上述方法，可以实现仅发出一个生成请求即可建立一个新的复合业务场景，并生成对应的复合业务规则，后续可在该复合业务场景下得到完整的活动量数据。复合业
务场景下的复合业务规则为两个单独历史业务规则的并集，即需要同时满足两者的过滤条件，则单独业务场景的两份活动量数据和完整业务场景的活动量数据会存在一定差异。例如，在单独的微信业务场景中，活动量数据为：xx业务经理在x日总共与客户进行了7次有效微信交流；在单独的面访业务场景中，活动量数据为：xx业务经理在x日总共与客户进行了5次有效面访。在完整的微信交流后随即进行面访的业务场景中，活动量数据可以是：xx业务经理在x日总共与客户进行了3次完整的有效微信交流加面访。即，本技术由于建立复合业务场景的过程较为简单高效，可方便快捷地实现不同维度的业绩管理。
64.在一种实施例中，在s5之后还包括：接收目标人员的绩效数据生成请求；响应于绩效数据生成请求，获取目标人员在各历史业务场景下的活动量数据、以及各历史业务场景下的预设绩效规则；根据活动量数据和预设绩效规则，生成目标人员的综合绩效数据。
65.目标人员即业务经理，业务经理的绩效与活动量数据息息相关。在当前的技术中，在计算各业务经理的绩效时，需要手动将各业务场景下的活动量数据进行导出，分别按照各业务场景下的预设绩效规则(多少活动量折算多少绩效点)来计算绩效数据，最后再进行综合，过程繁琐，效率较低，且容易出错。在本技术实施例中，在建立各历史业务场景后，将各业务场景的预设绩效规则预先导入至每个业务场景对应的子管理系统中，当需要统计时，直接在管理系统中发出目标人员的绩效数据生成请求，则管理系统响应该请求，从规则引擎数据库中获取每个历史业务场景下的活动量数据和对应的预设绩效规则，然后自动计算和加成，得到目标人员的综合绩效数据，并展示在管理系统的相关界面上。通过此方式，不需要人工跨子系统进行分别计算和加成，实现了对综合绩效数据的自动计算和一键获取。
66.在一种实施例中，在s5之后还包括：接收业务更新配置操作，根据配置操作在规则引擎中生成各业务场景的业务更新规则；基于预设周期生成对目标业务规则的更新请求；响应于更新请求，调用规则引擎基于目标业务场景的目标业务更新规则对目标接触历史数据和活动量数据进行处理，得到目标业务规则的更新数据；基于更新数据对目标业务规则进行更新。
67.在初次对业务规则进行配置，并基于该业务规则进行活动量数据的统计后，可能会存在业务规则中的过滤条件门槛过高或过低，导致活动量数据的统计值不够合理，需要对其进行调整。在本技术实施例中，预先在系统中对执行业务更新配置操作，对各业务规则在哪些情况下需要更新以及如何更新的情况进行配置，然后分别得到各业务场景下的业务更新规则，并存储至规则引擎数据库中。同时，设置定期自动更新机制，基于预设周期每间隔一时间段自动生成对目标业务场景的目标业务规则的更新请求，系统响应该更新请求，调用规则引擎从规则引擎数据库中取出目标业务场景的目标业务更新规则，将其加载到内存中，并对这些目标业务更新规则进行解析，然后对目标业务场景的目标接触历史数据和活动量数据执行目标业务更新规则，判断是否满足更新条件，并得到对应的业务决策，也即如何更新，最后生成目标业务规则的更新数据，并基于更新数据对目标业务规则中的相关过滤条件进行更新。
68.具体地，仍然以业务场景为人工外呼访问客户场景为例，业务规则中的过滤条件包括通话时长要不少于40秒。该业务场景的业务更新规则的过滤条件包括：通话时长小于40秒的通话次数于总通话次数的比例不能超过70％，如果超过，则对应的执行动作为：生成
将当前通话时长限制值减去5秒的更新数据。假设某一时间段内该业务场景下的目标接触历史数据包括100条通话记录，最终的活动量数据仅包括25条，在基于目标业务更新规则对这两个数据进行处理后，发现剩下的75条均由于不满足通话时长不少于40秒这一条件而不能参与统计，则满足业务更新规则的过滤条件，表示当前目标业务规则的过滤条件门槛较高，使得参与统计的有效数据量较少，需要将通话时长限制值调低。此时，生成的更新数据为“将当前通话时长限制值减去5秒”，基于该更新数据对目标业务规则进行更新，在更新后目标业务规则中的过滤条件为通话时长要不少于35秒。后续在基于该目标业务规则对目标接触历史数据进行处理时，有效数据的数量会相应增加。
69.在更新之前，可以将更新数据发送给规则配置人员，由规则配置人员来确认该更新数据是否合理，如果不合理，则不会进行更新，如果确认是合理的，则会进行更新。通过设置此机制，可以定期对业务规则进行自动维护，使得该业务规则可以更加合理，对业务经理的业绩监管也更加到位。
70.通过上述各实施例可知，本技术的活动量数据获取方法，通过设置规则引擎，实现了业务规则与业务决策的分离，在建立业务场景和业务规则时仅需要在规则引擎中进行简单的配置即可，不需要更改相关的业务代码，因此开发效率较高，且实现了业务规则的统一化配置，对业务规则的维护和新增也较为简单；此外，当需要获取目标业务场景下的活动量数据时，也可在规则引擎中直接根据预先配置好的目标业务规则进行客户活动量的统计，实现了活动量数据的统一化管理，降低了管理难度，因此本技术的活动量数据获取方法有利于新业务的迅速上线、有利于整个系统的业务拓展，且有利于对活动量数据的标准化管理。
71.在基于规则引擎构建的业务场景管理系统中，对接触渠道、业务场景、业务规则等均可以灵活配置，给总行业务部门带来了全新的灵活接入活动量场景，再也不需要为增加一个接触渠道、业务场景或者业务规则进行大量的研发工作，且对接触历史数据和活动量数据均提供了统一的保存接口和查询接口，实现了标准化和统一化管理，大大降低了与各部门之间的对接成本。
72.在上述实施例所述方法的基础上，本实施例将从活动量数据获取装置的角度进一步进行描述，请参阅图5，活动量数据获取装置可以包括：
73.第一接收模块110，用于接收场景配置操作，根据场景配置操作在规则引擎中建立多个业务场景；
74.第二接收模块120，用于接收规则配置操作，根据规则配置操作在规则引擎中分别生成各业务场景的业务规则；
75.第三接收模块130，用于接收目标业务场景下的活动量数据的获取请求；
76.获取模块140，用于响应于获取请求，从总接触历史数据中获取目标业务场景对应的目标接触历史数据；
77.处理模块150，用于调用规则引擎基于目标业务场景的目标业务规则对目标接触历史数据进行处理，得到目标业务场景下的活动量数据。
78.在一种实施例中，第二接收模块120包括：
79.接收子模块，用于接收规则配置操作，根据所述规则配置操作得到各业务场景的规则数据；
80.编译子模块，用于通过所述规则引擎对各规则数据进行编译，生成各业务场景的业务规则；
81.存储子模块，用于将所述多个业务规则存储至规则引擎数据库中。
82.在一种实施例中，活动量数据获取装置还包括：
83.第四接收模块，用于接收接触渠道配置操作，根据所述接触渠道配置操作，在多个接触渠道对应的服务与所述规则引擎数据库之间建立连接；
84.第五接收模块，用于接收总接触历史数据的保存请求；
85.得到模块，用于响应于所述保存请求，从所述多个接触渠道对应的服务中分别获取接触历史数据，并保存至所述规则引擎数据库，得到总接触历史数据。
86.在一种实施例中，所述目标接触历史数据包括多条目标接触记录，处理模块150包括：
87.匹配子模块，用于调用所述规则引擎将每条目标接触记录依次与所述目标业务规则进行匹配，判断所述每条目标接触记录是否满足所述目标业务规则；
88.统计子模块，用于统计所有满足所述目标业务规则的目标接触记录，得到所述活动量数据。
89.在一种实施例中，活动量数据获取装置还包括：
90.第六接收模块，用于接收复合业务场景的生成请求，所述复合业务场景包括所述规则引擎中的至少两个历史业务场景；
91.第一获取模块，用于响应于所述复合业务场景生成请求，获取各历史业务场景的历史业务规则；
92.第一生成模块，用于通过所述规则引擎对各历史业务规则进行编译和组合，生成所述复合业务场景的复合业务规则。
93.在一种实施例中，活动量数据获取装置还包括：
94.第七接收模块，用于接收目标人员的绩效数据生成请求；
95.第二获取模块，用于响应于所述绩效数据生成请求，获取所述目标人员在各历史业务场景下的活动量数据、以及各历史业务场景下的预设绩效规则；
96.第二生成模块，用于根据所述活动量数据和所述预设绩效规则，生成所述目标人员的综合绩效数据。
97.在一种实施例中，活动量数据获取装置还包括：
98.第八接收模块，用于接收业务更新配置操作，根据配置操作在所述规则引擎中生成各业务场景的业务更新规则；
99.第三生成模块，用于基于预设周期生成对目标业务规则的更新请求；
100.第一处理模块，用于响应于所述更新请求，调用所述规则引擎基于所述目标业务场景的目标业务更新规则对所述目标接触历史数据和所述活动量数据进行处理，得到所述目标业务规则的更新数据；
101.更新模块，用于基于所述更新数据对所述目标业务规则进行更新。
102.区别于现有技术，本技术提供的活动量数据获取装置，先接收场景配置操作，根据场景配置操作在规则引擎中建立多个业务场景，然后接收规则配置操作，根据规则配置操作在规则引擎中分别生成各业务场景的业务规则，再接收目标业务场景下的活动量数据的
获取请求，响应于获取请求从总接触历史数据中获取目标业务场景对应的目标接触历史数据，最后调用规则引擎基于目标业务场景的目标业务规则对目标接触历史数据进行处理，得到目标业务场景下的活动量数据。本技术通过设置规则引擎，实现了业务规则与业务决策的分离，在建立业务场景和业务规则时仅需要在规则引擎中进行简单的配置即可，不需要更改相关的业务代码，因此开发效率较高，且实现了业务规则的统一化配置，对业务规则的维护和新增也较为简单；此外，当需要获取目标业务场景下的活动量数据时，也可在规则引擎中直接根据预先配置好的目标业务规则进行客户活动量的统计，实现了活动量数据的统一化管理，降低了管理难度，因此本技术的活动量数据获取方法有利于新业务的迅速上线、有利于整个系统的业务拓展，且有利于对活动量数据的标准化管理。
103.相应的，本技术实施例还提供一种电子设备，如图6所示，该电子设备可以包括射频(rf，radio frequency)电路601、包括有一个或一个以上计算机可读存储介质的存储器602、输入单元603、显示单元604、传感器605、音频电路606、wifi模块607、包括有一个或者一个以上处理核心的处理器608、以及电源609等部件。本领域技术人员可以理解，图6中示出的电子设备结构并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：
104.射频电路601可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器608处理；另外，将涉及上行的数据发送给基站。存储器602可用于存储软件程序以及模块，处理器608通过运行存储在存储器602的软件程序以及模块，从而执行各种功能应用以及数据处理。输入单元603可用于接收输入的数字或字符信息，以及产生与客户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。
105.显示单元604可用于显示由客户输入的信息或提供给客户的信息以及服务器的各种图形客户接口，这些图形客户接口可以由图形、文本、图标、视频和其任意组合来构成。
106.电子设备还可包括至少一种传感器605，比如光传感器、运动传感器以及其他传感器。音频电路606包括扬声器，扬声器可提供客户与电子设备之间的音频接口。
107.wifi属于短距离无线传输技术，电子设备通过wifi模块607可以帮助客户收发电子邮件、浏览网页和随访流式媒体等，它为客户提供了无线的宽带互联网随访。虽然图6示出了wifi模块607，但是可以理解的是，其并不属于电子设备的必须构成，完全可以根据需要在不改变申请的本质的范围内而省略。
108.处理器608是电子设备的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器602内的软件程序和/或模块，以及调用存储在存储器602内的数据，执行电子设备的各种功能和处理数据，从而对手机进行整体监控。
109.电子设备还包括给各个部件供电的电源609(比如电池)，优选的，电源可以通过电源管理系统与处理器608逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
110.尽管未示出，电子设备还可以包括摄像头、蓝牙模块等，在此不再赘述。具体在本实施例中，服务器中的处理器608会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器602中，并由处理器608来运行存储在存储器602中的应用程序，从而实现以下功能：
111.接收场景配置操作，根据所述场景配置操作在规则引擎中建立多个业务场景；
112.接收规则配置操作，根据所述规则配置操作在所述规则引擎中分别生成各业务场景的业务规则；
113.接收目标业务场景下的活动量数据的获取请求；
114.响应于所述获取请求，从总接触历史数据中获取所述目标业务场景对应的目标接触历史数据；
115.调用所述规则引擎基于所述目标业务场景的目标业务规则对所述目标接触历史数据进行处理，得到所述目标业务场景下的活动量数据。
116.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见上文的详细描述，此处不再赘述。
117.本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。
118.为此，本技术实施例提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以实现以下功能：
119.接收场景配置操作，根据所述场景配置操作在规则引擎中建立多个业务场景；
120.接收规则配置操作，根据所述规则配置操作在所述规则引擎中分别生成各业务场景的业务规则；
121.接收目标业务场景下的活动量数据的获取请求；
122.响应于所述获取请求，从总接触历史数据中获取所述目标业务场景对应的目标接触历史数据；
123.调用所述规则引擎基于所述目标业务场景的目标业务规则对所述目标接触历史数据进行处理，得到所述目标业务场景下的活动量数据。
124.以上对本技术实施例所提供的一种活动量数据获取方法、装置、电子设备和计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本技术的技术方案及其核心思想；本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例的技术方案的范围。