Activity customer group judgment method and device, equipment and storage medium

Abstract

The invention provides an active customer group judgment method and device, equipment and a storage medium, and can be applied to the technical field of big data technology and financial science and technology. The method comprises the following steps: in response to the obtained information of a to-be-judged customer, extracting a judgment rule of a candidate customer group category from a preset active customer group rule table; forming a customer group rule chain according to the priority of each judgment condition in the judgment rules of the same candidate customer group category; utilizing rule processors corresponding to the judgment conditions in the customer group rule chain to sequentially judge whether the customer information meets the judgment conditions or not according to a customer group rule chain sequence; and determining a target customer group category of the customer according to a result whether the judgment condition is met or not output by the rule processor.

Description

Technical Field

[0001] This application relates to the fields of big data technology and fintech, and in particular to a method, apparatus, equipment, medium, and program product for determining active customer groups. Background Technology

[0002] Existing achievement-oriented activities often involve multiple customer groups, each with its own participation restrictions and reward designs. Therefore, a flexible customer group determination mechanism is crucial. While the importance of customer group diversity is recognized in existing achievement-oriented activities, traditional customer group determination mechanisms often suffer from problems such as coupled rule logic, ambiguous execution order, and insufficient scalability. A common practice is to hard-code the processing logic for different conditions together. When a condition needs to be adjusted, the entire determination logic must be reconstructed, resulting in extremely high costs for adapting to business changes. More importantly, the lack of structured management of the rule execution order often leads to the continuation of subsequent determinations even when a condition is not met, wasting system resources and reducing determination efficiency in high-concurrency scenarios. Summary of the Invention

[0003] In view of the above problems, this application provides a flexible method, apparatus, equipment, medium and program product for determining active customer groups.

[0004] According to a first aspect of this application, a method for determining an active customer group is provided, comprising: in response to obtaining information about a customer to be determined, extracting a determination rule for a candidate customer group category from a preset active customer group rule table; forming a customer group rule chain according to the priority of each determination condition in the determination rule for the same candidate customer group category; using a rule processor corresponding to each determination condition in the customer group rule chain, sequentially determining whether the customer information meets each determination condition according to the order of the customer group rule chain, wherein the rule processor is used to receive the information about the customer to be determined and the parameters corresponding to the determination conditions, perform a determination operation through preset logic, and output the result of whether the customer information meets the determination conditions; and determining the target customer group category of the customer based on the result of whether the determination conditions are met output by the rule processor.

[0005] According to an embodiment of this application, the determination rule for extracting a candidate customer group from a preset activity customer group rule table includes: determining the selection order of each candidate customer group based on the time evolution relationship of each candidate customer group in the preset activity customer group rule table, wherein the time evolution relationship indicates the evolution pattern of each candidate customer group over time in the customer life cycle; and selecting a candidate customer group from the candidate customer group that has an earlier evolution stage and has not yet been determined according to the selection order.

[0006] According to an embodiment of this application, a customer group rule chain is formed based on the priority of each judgment condition in the judgment rules of the same candidate customer group, including: marking each judgment condition as at least one of the following label types: static condition, dynamic condition, or high-frequency failure judgment condition, based on at least one of the data dependency, logical independence, and failure frequency of each judgment condition, wherein static conditions are independent of each other and can be executed in parallel, dynamic conditions are executed serially with the static conditions they depend on, and high-frequency failure judgment conditions have the highest priority among the parallel execution conditions; and determining the priority of each judgment condition based on the label type of each judgment condition.

[0007] According to an embodiment of this application, the method further includes: in response to obtaining information about a customer's participation in an activity; obtaining static data of the customer from a local cache, wherein the static data includes basic card status and fixed date information held by the customer; obtaining dynamic data of the customer from a distributed cache other than the local cache, wherein the dynamic data includes the customer's transaction behavior and business interaction information; and forming information about the customer to be determined based on the static data and the dynamic data.

[0008] According to an embodiment of this application, the method further includes: obtaining semi-static data of a customer from a local cache, wherein the semi-static data is constructed and stored in the local cache based on dynamic data according to a preset frequency; and combining static data, semi-static data and dynamic data to form information of the customer to be determined.

[0009] According to an embodiment of this application, the method further includes: classifying static data and / or semi-static data according to the data corresponding to each judgment condition in the judgment rules of the same candidate customer group; and packaging the classified static data and / or semi-static data and storing them in the local cache of the corresponding rule processor.

[0010] According to an embodiment of this application, the method further includes: obtaining the execution frequency of each customer group rule chain in the same time period; multiplying the execution frequency of the customer group rule chain by the corresponding preset single cost coefficient to obtain the resource demand value, wherein the single cost coefficient is set based on the rule chain length and reflects the resource consumption of a single execution; and allocating thread resources to the rule processor of the candidate customer group according to the proportion of the resource demand value of the candidate customer group to the overall resource demand value.

[0011] A second aspect of this application provides an active customer group determination device, comprising: a rule extraction module, configured to extract a determination rule for a candidate customer group category from a preset active customer group rule table in response to obtaining information about a customer to be determined; a customer group rule chain module, configured to form a customer group rule chain according to the priority of each determination condition in the determination rule of the same candidate customer group category; a rule processor module, configured to use the rule processors corresponding to each determination condition in the customer group rule chain to sequentially determine whether the customer information meets each determination condition according to the order of the customer group rule chain, wherein the rule processor is configured to receive the information of the customer to be determined and the parameters corresponding to the determination conditions, perform a determination operation through preset logic, and output the result of whether the customer information meets the determination conditions; and a customer group determination module, configured to determine the target customer group category of the customer based on the result of whether the determination conditions are met output by the rule processor.

