CN116186012A - 记录和奖励发放逻辑的版本的方法、装置、设备和介质 - Google Patents

记录和奖励发放逻辑的版本的方法、装置、设备和介质 Download PDF

Info

Publication number
CN116186012A
CN116186012A CN202310154794.6A CN202310154794A CN116186012A CN 116186012 A CN116186012 A CN 116186012A CN 202310154794 A CN202310154794 A CN 202310154794A CN 116186012 A CN116186012 A CN 116186012A
Authority
CN
China
Prior art keywords
activity
data
settlement
rule
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310154794.6A
Other languages
English (en)
Inventor
刘钊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Baoyun Network Information Service Co ltd
Original Assignee
Shanghai Baoyun Network Information Service Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Baoyun Network Information Service Co ltd filed Critical Shanghai Baoyun Network Information Service Co ltd
Priority to CN202310154794.6A priority Critical patent/CN116186012A/zh
Publication of CN116186012A publication Critical patent/CN116186012A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • General Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Game Theory and Decision Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Technology Law (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请公开了一种奖励结算方法、装置、设备和介质，属于计算机领域。所述结算方法包括：运营数据从匹配中心进入，匹配中心前置数据清洗模块；前置数据清洗模块，根据数据接入方数据结构配置好相关数据映射，前置模块将数据清洗为标准化数据结构后，数据流入匹配中心，正式开始对开启中的活动进行匹配；匹配中心将满足匹配的数据，继续往结算中心流出；结算中心则：处理实时结算和定死结算的活动，并发放奖励。

Description

记录和奖励发放逻辑的版本的方法、装置、设备和介质
技术领域
本申请属于计算机领域，具体涉及一种记录和奖励发放逻辑的版本的方法、装置、设备和介质。
背景技术
随着互联网技术的发展，人们越来越多的采用线上办理各种业务，例如通过网络办理保险业务。随着电子保单的启用，人们更加普遍地采用线上的方式办理保险业务。
保险业务是一项极其复杂的金融活动，涉及诸多保险活动规则。现有保险运营各业务线(如：个险、团险、车险、邀新、续保、续收、渠道等)都有各自单独的活动模块(系统)，以上各业务线衍生相关的退保、加人加费减人减费(保险保全的术语，也就是保单保障内容发生变更，加人是指比如保单原来保障1人，现在再加其他人加费是指比如保单原来保费10W，现在加保费比如再加5w，一般来说保费越高，保额(理赔赔付的)也就越高)、各对接保险公司数据结构等等各复杂场景揉合在一起的运营活动，其中运营活动指的是公司运营人员根据业务目标kpi等，开展一个或多个活动，以促进平台用户，如云i保的代理人用户去出更多的保单，出更多的保费的这类活动，活动主要是指出单，比如个人险，团队险，车险，宠物险等各种保险产品，按照运营计划假如到该运营活动中，本质上是为了提供用户平台黏性，提高平台出单量，提高平台月度、季度、年度等的出单目标，，基本都是各业务方的各玩各的，例如保险代理公司比如i云保下面的保通保险代理公司，需要在i云保app平台上卖各种保险产品，比如众安意外险，平安重疾险等等，那么众安、平安、太平洋等这些保险公司的的产品需要跟我们保通保险代理公司对接，每个保险公司的保单数据结构都不一样，各种投保流程也不统一等各种不统一，所以在每个保险公司的保险产品放在某一个运营活动内就很复杂，每一个业务方一旦需要开展运营活动，就需要运营+研发+测试+设计等各方参与支持。具体地，一个运营活动的开展，一般是由活动运营部门A同事提出，即提出活动开展意向(比如1月份平台需要开展一个个险出单活动，有20种不同的保险公司的产品需要加入到该活动)，然后把该需求意向交给需求分析部门B同事，B同事对需求进行详细分析，撰写出本活动需求文档，然后B同事组织以下各部门开展活动需求评审，收集各部门提出的问题和建议：活动运营部门(需求提出)、UED设计部门(设计活动图)、活动开发部门(开发活动代码逻辑，包含前端开发、后端开发)、活动测试部门(测试开发提交的活动页面)、大数据部门(活动数据报表展示)，以上各方都有各自的需求排期，不一定都有时间空余做这个活动需求，那在时间冲突的情况下，则需要排优先级，各方PK谁先谁后，各方参与解决，在各待处理的问题都解决后，活动进入开发阶段，前后端开发完成后，提交测试，测试完成后，活动上线平台，用户参与活动。，耗费人力物力财力、资源PK、需求难对齐、问题频出、运营数据统计耗时(过往的审核都是线下审核，邮件或者文件形式，运营人员编写活动内容耗时，审核内容每个活动都不一样，审核内容模板不统一，审核人员审核反馈也比较耗时)、方案审核时效拖沓，每个运营活动奖励以往都需要在活动结束后，有数据部门根据活动要求，计算出最终的活动奖励数据(计算需要时间)，然后线下提交给财务部审核到最终发放需要走财务流程，财务线下发放流程较慢，最终发放到用户的账户耗时很长时间，运营奖励发放时效冗长，从而导致的运营效率低下、运营目标难以达成、业务发展未达预期等诸多问题。
发明内容
本申请实施例的目的是提供一种奖励发放方法、装置、电子设备、介质、芯片和计算机程序产品，能够解决业务人员难以完整高效地获取业务逻辑的历史版本的问题。
第一方面，本申请实施例提供了一种奖励结算方法，所述方法包括：运营数据从匹配中心进入，匹配中心前置数据清洗模块；前置数据清洗模块，根据数据接入方数据结构配置好相关数据映射，前置模块将数据清洗为标准化数据结构后，数据流入匹配中心，正式开始对开启中的活动进行匹配；匹配中心将满足匹配的数据，继续往结算中心流出；结算中心则：处理实时结算的活动，当多个维度都满足时，实时发放活动奖励；预结算该数据所属用户的活动数据和预计奖励，提供api给到前端以便用户在活动页面UI可以实时查看到实时累计保费、实时累计业绩、实时累计件、距离下一个最近阶梯的差额、实时累计邀请人数、实时客户数、实时预计奖励等用户关心的信息；对于定时结算的任务，系统自动按照配置的结算时间开始进行结算，结算奖励明细和活动数据(如保单明细)经运营点击发送邮件后，数据流入财务审核人员邮箱，待审核结论后，本系统自动接收。最后由运营决定何时发放奖励，发放后奖励则自动到用户账户，非现金属性奖励如优惠券实时到用户券账户，现金属性奖励在经历完等待期后，用户可操作提现，活动结束。
第二方面，本申请实施例提供了一种奖励结算装置，所述装置包括：规则配置中心，用于在规则配置中心配置活动基本属性和活动规则，在配置完成之后，提交至DMC审核系统审核，待审核完成后回传审核结果，根据审核结果修改活动配置或开启活动配置，开启后，活动即进入开启阶段；规则匹配中心，用于把接入数据按照配置转换成标准格式，以及匹配活动对象、活动时间、规则产品，决定是否计入活动；规则结算中心，用于实时结算和定时结算奖励。
第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。
第四方面，本申请实施例提供一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。
第五方面，本申请实施例提供一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的方法。
第六方面，本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如第一方面所述的方法。
在本申请实施例中，每次上线新运营活动，只需要运营按需配置相关规则，一键提交财务审核，根据审核结果修改或开启活动，系统自动接入上游数据(不同的保险公司的保单数据结构，比如众安保险的保单数据、太平洋保险保单、太平保险等，其中还细分个险、团险、车险等)，根据规则配置实时匹配，实时计算用户预计奖励，提供用户页面展示接口，自动根据配置结算时间结算活动，结算后运营可一键提交财务邮件审核奖励内容，通过后可一键发放奖励到用户账户。简单、高效、快速达成运营目标、高效运营、促进业务线发展，提升公司效益。
附图说明
图1示例性地示出了本申请实施例提供的奖励发放方法的流程图；
图2示例性地示出了本申请实施例提供的奖励发放装置；
图3示意性地示出了本申请实施例的一种电子设备；
图4示意性地示出了本申请实施例的一种电子设备的硬件结构。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一图像可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。
本保险运营规则引擎系统即规则引擎系统分三个子系统(模块)，分别是：规则配置中心、规则匹配中心、规则结算中心。解决了以下原有的技术问题：
(1)每个业务线维护着一套自己的活动模块，每次做的活动都是定制化地去实现，重复的耗费该业务开发、测试、产品、设计的人力物力，实际都是以活动奖励的形式，激励用户、引导用户，达到运营目标，但这个成本是相当高昂且重复性高，所以一套统一共用的运营活动规则引擎系统则可以解决这个痛点，将运营场景的共性固化为规则配置模块，按需配置即可实现运营活动上线，节省成本、提高运营效率。
(2)来自不同业务方的数据类型都是不同的，这也是很多活动都需要定制化的根本原因，比如，保单号这一属性，个险业务线用policyNo表示，团险业务线用gpolicyNo表示(如下所示)，但从根本上他们都是保单号，所以规则引擎中心制定了一套标准的数据格式，在业务方接入数据时，在规则配置中心配置对应的字段属性映射关系，当接入数据时，规则匹配中心就可以按照映射关系，转换成本系统的标准格式，匹配和决定是否计入活动。
个险业务线的保单数据
{
"policyNo":"ZA0001",
"premium":10000,
"insureTime":"2023-01-05 00:00:00",
"acceptTime":"2023-01-05 00:00:00",
}
团险业务线保单数据：
{
"gpolicyNo":"GZA0001",
"gpremium":20000,
"insureTime":"2023-01-05 00:00:00",
"acceptTime":"2023-01-05 00:00:00"
}
(3)原有定制化活动，结算数据都是依靠人工线下拉取活动数据，运营线下核对以及线下财务审核，造成运营奖励时效滞后，降低了用户参加活动的积极性，而规则引擎-规则结算中心则可以定时任务，根据运营人员在规则配置中心设置的结算时间，系统届时自动开启结算任务，生成规则结算明细、汇总生成活动结算数据文件、发送审核邮件给到审核人员，审核通过后，运营人员一键发放活动奖励，提高运营奖励时效，将吸引更多的用户参与活动，更大的促进运营目标的达成。
下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的操作流程记录方法、操作流程还原方法和操作流程记录和还原方法进行详细地说明。
此外，在本申请实施例中，后续述及的步骤前的序号(如S101等)均不能代表各个方法中的各个步骤的执行顺序，只是为了将说明书中对步骤所进行的文字说明与说明书附图中的附图说明建立起相互对应的关系，各个方法中的各个步骤的执行顺序应当根据本申请实施例的逻辑关系进行确定。
1、规则配置中心
运营人员在规则配置中心配置活动基本属性，如活动名称、活动对象、活动险种类型、活动结算方式、结算时间、活动有效时间等活动基本属性，以及活动层面推送配置(活动与规则的关系是1:N，即一个活动下可以有N个规则，活动层面即为所下属的N个规则共用的数据，活动层面的推送配置，如活动开始结束时间推送、活动总保费推送、总业绩推送、活动已报名推送，推送形式包括短信、站内信、app推送，推送时间类型包括活动开启时推送、结算时推送、定时推送。)，然后进入规则配置，一个活动下可以配置多个规则，即规则与规则之间横向扩展，互相独立，规则下可以配置一个或多个维度(维度即匹配活动奖励的来源，比如个险-平台首单维度，即在接收上游保单数据时，只有当前保单属于个险平台首单才会计入活动奖励，当一个规则下配置了多个维度时，比如多个维度同时满足才会计入活动奖励，例如：规则1下同时配置了维度1:个险-平台首单维度、维度2：个险-产品首单维度。当用户出单时，只有保单既为产品(产品是险种下属的细分，比如险种有个险、团险、车险等是指一个大类，每个险种下都有各自的产品，比如众安尊享e生2023版，京东安联重疾险等这些指的就是具体的产品。)首单同时且是平台首单时，才会计入活动奖励)，规则之外的属性配置还有规则产品列表、规则奖励列表、规则结算、规则推送、奖励等待期、发放对象等配置信息。
其中，活动：规则：维度＝1：N：N
即一个活动下有N个规则，一个规则下N个维度，规则与规则之间互不影响，一个规则下的维度必须同时满足，才表示满足该规则，才能计入本规则。
比如，一张保单要是否计入规则，该规则下有3个维度，维度1：平台首单，维度2：活动首单，维度3：入职首单，那只有当该保单同时满足以上3个维度才能计入活动。
活动层的配置在规则上层，一个活动层的配置是下属多个规则的的共用用配置，而规则与规则之间的规则的配置则互不影响。在配置活动配置以及活动规则下的配置完成之后，进行提交至DMC(财务审核系统，活动配置好之后，通过接口将活动数据提交给DMC系统，财务在该系统审核完成(通过或不通过之后)，实时将意见回传给本活动系统。由运营决定开启活动或修改活动重新提交财务审核)审核系统审核，待审核完成后回传审核结果，运营人员根据审核结果修改活动配置或开启活动配置，开启后，活动即进入开启阶段。
2、规则匹配中心：
规则匹配中心接入上游系统或第三方接口、推送消息(本系统是活动系统，数据来源有很多，比如上游系统，上游系统如公司内的个险出单系统，团险出单系统，第三方接口，比如外部的第三方出单平台，与本系统对接，通过对接的方式将保单等数据传给活动系统，推送消息是区别于接口对接的另一种形式，即通过引入消息中间件的形式，监听消息，消息上游系统或者第三方发送到消息中间件然后消息中间件发送给活动系统，达到参与活动的目的。)，产品或技术人员在配置表(配置表可以理解为映射表，比如上游系统或者第三方接口的关于保单的数据，如保单号的key为policyNum，保费为policyPremium等各种命名方式，但本活动系统，标准化了各种关键保单属性key的命名，比如保单号policyNo,保费premium,业绩performance等等。即通过映射配置表，将policyNum对应于policyNo，policyPremium对应于premium。所以通过映射表的映射关系，将上游数据清洗成本系统统一的标准格式数据，然后本地新建标准保单记录等，进而匹配活动与活动规则。)配置好关键字段(关键字段如保费、保单号、投保时间、承保时间、支付时间、保险起期、保险止期、过犹时间、缴费期次，是否含身故等关系到活动规则匹配的即为关键字段，有些活动使用不到的字段即为非关键字段。上游数据字段与本系统的标准字段做映射，然后取值，然后赋值到本系统生成的保单属性上。)的映射，即规则匹配中心自有指定了一套标准的数据格式，当把接入数据按照配置转换成标准格式时，即开始匹配活动对象(活动对象即一个活动，本系统可以同时开展N个活动，活动与活动相互独立)、活动时间(投保时间、出单时间)、活动对象、规则产品(计划id【活动对象即一个活动，本系统可以同时开展N个活动，活动与活动相互独立】、缴费期限、保障期限)，从而决定是否计入活动，以个险活动为例，规则1配置了A001(一年期)、A002(趸交)、A003(30年期)，当上游保单为A001，但缴费期为20年期时，那么当前该保单不能计入活动，其他同理。计入活动是获取活动预计奖励的首要前提。所以，根据此规则，规则匹配中心在整个活动期间将对任意上游数据的并发的去匹配所有活动，同时保证实时计入各满足要求的活动中。
另外规则匹配中心同时提供api,对于实时上游数据进行匹配和试算预计活动奖励，提供给活动前端页面，及时给到用户实时活动预计奖励。
3、规则结算中心
在活动创建时，规则配置中心就有关于活动结算方式和结算时间的配置，目前支持实时结算和定时结算，实时结算是指在实时接收到上游接口数据时，经过转换成本系统的标准格式后，实时生成活动奖励数据表，实时发放奖励。而定时结算活动则依靠定时任务，在收到上游的数据时，在条件满足时由规则匹配中心计入活动，由规则结算中心在指定的时间系统自动启动结算任务，按照规则配置中心的配置的规则结算对象(报名用户/指定客群等)进行结算，生成规则奖励明细，然后本活动下的多个规则按照activityId(activityId即一个活动的id，是本系统内的每个运营活动的唯一标识。)+同一用户accountId(AccountId即用户id,是本公司app用户的唯一账号)进行汇总。汇总过的结算数据会自动保存在文件系统，同时将结算excel文件链接发送到审核人员邮箱，以供审核人员下载审核，审核员可以在邮件中选择审核通过/不通过，活动接收到审核结果后，如审核通过，则本活动奖励明细自动进入活动奖励发放阶段，最后由运营人员决定发放时间后，点击即可发放至用户账户中，本活动结束。
如图1所示，示例性地示出了本申请实施例提供的奖励发放方法的流程图。请参见图1，所述奖励发放方法包括以下步骤：
运营数据从匹配中心进入，匹配中心前置数据清洗模块；
前置数据清洗模块，根据数据接入方数据结构配置好相关数据映射，前置模块将数据清洗为标准化数据结构后，数据流入匹配中心，正式开始对开启中的活动进行匹配；
匹配中心将满足匹配的数据，继续往结算中心流出；
结算中心则：处理实时结算的活动，当多个维度都满足时，实时发放活动奖励；预结算该数据所属用户的活动数据和预计奖励，提供api给到前端以便用户在活动页面UI可以实时查看到实时累计保费、实时累计业绩、实时累计件、距离下一个最近阶梯的差额、实时累计邀请人数、实时客户数、实时预计奖励等用户关心的信息；对于定时结算的任务，系统自动按照配置的结算时间开始进行结算，结算奖励明细和活动数据(如保单明细)经运营点击发送邮件后，数据流入财务审核人员邮箱，待审核结论后，本系统自动接收。最后由运营决定何时发放奖励，发放后奖励则自动到用户账户，非现金属性奖励如优惠券实时到用户券账户，现金属性奖励在经历完等待期后，用户可操作提现，活动结束。
在本申请实施例中，每次上线新运营活动，只需要运营按需配置相关规则，一键提交财务审核，根据审核结果修改或开启活动，系统自动接入上游数据，根据规则配置实时匹配，实时计算用户预计奖励，提供用户页面展示接口，自动根据配置结算时间结算活动，结算后运营可一键提交财务邮件审核奖励内容，通过后可一键发放奖励到用户账户。简单、高效、快速达成运营目标、高效运营、促进业务线发展，提升公司效益。
如图2所示，示意性地示出了本申请实施例提供的一种奖励发放装置，包括：
规则配置中心：基础+规则配置的加工厂
基础配置：包括活动名称、活动模式(APP常规出单|个险邀新|团险邀新|产说会|渠道|续保|续收等)、活动参与对象、活动险种类别(个险、团险、车险、渠道)、推送配置(如报名推送提醒、达标推送提醒、激励推送提醒)、结算方式(实时|定时|循环)、活动时间等配置项。
规则配置：维度配置是规则配置的核心，是子系统规则匹配中心的匹配来源，本系统预提供维度配置池，配置池整合了各业务线使用过的及规划可能使用到的维度，并预留扩展入口用于迭代支持不断发展的业务而变化的运营需要，现有的维度类型有：平台首单(分个、团、车险，保费、业绩等大于等于小于运营设置值，下首单同)、产品首单、活动期间首单、入职后首单(入职保通后出的第一张保单。这里的入职是指本公司自定义的入职操作，即加入保通保险代理公司，成为保通保通代理公司的拥有银保监会认证代理执证号的代理人即表示入职。有入职当然有离职，离职即表示不再属于本保通保险代理公司下属的代理人，也可去别的代理公司入职。发放代理人活动奖励时，有些运营会制定规则，即当前还未离职的代理人可以活动奖励。)、保费阶梯(以保费累计为阶梯(含左不含右)，例如1000-10000保费奖励100、10000-20000保费奖励200、20000-30000保费奖励500、30000及以上保费奖励1000)、业绩阶梯(业绩阶梯即以业绩累计为准的阶梯)、保单件数阶梯(保单数阶梯，即每出一单保单数累计+1，按阶梯配置匹配奖励)、每单(每单即每一单维度，比如每一单送一张优惠券，也可配置发现金奖励)、注册时间期间(注册时间指的是注册云保app的注册时间，时间区间则值的是，该维度配置的一个时间区间)、入职时间区间、注册渠道、邀请数、首邀、邀请注册数阶梯、邀请入职数阶梯等。
规则配置除了维度外还有规则产品列表(出单产品限制)、奖励发放对象、奖励等待期、奖励内容(目前已支持优惠券、现金、券币、实物、权益)。当配置了现金属性的奖励时，等待期天数必填，等待期的作用是当现金属性的奖励发到用户账户并不是实时可提现，只有过了等待期方可提现，等待期是为了规避犹豫期内退保等现金奖励可扣回等运营场景。
层级关系：活动:规则:维度＝1:N:N,即一个活动下可以配置N个规则，规则与规则相互独立，互不影响，一个规则下可以配置N个维度，一个规则下的多个维度必须同时满足才可能拥有奖励。
规则匹配中心:运营数据(如保单)是否计入活动的判官
前置数据清洗映射板块:本系统已制定一套完整的标准数据结构，所有上游运营数据接入本系统时，必须经过与前置数据清洗模块，上游数据包括内部各业务线数据、外部第三方数据(本活动系统直接与保司对接的数据，即不是来自于本系统的出单系统的数据。如直接与众安保险某部门对接出单数据，用于开展某运营活动。)等，形式有本系统主动请求、第三方接口发送、内部业务系统MQ消息等多种形式，根据本系统需要明确必须字段与上游数据的对应结构关系，在首次接入前由研发或需求人员配置好对应的映射关系，系统即接收到数据进入时则可以自动进行清洗，生成本系统识别的标准数据，进而开始进行活动与规则匹配。
经过前置系统清洗过后的标准数据后，首先进入活动层配置数据匹配，根据保单投保时间与承保时间匹配是否满足活动有效时间内、出单人是否属于指定活动参与对象、险种是否匹配等，通过后，继而依靠多线程同时平行进入各规则层匹配，比如配置了平台首单维度，匹配本保单产品是否满足指定规则产品，满足则继续匹配是否属于平台首单，满足则建立与本活动id(本活动系统的创建的活动的数据库记录的唯一标识)+规则id(规则id是活动下属的规则的唯一标识，一个活动id下关联多个规则id,规则与规则之间的id不重复。)关联的平台首单记录(用于结算用)，多个维度遍历匹配。若存在如累计阶梯维度则建立累计阶梯和累计详情，实时计算当前用户在该规则下的累计保费、累计业绩、累计件数等信息。
规则结算中心：运营活动数据结算发动机
结算分为两部分：实时结算与定时结算(含循环结算)。
实时结算即在活动数据匹配完成后，针对在配置中心被配置为实时结算的活动，单规则内进行结算，例如规则1配置了2个维度，分别是维度1活动首单，维度2入职后首单，那根据运营的首单定义，校验是否满活动首单和入职后首单，当只有两个维度同时满足时，才会根据规则配置中心配置的奖励信息，生成奖励内容，并实时发放到用户账户，优惠券等非现金奖励实时生效，现金奖励在过了等待期方可提现。
定时结算与实时结算的规则一致，差别在于定时系统自动在运营设定的结算时刻开启定时任务，对整个活动的各个规则同时进行结算，各规则独立结算互不影响，定时结算通常用户阶梯累计维度的运营活动，如保费阶梯维度，运营可在一个阶梯维度下设置N个阶梯，并每个阶梯可以设置对应的奖励，结算时系统自动根据配置的阶梯，用户当前满足了哪个阶梯则为该用户记一笔对应奖励，阶梯可以配置交叉，取决于运营需要，自主按需配置。
例如：
不交叉的阶梯如下：
以保费累计为阶梯(含左不含右)，例如
阶梯1：1000-10000保费奖励100
阶梯2：10000-20000保费奖励200
阶梯3：20000-30000保费奖励500
阶梯4：30000及以上保费奖励1000
交叉即表示，
阶梯之前有交叉，以阶梯1和2为例，
阶梯1：1000-10000保费奖励100
阶梯2：2000-20000保费奖励200
那么当用户的累计保费达到3000时，则同时满足阶梯1和2，那么这时候，该用户的预计奖励则为100+200＝300。定时结算的结果是为每个满足奖励的用户在每个规则生成一笔奖励记录，然后多个规则合并成活动内的总奖励，奖励生成后，运营可将奖励明细和活动数据明细(如保单明细：保单号、投保时间、承保时间、出单人、投保人、保费、业绩、过犹时间、回执、回访、质检状态等信息)发送到财务审核邮箱，财务审核通过后，运营操作发放按钮，奖励则发放到用户账户，用户则在过了等待期后可提现至个人银行卡。
规则配置中心、规则匹配中心、规则结算中心，使用SpingCloud微服务架构，并集成feign依赖进行相互调用，数据库使用主流的MySQL，活动数据使用Redis缓存，上游接入数据使用RabbitMQ消息中间件或Nginx作为代理服务器接入第三方活动数据，文件系统使用aliyun oss，提供文件上传和下载。
如图3所示，本申请实施例还提供一种电子设备700，包括处理器701和存储器702，存储器702上存储有可在所述处理器701上运行的程序或指令，该程序或指令被处理器701执行时实现上述奖励发放方法实施例的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。
需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。
示意性地示出了本申请实施例提供的一种奖励发放装置600，包括：
本申请实施例中的奖励发放装置可以是电子设备，也可以是电子设备中的部件，例如集成电路或芯片。该电子设备可以是终端，也可以为除终端之外的其他设备。示例性的，电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、移动上网装置(Mobile Internet Device，MID)、增强现实(augmented reality，AR)/虚拟现实(virtualreality，VR)设备、机器人、可穿戴设备、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等，还可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personalcomputer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。
本申请实施例中的奖励发放装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。
本申请实施例提供的奖励发放装置能够实现图1的方法实施例实现的各个过程，为避免重复，这里不再赘述。
可选地，图4为实现本申请实施例的一种电子设备的硬件结构示意图。
该电子设备100包括但不限于：射频单元101、网络模块102、音频输出单元103、输入单元104、传感器105、显示单元106、用户输入单元107、接口单元108、存储器109、以及处理器110等部件。
本领域技术人员可以理解，电子设备100还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器110逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图10中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。
应理解的是，本申请实施例中，输入单元104可以包括图形处理器(GraphicsProcessing Unit，GPU)1041和麦克风1042，图形处理器1041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元106可包括显示面板1061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板1061。用户输入单元107包括触控面板1071以及其他输入设备1072中的至少一种。触控面板1071，也称为触摸屏。触控面板1071可包括触摸检测装置和触摸控制器两个部分。其他输入设备1072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。
存储器109可用于存储软件程序以及各种数据。存储器109可主要包括存储程序或指令的第一存储区和存储数据的第二存储区，其中，第一存储区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器109可以包括易失性存储器或非易失性存储器，或者，存储器x09可以包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请实施例中的存储器109包括但不限于这些和任意其它适合类型的存储器。
处理器110可包括一个或多个处理单元；可选的，处理器110集成应用处理器和调制解调处理器，其中，应用处理器主要处理涉及操作系统、用户界面和应用程序等的操作，调制解调处理器主要处理无线通信信号，如基带处理器。可以理解的是，上述调制解调处理器也可以不集成到处理器110中。
本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述奖励发放方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器ROM、随机存取存储器RAM、磁碟或者光盘等。
本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述图像分割方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。
本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如上述图像分割方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (10)

1.一种奖励结算方法，其特征在于，所述方法包括：
运营数据从匹配中心进入，匹配中心前置数据清洗模块；
前置数据清洗模块，根据数据接入方数据结构配置好相关数据映射，前置模块将数据清洗为标准化数据结构后，数据流入匹配中心，正式开始对开启中的活动进行匹配；
匹配中心将满足匹配的数据，继续往结算中心流出；
结算中心则：处理实时结算的活动，当多个维度都满足时，实时发放活动奖励；预结算该数据所属用户的活动数据和预计奖励，提供api给到前端以便用户在活动页面UI可以实时查看到实时累计保费、实时累计业绩、实时累计件、距离下一个最近阶梯的差额、实时累计邀请人数、实时客户数、实时预计奖励等用户关心的信息；对于定时结算的任务，系统自动按照配置的结算时间开始进行结算，结算奖励明细和活动数据(如保单明细)经运营点击发送邮件后，数据流入财务审核人员邮箱，待审核结论后，本系统自动接收。最后由运营决定何时发放奖励，发放后奖励则自动到用户账户，非现金属性奖励如优惠券实时到用户券账户，现金属性奖励在经历完等待期后，用户可操作提现，活动结束。
2.一种奖励结算装置，其特征在于，所述装置包括：
规则配置中心，用于在规则配置中心配置活动基本属性和活动规则，在配置完成之后，提交至DMC审核系统审核，待审核完成后回传审核结果，根据审核结果修改活动配置或开启活动配置，开启后，活动即进入开启阶段；
规则匹配中心，用于把接入数据按照配置转换成标准格式，以及匹配活动对象、活动时间、规则产品，决定是否计入活动；
规则结算中心，用于实时结算和定时结算奖励。
3.根据权利要求2所述的装置，其特征在于，规则中心包括：
基础配置模块，用于活动名称、活动模式、活动参与对象、活动险种类别、推送配置、结算方式、活动时间的配置；
规则配置模块：用于预提供维度配置池，预留扩展入口用于迭代支持不断发展的业务而变化的运营需要。
4.根据权利要求3所述的装置，其特征在于，规则中心还包括：
规则产品列表配置模块、奖励发放对象配置模块、奖励等待期配置模块、奖励内容配置模块。
5.根据权利要求3所述的装置，其特征在于，规则中心还包括：
层级关系配置模块，用于在一个活动下可以配置多个规则，以及在一个规则下可以配置多个维度。
6.根据权利要求2所述的装置，其特征在于，规则中心包括：
前置数据清洗映射板块，用于在上游运营数据接入时，对接收到数据自动进行清洗，生成标准数据，并与规则匹配。
7.根据权利要求6所述的装置，其特征在于，规则中心还包括：
配置匹配模块，用于在经过前置系统清洗过后的标准数据后，多线程同时平行进入各规则层匹配，以及多个维度遍历匹配。
8.根据权利要求2所述的装置，其特征在于，规则结算中心包括：
实时结算模块，用于在活动数据匹配完成后，针对在配置中心被配置为实时结算的活动进行结算，并根据规则配置中心配置的奖励信息，生成奖励内容，并实时发放到用户账户；
定时结算模块，用于在运营设定的结算时刻开启定时任务，对整个活动的各个规则同时进行结算，并为每个满足奖励的用户在每个规则生成一笔奖励记录，并将多个规则合并成活动内的总奖励，将奖励明细和活动数据明细发送到财务审核邮箱，在接收到财务审核通过的消息后以及响应于操作发放按钮被触发，发放奖励到用户账户。
9.一种电子设备，其特征在于，包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1所述的方法的步骤。
10.一种可读存储介质，其特征在于，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1所述的方法的步骤。
CN202310154794.6A 2023-02-22 2023-02-22 记录和奖励发放逻辑的版本的方法、装置、设备和介质 Pending CN116186012A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310154794.6A CN116186012A (zh) 2023-02-22 2023-02-22 记录和奖励发放逻辑的版本的方法、装置、设备和介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310154794.6A CN116186012A (zh) 2023-02-22 2023-02-22 记录和奖励发放逻辑的版本的方法、装置、设备和介质

Publications (1)

Publication Number Publication Date
CN116186012A true CN116186012A (zh) 2023-05-30

Family

ID=86445978

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310154794.6A Pending CN116186012A (zh) 2023-02-22 2023-02-22 记录和奖励发放逻辑的版本的方法、装置、设备和介质

Country Status (1)

Country Link
CN (1) CN116186012A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873906A (zh) * 2024-03-11 2024-04-12 云账户技术(天津)有限公司 一种交易系统中奖励金额发放的测试方法及装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117873906A (zh) * 2024-03-11 2024-04-12 云账户技术(天津)有限公司 一种交易系统中奖励金额发放的测试方法及装置
CN117873906B (zh) * 2024-03-11 2024-05-24 云账户技术(天津)有限公司 一种交易系统中奖励金额发放的测试方法及装置

Similar Documents

Publication Publication Date Title
US20230016952A1 (en) Information processing network based on uniform code issuance, method therefor, and sensing access device
CN107944834A (zh) 一种健身saas大数据一体化管理平台
US9569789B2 (en) System and method for administering marketing programs
US20090254412A1 (en) Methods and systems using targeted advertising
CN107977790A (zh) 一种集团型企业技术创新管理信息系统
US11853983B1 (en) Video revenue sharing program
US20090192869A1 (en) Marketing Control Center
US10776811B2 (en) Selectable ROCs in an online billing statement
CN111161017A (zh) 一种基于移动终端和区块链的云端营销系统及方法
US20130262188A1 (en) Social media brand management
CN104520888A (zh) 支持广告方的带宽平台
US20040122734A1 (en) Points-based rewards automation system and method
US20130317893A1 (en) System and method for coordinating event participation and payment
CN106169987A (zh) 一种公共服务平台及其使用方法
US20070198335A1 (en) System and method for providing loyalty rewards to an assistant designated to manage a financial transaction account
CN105610877A (zh) 数据交互方法、平台服务器及系统
CN102279947A (zh) 审计众包竞争提交
AU2019101649A4 (en) An improved system and method for coordinating influencers on social media networks
US20150058103A1 (en) Social media incentive point management
KR102321484B1 (ko) 문제 해결 시스템 및 문제 해결 방법
CN106716458A (zh) 用于专业服务系统和方法的计时和计费的改进的客户输入与维护系统
CN103649980A (zh) 赞助系统
CN108154421A (zh) 一种基于邻里的购物方法、系统及存储设备
CN116186012A (zh) 记录和奖励发放逻辑的版本的方法、装置、设备和介质
CN110189160A (zh) 基于心愿的网络社交、广告投放方法及网络社交系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination