Standard judgment method and system for task event and storage medium

Abstract

The embodiment of the invention provides an up-to-standard judgment method and system for a task event and a storage medium, and belongs to the field of task evaluation. The method comprises the following steps: constructing an index pool which comprises a plurality of preset indexes; selecting a preset index and / or creating a new index from the index pool as a target index according to a business demand; performing parameterization configuration on the standard reaching condition of the target index to generate a task event; and according to the achievement condition of the target index, performing standard judgment on the task event. The invention aims to design a marketing task up-to-standard calculation scheme which is simplified in development, flexible in configuration, convenient for business to reuse indexes and capable of reducing waste of calculation resources, by setting the index pool, manpower and time cost generated by repeatedly developing similar caliber indexes can be reduced, and intensive utilization of development resources is realized. In addition, through parameterized configuration, each index can be conveniently combined and published.

Description

Technical Field

[0001] This invention relates to the field of task evaluation, and more specifically to a method, system, and storage medium for determining the achievement of task events. Background Technology

[0002] Marketing campaigns have been widely used in current marketing activities, and the achievement of marketing campaign objectives is a core element in evaluating campaign effectiveness and ensuring that customer incentives are accurately delivered.

[0003] However, existing technical solutions typically exhibit the following limitations when addressing this requirement: First, the criteria for each task often require case-by-case customization, leading to significant duplication of effort and increased development costs. Second, these solutions generally deeply couple specific business conditions with technical code, meaning any minor adjustment to the metrics must rely on technical personnel modifying the underlying SQL, preventing business personnel from directly participating in adjustments and hindering marketing campaigns from quickly responding to rapidly changing market demands. Summary of the Invention

[0004] The purpose of this invention is to provide a method, system, and storage medium for determining the achievement of task events. This solution aims to design a marketing task achievement calculation scheme that simplifies development, allows for flexible configuration, facilitates business reuse of indicators, and reduces the waste of computing resources, while also supporting batch tasks.

[0005] To achieve the above objectives, embodiments of the present invention provide a method for determining the compliance of a task event. The method includes: constructing an indicator pool, including multiple pre-set indicators; selecting pre-set indicators and / or creating new indicators as target indicators from the indicator pool according to business needs; parameterizing the compliance conditions of the target indicators to generate task events; and determining the compliance of the task events based on the achievement of the target indicators.

[0006] On the other hand, the present invention provides a task event compliance determination system, the system comprising: an indicator pool construction device for constructing an indicator pool including multiple pre-set indicators; an indicator acquisition device for selecting pre-set indicators and / or creating new indicators as target indicators from the indicator pool according to business needs; a parameterization configuration device for parameterizing the compliance conditions of the target indicators to generate task events; and a compliance determination device for determining the compliance of the task events based on the achievement of the target indicators.

[0007] On the other hand, the present invention provides a machine-readable storage medium storing instructions for causing a machine to execute: the method for determining the achievement of a task event as described above.

[0008] On the other hand, the present invention provides a processor for running a program, wherein the program is run to execute: the method for determining the achievement of task events as described above.

[0009] On the other hand, the present invention provides a computer program product, including a computer program that, when executed by a processor, implements: the method for determining the achievement of task events as described above.

[0010] Through the above technical solutions, this invention provides a method, system, and storage medium for determining the compliance of task events. By setting up an indicator pool, it can reduce the manpower and time costs caused by repeatedly developing similar indicators, thus achieving intensive utilization of development resources. Furthermore, this invention allows for convenient combination and release of various indicators through parameterized configuration.

[0011] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0012] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings: Figure 1 This application provides a complete flowchart of the marketing task from access to customer interaction; Figure 2 This is a flowchart illustrating a method for determining the compliance of a task event according to an embodiment of the present invention; Figure 3 This is an overall flowchart of indicator generation provided by an embodiment of the present invention; Figure 4 This is a flowchart of creating a marketing task configuration according to an embodiment of the present invention; Figure 5 This is a main flowchart of batch processing during task execution provided by an embodiment of the present invention; Figure 6 This is a flowchart illustrating the process of generating a list of tasks to be processed according to an embodiment of the present invention. Figure 7 This is a flowchart illustrating the process of generating a list of indicators to be processed according to an embodiment of the present invention. Figure 8 This is a logic flowchart for batch processing compliance determination provided by an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a task event compliance determination system provided in an embodiment of the present invention; Figure 10This is a schematic diagram of the internal structure of a computer device according to an embodiment of this application.

[0013] Explanation of reference numerals in the attached figures A01 - Processor; A02 - Network interface; A03 - Internal memory; A04 - Display screen; A05 - Input device; A06 - Non-volatile storage medium; B01 - Operating System; B02 - Computer Program. Detailed Implementation

[0014] The specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustration and explanation only and are not intended to limit the scope of the present invention.

[0015] The applicant's research found that the shortcomings of the currently known solutions include: the criteria for each task event usually need to be determined on a case-by-case basis, requiring separate development of the entire process for judging each task, which is difficult to modify; and the task processing flow is not taken offline in a timely manner after the task ends, requiring manual operation and wasting computing resources.

