Methods, apparatus, equipment, and media for recording and reward distribution logic

Abstract

This application discloses a reward settlement method, apparatus, device, and medium, belonging to the field of computer science. The settlement method includes: operational data entering from a matching center; a pre-processing data cleaning module in the matching center; the pre-processing data cleaning module configuring relevant data mappings according to the data structure of the data access party; after cleaning the data into a standardized data structure, the data flows into the matching center, officially beginning the matching of ongoing activities; the matching center continues to send data that meets the matching criteria to the settlement center; the settlement center then processes activities with real-time settlement and fixed-settlement settlements, and distributes rewards.

Description

Technical Field

[0001] This application belongs to the field of computer science, and specifically relates to a method, apparatus, device, and medium for recording and awarding logic. Background Technology

[0002] With the development of internet technology, people are increasingly using online platforms to handle various transactions, such as insurance. With the introduction of electronic insurance policies, online methods are becoming even more prevalent for insurance transactions.

[0003] Insurance is an extremely complex financial activity involving numerous insurance rules. Existing insurance operations have various business lines (such as individual insurance, group insurance, auto insurance, new customer acquisition, renewal, collection, and channels) each with their own separate activity modules (systems). These business lines generate a complex interplay of operational activities, including policy cancellations, adding or removing policyholders (a term in insurance policy maintenance referring to changes in policy coverage; adding someone means adding another person to the policy, e.g., a premium of 100,000 RMB is increased by 50,000 RMB; generally, higher premiums result in higher coverage amounts), and various data structures with partner insurance companies. These operational activities refer to one or more activities conducted by company operations personnel based on business targets and KPIs to encourage platform users, such as agents on Yun i Bao, to issue more policies and generate more premiums. These activities primarily involve issuing policies, such as individual insurance and group insurance. Various insurance products, such as car insurance and pet insurance, are included in the operational activities according to the operational plan. Essentially, this is to increase user stickiness on the platform, improve the platform's sales volume, and meet the platform's monthly, quarterly, and annual sales targets. Basically, each business unit operates independently. For example, insurance agencies like Baotong Insurance Agency under iYunbao need to sell various insurance products on the iYunbao app platform, such as ZhongAn accident insurance and Ping An critical illness insurance. The products from insurance companies like ZhongAn, Ping An, and Pacific Insurance need to be integrated with Baotong Insurance Agency. Each insurance company has different policy data structures, and various application processes are not standardized. Therefore, including insurance products from each insurance company in a single operational activity is very complex. Once each business unit needs to carry out an operational activity, it requires the participation and support of operations, R&D, testing, and design teams. Specifically, the launch of an operational activity typically begins with colleague A from the activity operations department proposing the activity (for example, the platform needs to launch an insurance sales campaign in January, with products from 20 different insurance companies required to be included). This requirement is then passed on to colleague B from the requirements analysis department. Colleague B conducts a detailed analysis of the requirements, writes the activity requirements document, and then organizes a review of the requirements from the following departments: the activity operations department (requirement proposal), the UX / UI design department (designing activity diagrams), the activity development department (developing activity code logic, including front-end and back-end development), the activity testing department (testing the activity pages submitted by the development team), and the big data department (displaying activity data reports). Each of these departments has its own schedule and may not all have the time to work on the activity requirements. In case of time conflicts, priorities need to be set, with each department competing to determine which should be done first. All parties then work together to resolve the issues. Once all pending issues are resolved, the activity enters the development phase. After the front-end and back-end development is completed, the activity is submitted for testing. After testing is completed, the activity is launched on the platform, and users participate.The system suffers from numerous problems, including wasted human, material, and financial resources; resource competition; difficulty in aligning needs; frequent issues; and time-consuming data collection and analysis (previous reviews were all offline, conducted via email or documents, requiring time for operations staff to write activity content, as the content varied for each activity, templates were inconsistent, and feedback from reviewers was also time-consuming). Furthermore, the approval process for plans is often sluggish. Previously, after each activity, the data department would calculate the final reward data based on the activity requirements (calculation takes time), then submit it offline to the finance department for review and final disbursement, which involved a slow offline disbursement process and a long time before the rewards reached users' accounts. This lengthy disbursement process for operational rewards resulted in low operational efficiency, difficulty in achieving operational goals, and failure to meet business development expectations. Summary of the Invention