[0012] A third aspect of this application provides an electronic device, comprising: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0013] A fourth aspect of this application also provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the methods described above.

[0014] The fifth aspect of this application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0015] According to the activity customer group determination method, device, equipment, medium and program products provided in this application, by forming a customer group rule chain according to priority and executing it sequentially, rule segmentation and sequential judgment execution are realized; since each judgment condition corresponds to a dedicated rule processor, the rule processor only needs to receive customer information and condition parameters to execute the preset logic. Therefore, at least partially, the decoupling of the judgment logic is solved, and the technical effect of making it easy to modify a certain rule or add a new rule without changing the overall process is achieved, which enhances the flexibility of the judgment process. Attached Figure Description

[0016] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0017] Figure 1 The illustration shows an application scenario diagram of the active customer group determination method, apparatus, device, medium, and program product according to embodiments of this application;

[0018] Figure 2A flowchart illustrating a method for determining an active customer group according to an embodiment of this application is shown schematically.

[0019] Figure 3 A flowchart illustrating a second method for determining active customer groups according to an embodiment of this application is shown schematically.

[0020] Figure 4 A flowchart illustrating a third method for determining active customer groups according to an embodiment of this application is shown schematically.

[0021] Figure 5 The schematic diagram illustrates a method for determining active customer groups according to an embodiment of this application;

[0022] Figure 6 The schematic diagram illustrates the principle of a second method for determining active customer groups according to an embodiment of this application;

[0023] Figure 7 This schematically illustrates a structural block diagram of an active customer group determination device according to an embodiment of this application; and

[0024] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing an active customer group determination method according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0027] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0028] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0029] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0030] In the technical solution of this application, the collection, storage, use, processing, transmission, provision, application and application of user personal information all comply with the provisions of relevant laws and regulations, take necessary security measures, and do not violate public order and good morals.

[0031] In the technical solution of this application, the acquisition, collection, storage, use, processing, transmission, provision, application and application of data all comply with the provisions of relevant laws and regulations, take necessary security measures, and do not violate public order and good morals.

[0032] This application provides an embodiment of a method for determining an active customer group, comprising: in response to obtaining information about a customer to be determined, extracting a determination rule for a candidate customer group category from a preset active customer group rule table; forming a customer group rule chain according to the priority of each determination condition in the determination rule for the same candidate customer group category; using rule processors corresponding to each determination condition in the customer group rule chain, sequentially determining whether the customer information meets each determination condition according to the order of the customer group rule chain, wherein the rule processor is used to receive the information about the customer to be determined and the parameters corresponding to the determination conditions, perform a determination operation through preset logic, and output the result of whether the customer information meets the determination conditions; and determining the target customer group category of the customer based on the result of whether the determination conditions are met output by the rule processor.

[0033] Figure 1 The illustration shows an application scenario diagram of the active customer group determination method, apparatus, device, medium, and program product according to embodiments of this application.

[0034] like Figure 1As shown, application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the terminal devices 101, 102, 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0035] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0036] Terminal devices 101, 102, and 103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0037] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using terminal devices 101, 102, and 103 (for example only). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0038] It should be noted that the active customer group determination method provided in this application embodiment can generally be executed by server 105. Correspondingly, the active customer group determination device provided in this application embodiment can generally be located in server 105. The active customer group determination method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105. Correspondingly, the active customer group determination device provided in this application embodiment can also be located in a server or server cluster that is different from server 105 and capable of communicating with terminal devices 101, 102, 103 and / or server 105.

[0039] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0040] The following will be based on Figure 1 The described scene, through Figures 2-6 The method for determining the active customer group in the embodiments of the application will be described in detail.

[0041] Figure 2 A flowchart illustrating a method for determining an active customer group according to an embodiment of this application is shown schematically.

[0042] like Figure 2 As shown, the active customer group determination in this embodiment includes operations S210 to S240.

[0043] In operation S210, in response to obtaining the information of the customer to be judged, a judgment rule for a candidate customer group category is extracted from the preset active customer group rule table.

[0044] Some embodiments of this application take the "One Yuan Purchase" activity (hereinafter referred to as "the Activity") of the credit card center as an example to illustrate how to differentiate the participation rules and forms of the Activity according to different customer situations, and ultimately realize different One Yuan Purchase Activity participation processes for four different categories of customers: new customers, newly applied customers, inactive customers with existing cards, and active customers with existing cards. Moreover, customers can only participate in one of them and cannot participate in both at the same time.

[0045] The campaign supports four customer segment configurations: new customers, existing inactive customers, existing active customers, and new applicants. Each segment has its own base customer rules, and additional processing rules can be added on top of these, such as access whitelist restrictions, credit card number matching rules, and credit card transaction limit rules. Branches can configure these rules as needed to conduct diverse credit card customer segment campaigns. For example, the base customer rules for new customers include a credit card activation date >= ${yyyyMMdd}, and credit card number restrictions can be added on top of this to create requirements for new customers holding xx credit card number.

[0046] For example, users A and B wish to participate in an activity and submit their participation applications through the application. The information about users A and B below is fictitious and used to illustrate the solution in this embodiment; they do not actually exist.

[0047] When operating S210, in response to user A submitting an activity application, the system first obtains the information of user A to be judged, such as: valid card status "normal", valid card creation date "2024-06-10", invalid card cancellation record "none in the last 180 days", number of transactions in the last 3 months "0", and application record "submitted credit card application on June 5, 2024, activated on June 10", etc. Then, from the preset activity customer group rule table, the system extracts the judgment rules for the first candidate customer group "new customer" from the categories of new customer, new application customer, existing card inactive customer, and existing card active customer. The specific rules are recorded as follows.

