CN113384899A - 基于规则的运营方法及系统 - Google Patents

Abstract

本申请提供一种基于规则的运营方法及系统、计算设备及计算机可读存储介质，其中所述方法包括：规则引擎接收终端发送的分层组编号和用户信息，根据用户信息进一步提取用户扩展信息，并根据分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理；若存在匹配规则表达式的数据，获取与规则表达式对应的运营配置文件后，将所述运营配置文件发送给终端。该方法使得产品和运营人员可以独立进行业务逻辑的配置，无需研发人员的参与，提高了系统的运营效率。

Description

基于规则的运营方法及系统

技术领域

本申请涉及计算机技术领域，特别涉及一种基于规则的运营方法及系统、计算设备和计算机可读存储介质。

背景技术

在游戏系统中，存在大量复杂且多变的业务逻辑，需要根据用户的使用情况随时进行调整和更新。以往的处理方式是修改源代码，重新发版本上线。这个过程需要经历需求变更申请、开发、测试、验收、上线，需要产品和运营人员频繁与研发人员沟通，无法独立完成规则的配置，整个过程需要消耗大量人力物力、上线周期长，而且最终的配置结果也不灵活，并不适应各种场景的变化。

发明内容

有鉴于此，本申请实施例提供了一种基于规则的运营方法及系统、计算设备和计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本申请实施例的第一方面，提供了一种基于规则的运营方法，包括：

接收终端发送的数据包，所述数据包包括一分层组编号；

提取所述数据包中的当前用户信息；

规则引擎根据所述当前用户信息提取用户扩展信息；

规则引擎根据所述分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理；

若存在匹配规则表达式的数据，获取与规则表达式对应的运营配置文件；将所述运营配置文件发送给终端。

根据本申请实施例的第二方面，提供了一种基于规则的运营系统，包括：

接收模块，用于接收终端发送的数据包，所述数据包包括一分层组编号；

数据提取模块，提取所述数据包中的当前用户信息；

规则引擎，用于根据所述当前用户信息提取用户扩展信息；并根据所述分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理；

配置模块，用于若存在匹配规则表达式的数据，获取与规则表达式对应的运营配置文件；

发送模块，用于将所述运营配置文件发送给终端。

根据本申请实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述基于规则的运营方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述基于规则的运营方法的步骤。

本申请实施例中，通过使用规则引擎和规则表达式，使得产品和运营人员能够编写规则文件，独立进行系统逻辑的配置；而且表达式中可以使用中英文数据标签，产品和运营人员无需懂得编程语言即可使用，无需研发人员介入，提高了系统的运营效率；同时将用户端和服务器端的大量数据进行标签化存储，使得业务数据粒度更加精细，可以结合规则定制多种不同的业务场景，从而适应用户的需求变化，达到精细化运营的效果。

附图说明

图1是本申请实施例提供的计算设备的结构框图；

图2是本申请实施例提供的基于规则的运营方法的流程图；

图3是本申请实施例提供的一种具体实现场景的示意图；

图4是本申请实施例提供的规则列表的示意图；

图5是本申请实施例提供的基于规则的运营系统的结构示意图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“响应于确定”。

在本申请中，提供了一种基于规则的运营方法及系统、计算设备和计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例的计算设备100的结构框图。该计算设备100的部件包括但不限于存储器110和处理器120。处理器120与存储器110通过总线130相连接，数据库150用于保存数据。

计算设备100还包括接入设备140，接入设备140使得计算设备100能够经由一个或多个网络160通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备140可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本申请的一个实施例中，计算设备100的上述部件以及图1中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图1所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备100可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备100还可以是移动式或静止式的服务器。

其中，处理器120可以执行图2所示的基于规则的运营方法中的步骤。图2示出了根据本申请一实施例的基于规则的运营方法的流程图，该方法应用于服务器，包括步骤202至步骤206。

步骤202：接收终端发送的数据包，数据包包括一分层组编号；

在该步骤中，终端获取当前用户的信息，并根据当前的业务需求获取一分层组编号，将用户信息与分层组编号进行组织与打包后发送给服务器。

具体地，用户信息包括用户标识。

步骤204：提取数据包中的当前用户信息，规则引擎根据当前用户信息提取用户扩展信息；

具体地，在该步骤中，规则引擎根据终端用户信息中的用户标识，在数据库中进行查询，获得当前用户在游戏中的历史操作记录。

在一种具体的实施方式中，在服务器启动时，启动规则引擎的初始化，读入预设的规则文件，使用规则文件的表达式代码建立规则引擎实例；其中，在规则表达式中采用中英文标签的形式对数据变量进行描述，采用常用的符号对表达式进行组织，实现逻辑运算、算数运算、关系运算、对象属性处理等功能，并提供语法检测功能,可以及时发现表达式的书写错误；规则引擎还对表达式进行预处理和cache，对用户变量进行多级cache的管理；支持自定义函数和各类数学运算。

步骤206：规则引擎根据分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理；

具体地，在该步骤中规则引擎首先根据分层组编号查询规则库，得到一规则文件列表；进而遍历该规则文件列表中的每一个规则文件，利用规则文件中的表达式对当前用户信息以及用户扩展信息中的数据进行运算和匹配。