[0004] The purpose of this application is to provide a reward distribution method, apparatus, electronic device, medium, chip, and computer program product that can solve the problem that business personnel have difficulty obtaining complete and efficient historical versions of business logic.

[0005] Firstly, this application provides a reward settlement method, which includes: operational data entering from a matching center; a pre-data cleaning module in the matching center; the pre-data cleaning module configuring relevant data mappings according to the data structure of the data access party; after the pre-data cleaning module cleans the data into a standardized data structure, the data flows into the matching center to formally begin matching the ongoing activities; the matching center continues to send the matching data to the settlement center; the settlement center then: processes activities for real-time settlement, and when multiple dimensions are satisfied, issues activity rewards in real time; pre-settles the activity data and expected rewards of the user to whom the data belongs, and provides an API to the front end so that users can view the activity page UI. Users can view real-time information such as cumulative premiums, cumulative performance, cumulative policies, the difference from the next nearest tier, cumulative number of invitations, number of customers, and estimated rewards. For tasks with scheduled settlements, the system automatically starts settlement according to the configured settlement time. Settlement reward details and activity data, including policy details, are sent via email by operations and then flow into the email inbox of finance auditors. After the audit conclusion, the system automatically receives the data. Finally, operations decides when to distribute the rewards, which are then automatically credited to the user's account. Non-cash rewards, including coupons, are credited to the user's coupon account in real time. Cash rewards can be withdrawn by the user after the waiting period, at which point the activity ends.

[0006] Secondly, this application provides a reward settlement device, which includes: a rule configuration center, used to configure basic activity attributes and activity rules in the rule configuration center, and after the configuration is completed, submit it to the DMC financial audit system for review. After the review is completed, the audit result is returned, and the activity configuration is modified or the activity configuration is enabled according to the audit result. After enabling, the activity enters the enabling stage; a rule matching center, used to convert the access data into a standard format according to the configuration, and match the activity object, activity time, and rule product to determine whether to include it in the activity; and a rule settlement center, used for real-time settlement and timed settlement of rewards.

[0007] Thirdly, embodiments of this application provide an electronic device including a processor and a memory, wherein the memory stores programs or instructions executable on the processor, and the programs or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0008] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0009] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.

[0010] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method described in the first aspect.

[0011] In this embodiment, each time a new operational activity is launched, the operations team only needs to configure the relevant rules as needed, submit them for financial review with one click, and modify or start the activity based on the review results. The system automatically accesses upstream data (policy data structures from different insurance companies, such as policy data from ZhongAn Insurance, Pacific Insurance, and Taiping Insurance, which are further subdivided into individual insurance, group insurance, and auto insurance), matches the rules in real time, calculates the expected rewards for users in real time, provides an interface for displaying the rewards on the user page, and automatically settles the activity according to the configured settlement time. After settlement, the operations team can submit the reward content to the finance department via email for review with one click, and once approved, the rewards can be issued to the user's account with one click. This simple, efficient, and rapid approach achieves operational goals, promotes efficient operations, facilitates business line development, and improves company efficiency. Attached Figure Description

[0012] Figure 1 A flowchart of the reward distribution method provided in an embodiment of this application is illustrated by way of example;

[0013] Figure 2 An exemplary embodiment of the reward distribution device provided in this application is shown;

[0014] Figure 3 An electronic device according to an embodiment of this application is illustrated schematically;

[0015] Figure 4 The hardware structure of an electronic device according to an embodiment of this application is illustrated schematically. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0017] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first image can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0018] This insurance operation rule engine system consists of three subsystems (modules): rule configuration center, rule matching center, and rule settlement center. It resolves the following original technical issues:

[0019] (1) Each business line maintains its own activity module. Each activity is implemented in a customized manner, which repeatedly consumes the manpower and resources of the business development, testing, product and design. In fact, the activity rewards are used to incentivize and guide users to achieve operational goals. However, this cost is quite high and highly repetitive. Therefore, a unified and shared operational activity rule engine system can solve this pain point. It can solidify the commonality of operational scenarios into rule configuration modules, and operational activities can be launched as needed, saving costs and improving operational efficiency.