[0048] Rule 1: The valid card status is "normal", corresponding to rule processor 1, and the condition parameter is "normal".

[0049] Rule 2: The valid card creation date is greater than or equal to the activity submission start date "2024-06-01", corresponding to rule processor 2, with the condition parameter "2024-06-01".

[0050] Rule 3: No invalid card cancellation records in the past 180 days, corresponding to rule processor 3, with condition parameter "180".

[0051] In operation S220, a customer group rule chain is formed based on the priority of each judgment condition in the judgment rule of the same candidate customer group category.

[0052] In the example above, a customer group rule chain can be formed based on the priority of the rules for the candidate customer group category "new customer". Rule priorities can be preset, such as based on pre-marked priority tags, or determined according to the relationships between rules. In this example, the priority is based on performing basic qualification verification first, then time condition verification, and finally exclusion condition verification. The three extracted rules are arranged into a customer group rule chain from highest to lowest priority, with the final order being: Rule 1 – Rule 2 – Rule 3.

[0053] In operation S230, the rule processors corresponding to each judgment condition in the customer group rule chain are used to judge whether the customer information meets each judgment condition in the order of the customer group rule chain. The rule processor is used to receive the customer information to be judged and the parameters corresponding to the judgment conditions, execute the judgment operation through preset logic, and output the result of whether the customer information meets the judgment conditions.

[0054] In the embodiments of this application, the rule processor is a program unit that encapsulates specific judgment logic, specifically designed to execute conditional judgments for a single rule. By transforming the judgment logic of business rules into executable code logic, the automated and standardized judgment of rules is ensured. The rule processor can receive two types of input, including: customer information to be judged (such as valid card status, number of transactions, filing date, etc.) and rule conditional parameters (such as "March", "1 transaction"). The output result can be a Boolean value or similar identifier of "compliant with the rule" or "non-compliant with the rule", for the upper layer to determine whether to continue execution. The logic of the rule processor is independent of other rules; modifying a rule processor will not affect the execution of other rules. When a new rule is added, only the corresponding processor needs to be added; there is no need to reconstruct the overall judgment framework, allowing for flexible adjustments to business rules.

[0055] Each customer group holds a one-to-many record of customer group rules, as shown in Table 1. Each customer group rule record contains the class of the corresponding rule processor and the condition requirements of the corresponding rule. Rule records of the same customer group are grouped into a customer group rule chain according to priority. After a customer enters the activity, the customer group rule chain will be used to determine whether the customer matches the criteria for a new customer, a new application, an inactive existing customer, or an active existing customer. If any rule in the current customer group rule chain is not met, the current customer group will be excluded from the evaluation, and the process will proceed to the next customer group rule chain until all rules in the customer group rule chain meet the requirements. If the requirements are met, the customer will be tagged with the corresponding customer group and will be eligible to receive the corresponding customer group's rewards; otherwise, they will not be eligible to participate in the activity.

[0056] Table 1. Customer Group Rule Recording Diagram

[0057]

[0058] In the example above, for user A who wants to participate in the activity, the decision process is executed according to the order of rule 1 - rule 2 - rule 3.

[0059] Rule 1 determination: Call rule processor 1, which receives user A's "valid card status = normal" and condition parameter "normal", performs the determination through preset logic (comparing whether the customer's valid card status is consistent with the allowed status), and outputs the result "compliant with rule 1".

[0060] Rule 2 determination: Since Rule 1 was passed, Rule Processor 2 is called to receive User A's "Valid Card Filing Date = 2024-06-10" and condition parameter "2024-06-01". The judgment is performed through preset logic (calculating whether the filing date is later than or equal to the start date) and the result "Complies with Rule 2" is output.

[0061] Rule 3 determination: Since Rule 2 has passed the determination, Rule Processor 3 is called to receive User A's "no invalid card cancellation records in the past 180 days" and the condition parameter "180". The judgment is performed through the preset logic (checking whether the cancellation records in the past 180 days are empty) and the result "compliant with Rule 3" is output.

[0062] At this point, User A has passed all the criteria for the "new customer" customer group rule chain and will directly enter the new customer exclusive activity participation process, and will no longer enter the judgment process of other customer groups.

[0063] Suppose user B performs the same decision-making process as described above in operation S230, but when making the decision on rule 2, rule processor 2 outputs "Does not comply with rule 2". Thus, user B has failed all the decision-making conditions of the "new customer" group rule chain.

[0064] In operation S240, the target customer group category of the customer is determined based on the result of whether the judgment conditions are met, as output by the rule processor. Specifically, in response to the customer's information not meeting one of the judgment conditions, the judgment of the current candidate customer group is terminated, and the judgment rule for the next candidate customer group is extracted from the preset active customer group rule table for judgment, until all candidate customer group rule judgments are completed or the target customer group that the customer meets is determined.

[0065] In the example above, in response to the fact that Customer B does not meet the rule 2 in the new customer rule chain, the subsequent determination of the "new customer" group is immediately terminated. The determination rule for the next candidate customer group, "new applicants," is extracted from the activity customer group rule table. Subsequently, the operation process S220 and S230 for the "new applicants" customer group will be entered. If Customer B still does not meet the rules for this customer group, the rules for "existing card inactive customers" and "existing card active customers" will continue to be extracted and determined until a matching target customer group is found or all customer group determinations are completed. If none of them meet the requirements, Customer B will be notified that they are not eligible to participate in the activity.