[0016] In the solution involved in this invention, the launch of a task event (such as a marketing task) is divided into three stages: requirement access, task development and configuration, and task execution. Figure 1 This paper presents the entire process of marketing tasks, from initial contact to customer outreach, during a marketing campaign. However, the initial contact process, involving communication between technical personnel, requirements analysts, and business personnel, is outside the scope of this patent. This patent primarily addresses the implementation of the latter two stages: task development and configuration, and task execution.

[0017] Specifically, the task development configuration primarily serves to configure the achievement criteria for marketing and development tasks, and to link these tasks with the criteria. This configuration determines how task execution is judged to have achieved the objectives. Task execution is the goal of the marketing campaign and is the most complex part of this patent. This part designs and implements the method for calculating the criteria and the process for calculating task achievement. It calculates daily criterion data and, based on this data, task configuration, and task registration data, determines whether the customer has met the criteria. It is worth noting that the acquisition, storage, use, and processing of data in this application's technical solution all comply with relevant laws and regulations.

[0018] The implementation schemes for these two stages will be explained in detail below. First, this invention provides a method 100 for determining the achievement of task events, such as... Figure 2 As shown, the compliance determination method 100 may include steps S110-S140.

[0019] Step S110: Construct an indicator pool, which includes multiple pre-set indicators.