[0020] (2) The data types from different business parties are different, which is the fundamental reason why many activities need to be customized. For example, the policy number attribute is represented by policyNo in the individual insurance business line and gpolicyNo in the group insurance business line (as shown below). But fundamentally, they are all policy numbers. Therefore, the rule engine center has formulated a standard data format. When the business party accesses the data, the corresponding field attribute mapping relationship is configured in the rule configuration center. When the data is accessed, the rule matching center can convert it into the standard format of the system according to the mapping relationship, match and decide whether to include it in the activity.

[0021] Individual insurance policy data

[0022] {

[0023] "policyNo":"ZA0001",

[0024] "premium":10000,

[0025] "insureTime":"2023-01-0500:00:00",

[0026] "acceptTime":"2023-01-0500:00:00", ...

[0028] }

[0029] Group insurance policy data:

[0030] {

[0031] "gpolicyNo":"GZA0001",

[0032] "gpremium":20000,

[0033] "insureTime":"2023-01-0500:00:00",

[0034] "acceptTime":"2023-01-0500:00:00"

[0035] }

[0036] (3) In the past, the settlement data for customized activities relied on manual offline data retrieval, offline verification by operations staff, and offline financial audits. This resulted in a delay in the timeliness of operational rewards and reduced users' enthusiasm for participating in activities. However, the rule engine - rule settlement center can schedule tasks. Based on the settlement time set by the operations staff in the rule configuration center, the system will automatically start the settlement task at that time, generate rule settlement details, summarize and generate activity settlement data files, and send audit emails to the audit staff. After the audit is approved, the operations staff can issue activity rewards with one click, which improves the timeliness of operational rewards, attracts more users to participate in activities, and further promotes the achievement of operational goals.

[0037] The following description, in conjunction with the accompanying drawings, details the operation process recording method, operation process restoration method, and operation process recording and restoration method provided in this application through specific embodiments and application scenarios.

[0038] Furthermore, in the embodiments of this application, the sequence numbers preceding the steps mentioned later (such as S101, etc.) do not represent the execution order of the steps in each method, but are only used to establish a correspondence between the textual description of the steps in the specification and the description of the drawings in the specification. The execution order of the steps in each method should be determined according to the logical relationship of the embodiments of this application.

[0039] 1. Rule Configuration Center

[0040] Operations personnel configure basic activity attributes in the rule configuration center, such as activity name, target audience, insurance type, settlement method, settlement time, and activity validity period. They also configure activity-level push notifications (the relationship between activities and rules is 1:N, meaning one activity can have N rules; the activity level refers to the data shared by the N rules under it; push notifications at the activity level include activity start and end time push notifications, total premium push notifications, total performance push notifications, and activity registration notifications; push notification formats include SMS, in-app messages, and app push notifications; push notification time types include push notifications at activity start, push notifications at settlement, and scheduled push notifications). Then, they enter the rule configuration. Multiple rules can be configured under one activity, meaning rules can be horizontally expanded and independent of each other. One or more dimensions can be configured under a rule (a dimension is the source of the matching activity reward, such as individual...). The "First Purchase on Platform" dimension refers to the requirement that only policies that are the first purchase on the individual insurance platform will be eligible for activity rewards when receiving policy data from upstream. This means that multiple dimensions must be met simultaneously for a policy to be eligible for rewards. For example, Rule 1 might have both Dimension 1: Individual Insurance - First Purchase on Platform and Dimension 2: Individual Insurance - First Purchase on Product. When a user issues a policy, it will only be eligible for rewards if the policy is both the first purchase on the product (a product is a subcategory of insurance; for example, individual insurance, group insurance, and car insurance are broad categories, and each category has its own specific products, such as ZhongAn Zunxiang e-Sheng 2023 and JD Allianz Critical Illness Insurance) and the first purchase on the platform. Other attribute configurations beyond the rule include rule product list, rule reward list, rule settlement, rule push notifications, reward waiting period, and recipient information.