[0066] This embodiment achieves rule segmentation and sequential judgment execution by forming customer group rule chains according to priority and executing them sequentially. Each judgment condition corresponds to a dedicated rule processor. The rule processor only needs to receive customer information and condition parameters to execute the preset logic. Therefore, it at least partially solves the decoupling of judgment logic, and realizes the technical effect of making it easy to modify a certain rule or add a new rule without changing the overall process, thus enhancing the flexibility of judgment.

[0067] In some embodiments of this application, the determination rule for extracting a candidate customer group from a preset activity customer group rule table includes: determining the selection order of each candidate customer group according to the time evolution relationship of each candidate customer group in the preset activity customer group rule table, wherein the time evolution relationship indicates the evolution pattern of each candidate customer group over time in the customer life cycle; and selecting a candidate customer group from the candidate customer group that has an earlier evolution stage and has not yet been determined according to the selection order.

[0068] Figure 3 A flowchart illustrating a second method for determining active customer groups according to an embodiment of this application is shown.

[0069] The evolution of customer groups over the customer lifecycle follows a pattern: new customers who continue to generate transactions become active customers of existing cards, while those whose transaction frequency decreases become inactive customers. Inactive customers can become active customers of existing cards if they resume transactions, but they will not revert back to being new customers or newly applied customers. This evolution of candidate customer groups over the customer lifecycle can also serve as a reference order, upon which adjustments can be made. Figure 3As shown, this embodiment determines the selection order of "new customers - new applications - inactive existing customers - active existing customers" based on the time evolution relationship of each candidate customer group in the preset active customer group rule table. The "new customers" customer group corresponds to a new customer rule link, the "new applications" customer group corresponds to a new application rule link, the "inactive existing customers" customer group corresponds to an inactive existing customer rule link, and the "active existing customers" customer group corresponds to an active existing customer rule link. Each rule link includes rule processor 1, rule processor 2, ..., rule processor n.

[0070] When determining customer groups, if a customer B does not meet the criteria for the "new customer" group, the criteria for the "new customer" group with the most advanced evolution stage will be selected from the new applications that have never been judged, the existing inactive customers, and the existing active customers. This process will continue until all customer groups have been judged, at which point the judgment process will end.

[0071] This embodiment determines the selection order based on the evolution of candidate customer groups over time, ensuring that customer groups at earlier stages of evolution are judged first. This simplifies the judgment logic, reduces cross-judgment errors, and improves the accuracy of the results. Secondly, selecting customer groups according to the evolutionary pattern over time conforms to the natural development logic of the customer lifecycle, making the judgment process consistent with the customer growth path in actual business, easier for business personnel to understand and maintain, and enhancing business adaptability. It avoids the disorder of customer group judgment, reduces the waste of resources caused by repeated judgments or disordered order, and ensures that the judgment of each customer group is based on clear preconditions, thereby improving the overall judgment efficiency.

[0072] In some embodiments of this application, a customer group rule chain is formed according to the priority of each judgment condition in the judgment rules of the same candidate customer group, including: marking each judgment condition as at least one of the following label types: static condition, dynamic condition, or high-frequency failure judgment condition, based on at least one of the data dependency, logical independence, and failure frequency of each judgment condition. Static conditions are independent of each other and can be executed in parallel, dynamic conditions are executed serially with the static conditions they depend on, and high-frequency failure judgment conditions have the highest priority among the parallel execution conditions; and the priority of the judgment condition is determined according to the label type of each judgment condition.

[0073] Figure 4 A flowchart illustrating a third method for determining active customer groups according to an embodiment of this application is shown.

[0074] like Figure 4 As shown, the rule chain for determining existing inactive customers includes four criteria. For example, criterion 1: The valid card status is "normal"; criterion 2: There are no invalid card cancellation records in the past 180 days; criterion 3: The number of transactions in the past 3 months is less than 3; criterion 4: There has been no participation in similar activities in the past 30 days.

[0075] Based on data dependency, logical independence, and failure frequency analysis, Condition 1 has no data dependency, its data is static, and its failure frequency is low, making it a static condition. Condition 2 has no data dependency, its data is static, and its failure frequency is low, making it a static condition. Condition 3 depends on "valid card status is normal," its data is dynamic, changing in real time with customer consumption, and its failure frequency is moderate, making it a dynamic condition. Condition 4 has no data dependency, its data is static, but because the customer has already participated in the activity, its failure frequency is high, making it a high-frequency failure condition. Since Conditions 1, 2, and 4 have no data dependency and are static conditions, they can be executed in parallel. Because Condition 4 is a high-frequency failure condition, it is set as the highest priority among these parallel execution conditions.