[0020] The indicator pool is a collection of numerous indicators of different types, requiring multiple indicators to be pre-set. Its core function is to provide daily statistical values ​​from a user perspective for task achievement determination. The indicators mentioned in this patent are daily statistical values ​​from a user perspective, serving as a set of data used to determine whether a task has been achieved. For example, if a customer makes three credit card transactions on a given day (10 yuan, 58 yuan, and 100 yuan), and the task requires more than five transactions exceeding 50 yuan in the month, the system can design a count indicator A (the customer's indicator value for that day is 2, corresponding to the two successful transactions of 58 yuan and 100 yuan), while simultaneously recording the successful transaction amount of 158 yuan. This data will be used for task performance statistical analysis.

[0021] The indicator configuration table, as the core carrier of indicator generation rules, is designed with fields intended to achieve precise definition and full lifecycle management of indicators. In one embodiment, the data structure of the indicator configuration table of the indicator pool may include one or more of the following fields: indicator number, indicator category, processing SQL (Structured Query Language), date offset, indicator source, indicator name, indicator parameters, indicator description, and dependent data table list.

[0022] Specifically, the indicator number is the unique identifier of the indicator, ensuring its uniqueness; the indicator classification is used to categorize indicators according to business dimensions, which can improve management and retrieval efficiency; the processing SQL is the calculation logic script that directly generates indicator values; the date offset is a key parameter used to solve the problem of mismatch between the source data date and the target judgment date. Its function is to include source data that is outside the judgment range into the calculation through date offset. For example, calculating the "customer's monthly average daily balance" requires referencing the data at the end of last month. At this time, the corresponding offset needs to be configured to achieve data alignment; the indicator source is used to distinguish whether the indicator is newly created or derived (the generation process will be detailed later). If it is a derived indicator, its source indicator number must be recorded to ensure data traceability; the indicator name is the intuitive business name of the indicator; the indicator parameters are fixed business conditions abstracted from the processing SQL. Once the indicator is published, it cannot be modified to ensure rule consistency; the indicator description is used to explain in detail the generation conditions and business meaning of the indicator, which is easy to understand and reuse across scenarios; the dependent data table list clearly records all the underlying data tables on which the indicator calculation depends, which is an important basis for data lineage and integrity.

[0023] At the storage architecture level, this patented solution employs an indicator pool for unified storage and management of all indicators. In one embodiment, the indicator pool is designed to support 500 or more valid indicators (i.e., indicators currently being used by tasks) and implements differentiated data lifecycle management strategies. For example, for indicators currently being used by tasks, data from the most recent 100 days can be retained; while for indicators no longer referenced, processing continues for only 10 days to ensure smooth data decommissioning. This design is sufficient for most batch processing scenarios. Furthermore, to significantly simplify the indicator generation process, this solution can also incorporate a built-in general indicator generation job engine. This engine consists of a set of dynamically scalable job processes, with the number of jobs flexibly set based on the total number of indicators to be processed and available system resources. For example, these general jobs are uniformly configured to run every 3 hours (this frequency can be adjusted according to actual operational needs), allowing each job to focus on processing different indicators through task scheduling. After all jobs are completed, the resulting indicator data is efficiently written to different partitions of the indicator pool table in parallel, thereby ensuring overall processing performance and scalability.

[0024] In one embodiment, the overall process of indicator generation is as follows: Figure 3 As shown, the processing steps for each step are detailed below: First, check if there are any pending indicators for the day. If not, the process ends directly; otherwise, proceed to the task allocation stage. Then, a pending indicator can be obtained through a CAS (Compare-and-Swap) atomic operation, and its processing status and batch number are updated to "Processing." This mechanism effectively avoids duplicate calculations of the same indicator by multiple processing jobs. Next, the process verifies whether the source data table on which the indicator depends has ready for the day. If the data is not ready, the indicator status is reset to "Unprocessed," and the pending queue is re-polled. Once the data is ready, the predefined generation SQL in the indicator configuration table is executed to produce the incremental data for the day, and the indicator type is determined based on this. If the indicator is a status indicator (such as the current customer level, which usually requires a daily full snapshot), the full data from yesterday needs to be extracted and merged with today's incremental data to finally generate today's full indicator result. If it is not a status indicator (such as event-based indicators like the number of transactions), the incremental data is used directly as the final result. During the data storage phase, target partitions can be dynamically generated based on configured date offsets (the offset is typically 0 or a positive number to ensure data alignment). The generated metric data is then written to this partition in parallel. This partition employs a three-level structure: "Date-Metric Category-Metric Number," placing the date at the first level significantly improves the efficiency of historical data cleaning. After writing is complete, the metric status is updated to "Completed," and the next pending metric is automatically polled. This process is repeated until all metrics have been processed, ultimately terminating the entire job.

[0025] Step S120: Based on business needs, select a pre-set indicator from the indicator pool and / or create a new indicator as the target indicator.

[0026] This step allows you to select existing metrics from a pre-built metric pool, or create entirely new metrics if necessary, based on specific business needs (such as a new marketing campaign), to serve as the target metrics for this marketing task. The purpose of generating metrics is to extract target data corresponding to customer task completion as data indicators, aggregate them, and then apply them to task achievement calculations. Metric processing includes two parts: metric generation and metric cleanup. Metric cleanup typically follows a preset data retention strategy; for example, it can be configured by default to retain metric data from the most recent 100 days. However, if the task's execution period exceeds 100 days, a flexible rule of "task period + 30 days" will be used to retain data to ensure coverage of the task's entire lifecycle.

[0027] The data structure for target metrics can include one or more of the following fields: metric ID, metric category, metric date, customer ID, frequency statistics, amount statistics, and metric value. Specifically, the metric ID serves as a unique identifier, ensuring the precise location of each metric within the system; the metric category categorizes metrics from a business perspective, facilitating systematic management; the metric date records the specific calculation date of the metric data; the customer ID clearly identifies the customer to whom the metric data belongs, and is core to achieving "customer-task" association and target achievement calculation. Furthermore, as an important supplement to statistics and analysis, the frequency statistics and amount statistics quantify the frequency of customer behavior and the total amount associated within a single day, respectively, primarily providing data support for subsequent business performance evaluation. The metric value is the core numerical value in this data structure that serves the final business judgment, directly used for the logical determination of whether the task has been achieved.

[0028] As mentioned earlier, business requirements can be inputted through marketing campaigns. Each marketing campaign requires the development and configuration of multiple marketing tasks. The primary function of these processes is to quickly and flexibly configure marketing tasks and develop corresponding metrics, facilitating rapid deployment and enabling marketing campaigns to respond quickly to demands. Ultimately, all these configuration and development efforts converge on the marketing task development and configuration process. Its core value lies in the ability to quickly and flexibly configure marketing tasks and develop corresponding metrics. This not only greatly facilitates rapid deployment but also enables marketing campaigns to respond swiftly to market changes and business needs.

[0029] The marketing task development and configuration process involves tasks such as task configuration, task metric development, and task-metric association. For example, Figure 4The process for creating a marketing task configuration is as follows: First, a marketing campaign needs to be created, and specific tasks need to be created under this campaign (a marketing campaign can contain multiple tasks). The basic attributes of the tasks, such as task name, execution period, and task description, must be configured. Next, the crucial task metric association step begins: if the required metric already exists, it is directly associated; otherwise, the metric creation process must be initiated.

[0030] It's important to emphasize that metric creation is divided into two modes: "metric creation" and "metric derivation." Metric creation refers to creating a completely new metric from scratch. This process requires configuring various metric attributes. The core is to develop an SQL script to generate the metric based on the business compliance criteria determined by the task, connecting with the source system, and using the provided technical specifications. During this process, some adjustable conditions in the technical specifications are abstracted into metric parameters, aiming to facilitate future metric derivation. After metric development is complete, it enters the functional testing phase to ensure its accuracy and stability. Metric derivation, on the other hand, is a method to quickly derive new metrics from existing ones. Derived metrics are completely identical to the source metrics in their underlying processing logic; the main difference lies in the metric number and specific parameter values. Thanks to this inheritance relationship, derived metrics theoretically do not require repeated development and functional testing and can directly enter the release phase. After metric release, the process enters the task compliance condition configuration phase. After the task passes testing, a series of pre-launch verifications, such as canary release and whitelist testing, will be conducted. Finally, after the whitelist test is passed, the task will be officially released to customers, thus completing the entire development and configuration process of the marketing task.

[0031] Step S130: Configure the target indicator's achievement conditions parametrically to generate task events.

[0032] After selecting the target metrics, the crucial parameterization configuration phase is required. The goal is to define clear and quantifiable rules for subsequent task achievement determination, thereby formally generating executable task events. The core of this process lies in the flexible configuration of a series of achievement threshold parameters. Parameterization configuration includes configuring one or more of the following achievement thresholds: threshold values, judgment symbols, etc. Threshold values ​​serve as the benchmark for judgment. For example, in a credit card spending task, the threshold value for the "number of transactions" metric is set to 3, and the threshold value for the "transaction amount" metric is set to 3000. Judgment symbols are used to clarify the logical relationship between the metric value and the threshold. Common symbols include "greater than" (>), "equal to" (=), or "less than" (<), used to accurately determine whether the metric has achieved the preset target.

[0033] It is important to emphasize that the key innovation of this invention lies in the refinement and abstraction of indicator parameters. When an indicator is first created, the relevant parameters are initially configured by technical personnel. Afterward, business personnel can directly derive derivative indicators that meet new business scenarios by adjusting the parameter values ​​of existing indicators without technical intervention. Since the underlying calculation logic (processing SQL) of the derived indicators is consistent with that of the source indicators, differing only in parameters, repetitive functional testing can be avoided, allowing direct entry into the release process. Furthermore, by parameterizing the achievement conditions of the target indicators, various indicators can be easily combined and released, significantly shortening the development cycle from business requirements to indicator deployment. It should be noted that the number and specific types of indicator parameters are entirely determined by business criteria, providing significant business flexibility. Different indicators can have completely different numbers and types of parameters to accurately adapt to diverse marketing judgment rules.

[0034] Step S140: Determine whether the task event has met the target based on the achievement of the target indicators.

[0035] The performance evaluation of task events is the core of this patent. To better support the achievement of task performance evaluation, this step can also include single processing functions and multiple batch processing functions, meaning there can be one or more target indicators. For example... Figure 5 The main process of batch processing during task execution is given. Specifically, in... Figure 5 The main process includes several parts: online data synchronization to a batch library, generation of a pending list, indicator processing, task achievement calculation, and writing the achievement results back to the online library. The online data synchronization to the batch library can be scheduled to synchronize the previous day's online data to the batch library at 1:00 AM daily; this can be implemented using general logic and is not the focus of this patent. This patent will explain the implementation of the task execution logic from three parts: pending list generation, indicator processing, and task achievement calculation. Specifically, when there is only one target indicator, step S140 includes the following steps S141-S143.

[0036] Step S141: Generate a list of metrics to be processed based on the list of tasks to be processed generated at a set time point.

[0037] Step S142: Based on the completed data and the achievement conditions of the target indicators in the list of indicators to be processed, determine the completion status of the target indicators.

[0038] Step S143: Based on the completion status, determine whether the task event has met the target.

[0039] Specifically, regarding the generation of the pending list in step S141, after the configuration data in the online database is synchronized to the batch database daily, the process of generating the pending list will be executed, mainly generating a pending indicator list and a pending task list. The differences in the generation logic of these two pending processes will be explained below.

[0040] To generate a list of tasks to be processed, the configuration data in the online database needs to be synchronized to the batch database daily. Then, the batch job for generating tasks to be processed is started, thus generating the tasks to be processed for the day. In this way, the subsequent task processing flow will only process the list of tasks to be processed generated on the same day. Figure 6 The process for generating the list of tasks to be processed is given, and the following steps need to be performed: 1) First, query tasks that have not expired. Then, filter out tasks that are still in the judgment period and proceed to step 2). Filter out tasks that have expired and proceed to step 3.