[0041] Wherein, Activity: Rule: Dimension = 1:N:N

[0042] That is, an activity has N rules, and a rule has N dimensions. The rules do not affect each other. All dimensions under a rule must be satisfied at the same time to be considered as satisfying the rule and to be included in the rule.

[0043] For example, to determine whether an insurance policy is included in the rules, there are three dimensions: Dimension 1: first policy on the platform, Dimension 2: first policy during the promotion, and Dimension 3: first policy upon joining the company. Only when the policy meets all three of these dimensions can it be included in the promotion.

[0044] The activity layer configuration sits above the rules layer. An activity layer configuration is shared by multiple subordinate rules, while the configurations of individual rules do not affect each other. After configuring the activity and its rules, the configuration is submitted to the DMC (Financial Audit System). Once the activity is configured, the activity data is submitted to the DMC system via an interface. The finance department reviews the data in this system (approving or disapproving) and sends feedback back to the activity system in real time. The operations team then decides whether to activate the activity or modify it and resubmit it for financial review. The audit system reviews the activity and sends back the results. Operations personnel modify or activate the activity configuration based on the results. Once activated, the activity enters the activation phase.

[0045] 2. Rule Matching Center:

[0046] The rule matching center connects to upstream systems or third-party interfaces and pushes messages (this system is an activity system, and its data sources are numerous, such as upstream systems like the company's individual insurance policy issuance system and group insurance policy issuance system, and third-party interfaces like external third-party policy issuance platforms, which interface with this system to transmit policy data to the activity system. Pushing messages is a different form from interface integration; it involves introducing a message middleware to listen for messages. Messages are sent from upstream systems or third parties to the message middleware, which then sends them to the activity system to achieve the purpose of participating in the activity). Product or technical personnel configure the system in a configuration table (the configuration table can...). This can be understood as a mapping table. For example, upstream systems or third-party interfaces might use various naming conventions for policy data, such as policy number as the key "policyNum" and premium as "policyPremium." However, this system standardizes the naming of various key policy attributes, such as policy number "policyNo," premium "premium," and performance "performance." In other words, through the mapping configuration table, policyNum is mapped to policyNo, and policyPremium to premium. Therefore, the mapping relationship in the mapping table unifies the upstream data cleaning cost system. The system uses standard format data, then creates standard policy records locally, and matches activities with activity rules. Key fields (such as premium, policy number, application date, underwriting date, payment date, insurance start date, insurance end date, expiry date, payment period, and whether it includes death benefits—fields relevant to activity rule matching are considered key fields; fields not used in some activities are considered non-key fields) are mapped between upstream data fields and the system's standard fields, then retrieves the values ​​and assigns them to the policy attributes generated by the system. The rule matching center has its own set of standard data formats. When the access data is converted to the standard format according to the configuration,... The matching process begins by matching the activity object (an activity object is a single activity; the system can run multiple independent activities simultaneously), activity time (insurance application time, policy issuance time), activity object, and rule product (plan ID, payment period, and coverage period) to determine whether to include it in the activity. For example, in an individual insurance activity, rule 1 is configured with A001 (one-year term), A002 (lump-sum payment), and A003 (30-year term). If the upstream policy is A001 but the payment period is 20 years, then that policy cannot be included in the activity. The same logic applies to other policies. Inclusion in the activity is a prerequisite for obtaining the expected activity rewards. Therefore, according to this rule, the rule matching center will concurrently match all activities with any upstream data throughout the entire activity period, ensuring real-time inclusion in all eligible activities.

[0047] In addition, the rule matching center also provides an API to match and calculate the expected activity rewards based on real-time upstream data, and provide this information to the activity front-end page so that users can receive the real-time expected activity rewards in a timely manner.

[0048] 3. Rules Settlement Center

[0049] When an activity is created, the rule configuration center configures the settlement method and time. Currently, it supports real-time settlement and scheduled settlement. Real-time settlement means that when upstream interface data is received in real time, it is converted into the system's standard format, and the activity reward data table is generated and rewards are distributed in real time. Scheduled settlement activities rely on scheduled tasks. When upstream data is received, the rule matching center records the activity when conditions are met. The rule settlement center automatically starts the settlement task at the specified time, performs settlement according to the rule settlement objects (registered users / specified customer groups, etc.) configured in the rule configuration center, generates rule reward details, and then aggregates multiple rules under this activity according to activityId (activityId is the ID of an activity, which is a unique identifier for each operational activity in this system) + the same user's accountId (AccountId is the user ID, which is the unique account of a user in this company's app). The aggregated settlement data will be automatically saved in the file system. At the same time, a link to the settlement Excel file will be sent to the reviewer's email address for review. The reviewer can choose to approve or disapprove the review in the email. After the activity receives the review results, if the review is approved, the activity reward details will automatically enter the activity reward distribution stage. Finally, the operations staff will decide on the distribution time, and the rewards will be distributed to the user's account by clicking the button. The activity will then end.

[0050] like Figure 1 The diagram illustrates a flowchart of a reward distribution method provided in an embodiment of this application. Please refer to [link / reference]. Figure 1 The reward distribution method includes the following steps:

[0051] Operational data enters from the matching center, which has a pre-processing data cleaning module.

[0052] The pre-processing data cleaning module configures relevant data mappings according to the data structure of the data access party. After the pre-processing module cleans the data into a standardized data structure, the data flows into the matching center to officially begin matching the ongoing activities.

[0053] The matching center will continue to send the matched data to the settlement center;

[0054] The settlement center handles real-time settlement activities, distributing activity rewards in real time when multiple dimensions are met. It also pre-settles the activity data and expected rewards for the user to whom the data belongs, providing an API to the front-end so users can view real-time cumulative premiums, cumulative performance, cumulative policies, the difference from the next nearest tier, cumulative number of invitations, number of customers, and expected rewards on the activity page UI. For scheduled settlement tasks, the system automatically starts settlement according to the configured settlement time. Settlement reward details and activity data, including policy details, are sent via email by operations and then flow into the finance auditor's inbox. The system automatically receives the audit results. Finally, operations decides when to distribute rewards, which are automatically credited to the user's account. Non-cash rewards, including coupons, are credited to the user's coupon account in real time. Cash rewards can be withdrawn after a waiting period, at which point the activity ends.

[0055] In this embodiment, each time a new operational activity is launched, the operations team only needs to configure the relevant rules as needed, submit them for financial review with one click, modify or start the activity based on the review results, and the system automatically accesses upstream data, matches the rules in real time, calculates the expected user rewards in real time, provides a user page display interface, and automatically settles the activity according to the configured settlement time. After settlement, the operations team can submit the reward content to the finance department via email for review with one click, and once approved, the rewards can be distributed to user accounts with one click. This approach achieves operational goals simply, efficiently, and quickly, promotes efficient operations, facilitates business line development, and improves company efficiency.

[0056] like Figure 2 As shown, a reward distribution device provided in an embodiment of this application is schematically illustrated, comprising:

[0057] Rule Configuration Center: A factory for basic and rule configuration

[0058] Basic configuration includes the activity name, activity mode (regular APP sales | individual insurance new customer referral | group insurance new customer referral | product presentation | channel | renewal | renewal, etc.), target participants, insurance type (individual insurance, group insurance, auto insurance, channel), push notification configuration (such as registration push notification, target achievement push notification, incentive push notification), settlement method (real-time | timed | recurring), activity time, and other configuration items.

[0059] Rule Configuration: Dimension configuration is the core of rule configuration and the matching source for the subsystem's rule matching center. This system provides a pre-provided dimension configuration pool, which integrates dimensions used and planned for potential use by various business lines. It also reserves expansion entry points for iterative support of evolving business needs and changing operational requirements. Existing dimension types include: Platform First Order (divided into individual, group, and auto insurance, with premiums, performance, etc., greater than or equal to or less than the operational setting value; the same applies to subsequent first orders), Product First Order, First Order during an Activity Period, and First Order after Joining (the first policy issued after joining Baotong. Here, "joining" refers to the company's customized onboarding process, i.e., joining Baotong Insurance Agency and becoming an agent with a CBIRC-certified agent license number. Of course, there is also "leaving," meaning no longer belonging to this Baotong Insurance Agency and can join another agency. When distributing agent activity rewards, some... The camp establishes rules that currently employed agents can receive activity rewards, including: premium tiers (based on accumulated premiums, excluding the right side, e.g., 1000-10000 premiums reward 100, 10000-20000 premiums reward 200, 20000-30000 premiums reward 500, 30000 and above premiums reward 1000), performance tiers (based on accumulated performance), policy number tiers (for each policy issued, the cumulative number of policies increases by 1, with rewards matched to each tier), per policy (each policy is a single dimension, e.g., a coupon is given per policy, or a cash reward can be configured), registration time period (registration time refers to the registration time on the Yunbao app, and time range refers to a time range configured for this dimension), onboarding time range, registration channel, number of invitations, first invitation, invited registration tiers, invited onboarding tiers, etc.

[0060] In addition to dimensions, the rule configuration also includes a list of rule products (restrictions on products issued), reward recipients, reward waiting period, and reward content (currently supporting coupons, cash, vouchers, physical goods, and benefits). When configuring cash rewards, the waiting period is mandatory. The purpose of the waiting period is to prevent cash rewards from being withdrawn immediately after being sent to the user's account; withdrawal is only possible after the waiting period has passed. The waiting period is designed to avoid operational scenarios such as cancellations during the cooling-off period where cash rewards can be deducted.

[0061] Hierarchical relationship: Activity: Rule: Dimension = 1:N:N, meaning that an activity can be configured with N rules, and the rules are independent of each other and do not affect each other. A rule can be configured with N dimensions, and multiple dimensions under a rule must be satisfied simultaneously to receive a reward.

[0062] Rule Matching Center: The Judge of Whether Operational Data (such as Insurance Policies) Should Be Included in the Activity

[0063] Pre-processing data cleaning and mapping module: This system has established a complete standard data structure. All upstream operational data entering this system must pass through the pre-processing data cleaning module. Upstream data includes internal business line data and external third-party data (data that this system directly interfaces with insurance companies, i.e., data that does not originate from this system's policy issuance system. For example, policy issuance data directly interfaced with a department of ZhongAn Insurance for the purpose of conducting a certain operational activity). The data can take various forms, such as proactive requests from this system, sending data through third-party interfaces, and MQ messages from internal business systems. The system must define the corresponding structural relationships between required fields and upstream data. Before the initial integration, the development or requirements personnel must configure the corresponding mapping relationships. When the system receives incoming data, it can automatically clean it, generating standard data that the system can recognize, and then begin matching activities and rules.

[0064] After the standard data is cleaned by the pre-processing system, it first enters the activity layer for configuration data matching. This is based on whether the policy's application and underwriting times match within the activity's valid timeframe, whether the policyholder is a designated participant, and whether the insurance type matches. If successful, it then uses multi-threading to simultaneously and in parallel enter each rule layer for matching. For example, if a "first order" dimension is configured, it matches whether the policy meets the specified rule. If so, it continues to match whether it is the platform's first order. If so, it creates a "first order" record associated with the activity ID (a unique identifier for the activity's database record created by the system) and the rule ID (a unique identifier for rules under the activity; one activity ID can be associated with multiple rule IDs, and the IDs between rules are unique). This process iterates through multiple dimensions for matching. If a cumulative tier dimension exists, it creates a cumulative tier and cumulative details, calculating in real-time the current user's cumulative premium, cumulative performance, and cumulative number of policies under that rule.

[0065] Rules Settlement Center: The Engine for Settlement of Operational Activity Data

[0066] Settlement is divided into two parts: real-time settlement and timed settlement (including cyclical settlement).

[0067] Real-time settlement means that after the activity data matching is completed, settlement is carried out within a single rule for activities configured for real-time settlement in the configuration center. For example, if rule 1 is configured with two dimensions, namely Dimension 1 first order of the activity and Dimension 2 first order after joining the company, then according to the definition of the first order in operations, it is checked whether the first order of the activity and the first order after joining the company are met. Only when both dimensions are met will the reward content be generated according to the reward information configured in the rule configuration center and distributed to the user account in real time. Non-cash rewards such as coupons take effect in real time, while cash rewards can be withdrawn after the waiting period.

[0068] The rules for scheduled settlement and real-time settlement are the same. The difference is that the scheduled system automatically starts the scheduled task at the settlement time set by the operation, and settles all the rules of the entire activity at the same time. Each rule is settled independently and does not affect each other. Scheduled settlement is usually for operation activities with user tier accumulation dimensions, such as premium tier dimensions. The operation can set N tiers under a tier dimension, and each tier can be set with corresponding rewards. During settlement, the system automatically records a corresponding reward for the user based on the configured tier and which tier the user has currently met. Tiers can be configured to overlap, depending on the needs of the operation, and can be configured as needed.

[0069] For example:

[0070] The non-intersecting steps are as follows:

[0071] Using accumulated premiums as tiers (including the left but excluding the right), for example...

[0072] Tier 1: 1000-10000 premium bonus of 100

[0073] Tier 2: 200 bonus for premiums between 10,000 and 20,000

[0074] Tier 3: 500 bonus for premiums between 20,000 and 30,000

[0075] Tier 4: 1000 bonus for premiums of 30,000 and above

[0076] Intersection means,

[0077] There are intersections between the steps; for example, steps 1 and 2.

[0078] Tier 1: 1000-10000 premium bonus of 100

[0079] Tier 2: 2000-20000 premium bonus of 200

[0080] When a user's cumulative premium reaches 3000, they simultaneously meet both tier 1 and 2 requirements. In this case, the user's expected reward would be 100 + 200 = 300. The periodic settlement generates a reward record for each user who meets the reward criteria for each rule. Multiple rules are then combined into a total reward for the activity. After the reward is generated, the operations team sends the reward details and activity data details (such as policy details: policy number, application time, underwriting time, issuer, policyholder, premium, performance, waiting time, receipt, follow-up, quality inspection status, etc.) to the finance department's review email address. Once the finance department approves the reward, the operations team activates the distribution button, and the reward is sent to the user's account. The user can then withdraw the reward to their personal bank card after the waiting period.

[0081] The rule configuration center, rule matching center, and rule settlement center use the SpringCloud microservice architecture and integrate Feign dependency for mutual calls. The database uses the mainstream MySQL, and activity data is cached using Redis. Upstream access data uses RabbitMQ message middleware or Nginx as a proxy server to access third-party activity data. The file system uses Aliyun OSS to provide file upload and download.

[0082] like Figure 3 As shown, this application embodiment also provides an electronic device 700, including a processor 701 and a memory 702. The memory 702 stores a program or instructions that can run on the processor 701. When the program or instructions are executed by the processor 701, they implement the various steps of the above-described reward distribution method embodiment and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0083] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0084] The illustration schematically shows a reward distribution device 600 provided in an embodiment of this application, comprising:

[0085] The reward disbursement device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television set (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the device.

[0086] The reward distribution device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.

[0087] The reward distribution device provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.

[0088] Optionally, Figure 4 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.

[0089] The electronic device 100 includes, but is not limited to, components such as: radio frequency unit 101, network module 102, audio output unit 103, input unit 104, sensor 105, display unit 106, user input unit 107, interface unit 108, memory 109, and processor 110.

[0090] Those skilled in the art will understand that the electronic device 100 may also include a power supply (such as a battery) for powering various components. The power supply can be logically connected to the processor 110 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The electronic device structure shown in the figure does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.

[0091] It should be understood that, in this embodiment, the input unit 104 may include a graphics processing unit (GPU) 1041 and a microphone 1042. The GPU 1041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 106 may include a display panel 1061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 107 includes at least one of a touch panel 1071 and other input devices 1072. The touch panel 1071 is also called a touch screen. The touch panel 1071 may include a touch detection device and a touch controller. Other input devices 1072 may include, but are not limited to, a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), a trackball, a mouse, and a joystick, which will not be described in detail here.

[0092] The memory 109 can be used to store software programs and various data. The memory 109 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 109 may include volatile memory or non-volatile memory, or it may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 109 in the embodiments of this application includes, but is not limited to, these and any other suitable types of memory.