[0076] Based on the above analysis, a rule chain execution process for existing inactive customers is formed (e.g., Figure 4 (As shown). After condition 4 is passed, conditions 1 and 2 are executed in parallel. After condition 1 is passed, condition 3 is executed. The process ends when all conditions are passed. If any condition fails, the existing active customer rule chain execution process begins.

[0077] pass Figure 4 The priority design allows us to use condition 4 to directly exclude most customers who have participated in the activity, and improve the overall decision efficiency by executing static conditions in parallel.

[0078] This embodiment marks independent static conditions as parallelizable, fully utilizing computing resources to process multiple independent conditions simultaneously, reducing overall decision-making time. Dynamic conditions and dependent static conditions are executed sequentially, avoiding logical errors caused by disordered order and ensuring decision accuracy. High-frequency failure conditions have the highest priority in parallel processing; due to their high failure probability, prioritizing their execution can terminate the current customer group's decision-making early, reducing invalid calculations for subsequent conditions. This embodiment determines priorities by label type, leveraging parallelism to improve efficiency, ensuring logical correctness through serial processing, and minimizing resource waste by prioritizing high-frequency failure conditions, thus comprehensively optimizing the decision-making process.

[0079] In some embodiments of this application, the method for determining the active customer group further includes: in response to obtaining information about a customer's participation in an activity; obtaining static data of the customer from a local cache, wherein the static data includes the basic status of the card held by the customer and fixed date information; obtaining dynamic data of the customer from a distributed cache other than the local cache, wherein the dynamic data includes the customer's transaction behavior and business interaction information; and forming information about the customer to be determined based on the static data and the dynamic data.

[0080] Figure 5 The schematic diagram illustrates a method for determining active customer groups according to an embodiment of this application.

[0081] like Figure 5 As shown, when a customer submits an application to participate in an activity, the system receives the request and triggers a customer segmentation process. At this point, it is necessary to collect complete information about the customer, such as card status and transaction records, as the basis for rule determination.

[0082] The data acquisition process retrieves customer static data from the local cache, forming static data fragments. Static data refers to long-term, stable, and infrequently changing basic customer information, such as basic customer card status and fixed dates. This data forms the basis for customer segmentation. Because this data changes infrequently, it can be preferentially stored in the application process's local cache.

[0083] The data acquisition process retrieves dynamic customer data from a distributed cache, forming static data fragments. Dynamic data refers to information that changes in real-time or frequently with customer behavior, including transaction behavior and business interaction records. Transaction behavior records may include, for example, the number of transactions in the past 3 months, the transaction amount in the past 12 months, and the date of the last purchase; business interaction records may include the date of the most recent application and whether the customer has participated in similar activities in the past 30 days. Due to the high real-time requirements of dynamic data, such as the need to update the number of transactions after each purchase, dynamic data is stored in a distributed cache. The distributed cache can share data across nodes, ensuring that different servers can obtain the latest dynamic data, and supports high-concurrency access through cluster expansion.

[0084] Through data integration, static data retrieved from the local cache is combined with dynamic data retrieved from the distributed cache to form complete information about the customer to be assessed. For example, the integrated information for user A includes valid card status, registration date, number of transactions in the past 3 months, and activity participation records in the past 30 days.

[0085] This embodiment constructs a two-tier architecture of "local cache + distributed cache" for core static data that customer group rules in the file frequently rely on. Static data is stored in the local cache; local memory-level access significantly reduces read latency and eliminates the need for repeated access to the underlying database, reducing database load. Secondly, dynamic data is stored in the distributed cache, ensuring data consistency across multiple nodes and supporting high-concurrency access through the cache cluster, avoiding single-node storage bottlenecks. By caching repeatedly queried raw data in memory-level storage, access to the underlying database is avoided for each rule execution, reducing I / O operations and improving the efficiency of customer group determination.

[0086] In some embodiments of this application, the active customer group determination method further includes: obtaining semi-static customer data from a local cache, wherein the semi-static data is constructed and stored in the local cache based on dynamic data according to a preset frequency; and combining static data, semi-static data and dynamic data to form information about the customer to be determined.

[0087] This embodiment addresses indicators that require real-time statistics (such as "number of transactions in the last a month", where a = 1, 2, 3, 6, or 12). Instead of traversing historical transaction records every time a rule is made, it uses a dual mechanism of "timed pre-calculation + data change triggering" to pre-calculate and store the indicator results. When the rule is executed, the pre-calculated value is directly called, eliminating the overhead of repeated traversal by the general-purpose microprocessor (CPU).

[0088] For example, at the end of January, February, March, June, or December, the system automatically calculates metrics such as the number of transactions for all customers in recent months. When a customer makes a new transaction, an incremental calculation is immediately triggered to update the number of transactions for the past month, ensuring data timeliness. The pre-calculated results are stored locally as semi-static data. Assuming customer C applies to participate in an activity, static and semi-static data are retrieved from the local cache, and dynamic data is retrieved from the distributed cache. These static, semi-static, and dynamic data are then combined to form complete information about customer C (the information of the customer to be evaluated).

[0089] In this embodiment, semi-static data is stored in a local cache, which can significantly reduce read latency and improve data acquisition efficiency compared to retrieving data from a distributed cache / database or performing real-time calculations each time. Secondly, semi-static data is pre-built and updated at a preset frequency, avoiding the need for real-time calculation of dynamically derived data each time customer group is determined, thus reducing CPU resource consumption caused by repeated calculations. By combining static, semi-static, and dynamic data, the reliability of basic information can be guaranteed by static data, the validity of the latest business behavior can be ensured by dynamic data, and efficiency and timeliness can be balanced by semi-static data. The resulting judgment information is comprehensive, accurate, and low in acquisition cost, providing support for subsequent efficient judgment.

[0090] In some embodiments of this application, the active customer group determination method further includes: classifying static data and / or semi-static data according to the data corresponding to each determination condition in the determination rules of the same candidate customer group, based on the candidate customer group and / or determination conditions; and packaging the classified static data and / or semi-static data and storing them in the local cache of the corresponding rule processor.

[0091] This embodiment further optimizes data access relevance and computing resource allocation based on basic caching and pre-computation. Static and semi-static data that rules for the same customer group depend on are packaged and stored, reducing the number of multi-source data reads during a single rule execution.

[0092] Figure 6 The schematic diagram illustrates the principle of a second method for determining active customer groups according to an embodiment of this application.

[0093] like Figure 6As shown, based on the data corresponding to each judgment condition in the judgment rules for the same candidate customer group, the static and semi-static data corresponding to the new customer group are classified and packaged into Package 1, Package 2, ..., Package n, and stored in the local cache corresponding to the rule processor of the new customer rule chain. The rule processor of the new customer rule chain includes Rule Processor 1, Rule Processor 2, ..., Rule Processor n. This allows for quick retrieval from the corresponding local cache when performing customer group judgment.

[0094] This embodiment categorizes static and semi-static data by candidate customer groups, allowing for direct location of the specific data set for each customer group when making subsequent determinations. This avoids sifting through irrelevant information from the full dataset, reducing the time spent on data searching and filtering. Secondly, packaging and storing the categorized data in a local cache significantly reduces read latency through local memory access and enables a single read to retrieve all the static and semi-static data required for customer group determination, avoiding frequent I / O operations from multiple data sources. Static and semi-static data have low change frequency, and the packaged cache by customer group eliminates the need for frequent updates, reducing resource consumption from repeated accesses to the underlying storage. Furthermore, the packaged data structure is highly compatible with the determination rules for the corresponding customer groups, providing accurate and efficient data support for subsequent rule execution and further optimizing the overall determination process.

[0095] In some embodiments of this application, the method for determining active customer groups further includes: obtaining the execution frequency of each customer group rule chain in the same time period; multiplying the execution frequency of the customer group rule chain by the corresponding preset single-execution cost coefficient to obtain the resource demand value, wherein the single-execution cost coefficient is set based on the rule chain length and reflects the resource consumption of a single execution; and allocating thread resources to the rule processor of the candidate customer group according to the proportion of the resource demand value of the candidate customer group to the overall value.

[0096] For example, during the same period and a certain activity, the rule chain for new customers is executed 1000 times, with a single-execution cost coefficient of 1.0 and a resource requirement weight of 1000. The rule chain for newly acquired customers is executed 300 times, with a single-execution cost coefficient of 1.5 and a resource requirement weight of 450. The rule chain for existing active customers is executed 400 times, with a single-execution cost coefficient of 2.0 and a resource requirement weight of 800. The rule chain for existing inactive customers is executed 100 times, with a single-execution cost coefficient of 3.0 and a resource requirement weight of 300.

[0097] Based on calculations, the resource requirements of each customer group account for approximately 40%, 18%, 32%, and 10% of the total, respectively. If the total number of threads is 20, then the threads are allocated according to their weight percentages: 8 threads for new customers, 4 threads for new application customers, 6 threads for existing active customers, and 2 threads for existing inactive customers.

[0098] Traditional thread allocation based solely on execution frequency ignores the high resource consumption of long rule chains in a single execution, leading to frequent delays in long chains due to insufficient resources; on the other hand, allocation based solely on chain length allows low-frequency long chains to consume too many resources, causing resource shortages in short chains.

[0099] This embodiment calculates resource requirements based on execution frequency and a single-execution cost coefficient set according to chain length. It considers both the resource priority of high-frequency rule chains and the high single-execution consumption of long chains, ultimately allocating threads according to the proportion of the required value. This avoids resource shortages caused by the length of long chains and prevents resource insufficiency due to high frequency of short chains, ensuring that thread resources match the actual load of each rule chain. By dynamically allocating CPU / IO resources, resource redundancy is avoided during peak periods, improving overall resource utilization and rule execution efficiency.

[0100] The rules for customer group determination and the types of customer groups in the embodiments of this application can be flexibly set. For example, there can be 3, 4, 5, 6 or more types of customer groups. In one activity, the rules for determining 4 types of customer groups are as follows.

[0101] (1) Rules for judging new customer groups

[0102] 1) The customer has at least one valid primary card; 2) Any valid primary card under the customer's name satisfies that the card filing date is ≥ the start date of submission; 3) Any invalid card under the customer's name satisfies that: ① For invalid cards whose filing date is less than the minimum filing time of valid cards, the difference between the account closure and settlement date and the minimum filing date of valid cards is ≥ 180 days; ② For invalid cards whose filing date is greater than or equal to the minimum filing time of valid cards, no judgment is required.