[0041] 2) Generate a new pending list, where the pending judgment date, data date, and maximum judgment date are all the business processing dates. Generate a pending task list, then associate it with the unprocessed tasks from the previous day, update the pending judgment date of the current data with the judgment date from the previous day, and execute step 4).

[0042] 3) Associate the unprocessed tasks whose data date is yesterday's business date, set the data date to the business processing date, keep the pending judgment date and the maximum pending date unchanged, generate a list of pending tasks, and execute step 4).

[0043] 4) Merge the two types of data to generate a pending processing list for the day, ready for use in subsequent processes.

[0044] It's important to note that each task has two timeframes: a task judgment period and a task validity period. The task judgment period is included within the task validity period. Only tasks whose pending judgment date falls within the judgment period can participate in the achievement judgment. If a task with the last pending judgment date remains unjudged, the pending judgment date will remain unchanged but will be updated daily as a pending task until the task expires. Each pending task has three dates: the pending processing date, the maximum pending processing date, and the data date. Normally, these three are equal. If a task was not judged the previous day, the pending processing date < the maximum pending processing date = the data date. If the task has already passed its judgment period, the maximum pending processing date will not be updated, and the pending processing date = the maximum pending processing date < the data date. In extreme cases, if a task remains unprocessed for two consecutive days and expires, the pending processing date < the maximum pending processing date < the data date.