在一种具体的实施方式中，规则文件列表的规则文件按权重排序；当规则文件中的表达式匹配成功时，停止遍历。

权重的设定由本领域技术人员根据具体的需求实现，在此不做特别的限定。

在另一种具体的实施方式中，规则引擎对表达式进行词法解析后进行运算和判定；

在另一种具体的实施方式中，为每个匹配成功的规则文件设置一个计数器，每匹配成功一次，计数器加1；若计数器的数值大于一阈值，降低该规则文件的权重值，从而防止同一规则被多次匹配，导致重复的运营方式。

步骤208：若存在匹配规则表达式的数据，获取与规则表达式对应的运营配置文件；将所述运营配置文件发送给终端。

具体地，在该步骤中，每一条规则表达式对应一个运营配置文件，当规则表达式被匹配时，服务器获取与该规则表达式对应的运营配置文件，并将其返回给终端，终端根据该运营配置文件对游戏进行配置，实现运营业务逻辑的调整。

具体地，该运营配置文件包括多种运营类型，包括但不限于礼包配置文件、难度配置文件，商城及道具配置文件等等。只要与游戏运营相关的数据，都可以通过上述方式进行配置，在此不再赘述。本领域技术人员也可知晓，上述方法并不局限于游戏系统，也同样适用于其他的计算机信息系统。

上述方案获取用户终端发送的数据，通过预设的规则引擎确定与之对应的规则文件；再由规则引擎根据规则文件中匹配的规则确定相应的运营配置文件。通过该方式，将复杂多变的规则从硬编码中解放出来，以规则的形式来处理业务逻辑，在提高了系统灵活性和效率。

图3则示出了本申请实施例一种具体地实现场景，用于控制游戏中用户礼包的发放，为不同的用户配置不同的礼包。

运营人员通过规则引擎提供的功能编写规则，如下例所示：

规则A：

version_compare($版本号,">＝","1.1.37")&&$clientId＝＝'Android_5.01_tyGuest,facebook.googleplay.0-hall20497.googleplay.DreamHDM'&&($付费金额大于 之前的单次金额＝＝15.99||($付费金额大于之前的单次金额＝＝19.99&&$最近一次付费 间隔>＝2880))&&$注册时间戳>＝1621512000

在上述规则表达式中，通过中英文标签“版本号”、“clientId”、“付费金额大于之前的单次金额”等来表达数据变量，使得运营人员无需了解编程语言即可实现规则的配置。

在本实施例中，终端获取当前用户A的信息，如当前游戏应用的版本号、安装包的前端标签(clientId)，并且，例如当用户A点击游戏应用“礼包”界面时，获取礼包的分层组编号，然后将这些信息一起打包发送给服务器的规则引擎。

如图4所示，规则引擎通过分层组编号获取礼包发放规则列表。

规则引擎依次将获得的数据输入到规则列表的每个规则文件中进行匹配，规则引擎获取的数据如表1所示：

表1 规则引擎获得的用户A的数据

在表1中，“版本号”,“clientId”为终端发送的用户A的相关数据。“付费金额大于之前的单次金额”、“最近一次付费间隔”和“注册时间戳”为规则引擎根据用户标识在数据库中获取的用户历史操作数据。

在本实施例中，规则引擎判断用户A的数据与规则A的表达式匹配，因此获取与规则A对应的游戏礼包配置文件发送给用户A所在的终端。

如图4所示，规则列表中的每个规则文件都有一个权重，规则文件按照权重从大到小的顺序，依次排序。

如图4所示，规则列表中的每个规则文件还对应一个计数器，每当该规则文件匹配成功一次，计数器加1；当某个规则文件被多次匹配，导致计数器的数值大于一阈值时，则降低该规则文件的权重值，从而防止同一规则被多次匹配，导致配置重复的运营方式，用户的体验一成不变。

本申请实施例另一种具体地实现场景用于控制游戏中不同游戏能力玩家的游戏难度。

游戏运营人员通过规则引擎提供的功能编写规则，如下例所示：

规则B：

$最近3天通关数>0&&$最近3天通关数<10&&

$上轮指南针活动结果＝＝1||$最近3天通关数>＝10&&

$最近3天通关数<20&&$上轮指南针活动结果＝＝0

在上述规则表达式中，通过中文标签来表达数据变量。

上述“最近3天通关数”等变量均为规则引擎根据用户标识在数据库中获取的用户历史操作数据。

通过上述表达式，游戏运营人员可以通过规则引擎获取服务器所记录的用户历史游玩数据,对用户能力进行评估和分级,进而针对性的下发难度配置给终端进行难度的调整,避免难度太高造成的用户流失,或者难度太低带来的无聊感。

本申请实施例另一种具体地实现场景可以根据用户的购买力和历史购买行为,提供不同的商品或道具供用户选择。

规则C：

version_compare($版本号,">＝","1.1.11")&&

$clientId＝＝'Android_5.01_tyGuest,facebook.googleplay.0-

hall20497.googleplay.DreamHDM'&&