[0103] Note: A valid card indicates that the account closure and settlement date has no value; an invalid card indicates that the account closure and settlement date is less than or equal to the current date.

[0104] (2) Rules for judging the customer base of new customers

[0105] 1) The customer has no valid primary card; 2) All invalid cards under the customer's name meet the following condition: current date - account closure settlement date ≥ 180 days; 3) The customer has at least one application that meets the following condition: start date of application ≤ customer application date ≤ end date of application.

[0106] (3) Rules for judging the existing inactive customer base

[0107] Whether condition A or B is met depends on the activity rules.

[0108] A. Determine based on activity identifier

[0109] 1) There is at least one valid principal card under the customer's name; 2) At least one valid principal card under the customer's name satisfies: the sent start date ≤ the card filing date ≤ the sent end date; 3) The customer activity flag is "activated - inactive" or "not activated - inactive".

[0110] B. Judgment based on the number of transactions

[0111] 1) There is at least one valid principal card under the customer's name; 2) At least one valid principal card under the customer's name satisfies: the sent start date ≤ the card filing date ≤ the sent end date; 3) The sum of transactions of all cards under the customer's name satisfies (the transactions of the supplementary cards are counted on the principal card): the customer's transactions in the recent a months < b (a and b are the sent values, and the 5 groups of values are 12, 6; 1, 1; 2, 1; 3, 1; 6, 1).