[0045] To generate a list of pending metrics, the configuration data in the online database needs to be synchronized to the batch database daily. At the same time as generating the list of pending tasks, the metrics to be processed for the day are also generated. The pending tasks will only process the pending tasks of the day. The pending tasks of the previous day will not be processed on the next day. Tasks that need to be processed on the previous day will be merged into the current day for processing. However, the list of pending metrics needs to be processed daily. This is determined by the nature of the data. Figure 7 The process for generating the list of metrics to be processed is given, which mainly involves the following steps: 1) Query tasks that have expired within 10 days and tasks that have not yet expired.

[0046] 2) Retrieve all metrics associated with the task in step 1).

[0047] 3) Generate a list of indicators to be processed for the day.

[0048] It should be noted that many tasks will be presented to customers consecutively, but there may be a few days' interval in between. In order to ensure the continuity of data, you can also query the corresponding indicators of tasks that have expired within 10 days and continue to generate a list of tasks to be processed.

[0049] The achievement calculation in steps S142-S143 is the final and most crucial step in this patent, as it relates to the achievement result and customer experience, ultimately affecting the effectiveness of the marketing campaign. Specifically, in step S142, the "completion data" (i.e., indicator values) calculated and stored in the "indicator table" in previous processes needs to be retrieved and compared with the preset "achievement conditions" (such as indicator thresholds and judgment symbols) in the "task configuration table" to accurately determine the completion status (achieved or not achieved) of each target indicator. The final step S143 then determines whether the entire task event has been successfully achieved based on the "completion status" output in step S142.

[0050] It's also important to note that compliance calculation and indicator calculation are two independent data processing procedures. Indicator calculation involves diverse data sources (corresponding to different business data tables) and complex generation logic, thus requiring the deployment of multiple general-purpose jobs for parallel generation. In contrast, compliance calculation uses relatively fixed and unified data sources (i.e., from the "indicator table"), allowing this solution to employ a single, timed job to calculate compliance results in batches. This separation of architectures ensures efficiency, stability, and scalability when processing massive amounts of data.

[0051] In summary, this invention aims to design a marketing task achievement calculation scheme that simplifies development, allows for flexible configuration, facilitates the reuse of metrics in business operations, and reduces the waste of computing resources. The advantages of this patented technical solution include: 1. Metric Reuse and Cost Control. By introducing a core architecture of "metric pool," this solution extracts the specific criteria for task judgment (i.e., metrics) from the task logic itself, consolidating them into a centrally managed set of metrics. The most direct benefit of this design is breaking the hard-coded binding between metrics and tasks, allowing the same metric (e.g., "total daily credit card transaction amount") to be seamlessly reused by multiple marketing tasks (e.g., "quarterly spending sprint" and "new customer first-swipe reward"). This significantly reduces the manpower and time costs incurred from repeatedly developing similar metrics, achieving intensive utilization of development resources.

[0052] 2. Standardized Generation Process and Flexible Resources. The technical solution of this invention deploys a set of fixed, general tasks for generating metrics, forming a standardized computational pipeline. When a business needs to add a new metric, the work of technical personnel is simplified to defining the business SQL and parameters only in the "metric configuration table," without needing to worry about the underlying execution environment and resource scheduling. More importantly, this solution establishes an intelligent metric lifecycle management mechanism: whether a metric continues to generate data depends entirely on whether it is referenced by active marketing tasks. Once all marketing tasks associated with a metric have expired, the computation of that metric will automatically stop. This "on-demand computation" model effectively avoids unnecessary waste of computing resources and ensures efficient allocation of system resources.

[0053] 3. Parameterized Configuration and Business Agility. This invention also innovatively refines and abstracts the business conditions in the indicator processing SQL to form configurable "indicator parameters" (such as transaction amount minimums, merchant types, etc.). When an indicator is first created, these parameters are initially configured and embedded into the SQL by technical personnel. Afterward, business personnel can directly and quickly derive derivative indicators adapted to new scenarios by adjusting the parameter values ​​of existing indicators without the intervention of the technical team. Since the derived indicators inherit the mature calculation logic of the source indicators, differing only in parameter values, they can be considered a low-risk change, thus eliminating repetitive functional testing and allowing direct entry into the release process. This design shortens the development cycle from days to hours, or even minutes, significantly improving business response speed and market responsiveness.

[0054] In another embodiment, this solution can also be applied to batch compliance determination solutions. That is, when there are multiple target indicators, this solution can also determine whether multiple tasks participated in by the customer have met the target based on parameterized configuration conditions and aggregation conditions, thus achieving complex multi-condition determination. Specifically, after step S120, the compliance determination method 100 of the present invention further includes steps S150-S160: Step S150: Configure the parameterization conditions and aggregation rules for multiple target indicators to generate task events.