$组合礼包历史单次购买最大额度<＝15.99&&

$组合礼包历史单次购买最大额度>6.99&&

$纯金币包历史单次购买最大额度<＝4.99&&

$纯金币包历史单次购买最大额度>0.99

同样，通过规则C，游戏运营人员实现了根据不同用户历史购买数据，推荐不同的运营配置文件到终端，实现了游戏的难度根据用户的游戏能力随时调整。

在上述多个实施例中，基于规则的运营方法从终端和服务器中获得了多种维度的用户和用户行为标签，根据不同用户、不同场景、不同流程的差异将这些数据标签进行组合，配置出相适应的规则，从而实现了游戏系统中多种类型的精细化运营方式，极大的提高了用户的满意度和体验。

与上述方法实施例相对应，本申请还提供了一种基于规则的运营系统的实施例，图5示出了本申请一个实施例的一种基于规则的运营系统的结构示意图。如图5所示，该系统包括：

接收模块，用于接收终端发送的数据包，所述数据包包括一分层组编号；

数据提取模块，提取所述数据包中的当前用户信息；

规则引擎，用于根据所述当前用户信息提取用户扩展信息；并根据所述分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理；

配置模块，用于若存在匹配规则表达式的数据，获取与规则表达式对应的运营配置文件；

发送模块，用于将所述运营配置文件发送给终端。

可选地，规则引擎被配置为：

根据当前用户信息中的用户标识在数据库中进行查询，获得当前用户的历史操作记录。

可选地，规则引擎还被配置为：

根据所述分层组编号查询规则库，得到规则文件列表；遍历所述规则文件列表，利用规则文件中的表达式对当前用户信息、用户扩展信息中的数据进行运算和匹配；当规则文件中的表达式匹配成功时，停止遍历。

可选地，规则引擎还被配置为：

规则文件列表中的规则文件按权重排序。

可选地，规则引擎还被配置为：

为每个匹配成功的规则文件设置一个计数器，每匹配成功一次，计数器加1；若计数器的数组大于一阈值，降低该规则文件的权重值。

可选地，规则引擎还被配置为：

规则表达式包括中英文标签以及运算符。

可选地，配置模块被配置为：

运营配置文件包括但不限于下列文件之一：礼包配置文件、难度配置文件，商城及道具配置文件。

上述为本实施例的一种基于规则的运营系统的示意性方案。需要说明的是，该基于规则的运营系统的技术方案与上述的基于规则的运营方法的技术方案属于同一构思，基于规则的运营系统的技术方案未详细描述的细节内容，均可以参见上述基于规则的运营方法的技术方案的描述。

本申请一实施例中还提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述的基于规则的运营方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的基于规则的运营方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述基于规则的运营方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述基于规则的运营方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的基于规则的运营方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述基于规则的运营方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (10)

1.一种基于规则的运营方法，应用于服务器，其特征在于包括：

接收终端发送的数据包，所述数据包包括一分层组编号；

提取所述数据包中的当前用户信息，规则引擎根据所述当前用户信息提取用户扩展信息；

规则引擎根据所述分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理；

若存在匹配规则表达式的数据，获取与规则表达式对应的运营配置文件；将所述运营配置文件发送给终端。

2.根据权利要求1所述的方法，其中规则引擎根据所述当前用户信息提取用户扩展信息包括：

规则引擎根据当前用户信息中的用户标识在数据库中进行查询，获得当前用户的历史操作记录。

3.根据权利要求1所述的方法，其中规则引擎根据所述分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理包括：

根据所述分层组编号查询规则库，得到规则文件列表；

遍历所述规则文件列表，利用规则文件中的表达式对当前用户信息、用户扩展信息中的数据进行运算和匹配；

当规则文件中的表达式匹配成功时，停止遍历。

4.根据权利要求3所述的方法，其中，所述遍历所述规则文件列表还包括：

所述规则文件列表中的规则文件按权重排序。

5.根据权利要求3所述的方法，还包括：

为每个匹配成功的规则文件设置一个计数器，每匹配成功一次，计数器加1；

若计数器的数组大于一阈值，降低该规则文件的权重值。

6.根据权利要求1所述的方法，所述规则表达式包括中英文标签以及运算符。

7.根据权利要求1所述的方法，还包括：

所述运营配置文件包括但不限于下列文件之一：

礼包配置文件、难度配置文件，商城及道具配置文件。

8.一种基于规则的运营系统，其特征在于，包括：

接收模块，用于接收终端发送的数据包，所述数据包包括一分层组编号；

数据提取模块，提取所述数据包中的当前用户信息；

规则引擎，用于根据所述当前用户信息提取用户扩展信息；并根据所述分层组编号、当前用户信息以及用户扩展信息进行规则表达式的匹配和处理；

配置模块，用于若存在匹配规则表达式的数据，获取与规则表达式对应的运营配置文件；

发送模块，用于将所述运营配置文件发送给终端。

9.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述指令时实现权利要求1-7任意一项所述方法的步骤。

10.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该指令被处理器执行时实现权利要求1-7任意一项所述方法的步骤。

Images