[0112] (4)Judgment rules for the stock active customer group

[0113] Meet condition A or B, determined according to the activity rules.

[0114] A. Judgment based on the activity flag

[0115] 1) There is at least one valid principal card under the customer's name; 2) At least one valid principal card under the customer's name satisfies: the sent start date ≤ the card filing date ≤ the sent end date; 3) The customer activity flag is "has card - active".

[0116] B. Judgment based on the number of transactions

[0117] 1) There is at least one valid principal card under the customer's name; 2) At least one valid principal card under the customer's name satisfies: the sent start date ≤ the card filing date ≤ the sent end date; 3) The sum of transactions of all cards under the customer's name satisfies (the transactions of the supplementary cards are counted on the principal card): the customer's transactions in the recent a months ≥ b (a and b are the sent values, and the 5 groups of values are 12, 6; 1, 1; 2, 1; 3, 1; 6, 1).

[0118] Based on the above - mentioned activity customer group determination method, this application also provides an activity customer group determination device. The following will be combined with Figure 7 to describe this device in detail.

[0119] Figure 7 Schematically shows the structural block diagram of the activity customer group determination device according to the embodiment of this application.

[0120] As Figure 7 shown, the activity customer group determination device 700 of this embodiment includes a rule extraction module 710, a customer group rule chain module 720, a rule processor module 730, and a customer group determination module 740.

[0121] The rule extraction module 710 is used to extract a judgment rule for a candidate customer group category from a preset active customer group rule table in response to obtaining information about the customer to be judged.

[0122] The customer group rule chain module 720 is used to form a customer group rule chain based on the priority of each judgment condition in the judgment rule of the same candidate customer group category.

[0123] The rule processor module 730 is used to use the rule processors corresponding to each judgment condition in the customer group rule chain to judge whether the customer information meets each judgment condition in the order of the customer group rule chain. The rule processor is used to receive the customer information to be judged and the parameters corresponding to the judgment conditions, execute the judgment operation through preset logic, and output the result of whether the customer information meets the judgment conditions.

[0124] The customer group determination module 740 is used to determine the target customer group category of the customer based on the result of whether the judgment conditions are met, as output by the rule processor.

[0125] According to an embodiment of this application, the rule extraction module 710 is further configured to determine the selection order of each candidate customer group based on the time evolution relationship of each candidate customer group in the preset activity customer group rule table, wherein the time evolution relationship indicates the evolution pattern of each candidate customer group over time in the customer life cycle; and select the judgment rule of a candidate customer group that has an earlier evolution stage and has not been judged from the candidate customer groups according to the selection order.

[0126] According to an embodiment of this application, the customer group rule chain module 720 is further configured to mark each judgment condition as at least one of the following label types: static condition, dynamic condition, or high-frequency failure judgment condition, based on at least one of the data dependency, logical independence, and failure frequency of each judgment condition. Static conditions are independent of each other and can be executed in parallel; dynamic conditions are executed serially with the static conditions they depend on; and high-frequency failure judgment conditions have the highest priority among the parallel execution conditions. The priority of each judgment condition is determined based on its label type.

[0127] According to an embodiment of this application, the apparatus further includes an information acquisition module, configured to: acquire static data of the customer from a local cache in response to acquiring information about the customer's participation in an activity; acquire static data of the customer from a local cache, wherein the static data includes basic card status and fixed date information held by the customer; acquire dynamic data of the customer from a distributed cache other than the local cache, wherein the dynamic data includes the customer's transaction behavior and business interaction information; and form information about the customer to be determined based on the static data and the dynamic data.

[0128] According to an embodiment of this application, the information acquisition module is further configured to acquire semi-static data of customers from a local cache, wherein the semi-static data is constructed and stored in the local cache based on dynamic data according to a preset frequency; and the information of the customer to be determined is formed by combining static data, semi-static data and dynamic data.

[0129] According to an embodiment of this application, the information acquisition module is further configured to classify static data and / or semi-static data according to the data corresponding to each judgment condition in the judgment rules of the same candidate customer group, and to package the classified static data and / or semi-static data and store them in the local cache of the corresponding rule processor.

[0130] According to an embodiment of this application, the device further includes a resource adjustment module, used to obtain the execution frequency of each customer group rule chain in the same time period; multiply the execution frequency of the customer group rule chain by the corresponding preset single cost coefficient to obtain the resource demand value, wherein the single cost coefficient is set based on the rule chain length and reflects the resource consumption of a single execution; and allocate thread resources to the rule processor of the candidate customer group according to the proportion of the resource demand value of the candidate customer group to the overall value.

[0131] According to embodiments of this application, any multiple modules among the rule extraction module 710, customer group rule chain module 720, rule processor module 730, customer group determination module 740, information acquisition module, and resource adjustment module can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the rule extraction module 710, customer group rule chain module 720, rule processor module 730, customer group determination module 740, information acquisition module, and resource adjustment module can be at least partially implemented as hardware circuits, such as field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits (ASICs), or implemented by any other reasonable means of integrating or packaging circuits, or implemented by any one of software, hardware, and firmware, or by any appropriate combination of any of these three implementation methods. Alternatively, at least one of the rule extraction module 710, the customer group rule chain module 720, the rule processor module 730, the customer group determination module 740, the information acquisition module, and the resource adjustment module can be implemented at least partially as a computer program module, which can perform corresponding functions when the computer program module is run.

[0132] Figure 8 A block diagram schematically illustrates an electronic device suitable for implementing an active customer group determination method according to an embodiment of this application.