[0093] Processor 110 may include one or more processing units; optionally, processor 110 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 110.

[0094] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described reward distribution method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0095] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0096] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described image segmentation method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0097] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0098] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the image segmentation method embodiments described above, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0099] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0100] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0101] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A reward settlement method, characterized in that, The method includes: Operational data enters from the matching center, which has a pre-processing data cleaning module. The pre-processing data cleaning module configures relevant data mappings according to the data structure of the data access party. After the pre-processing module cleans the data into a standardized data structure, the data flows into the matching center to officially begin matching the ongoing activities. The matching center will continue to send the matched data to the settlement center; The settlement center handles real-time settlement activities, distributing activity rewards in real time when multiple dimensions are met. It also pre-settles the activity data and expected rewards for the user to whom the data belongs, providing an API to the front-end so users can view real-time cumulative premiums, cumulative performance, cumulative policies, the difference from the next nearest tier, cumulative number of invitations, number of customers, and expected rewards on the activity page UI. For scheduled settlement tasks, the system automatically starts settlement according to the configured settlement time. Settlement reward details and activity data, including policy details, are sent via email by operations and then flow into the finance auditor's inbox. The system automatically receives the audit results. Finally, operations decides when to distribute rewards, which are automatically credited to the user's account. Non-cash rewards, including coupons, are credited to the user's coupon account in real time. Cash rewards can be withdrawn after a waiting period, at which point the activity ends.