[0055] The parameterized configuration can include configuring one or more of the following threshold values: intra-indicator threshold values, inter-indicator threshold values, intra-indicator decision symbols, and inter-indicator decision symbols. The aggregation rule configuration can include configuring one or more of the following aggregation types: intra-indicator aggregation type, and inter-indicator aggregation type.

[0056] The parameterized configuration primarily sets various numerical thresholds, including intra-indicator thresholds (the threshold for a single indicator) and inter-indicator thresholds (the overall threshold for multiple indicators), supplemented by "intra-indicator judgment symbols" and "inter-indicator judgment symbols" to clarify the comparison relationship. The aggregation rule configuration focuses on defining the calculation logic of data and indicators, specifically including intra-indicator aggregation types (such as counting transactions using COUNT, summing amounts using SUM), and "inter-indicator aggregation types" to determine how to integrate the judgment results of various independent indicators (such as counting the number of compliant indicators using COUNT or summing using SUM). All the above configuration information is systematically recorded in the Task Configuration Table, which serves as the core data carrier. Specifically, the following fields are used to achieve the logical binding of tasks and indicators and the definition of rules: Task ID is the unique identifier of the task; Indicator ID is associated with the specific indicator in the Indicator Configuration Table; Intra-indicator threshold values ​​define the compliance standard for a single indicator; Inter-indicator threshold values ​​set the final threshold that multiple indicators as a whole must meet.

[0057] The following two tasks illustrate how to use each field: In Task 1, the business requirement is that monthly credit card spending must simultaneously meet the criteria of "each transaction > 50 yuan", "total number of transactions > 3", and "total amount > 3000 yuan". To achieve this logic, this task needs to associate two core metrics: "number of credit card transactions" and "credit card transaction amount". Under this configuration, "3 transactions" and "3000 yuan" are the "internal threshold values" of these two metrics, respectively. The "internal judgment sign" of both metrics is set to "greater than", and the "internal aggregation type" of the number of transactions metric is COUNT (count), while the "internal aggregation type" of the amount metric is SUM (sum). Since the rule requires that both conditions must be met simultaneously (an AND relationship), the "internal aggregation type" is configured as COUNT, which counts the number of metrics that meet the criteria; combined with the "internal judgment sign" being "greater than" and the "internal threshold value" being 1, this configuration is mathematically equivalent to "all metrics must meet the criteria".

[0058] In Task 2, the rule changes to a total credit card "or" debit card spending exceeding 3000 yuan, with credit card spending exceeding 1000 yuan. This task also involves two metrics: "Credit Card Transaction Amount" and "Debit Card Transaction Amount," both with an "Intra-metric Aggregation Type" of SUM. To implement the "or" logic and accumulate the total amount, the "Inter-metric Aggregation Type" is set to SUM, the decision sign is "greater than," and the threshold is set to 3000. Simultaneously, by setting a separate threshold (1000 yuan) for credit cards within the metric, a specific lower bound constraint is nested within the overall premise of cumulative summation.

[0059] As the examples above demonstrate, by flexibly configuring the values ​​of relevant fields in the task configuration table, complex task achievement conditions, ranging from multiple "AND" conditions to conditional "OR" conditions, can be precisely defined. This fully demonstrates the high flexibility and powerful business performance of the configuration system. This flexible configuration method can accurately adapt to the interests and spending power of different customer groups. This "personalized" judgment rule significantly enhances the personalization and engagement of tasks, thereby improving customer participation and completion rates in overall marketing campaigns.

[0060] Step S160: Based on the achievement status of each target indicator and the aggregation conditions for achievement among multiple target indicators, determine the achievement of the task event.

[0061] The core task of this step is to determine the achievement of task events based on the achievement status of each target indicator and the aggregation conditions between indicators configured in step S150. This may include the following specific steps: Step S161: Based on the list of tasks to be processed generated at the set time point, generate a list of metrics to be processed. The specific execution steps are detailed in step S141 and will not be repeated here.

[0062] Step S162: Based on the completed data and the achievement conditions of each target indicator in the list of indicators to be processed, determine the completion status of multiple target indicators.

[0063] Step S163: Based on the completion indicators of multiple target indicators and the aggregation conditions for achieving the target, determine the achievement of the task event.

[0064] The compliance calculation in steps S162-S163 is a crucial step in this patent, relating to the compliance result and customer experience, ultimately affecting the effectiveness of marketing activities. The specific logic for batch processing compliance determination is as follows: Figure 8 As shown, the detailed steps are as follows: 1) Obtain all pending tasks for the day and associate them with the list of pending metrics. If the calculation date of a metric for a task is greater than or equal to the task's pending judgment date, the task is marked as a "metric ready task" and can be included in the current judgment batch; otherwise, it will be treated as an "unready task" and will not be processed temporarily.

[0065] 2) For all ready tasks participating in the current judgment, update their current judgment date to the smaller of the "maximum allowed judgment date" and the "indicator data date", and regenerate the list of pending tasks for the current time accordingly.

[0066] 3) Check if the updated list of pending tasks is empty. If not empty, proceed to step 4; if empty, proceed to step 7.