[0133] like Figure 8 As shown, an electronic device 800 according to an embodiment of this application includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage portion 808 into a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0134] RAM 803 stores various programs and data required for the operation of electronic device 800. Processor 801, ROM 802, and RAM 803 are interconnected via bus 804. Processor 801 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 802 and / or RAM 803. It should be noted that programs may also be stored in one or more memories other than ROM 802 and RAM 803. Processor 801 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0135] According to embodiments of this application, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to a bus 804. The electronic device 800 may also include one or more of the following components connected to the I / O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0136] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0137] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 802 and / or RAM 803 and / or one or more memories other than ROM 802 and RAM 803 described above.

[0138] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to enable the computer system to implement the item recommendation method provided in the embodiments of this application.

[0139] When the computer program is executed by the processor 801, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0140] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 809, and / or installed from a removable medium 811. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0141] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 809, and / or installed from the removable medium 811. When the computer program is executed by the processor 801, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0142] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0143] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0144] Those skilled in the art will understand that the features described in the various embodiments and / or claims of this application can be combined or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments and / or claims of this application can be combined or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

[0145] The embodiments of this application have been described above. However, these embodiments are merely illustrative and not intended to limit the scope of this application. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this application is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this application, and all such substitutions and modifications should fall within the scope of this application.

Claims

1. A method for determining the target customer group for an event, characterized in that, include: In response to obtaining information about customers to be judged, the system extracts the judgment rules for candidate customer groups from the preset activity customer group rule table. A customer group rule chain is formed based on the priority of each judgment condition in the judgment rule for the same candidate customer group category. Using the rule processors corresponding to each judgment condition in the customer group rule chain, the information of the customer is judged in the order of the customer group rule chain to determine whether it meets each judgment condition. The rule processor is used to receive the information of the customer to be judged and the parameters corresponding to the judgment condition, execute the judgment operation through preset logic, and output the result of whether the customer information meets the judgment condition. Based on the result of whether the judgment conditions are met, the target customer group category of the customer is determined.

2. The method according to claim 1, characterized in that, The determination rule for extracting a candidate customer group from a preset activity customer group rule table includes: Based on the time evolution relationship of each candidate customer group in the preset activity customer group rule table, the selection order of each candidate customer group is determined, wherein the time evolution relationship indicates the evolution pattern of each candidate customer group over time in the customer life cycle; The selection rule is to choose a candidate group from the candidate groups that has an earlier evolutionary stage and has not yet been determined, according to the selection order.

3. The method according to claim 1, characterized in that, The step of forming a customer group rule chain based on the priority of each judgment condition in the judgment rule for the same candidate customer group includes: Based on at least one of the data dependency, logical independence, and failure frequency of each judgment condition, each judgment condition is marked as at least one of the following label types: static condition, dynamic condition, or high-frequency failure judgment condition. The static conditions are independent of each other and can be executed in parallel. The dynamic conditions are executed serially with the static conditions they depend on. The high-frequency failure judgment condition has the highest priority among the parallel execution conditions. The priority of each decision condition is determined based on its tag type.

4. The method according to claim 1, characterized in that, Also includes: In response to obtaining information about customer participation in activities; Retrieve the customer's static data from the local cache, wherein the static data includes the basic status of the card held by the customer and fixed date information; The customer's dynamic data is obtained from a distributed cache other than the local cache, wherein the dynamic data includes the customer's transaction behavior and business interaction information; The information of the customer to be determined is formed based on the static data and the dynamic data.

5. The method according to claim 4, characterized in that, Also includes: The semi-static data of the customer is obtained from the local cache, wherein the semi-static data is constructed and stored in the local cache based on the dynamic data according to a preset frequency; The information of the customer to be determined is formed by combining the static data, semi-static data, and dynamic data.

6. The method according to claim 5, characterized in that, Also includes: Based on the data corresponding to each judgment condition in the judgment rules for the same candidate customer group, the static data and / or semi-static data are classified according to the candidate customer group and / or judgment conditions. The categorized static and / or semi-static data are packaged and stored in the local cache of the corresponding rule processor.

7. The method according to claim 1, characterized in that, Also includes: Obtain the execution frequency of each customer group rule chain during the same time period; The resource requirement value is obtained by multiplying the execution frequency of the customer group rule chain by the corresponding preset single cost coefficient, wherein the single cost coefficient is set based on the rule chain length and reflects the resource consumption of a single execution. Thread resources are allocated to the rule processor of the candidate customer group according to the proportion of the resource demand value of the candidate customer group to the total.

8. A device for determining active customer groups, comprising: The rule extraction module is used to extract a judgment rule for a candidate customer group category from the preset activity customer group rule table in response to the acquisition of customer information to be judged; The customer group rule chain module is used to form a customer group rule chain based on the priority of each judgment condition in the judgment rule for the same candidate customer group category. The rule processor module is used to use the rule processors corresponding to each judgment condition in the customer group rule chain to sequentially judge whether the customer information meets each judgment condition according to the order of the customer group rule chain. The rule processor is used to receive the information of the customer to be judged and the parameters corresponding to the judgment condition, execute the judgment operation through preset logic, and output the result of whether the customer information meets the judgment condition. as well as The customer group determination module is used to determine the target customer group category of the customer based on the result of whether the judgment conditions are met, as output by the rule processor.

9. An electronic device, comprising: One or more processors; Storage device for storing one or more programs. Wherein, when the one or more programs are executed by the one or more processors, the one or more processors perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

11. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images