2. A reward settlement device for implementing the reward settlement method as described in claim 1, characterized in that, The device includes: The rule configuration center is used to configure the basic attributes and rules of an activity. After the configuration is completed, it is submitted to the DMC financial audit system for review. After the review is completed, the review results are returned. Based on the review results, the activity configuration is modified or the activity configuration is enabled. Once enabled, the activity enters the activation phase. The rule matching center is used to convert access data into a standard format according to the configuration, and to match the activity object, activity time, and rule product to determine whether to include it in the activity. The rules settlement center is used for real-time and timed settlement of rewards.

3. The apparatus according to claim 2, characterized in that, The rules center includes: The basic configuration module is used to configure the activity name, activity mode, target participants, insurance type, push notification settings, settlement method, and activity time. Rule configuration module: This module provides a pre-configured pool of dimensions and reserves an extension entry point to iteratively support the evolving operational needs of the business.

4. The apparatus according to claim 3, characterized in that, The rules center also includes: The module includes a rules-based product list configuration module, a reward recipient configuration module, a reward waiting period configuration module, and a reward content configuration module.

5. The apparatus according to claim 3, characterized in that, The rules center also includes: The hierarchical relationship configuration module allows you to configure multiple rules under an activity, and multiple dimensions under a rule.

6. The apparatus according to claim 2, characterized in that, The rules center includes: The pre-processing data cleaning and mapping module is used to automatically clean the received data when upstream operational data is accessed, generate standard data, and match it with rules.

7. The apparatus according to claim 6, characterized in that, The rules center also includes: The configuration matching module is used to simultaneously and in parallel enter each rule layer for matching after the standard data has been cleaned by the pre-processing system, as well as to traverse and match multiple dimensions.

8. The apparatus according to claim 2, characterized in that, The rules settlement center includes: The real-time settlement module is used to settle the activities that are configured for real-time settlement in the configuration center after the activity data matching is completed, and to generate reward content according to the reward information configured in the rule configuration center and distribute it to the user account in real time. The scheduled settlement module is used to start scheduled tasks at the settlement time set by the operations team, simultaneously settle all rules of the entire activity, generate a reward record for each user who meets the reward for each rule, merge multiple rules into the total reward within the activity, and send the reward details and activity data details to the finance review email. After receiving the message that the finance team has approved the reward and in response to the triggering of the operation distribution button, the reward is distributed to the user's account.

9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing programs or instructions that can run on the processor, the programs or instructions being executed by the processor to implement the steps of the method as described in claim 1.

10. A readable storage medium, characterized in that, A program or instructions are stored on the readable storage medium, which, when executed by a processor, implement the steps of the method as described in claim 1.

Images