[0067] 4) Extract up to N tasks from the pending list (the value of N is dynamically determined based on the computing resources allocated by the system) to form an execution batch.

[0068] 5) Perform compliance calculation for this batch of tasks: First, based on the "internal threshold" and "internal judgment symbol" in the task configuration table, perform "internal compliance calculation" for each indicator for each customer.

[0069] 6) Subsequently, the achievement results of each indicator are used as input, and "inter-indicator achievement calculation" is performed according to the configured "inter-indicator aggregation type" (such as COUNT or SUM) to obtain the final judgment result of the entire task event.

[0070] 7) Write the compliance results of this batch into a temporary table.

[0071] 8) Update the status of these N tasks in the pending list: If the "maximum pending date" of a task is the same as the current "pending date", update the task status to "completed"; otherwise, increase its pending date by 1 day and reset the task status to "incomplete". After completion, the process returns to step 3) and loops.

[0072] 9) Once all tasks in the pending list have been processed, the current target calculation ends, and the system will synchronously load the final judgment result from the temporary table into the online database for use by the front-end business system.

[0073] It is important to emphasize that indicator calculation and target achievement calculation are two fundamentally different data processing tasks. Indicator calculation directly deals with diverse raw business data (such as transaction tables), with varying data sources and generation logics. Therefore, multiple general-purpose jobs are needed to generate indicator tables in parallel. Target achievement calculation, on the other hand, uses fixed, pre-calculated indicator tables as its data source, with relatively uniform logic. Therefore, this solution employs a single, timed job for batch calculation. In one embodiment, data synchronization from the online database to the batch database can be completed around 1:00 AM, while indicator calculation starts around 2:00 AM. Target achievement calculation begins immediately after the completion of the indicator calculations it depends on, and thereafter executes periodically every 4 hours. This time interval can be flexibly adjusted between 3 and 6 hours based on actual business load and performance requirements to ensure timely and accurate results feedback for marketing campaigns.

[0074] In summary, this invention aims to design a simplified, flexibly configurable, and easily reusable business metrics calculation scheme for batch marketing task achievement calculation, while reducing computational resource waste. In addition to the technical effects already described, the advantages of this patented technical solution also include: 1. Support for complex judgment logic. This solution breaks through the limitations of traditional single-indicator judgment, enabling marketing tasks to be bound to multiple target indicators. It also allows for flexible configuration of complex judgment relationships such as "AND," "OR," "summation," and "counting" through the "task configuration table," such as "both indicator A and indicator B must meet the target," "either indicator A or indicator B only needs to meet the target," or "the sum of indicator A and indicator B must meet the target," providing a solid technical foundation for achieving precise and personalized marketing strategies.

[0075] 2. Intelligent Task Scheduling and Execution Efficiency. In the backend processing architecture, the solution designs "Indicator Calculation" and "Achievement Calculation" as two independent and ordered stages. Indicator Calculation, as the data preparation stage, generates or updates data in the "Indicator Table" from various source data tables according to the definitions in the "Indicator Configuration Table." Due to the diversity and complexity of the source data, this stage relies on multiple general-purpose jobs executed in parallel. "Achievement Calculation," on the other hand, uses a stable and unified "Indicator Table" as its data source. Its logic is relatively standardized, so it can be processed in batches using a single scheduled job. This separation design ensures the overall efficiency and stability of the processing.

[0076] 3. Flexible Aggregation Strategies and Business Adaptability. The solution supports dynamic selection of aggregation types through configuration, providing a rich selection of strategies for task achievement determination. For example, event-based metrics can use COUNT or SUM, while status-based metrics may involve operations such as status merging. Through this configurable approach, the system is freed from dependence on fixed aggregation logic, enabling flexible adaptation to various novel business models that may emerge in the future, demonstrating excellent foresight and scalability.

[0077] 4. Delayed Data Processing and Computational Economy. To address tasks that may be unable to be processed for several consecutive days due to data delays in actual business operations, the solution incorporates a data merging and calculation mechanism upon data arrival. This avoids repetitive and ineffective calculations on incomplete data daily. Although the amount of data processed per cycle may increase due to merging, the overall computational complexity and system load do not increase linearly due to the use of efficient batch processing algorithms. This ensures efficient utilization of computing resources while maintaining the accuracy of the results.

[0078] On the other hand, the present invention also provides a task event compliance determination system 200, such as... Figure 9 The device may include: an indicator pool construction device 210 for constructing an indicator pool, including multiple pre-set indicators; an indicator acquisition device 220 for selecting pre-set indicators and / or creating new indicators as target indicators from the indicator pool according to business needs; a parameterization configuration device 230 for parameterizing the achievement conditions of the target indicators to generate task events; and a achievement determination device 240 for determining the achievement of the task events based on the achievement status of the target indicators.

[0079] Other beneficial effects of the task event compliance determination system 200 of the present invention can be found in the above description of the task event compliance determination method 100, and will not be repeated here.

[0080] This invention also provides a machine-readable storage medium storing instructions for causing a machine to execute: a method for determining the achievement of a task event as described above.

[0081] This invention provides a processor for running a program, wherein the program is executed to perform: a method for determining the achievement of task events as described above.

[0082] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 10As shown in the figure, the computer device may include a processor A01, a network interface A02, a display screen A04, an input device A05, and a memory (not shown) connected via a system bus. The processor A01 provides computing and control capabilities. The memory may include internal memory A03 and a non-volatile storage medium A06. The non-volatile storage medium A06 stores an operating system B01 and a computer program B02. The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 stored in the non-volatile storage medium A06. The network interface A02 is used for communication with external terminals via a network connection. When the computer program is executed by the processor A01, it implements the task event compliance determination method described above. The display screen A04 may be a liquid crystal display (LCD) or an e-ink display. The input device A05 may be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0083] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0084] In one embodiment, the task event compliance determination method provided in this application can be implemented as a computer program, which can be implemented in various ways, such as... Figure 10 The method runs on the computer device shown. The computer device's memory can store various program modules that constitute the compliance determination method for the task event. The computer program, composed of the various program modules, causes the processor to execute the various steps in the compliance determination method for the task event of the various embodiments of this application described in this specification.

[0085] In one embodiment, this application also provides a computer program product that, when executed on a data processing device, is adapted to execute a program that initializes the various steps of the above-described method.

[0086] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0087] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0088] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0089] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The functional steps specified in one or more boxes.

[0090] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0091] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, like read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0092] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0093] 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, they do not mean that the applicant has used or necessarily used the solution.

[0094] It should also be noted that 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 process, method, article, or apparatus. Unless otherwise specified, 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.

[0095] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for determining the compliance of a task event, characterized in that, The determination method includes: Build an indicator pool, including multiple pre-set indicators; Based on business needs, select pre-set indicators from the indicator pool and / or create new indicators as target indicators; The conditions for achieving the target metric are parameterized to generate task events; and Based on the achievement of the target indicators, the task event is judged to have met the target.

2. The determination method according to claim 1, characterized in that, The creation of new indicators includes both indicator creation and indicator derivation. The process for creating and releasing a new indicator includes indicator development, indicator testing, and indicator release. The release process derived from the indicator includes indicator release.

3. The determination method according to claim 1, characterized in that, The step of determining whether the task event has met the target indicators includes: Based on the list of tasks to be processed generated at a set time point, a list of metrics to be processed is generated. Based on the completed data and the achievement conditions of the target indicators in the list of indicators to be processed, the completion status of the target indicators is determined; and Based on the completion status, the task event is judged to have met the target.

4. The determination method according to claim 1, characterized in that, The target indicators are multiple, and the determination method further includes: The achievement conditions for multiple target indicators are parameterized and aggregation rules are configured to generate the task events; and The task event is judged to have met the target based on the achievement of each target indicator and the aggregation conditions for the achievement of multiple target indicators.

5. The determination method according to claim 4, characterized in that, The step of determining the achievement of the task event based on the achievement status of each target indicator and the achievement aggregation conditions among the multiple target indicators includes: Based on the list of tasks to be processed generated at a set time point, a list of metrics to be processed is generated. Based on the completed data and the achievement conditions of each target indicator in the list of indicators to be processed, the completion status of the multiple target indicators is determined; and The task event is judged to have met the target based on the completion indicators of the multiple target indicators and the aggregation conditions for achieving the target.

6. The determination method according to claim 4, characterized in that, The parameterized configuration includes configuring one or more of the following compliance thresholds: intra-indicator threshold value, inter-indicator threshold value, intra-indicator decision symbol, inter-indicator decision symbol, and / or The aggregation rule configuration includes configuring one or more of the following metric aggregation types: intra-metric aggregation type and inter-metric aggregation type.

7. The determination method according to claim 1, characterized in that, The data structure of the target indicator includes one or more of the following fields: indicator number, indicator category, indicator date, customer number, frequency statistics, amount statistics, and indicator value.

8. The determination method according to claim 1, characterized in that, The data structure of the indicator configuration table in the indicator pool includes one or more of the following fields: indicator number, indicator category, processing SQL, date offset, indicator source, indicator name, indicator parameters, indicator description, and dependent data table list.

9. A system for determining the achievement of a task event, characterized in that, The determination system includes: An indicator pool construction device is used to construct an indicator pool, which includes multiple pre-set indicators. The indicator acquisition device is used to select pre-set indicators and / or create new indicators as target indicators from the indicator pool according to business needs. A parameterized configuration device is used to parameterize the achievement conditions of the target indicator to generate task events; and The achievement determination device is used to determine the achievement of the task event based on the achievement of the target indicators.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores instructions for causing the machine to execute: a method for determining the compliance of a task event according to any one of claims 1-8.

11. A processor, characterized in that, Used to run a program, wherein the program is run to execute: a method for determining the compliance of a task event according to any one of claims 1-8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements: the method for determining the compliance of task events according to any one of claims 1-8.

Images