Real-time route switching method and device based on multi-rule decision engine

Abstract

The application discloses a kind of real-time routing switching method and device based on multi-rule decision engine.The method is calculated by the real-time feedback data of the combined node collected, and the investment return rate of each node is obtained;Through routing decision engine, according to the investment return rate, the pre-defined multi-dimensional performance evaluation and decision rule is executed, and the performance of the combined node is evaluated and compared, and the routing switching decision is generated;During marketing activity, according to the routing switching decision, the routing switching between suppliers or strategies is executed;The routing switching decision and the corresponding execution effect are recorded to the strategy effect knowledge base.The application can achieve the technical effect of automatically switching data from inefficient suppliers or strategies to efficient suppliers or strategies by monitoring ROI data in real time.

Description

Technical Field

[0001] This invention relates to the field of computer technology applications, and in particular to a real-time routing switching method and apparatus based on a multi-rule decision engine. Background Technology

[0002] In current large-scale campaigns such as telemarketing and SMS marketing, businesses typically rely on multiple vendors to execute marketing tasks. Before the campaign begins, operations personnel will allocate appropriate vendors and initial data volumes for different marketing strategies based on historical experience.

[0003] However, the marketing environment is dynamic and constantly changing. During an event, many factors can cause pre-planned strategies to fail: for example, the quality of a supplier's channel may suddenly drop; the effectiveness of a marketing strategy for a specific customer group may rapidly diminish; or a supplier may experience queuing due to concurrency limitations, while another supplier is idle and efficient.

[0004] Existing technologies typically employ a batch-by-batch or day-by-day approach to evaluate effectiveness, followed by strategy adjustments for the next day. This approach has a long response cycle, cannot provide real-time intervention for negative effects during the campaign, and results in significant budget waste and opportunity costs.

[0005] There is currently no effective solution to the problems of resource waste and inefficiency caused by the rigidity and slow response of the marketing campaign process in existing technologies. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention aims to provide a real-time routing switching method and apparatus based on a multi-rule decision engine, thereby at least resolving the resource waste and inefficiency caused by the rigidity and sluggish response of the marketing campaign process in the prior art.

[0007] The technical solution of this invention is implemented as follows: This invention provides a real-time routing switching method based on a multi-rule decision engine, comprising: calculating the return on investment (ROI) of each node based on real-time feedback data collected from the combined nodes; using the routing decision engine to perform performance evaluation and comparison of the combined nodes based on the ROI, generating a routing switching decision; executing routing switching between suppliers or strategies during a marketing campaign, based on the routing switching decision; and recording the routing switching decision and its corresponding execution effect in a strategy effect knowledge base.

[0008] Optionally, the return on investment (ROI) of each node can be calculated based on the real-time feedback data collected from the combined nodes. This includes: continuously collecting real-time feedback data from all executing combined nodes, where the real-time feedback data includes cost data and business revenue data; performing real-time calculations based on the cost data and business revenue data to obtain the calculation results; updating the instantaneous ROI and cumulative ROI of each node based on the results; and obtaining the ROI of each node based on the instantaneous ROI and cumulative ROI of the period.

[0009] Optionally, predefined multi-dimensional performance evaluation and decision-making rules include: performance degradation judgment logic based on absolute thresholds, performance superiority judgment logic based on relative comparisons, and capacity replenishment judgment logic based on system resource utilization.

[0010] Furthermore, optionally, the performance degradation judgment logic based on absolute thresholds includes: setting a minimum acceptable rate of return warning threshold for each strategy, and triggering a switching action when the cumulative rate of return of the current execution node is detected to be lower than the corresponding rate of return warning threshold.

[0011] Optionally, the performance evaluation logic based on relative comparison includes: for multiple supplier nodes serving the same strategy, continuously compare the cumulative return on investment of multiple supplier nodes, and when it is found that the cumulative return on investment of a supplier node is higher than that of the current node, trigger the switching action to the better node.

[0012] Optionally, the capacity replenishment judgment logic based on system resource utilization includes: monitoring the real-time load status of each supplier node, and when it is found that a node with high return on investment has remaining processing capacity and other nodes have data backlog, triggering the action of switching the backlog data to a node with high return on investment and idle capacity.

[0013] Optionally, the routing switch between vendors or policies can include: a mechanism to ensure that data is not lost or duplicated, a state synchronization mechanism, and an exception handling strategy.

[0014] Further, optional, data loss and duplication prevention mechanisms include: before initiating a switchover command, marking the batch of data to be migrated as being in a switchover state on the source node and atomically pausing data allocation for the batch; submitting the data batch information marked as being in a switchover state to the target node as a transaction unit, and only updating the data status of the source node to switched over after the target node confirms successful receipt; each piece of data to be marketed has a globally unique identifier, and the target node checks the globally unique identifier when processing data to ensure idempotency control; exception handling strategies include: when a switchover failure occurs, recording a failure log and retrying according to the configured settings. The strategy automatically retryes at a later time or escalates to an alarm notification for manual intervention; when a supplier failure occurs, the heartbeat or interface availability of the supplier node is continuously monitored; when a failure is detected, the ROI of all combinations of supplier nodes is forced to the minimum value or marked as unavailable, triggering the absolute threshold rule to switch the data in the queue to other healthy nodes; when a network interruption occurs, asynchronous acknowledgment and local persistent queues are used when sending data to the supplier; if the network interruption causes the transmission to fail, the data is retained in the local persistent queue and will be automatically resumed after the network is restored; and, network interruption is regarded as supplier abnormality, triggering the failover logic.

[0015] Optionally, the routing switch between suppliers or between strategies also includes: supplier switching and strategy switching; wherein, supplier switching includes: when a specific amount of data is initially allocated to the first supplier, if real-time monitoring finds that the return on investment of some data executed by the first supplier does not meet business needs, and the return on investment of the second supplier under the current strategy is higher than that of the first supplier, then the subsequent data is suspended from being sent to the first supplier, and the remaining data is rerouted to the second supplier; strategy switching includes: when it is found that the return on investment of the first strategy is trending downward, and the return on investment of the second strategy for similar customer groups is steadily increasing, then the newly arrived data or data already in the queue is migrated from the first strategy to the best supplier corresponding to the second strategy.

[0016] This invention provides a real-time routing switching device based on a multi-rule decision engine, comprising: a calculation module for calculating the return on investment (ROI) of each node based on real-time feedback data collected from the combined nodes; a decision generation module for evaluating and comparing the combined nodes based on the ROI using the routing decision engine and executing predefined multi-dimensional performance evaluation and decision rules to generate routing switching decisions; a routing switching module for executing routing switching between suppliers or strategies during marketing activities based on the routing switching decisions; and a storage module for recording the routing switching decisions and corresponding execution effects in a strategy effect knowledge base.

[0017] This invention provides a real-time routing switching method and apparatus based on a multi-rule decision engine. It calculates the return on investment (ROI) of each node based on real-time feedback data collected from the combined nodes. The routing decision engine then executes predefined multi-dimensional performance evaluation and decision rules based on the ROI to evaluate and compare the combined nodes, generating routing switching decisions. During marketing activities, routing switching between suppliers or strategies is executed according to the routing switching decisions. The routing switching decisions and their corresponding execution effects are recorded in a strategy performance knowledge base, thereby achieving the technical effect of automatically switching data from inefficient suppliers or strategies to efficient ones by monitoring ROI data in real time. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings: Figure 1 A flowchart illustrating a real-time routing switching method based on a multi-rule decision engine, provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the data processing flow in a real-time routing switching method based on a multi-rule decision engine provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a real-time routing switching device based on a multi-rule decision engine, provided in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish different objects, rather than to limit a specific order.

[0021] It should also be noted that the various embodiments of the present invention described below can be executed individually or in combination with each other, and the embodiments of the present invention do not impose specific limitations in this regard.

[0022] Technical terms used in the embodiments of this application: ROI (Return on Investment): In this embodiment of the application, it specifically refers to the ratio of input costs to revenue generated in marketing activities. It is a core indicator for measuring the effectiveness of marketing strategies and suppliers.

[0023] Suppliers: refers to entities that provide marketing execution services, such as AI outbound call providers and SMS channel service providers.

[0024] Strategy: refers to a set of marketing rules designed for a specific customer group, product, or channel, including but not limited to the wording, timing, and frequency of outreach.

[0025] Routing: refers to the process of allocating and sending marketing data (such as customer lists) to specific suppliers to carry out marketing actions.

[0026] Routing decision engine: The core processing module in this invention automatically makes supplier and strategy selection decisions based on preset rules and real-time ROI data.

[0027] This invention provides a real-time routing switching method based on a multi-rule decision engine. Figure 1 A flowchart illustrating a real-time routing switching method based on a multi-rule decision engine provided in an embodiment of the present invention; as shown below. Figure 1 As shown in the embodiments of this application, the real-time routing switching method based on a multi-rule decision engine includes: Step S102: Calculate the return on investment for each node based on the real-time feedback data collected from the combined nodes. Optionally, the calculation of the return on investment (ROI) of each node based on the collected real-time feedback data of the combined nodes in step S102 includes: continuously collecting real-time feedback data from all executing combined nodes, wherein the real-time feedback data includes cost data and business revenue data; performing real-time calculations based on the cost data and business revenue data to obtain calculation results; updating the instantaneous ROI and the cumulative ROI of each node based on the results; and obtaining the ROI of each node based on the instantaneous ROI and the cumulative ROI of the period.

[0028] Specifically, Figure 2 This is a schematic diagram of the data processing flow in a real-time routing switching method based on a multi-rule decision engine provided in an embodiment of the present invention; as shown below. Figure 2 As shown, in the implementation of this application, real-time feedback data is continuously collected from all executing "strategy-vendor" combination nodes (i.e., combination nodes in the embodiments of this application), including cost data and business revenue data; wherein, cost data includes: call duration and number of SMS messages; business revenue data includes: connection, order completion, and credit granting.

[0029] Based on cost data and business revenue data, the instantaneous ROI and cumulative ROI of each node are calculated and updated in real time (i.e., the instantaneous return on investment and the cumulative return on investment in this embodiment of the application).

[0030] In this embodiment of the application, the calculation based on the real-time feedback data of the collected combination nodes includes: dynamically calculating the instantaneous and cumulative return on investment (ROI) of each "strategy-supplier" combination node by continuously summarizing the cost and revenue vector of each "strategy-supplier" combination node within a unit of time.

[0031] Step S104: Based on the return on investment, the routing decision engine executes predefined multi-dimensional performance evaluation and decision rules to evaluate and compare the performance of the combined nodes and generate a routing switching decision. Optionally, predefined multi-dimensional performance evaluation and decision-making rules include: performance degradation judgment logic based on absolute thresholds, performance superiority judgment logic based on relative comparisons, and capacity replenishment judgment logic based on system resource utilization.

[0032] Specifically, such as Figure 2 As shown, in this embodiment of the application, the routing decision engine receives the real-time ROI data stream generated in step S102, that is, the ROI including instantaneous ROI and cumulative ROI over a period of time.

[0033] The routing decision engine has a built-in and executes a set of predefined multi-dimensional performance evaluation and decision rules. This set of rules, based on business logic, is used to evaluate and compare the performance of each "policy-vendor" combination node in real time and output routing switching decisions. The core evaluation dimensions and decision logic include: In this embodiment, the routing decision engine runs multiple sets of evaluation logic simultaneously. First, it performs a performance baseline protection check, determining whether the current node's ROI has fallen below a preset threshold. Second, it performs a selective migration check, searching for nodes with significantly higher ROI and the same strategy. Finally, it performs global efficiency optimization, checking whether high-ROI nodes have the idle capacity to process the backlog of data from other nodes. These logics are computed in parallel, generating their respective switching trigger signals and candidate suggestions. The specific logics for performance degradation judgment based on absolute thresholds, performance superiority judgment based on relative comparison, and capacity replenishment judgment based on system resource utilization in the multi-dimensional performance evaluation and decision-making rules of this application are as follows: Optionally, the performance degradation judgment logic based on absolute thresholds includes: setting a minimum acceptable rate of return warning threshold for each strategy, and triggering a switching action when the cumulative rate of return of the current execution node is detected to be lower than the corresponding rate of return warning threshold.

[0034] Specifically, in this embodiment, the performance degradation judgment logic based on absolute thresholds can be as follows: a minimum acceptable return on investment (ROI) warning threshold is set for each strategy. When the routing decision engine detects that the cumulative ROI of the current execution node is lower than its corresponding warning threshold, it determines that the performance of the execution node is substandard, triggers a switching action, and finds a replacement from the currently qualified nodes.

[0035] Optionally, the performance evaluation logic based on relative comparison includes: for multiple supplier nodes serving the same strategy, continuously compare the cumulative return on investment of multiple supplier nodes, and when it is found that the cumulative return on investment of a supplier node is higher than that of the current node, trigger the switching action to the better node.

[0036] Specifically, in this embodiment, the performance evaluation logic based on relative comparison can be as follows: For multiple supplier nodes serving the same strategy, the routing decision engine continuously compares the cumulative ROI of the multiple supplier nodes. When it is found that the cumulative ROI of another supplier node is significantly higher than (for example, exceeding a set lag tolerance value) the current node, the current node is determined to be non-optimal, triggering a switch to a better node in order to maximize revenue.

[0037] Optionally, the capacity replenishment judgment logic based on system resource utilization includes: monitoring the real-time load status of each supplier node, and when it is found that a node with high return on investment has remaining processing capacity and other nodes have data backlog, triggering the action of switching the backlog data to a node with high return on investment and idle capacity.

[0038] Specifically, in this embodiment, the capacity replenishment judgment logic based on system resource utilization can be as follows: while monitoring performance indicators, the routing decision engine also monitors the real-time load status of each supplier node (such as data processing queue length and throughput). When it is found that a high ROI node has remaining processing capacity, while other nodes have data backlog, even if the latter's performance has not reached the absolute threshold, it can trigger the action of switching the backlogged data to a high ROI node with idle capacity, so as to optimize the overall capacity and efficiency of the system.

[0039] In this embodiment of the application, during the decision integration and execution process: when multiple logics are triggered, the system makes a decision according to a preset priority (e.g., "bottom-line protection" takes precedence over "optimal migration"). Finally, from the candidate nodes, the optimal target is selected based on a weighted scoring function that integrates ROI, real-time load, and response speed. A switching instruction is generated, and the system atomically pauses the original data stream and redirects the data to be processed to the new target node.

[0040] Step S106: During the marketing campaign, perform routing switching between suppliers or between strategies based on the routing switching decision; Optionally, the routing switch between suppliers or policies performed in step S106 includes: a mechanism to ensure that data is not lost or duplicated, a state synchronization mechanism, and an exception handling strategy.

[0041] Further, optional, data loss and duplication prevention mechanisms include: before initiating a switchover command, marking the batch of data to be migrated as being in a switchover state on the source node and atomically pausing data allocation for the batch; submitting the data batch information marked as being in a switchover state to the target node as a transaction unit, and only updating the data status of the source node to switched over after the target node confirms successful receipt; each piece of data to be marketed has a globally unique identifier, and the target node checks the globally unique identifier when processing data to ensure idempotency control; exception handling strategies include: when a switchover failure occurs, recording a failure log and retrying according to the configured settings. The strategy automatically retryes at a later time or escalates to an alarm notification for manual intervention; when a supplier failure occurs, the heartbeat or interface availability of the supplier node is continuously monitored; when a failure is detected, the ROI of all combinations of supplier nodes is forced to the minimum value or marked as unavailable, triggering the absolute threshold rule to switch the data in the queue to other healthy nodes; when a network interruption occurs, asynchronous acknowledgment and local persistent queues are used when sending data to the supplier; if the network interruption causes the transmission to fail, the data is retained in the local persistent queue and will be automatically resumed after the network is restored; and, network interruption is regarded as supplier abnormality, triggering the failover logic.

[0042] Optionally, step S106, which involves switching between suppliers or strategies, further includes: switching between suppliers and switching between strategies. The switching between suppliers includes: when a specific amount of data is initially allocated to the first supplier, if real-time monitoring reveals that the return on investment (ROI) of some data already executed by the first supplier does not meet business needs, and the ROI of the second supplier under the current strategy is higher than that of the first supplier, then the sending of subsequent data to the first supplier is suspended, and the remaining data is rerouted to the second supplier. The switching between strategies includes: when it is found that the ROI of the first strategy is trending downwards, and the ROI of the second strategy targeting similar customer groups is steadily increasing, then newly added data or data already in the queue is migrated from the first strategy to the best supplier corresponding to the second strategy.

[0043] Specifically, such as Figure 2 As shown, in this embodiment of the application, based on the routing switching decision obtained in step S104, the switching instruction is automatically executed during the marketing campaign: In this application embodiment, performing routing switching between suppliers or policies includes three cases: Scenario 1: Switching between suppliers: Scenario: Initially, 100,000 data entries (i.e., a specific volume of data in this embodiment) are allocated to supplier A (i.e., the first supplier in this embodiment). Real-time monitoring reveals that the ROI of the 5,000 data entries already processed (i.e., a portion of the data in this embodiment) is poor, while supplier B (i.e., the second supplier in this embodiment) has a higher ROI under the current strategy.

[0044] Action: The system immediately suspends sending subsequent data to supplier A and automatically and seamlessly reroutes the remaining 95,000 data entries (i.e., the remaining data in this embodiment) to supplier B.

[0045] Scenario 2: Switching between strategies: Scenario: The system detects that the ROI of strategy X (i.e., the first strategy in this application embodiment) is trending downward, while the ROI of strategy Y (i.e., the second strategy in this application embodiment) targeting similar customer groups is steadily increasing.

[0046] Action: The system automatically migrates new data or data already in the queue from strategy X to the best supplier corresponding to strategy Y.

[0047] Scenario 3: Reliability assurance and anomaly handling mechanisms during handover: Data loss and duplication prevention mechanisms: Status marking and atomic operations: Before initiating a switchover command, the system first marks the batch of data to be migrated as "switching in progress" on the source node and atomically suspends the allocation of the batch of data.

[0048] Transactional transfer: The data routing control module submits the marked data batch information as a complete transaction unit to the target node. Only after the target node confirms receipt and returns a success response will the system update the source node's data status to "switched over" and clear the "switching over" flag. If the target node fails to receive the data, the transaction is rolled back, the "switching over" flag on the source node is removed, and the data is restored to the "pending allocation" state, which can be retried or handled by other mechanisms.

[0049] Unique Identifier and Idempotency: Each piece of data to be marketed has a globally unique identifier. When processing data, the target node checks this identifier to ensure that data with the same identifier will not have its marketing actions executed repeatedly, thus achieving idempotency control.

[0050] State synchronization mechanism: State synchronization before switching: The switching instruction includes not only the data itself, but also the necessary context information (such as the strategy identifiers that have been tried for the customer group with this data, the number of historical interactions, etc.) to ensure that the target supplier or strategy can continue to be executed based on the correct context.

[0051] Runtime state synchronization: The system maintains a global routing mapping table, recording in real time the correspondence between each data batch and the current execution node (policy-vendor combination). Any switching operation will synchronously update this mapping table, ensuring that all query components (such as monitoring and billing) are in sync. Figure 1 To.

[0052] Exception handling strategy: Switchover failure: As mentioned above, a transaction rollback mechanism is used. The system will record the failure log and automatically retry at a later time according to the configured retry strategy (such as interval retry, exponential backoff), or escalate to an alarm notification for manual intervention.

[0053] Supplier failure: The real-time data acquisition module continuously monitors the "heartbeat" or interface availability of supplier nodes. Once a failure is detected, the ROI of all "policy-supplier" combinations of that node is immediately forced to the minimum value or marked as unavailable, thereby triggering the absolute threshold rule and quickly switching the data in its queue to other healthy nodes.

[0054] Network interruption: When sending data to the provider, the system uses asynchronous acknowledgments and a local persistent queue. If a network interruption causes a transmission failure, the data will be retained in the local persistent queue and automatically resumed once the network is restored. Simultaneously, network interruption is considered a provider anomaly and will also trigger failover logic.

[0055] In this embodiment, the effect of each switch is quantitatively evaluated (e.g., ROI improvement) and used to adjust system parameters (e.g., threshold, lag value, scoring weight). Optimization methods such as gradient descent are used to self-adjust the system behavior towards improving the overall success rate. All decisions and results are structured and stored, forming a knowledge base for analysis and providing a data foundation for potential derivative strategies.

[0056] Step S108: Record the routing switching decision and the corresponding execution effect to the strategy effect knowledge base.

[0057] Specifically, such as Figure 2 As shown, all routing decisions, switching actions, and their subsequent effects (such as the improvement in ROI after switching) are recorded in the strategy effect knowledge base. This strategy effect knowledge base is used to verify and optimize the effectiveness of decision rules and to provide a data foundation for automatically generating better strategies through machine learning algorithms in the future, thereby enabling the system to self-evolve.

[0058] The data structure design of the strategy effect knowledge base in this embodiment is as follows: The strategy effectiveness knowledge base is implemented using a relational database, with its core function being to record information across the entire decision-making process. In a preferred example, the relational table structure design includes: Decision Record Table: Stores the core information of each switching decision. Fields include: Decision ID, Timestamp, Source Strategy ID, Source Supplier ID, Target Supplier ID, Trigger Rule Identifier, Switching Data Volume, Cumulative ROI before Switching, Cumulative ROI after Switching (to be updated later), and Effect Improvement ΔROI.

[0059] Rule Performance Table: Aggregates statistical performance by rule type. Fields include: rule identifier, number of triggers, average ΔROI, and success rate (defined as the percentage of decision that improves ROI after switching), used to evaluate the effectiveness of each rule.

[0060] Strategy-Supplier Performance Wide Table: Records multiple features of each combination in time series, including conversion rate, cost, response speed, load, etc., in addition to ROI, as a training feature pool for machine learning models.

[0061] The specific integration and evolution of the machine learning model in this embodiment are as follows: Training Process: Historical decision records and a strategy-supplier performance wide table are used as data sources. The effect (ΔROI) of a single switching decision and its subsequent period (e.g., 1 hour) is treated as a sample. Feature engineering may include: the difference in ROI before and after the switch, the load of each node, time periods, customer attribute encoding, and one-hot encoding of trigger rule combinations. The training objective of the model (e.g., Gradient Boosting Decision Tree (GBDT) or Deep Neural Network (DNN) is to predict the potential ROI improvement from a single switching action.

[0062] Model Application and Evaluation: The trained model can be integrated into the routing decision engine as a new and more complex evaluation dimension. After the rule is triggered and a list of candidate suppliers is generated, the model can be used to rank the predicted improvement scores of each candidate to assist in the final selection. Model evaluation methods include: calculating the mean squared error (MSE) between the predicted ΔROI and the actual ΔROI on historical data; and using AUC to evaluate the model's ability to distinguish between "high-benefit switching" and "low-benefit switching." The model is retrained periodically (e.g., daily) using the latest data to achieve continuous policy evolution.

[0063] In summary, combining steps S102 to S108, the real-time route switching method based on a multi-rule decision engine provided in this application embodiment is as follows in a preferred example: The real-time routing switching method based on a multi-rule decision engine provided in this application is described in a formulaic process: Step 1. System Input and Basic Definitions: Strategy set: S = {s1, s2, ..., s} n}; Supplier set: V = {v1, v2, ..., v m}; Time window: T = {t0, t1, ..., t k (Discrete time points); Step 2. Real-time data acquisition and feature calculation: Among them, the cost feature vector is: For each strategy-supplier combination node (s i , v j At time t: Cost ij (t) = [c1, c2, c3, ...]; in: c1 = Unit outbound call cost × Number of outbound calls; c2 = SMS channel cost × Number of messages sent; c3 = Cost of human agents × Service duration; ... Profit feature vector: Revenue ij (t) = [r1, r2, r3, ...]; in: r1 = Connection rate × Customer value; r2 = Conversion rate × Average order value; r3 = Credit approval rate × Average credit limit; ... Real-time ROI calculation: Instantaneous ROI (current time window): ROI_instant ij (t) = (ΣRevenue ij (t) - ΣCost ij (t)) / ΣCost ij (t); Cumulative ROI (since the start of the campaign): ROI_cumulative ij (t) = (Σ_{τ=t0}^{t} Revenue ij (τ) - Σ_{τ=t0}^{t} Cost ij (τ)) / Σ_{τ=t0}^{t} Cost ij (τ).

[0064] Step 3. Routing Decision Engine: Parallel Evaluation of Multiple Rules Rule 1: Absolute threshold judgment if ROI_cumulative ij (t)<θ_threshold i then Trigger_Switch = TRUE Switch_Reason = "Absolute threshold trigger" Candidate_Suppliers = {v k | ROI_cumulative ik (t) ≥ θ_threshold i} Where θ_threshold i For strategy s i The lowest acceptable ROI.

[0065] Rule 1 in this embodiment describes the core algorithm of the "performance degradation judgment logic based on absolute threshold" in the routing decision engine, and its specific meaning is as follows: Triggering condition: When the system detects a currently executing policy-vendor combination (policy s) i Supplier v j The cumulative return on investment (ROI) over time t. ij (t) is lower than the minimum acceptable rate of return threshold (θ_threshold) preset for this strategy. i When ), the condition is met.

[0066] The specific actions to be performed include the following: Trigger Switch: Set the switch trigger flag (Trigger_Switch) to "TRUE" to indicate that a route switch needs to be performed immediately.

[0067] Record the reason: Mark the switching reason (Switch_Reason) as "absolute threshold trigger" for easy subsequent analysis and auditing.

[0068] Generate a candidate set: The system automatically filters candidates from all suppliers under the same strategy. i The current cumulative return on investment is still not lower than the threshold θ_threshold i The suppliers in this set constitute a candidate supplier set (Candidate_Suppliers). The suppliers in this set are the alternative targets that currently meet the performance requirements and are available for switching.

[0069] Ultimately, the logical purpose of Rule 1 is as follows: Rule 1 is the system's "bottom-line protection" mechanism, which aims to identify and interrupt the consumption of marketing resources that have fallen below the acceptable level in real time (intelligent loss prevention), and automatically guide subsequent data traffic to suppliers that still maintain the standard performance under the same strategy, thereby preventing the continuous waste of budget at inefficient nodes.

[0070] Rule 2: Judgment of Relative Advantage if v k ∈ V, such that: ROI_cumulative ik (t)>ROI_cumulative ij (t) + Hysteresis then Trigger_Switch = TRUE Switch_Reason = "Relative Advantage Trigger" Best_Supplier = argmax_{v k ROI_cumulative ik (t) Hysteresis is the hysteresis tolerance value, which prevents frequent switching.

[0071] Rule 2 in this application embodiment is a core algorithm description of the "performance superiority judgment logic based on relative comparison" in the routing decision engine, and its meaning is as follows: Triggering condition: When the system detects that, under the same policy s i Under these circumstances, there exists at least one other supplier v k Its cumulative return on investment (ROI_cumulative) over time t ik (t) is significantly higher than the current supplier v j Cumulative Return on Investment (ROI) ij When (t)), the condition is met.

[0072] The term "significantly higher" here is defined by a technical parameter called Hysteresis (hysteresis tolerance), meaning it must exceed the current value plus this tolerance value. The purpose of Hysteresis is to set up a switching buffer to prevent unnecessary frequent switching triggered by minor normal fluctuations or brief ups and downs in ROI data, thereby ensuring the stability of system decision-making and execution efficiency.

[0073] The actions to be performed include the following: Trigger Switch: Set the switch trigger flag (Trigger_Switch) to "TRUE".

[0074] Record the reason: Mark the switch reason (Switch_Reason) as "relative advantage trigger".

[0075] Determining the optimal objective: The system does not randomly select any better supplier, but rather uses the function argmax_{v k ROI_cumulative ik (t), automatically calculates and locks the current state under the same policy s i The supplier with the highest cumulative return on investment is selected and designated as the Best_Supplier. This ensures that each switch proceeds in the direction with the greatest known potential for return.

[0076] Ultimately, the logical purpose of Rule Two is to serve as a "profit maximization" mechanism for the system. Rule Two does not merely aim to reach the passing grade (absolute threshold), but rather proactively seeks out and switches to the best-performing supplier within the same strategy. Its technical effect lies in dynamically pursuing the most efficient resources, thereby continuously improving and optimizing the overall return on investment of the marketing campaign throughout the campaign cycle, maximizing system output.

[0077] Rule 3: Assessment of Capacity Supplementation if v k ∈ V, such that: ROI_cumulative ik (t) ≥ θ_threshold i and Load k (t) <Capacity k × γ and Queue_Length ij (t)>Queue_Threshold then Trigger_Switch = TRUE Switch_Reason = "Capacity replenishment triggered" Candidate_Suppliers = {v k | Meet the above conditions} in: Load k (t) = supplier v k Current load; Capacity k = Supplier v k Maximum processing capacity; γ = Capacity utilization threshold (e.g., 80%) Queue_Length ij (t) = Current strategy - Queued data volume of supplier combination.

[0078] Rule 3 in this embodiment is a core algorithm description of the "capacity replenishment judgment logic based on system resource utilization" in the routing decision engine. It aims to solve the overall system throughput and efficiency problems, and its meaning is as follows: Triggering condition: The condition is met when the system simultaneously detects the following three technical states: Condition 1, Performance Qualification Meets Standard: There is at least one other supplier v k In the current strategy s i Cumulative Return on Investment (ROI) ik (t) is still not lower than the minimum acceptable threshold (θ_threshold) of this strategy. i This ensures that the target switching itself is effective.

[0079] Condition 2, having available capacity: Meanwhile, the supplier v k Current real-time load k (t), such as the number of tasks being processed, is below its maximum processing capacity. k A preset percentage (γ, for example, 80%) is used to define a "available" state, ensuring that the target is capable of receiving new tasks.

[0080] Condition 3, current node backlog: and the currently executing strategy - supplier combination node (s i , v j There is a data processing backlog, and the amount of data waiting in the queue (Queue_Length) is... ij (t) exceeded a preset queue length threshold (Queue_Threshold).

[0081] The actions to be performed include the following: Trigger Switch: Set the switch trigger flag (Trigger_Switch) to "TRUE".

[0082] Record the reason: Mark the switch reason (Switch_Reason) as "Capacity replenishment triggered".

[0083] Candidate set generation: The system filters out all suppliers that simultaneously meet the above conditions of "performance targets met" and "having available capacity" to form a candidate supplier set (Candidate_Suppliers). Subsequently, the system can select the final switching target from this set based on a comprehensive score.

[0084] Ultimately, the logical purpose of Rule 3 is to act as a "global efficiency optimizer" for the system. It doesn't address the "good" or "bad" nature of individual nodes (that's the task of Rules 1 and 2), but rather the uneven utilization of system resources. Its technical effect is: Eliminating bottlenecks: When a node processes data slowly, causing data backlog (which may become a system bottleneck), the system will proactively divert the data even if its ROI is acceptable.

[0085] Improve overall throughput: By dynamically scheduling backlogged data to equally efficient (ROI-compliant) nodes that are under light load, the idle processing capacity of high-ROI suppliers is fully utilized.

[0086] Achieving load balancing: While ensuring marketing effectiveness (ROI), the task allocation of the entire system was optimized, reducing the overall waiting time of the task queue, thereby improving the execution speed of marketing activities and overall operational efficiency.

[0087] Step 4. Decision Integration and Supplier Selection: The rule priority and conflict resolution in this embodiment are as follows: If multiple rules are triggered simultaneously: Priority: Rule 1 > Rule 2 > Rule 3 Final decision = Output of the highest priority rule else if a single rule is triggered: Final decision = Output of the rule else: Maintain current route In this embodiment of the application, the optimal supplier selection function is: Selected_Supplier = argmax_{v ∈ Candidate_Suppliers} [ α × ROI_cumulative iv (t) + β × (1 - Load v (t) / Capacity v ) + γ × Response_Speed_Score v (t) ] Where α + β + γ = 1 is the weighting coefficient, which can be adjusted according to business objectives.

[0088] Step 5. Routing switch execution In this embodiment of the application, the switching instruction generation can specifically be as follows: Switch_Command = { "from_strategy": s i , "from_supplier": v j , "to_supplier": Selected_Supplier, "switch_reason": Switch_Reason, "data_volume": Remaining_Data ij (t), "timestamp": t } This application defines a data structure for a "SwitchCommand" generated by the routing decision engine during a switchover. A switchCommand is a structured instruction object containing all key information for a single routing switchover operation, used to drive and control subsequent switchover execution processes.

[0089] The specific meanings and functions are as follows: The components of an instruction (field meanings): "from_strategy": s i This means: Specify the source strategy involved in this switch. Identify which marketing strategy (e.g., Strategy X) the data will be removed from.

[0090] "from_supplier": v j This means: Specify the source vendor for this switch. Identify which vendor (e.g., vendor A) is currently processing the data.

[0091] "to_supplier": Selected_Supplier means: specify the target supplier for this switch. This is the new supplier (such as supplier B) to which the data will be routed, selected by the routing decision engine based on rules (such as absolute threshold, relative advantage, or capacity replenishment).

[0092] "switch_reason": Switch_Reason records the reason that triggered this switch. Its value is a string corresponding to the result of the aforementioned evaluation rule, such as "absolute threshold trigger," "relative advantage trigger," or "capacity replenishment trigger." This is crucial for system monitoring, effect analysis, and rule optimization.

[0093] "data_volume": Remaining_Data ij (t) means: specify the amount of data that needs to be switched. This is a quantitative technical parameter, usually referring to the amount of data currently in the source node (policy s). i Supplier v j The number of remaining data entries or batches that are queued for processing but have not yet been executed.

[0094] "timestamp": t means: record the precise timestamp of the command generation. Used for audit trails, status synchronization, and evaluating the timeliness of switching actions.

[0095] In this embodiment of the application, the core role of the switching instruction generation in the entire technical solution is that the structured Switch_Command serves as a technical bridge and carrier connecting the two core links of "decision-making" and "execution".

[0096] Encapsulation of decision results: This involves abstracting the decision conclusions output by the routing decision engine (a logic processing module) into a single, abstract structure ("strategy s"). i Supplier v j The remaining data, for some reason, was switched to the supplier Selected_Supplier, and transformed into a specific, explicit technical instruction that can be directly parsed and manipulated by downstream execution modules.

[0097] Ensuring atomicity and consistency of execution: The system performs "transactional transfers." The Switch_Command object itself can be considered a transaction descriptor. Based on this instruction, the execution module (control execution module) atomically executes a series of operations such as "pausing the source data stream, transferring the specified amount of data, and starting the target data stream," ensuring that the system state transitions from one consistent point to another.

[0098] Achieving status tracking and observability: This command contains complete contextual information. The system can record this information in logs or a knowledge base, enabling end-to-end traceability of every switchover action. Operations personnel or subsequent analysis modules can clearly know: when, why, and how much data was switched from whom to whom.

[0099] In summary, the process of generating switching instructions in this embodiment is not a computational logic, but rather the definition of a key data structure. This structure forms the technological foundation for the "execution" stage of "automatic closed-loop control," ensuring that decision-making intentions can be accurately, reliably, and auditably translated into actual system actions.

[0100] In the data flow control process described in this application embodiment: Pause the original route: Pause_Data_Flow(s i , v j ) Update_Queue_Status(s i , v j "PAUSED") Among them, Pause_Data_Flow(s) i , v j ) is a system call or control function that immediately stops the process from the source node (policy s). i Supplier v j This function sends out any new marketing data. After executing this function, the system will no longer retrieve data from the node's data queue and allocate it to supplier v. j Conduct marketing operations.

[0101] The goal is to achieve the key innovation of "pausing inefficient consumption" through specific technical means, which creates conditions for subsequent secure data transfer by proactively cutting off data flow at the software level.

[0102] Update_Queue_Status(s i , v j "PAUSED" is a state update operation that updates the source node (policy s). i Supplier v j The status flag in the system global routing map or internal queue manager is atomically updated to "PAUSED".

[0103] The goal is to ensure the consistency of the system state. Once the state is updated, all other system components that depend on this state (such as monitoring dashboards, billing modules, and other decision threads) will immediately "see" that the node has been paused, thereby preventing other modules (such as load balancers) from incorrectly assigning new tasks to the node during the switchover process; and providing a clear initial state basis for subsequent "transactional transfers".

[0104] In the embodiments of this application, this constitutes the "first half" of the handover operation, namely, an atomic pause. Together with the subsequent "starting a new route" step, it ensures the integrity and isolation of the handover operation at the system level.

[0105] The technical process of suspending the original route in this application embodiment can be understood as follows: Decision Trigger: The routing decision engine determines the path from node A (s) based on rule-based judgment. i v j Switch to node B.

[0106] Command generation: Generates a Switch_Command containing information such as the target and data volume.

[0107] Execution pause (pseudocode section): The system first calls `Pause_Data_Flow` and `Update_Queue_Status` on node A. This is an atomic combined operation; either both succeed or both fail. Upon success, the data flow on node A is frozen, and its state is locked.

[0108] Execution transfer: Only after confirming that node A has been successfully paused can the system safely retrieve Remaining_Data from node A's queue and commit it to node B as a transaction unit.

[0109] In this embodiment, pausing the original route is the foundation for achieving "real-time intelligent loss mitigation" and "seamless switching." Traditional systems, even if they detect inefficiency, can only wait for the current batch to finish executing. However, this embodiment, through proactive and programmable pause control commands, can achieve immediate interruption: the moment performance is found to be substandard (such as ROI falling below a threshold), the continued waste of budget is immediately stopped; state safety: by synchronously updating the state, the system is prevented from generating erroneous behavior in the intermediate state of "paused but not updated state," which is a key preliminary step to ensure that data is not duplicated or lost.

[0110] The "Pause Original Route" embodiment in this application describes a key system control command that uses software to precisely and atomically manipulate data flow and system state, transforming the "pause" business logic into a technical operation that can be reliably executed by a computer. This is one of the technical cornerstones for achieving automatic, real-time, and reliable switching in this application embodiment.

[0111] Start a new router: Resume_Data_Flow(s i Selected_Supplier) Allocate_Data(Remaining_Data ij (t), s i Selected_Supplier) Among them, Resume_Data_Flow(s i`Selected_Supplier` is the system control function corresponding to `Pause_Data_Flow`. Its function is to select the appropriate server at the target node (where the server is selected by the policy). i This function initiates or resumes data flow on the newly selected supplier (Selected_Supplier). After executing this function, the system will allow the sending of data belonging to policy s to that supplier. i Marketing data.

[0112] The purpose is to activate the receiving channel for the target node, preparing it for subsequent data allocation. This is the key switch to redirect marketing tasks from the old path to the new path.

[0113] Allocate_Data(Remaining_Data ij (t), s i Selected_Supplier is a data scheduling operation. This function schedules a specific, defined amount of data (i.e., the remaining data (Remaining_Data) that has been paused and migrated from the source node). ij (t)) is formally allocated and submitted to the target node (policy s) i The supplier (Selected_Supplier) will handle this.

[0114] The goal is to complete the actual transfer of data entities. This is the final destination of the switching operation, ensuring that data resources such as the customer list to be marketed are rescheduled from inefficient or suboptimal old execution nodes to efficient new execution nodes.

[0115] In this embodiment, the code for starting a new route is a specific implementation of "starting a new route", which together with the step of "pausing the original route" constitutes a complete transactional switching operation.

[0116] The standard technical process for initiating a new route in this embodiment is as follows: Pause and lock the source (preceding steps): Pause_Data_Flow and Update_Queue_Status ensure that the data flow out of the source node is atomically stopped and the status is clear.

[0117] Preparation objective: Enable data inflow permission for the target node using `Resume_Data_Flow`. This step must be completed before the data is actually allocated to ensure that the target node is ready and to prevent data from having nowhere to go.

[0118] Data migration: Allocate_Data performs the core data migration task. This operation is typically tied to a transaction mechanism to ensure that the data is either successfully committed to the target or rolled back.

[0119] In this embodiment, the code for initiating a new route directly achieves seamless rerouting and capacity maximization.

[0120] Achieving seamless transition: By using a Resume-then-Allocate sequence, the system ensures that the data flow is uninterrupted during the switchover process. Once the old path is paused, the new path immediately takes over, allowing marketing campaigns to continue and avoiding business interruptions caused by the switchover.

[0121] Ensuring data consistency: The Allocate_Data function operates on Remaining_Data. ij (t) is a precise dataset determined at the moment of pause. This, combined with unique data identification and idempotency control, strictly prevents data duplication or loss.

[0122] Maximizing execution efficiency: The entire process is an automated, programmatic sequence of instructions that can be completed in milliseconds, enabling "real-time" switching. This directly transforms the optimization judgments of the decision engine into the immediate and efficient reallocation of system resources (data flow, computing power).

[0123] The code for initiating a new route in this embodiment describes the key steps of "initiating a new route" and "allocating" during the switching process. Translating the abstract decision of "switching to vendor B" into a series of control instructions and scheduling commands that can be precisely executed by the computer system is the core manifestation of the fully automatic, highly reliable, and real-time route switching achieved in this embodiment at the operational level.

[0124] Step 6. Effect Monitoring and Parameter Adaptation The specific evaluation of the switching effect in this application embodiment is as follows: ΔROI = ROI_cumulative i _selected(t+Δt) - ROI_cumulative ij (t) Success_Score = f(ΔROI, Queue_Reduction, Cost_Savings) Among them, ΔROI is the core performance quantification indicator, which is calculated after a period of time (Δt) following the switch, the newly selected supplier (Selected_Supplier) performs better under strategy s. i The cumulative return on investment generated under the switch, compared with the original supplier (v) j ΔROI is the difference between the cumulative rates of return on investment (ROI) at the same point in time. In this embodiment, ΔROI directly and objectively measures the return improvement brought about by a switching decision. A positive ΔROI indicates that the switching is effective; Success_Score = f(ΔROI, Queue_Reduction, Cost_Savings) is a comprehensive success scoring function. The system considers not only ROI improvement (ΔROI) but also other technical benefits, such as: Queue_Reduction: Queue reduction amount (reflects the improvement in system throughput and latency).

[0125] Cost_Savings: Cost savings (reflecting the effectiveness of stop-loss orders).

[0126] This application provides a more comprehensive, multi-dimensional (benefit, efficiency, cost) utility assessment. This comprehensive score (Success_Score) is the objective function for subsequent parameter optimization.

[0127] The specific details of the parameter adaptive adjustment in this application embodiment are as follows: Dynamically optimize based on historical switching effects: θ_threshold i = θ_threshold i + η × Success / θ Hysteresis = Hysteresis + η × Success / Hysteresis [α, β, γ] = [α, β, γ]+ η × Success Where η is the learning rate, a hyperparameter that controls the size of the step size for each adjustment.

[0128] Success / Parameters or Success (gradient): Represents the overall success score (Success_Score) relative to a certain parameter (such as θ_threshold). i The rate of change (partial derivative or gradient) of a parameter or a set of parameters (such as [α, β, γ]) indicates how the parameter should be fine-tuned to improve the success rate.

[0129] The specific targets of the adjustment are as follows: θ_threshold i = θ_threshold i + η × Success / θ: Dynamically optimizes the minimum acceptable ROI threshold for each strategy. If historical data shows that most switches triggered at a certain threshold are successful ( Success / (If θ is positive), the system may raise the threshold to stop losses earlier; conversely, it may lower it to avoid premature switching.

[0130] Hysteresis = Hysteresis + η × Success / Hysteresis: Dynamically optimizes hysteresis tolerance. By analyzing the relationship between this value and the handover success rate, the system can automatically find the optimal buffer value that balances "agility" (rapid response to changes) and "stability" (preventing jitter).

[0131] [α, β, γ] = [α, β, γ]+ η × Success: Dynamically optimizes the weighting coefficients in the supplier selection function. The system learns how to balance "Return on Investment (α)," "Load Idleness (β)," and "Response Speed ​​(γ)" to make the selection with the highest overall success rate.

[0132] The embodiments of this application achieve system self-adjustment through parameter adaptive adjustment, solving the problem that preset parameters may be suboptimal or parameters may become outdated due to environmental changes, enabling the system to continuously adapt to the dynamic marketing environment and continuously improve its decision-making quality.

[0133] Step 7. Knowledge Base Updates and Strategy Evolution The decision record in this embodiment is as follows: Knowledge_Base.append({ "decision_id": UUID, "trigger_conditions": [the states of rule one, rule two, and rule three], "selected_supplier": Selected_Supplier, "outcome_metrics": [ΔROI, Success_Score, ...], "timestamp": t }) Among them, Knowledge_Base.append({ ...}) defines a structured record to be stored in the policy effect knowledge base.

[0134] Key fields include: `trigger_conditions`: Precisely records the triggering status of each rule (rule one, two, and three) when this switch is triggered. This is crucial for subsequent analysis of which rule combination is more effective.

[0135] outcome_metrics: Records the outcome metrics of this decision (such as ΔROI, Success_Score).

[0136] In this embodiment, the decision records construct a high-quality, well-labeled decision-outcome dataset, which serves as the data foundation for all subsequent analysis and evolution.

[0137] In this application embodiment, strategy derivation is based on success patterns and automatically generates new test strategies: New_Strategy = Derive_From_Success_Pattern(Knowledge_Base) Add_To_AB_Test_Pool(New_Strategy) Among them, New_Strategy = Derive_From_Success_Pattern(Knowledge_Base) is a high-order strategy generation function based on data mining or machine learning. It can analyze a large number of successful switching records in the knowledge base, find common patterns (e.g., "Whenever features A and B appear, switching from supplier X to Y will always bring high returns"), and automatically synthesize or recommend new marketing strategies (New_Strategy) based on these successful patterns.

[0138] Add_To_AB_Test_Pool(New_Strategy): Adds the generated new strategy to the A / B testing pool. The system will automatically or semi-automatically deploy it as a new option in a small-scale testing environment to verify its effectiveness.

[0139] In this embodiment, strategy derivation is based on success patterns and automatically generates new test strategies to achieve strategy innovation and self-evolution of the system. The system not only optimizes the execution path of existing strategies, but also discovers potentially better new strategy combinations that human operators may not have thought of, thereby breaking through the limitations of the original strategy set and continuously exploring the effect boundary.

[0140] These two parts together constitute the core embodiment of this invention's transition from automation to intelligence. From a micro-adaptive perspective, the gradient method is used to optimize the parameters of the decision engine (such as thresholds and weights) online, making the rules execute more intelligently.

[0141] From a macro-evolutionary perspective: By mining patterns, new strategies can be generated and tested offline, fundamentally expanding the system's capabilities.

[0142] These two parts elevate the embodiments of this application into an intelligent closed-loop system with complete capabilities of perception, decision-making, execution, learning, and innovation, rather than just a fixed automated process.

[0143] The purpose of the real-time routing switching method based on a multi-rule decision engine provided in this application is to overcome the shortcomings of the prior art. The real-time routing switching method based on a multi-rule decision engine provided in this application aims to: realize real-time monitoring and evaluation of the effectiveness of suppliers and strategies during the marketing campaign; establish an automated decision-making and execution mechanism that can immediately route data resources from inefficient points to efficient points when performance differences or degradation are detected; and achieve real-time intelligent loss mitigation and capacity maximization through a "pause-switch" mechanism, thereby significantly improving the overall return on investment (ROI) and operational efficiency of the marketing campaign.

[0144] This invention provides a real-time routing switching method based on a multi-rule decision engine. It calculates the return on investment (ROI) of each node based on real-time feedback data collected from the combined nodes. The routing decision engine then executes predefined multi-dimensional performance evaluation and decision rules based on the ROI to evaluate and compare the combined nodes, generating routing switching decisions. During marketing campaigns, routing switching between suppliers or strategies is executed according to the routing switching decisions. The routing switching decisions and their corresponding execution effects are recorded in a strategy performance knowledge base, thereby achieving the technical effect of automatically switching data from inefficient suppliers or strategies to efficient ones by monitoring ROI data in real time.

[0145] This invention provides a real-time routing switching device based on a multi-rule decision engine. Figure 3 This is a schematic diagram of a real-time routing switching device based on a multi-rule decision engine, provided in an embodiment of the present invention; as shown. Figure 3 As shown in the embodiment of this application, the real-time routing switching device based on a multi-rule decision engine includes: The calculation module 32 is used to calculate the return on investment (ROI) of each node based on the real-time feedback data collected from the combined nodes; the decision generation module 34 is used to perform performance evaluation and comparison of the combined nodes based on the ROI through the routing decision engine, and generate routing switching decisions; the routing switching module 36 is used to perform routing switching between suppliers or between strategies based on the routing switching decisions during the marketing campaign; and the storage module 38 is used to record the routing switching decisions and their corresponding execution effects in the strategy effect knowledge base.

[0146] This invention provides a real-time routing switching device based on a multi-rule decision engine. It calculates the return on investment (ROI) of each node based on real-time feedback data collected from the combined nodes. The routing decision engine then executes predefined multi-dimensional performance evaluation and decision rules based on the ROI to evaluate and compare the combined nodes, generating routing switching decisions. During marketing activities, routing switching between suppliers or strategies is executed according to the routing switching decisions. The routing switching decisions and their corresponding execution effects are recorded in a strategy performance knowledge base, thereby achieving the technical effect of automatically switching data from inefficient suppliers or strategies to efficient ones by monitoring ROI data in real time.

[0147] The above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention.

Claims

1. A real-time routing switching method based on a multi-rule decision engine, characterized in that, include: The return on investment for each node is calculated based on the real-time feedback data collected from the combined nodes. Based on the return on investment, the routing decision engine executes predefined multi-dimensional performance evaluation and decision rules to evaluate and compare the performance of the combined nodes and generate routing switching decisions. During a marketing campaign, routing switches between suppliers or between strategies are executed based on the routing switch decision. The routing switching decision and its corresponding execution effect are recorded in the strategy effect knowledge base.

2. The real-time routing switching method based on a multi-rule decision engine according to claim 1, characterized in that, The return on investment for each node is calculated based on the real-time feedback data collected from the combined nodes, including: The real-time feedback data is continuously collected from all the currently executing combined nodes, wherein the real-time feedback data includes: cost data and business revenue data; The calculation results are obtained by performing real-time calculations based on the cost data and the business revenue data. Update the instantaneous return on investment and the cumulative return on investment over the period for each node based on the results; The investment return rate for each node is obtained based on the instantaneous investment return rate and the cumulative investment return rate over the period.

3. The real-time routing switching method based on a multi-rule decision engine according to claim 1, characterized in that, The predefined multi-dimensional performance evaluation and decision-making rules include: performance degradation judgment logic based on absolute thresholds, performance superiority judgment logic based on relative comparisons, and capacity replenishment judgment logic based on system resource utilization.

4. The real-time routing switching method based on a multi-rule decision engine according to claim 3, characterized in that, The performance degradation judgment logic based on absolute thresholds includes: setting a minimum acceptable rate of return warning threshold for each strategy; and triggering a switching action when the cumulative rate of return of the current execution node is detected to be lower than the corresponding rate of return warning threshold.

5. The real-time routing switching method based on a multi-rule decision engine according to claim 3, characterized in that, The performance evaluation logic based on relative comparison includes: for multiple supplier nodes serving the same strategy, continuously comparing the cumulative return on investment of the multiple supplier nodes; when it is found that the cumulative return on investment of a supplier node is higher than that of the current node, triggering a switch to the better node.

6. The real-time routing switching method based on a multi-rule decision engine according to claim 3, characterized in that, The capacity replenishment judgment logic based on system resource utilization includes: monitoring the real-time load status of each supplier node; when it is found that a node with high return on investment has remaining processing capacity and other nodes have data backlog, triggering the action of switching the backlogged data to a node with high return on investment and idle capacity.

7. The real-time routing switching method based on a multi-rule decision engine according to claim 1, characterized in that, The routing switching between suppliers or policies includes: a mechanism to ensure that data is not lost or duplicated, a state synchronization mechanism, and an exception handling strategy.

8. The real-time routing switching method based on a multi-rule decision engine according to claim 7, characterized in that, The mechanism to ensure that data is not lost or duplicated includes: before initiating a switchover command, marking the batch of data to be migrated as being in a switchover state on the source node, and atomically pausing the data allocation of the batch of data to be migrated; submitting the data batch information marked as being in a switchover state to the target node as a transaction unit, and only updating the data status of the source node to be switched over after the target node confirms successful receipt; each piece of data to be marketed has a globally unique identifier, and the target node checks the globally unique identifier when processing the data to ensure idempotency control; The exception handling strategy includes: When a switchover fails, a failure log is recorded, and the switchover is automatically retried at a later time according to the configured retry policy, or the alarm is escalated to notify manual intervention. When a supplier failure occurs, continuously monitor the heartbeat or interface availability of the supplier node; when a failure is detected, force the ROI of all combinations of the supplier node to the minimum value or mark it as unavailable, trigger the absolute threshold rule, and switch the data in the queue to other healthy nodes; When a network interruption occurs, asynchronous acknowledgment and local persistent queues are used when sending data to the supplier. If the network interruption causes the transmission to fail, the data is retained in the local persistent queue and will be automatically resumed after the network is restored. In addition, the network interruption is regarded as a supplier abnormality and triggers the failover logic.

9. The real-time routing switching method based on a multi-rule decision engine according to claim 7, characterized in that, The execution of routing switching between suppliers or policies further includes: switching between suppliers and switching between policies; wherein... The switching between suppliers includes: When a specific amount of data is initially allocated to the first supplier, if real-time monitoring finds that the return on investment of the data already executed by the first supplier does not meet business needs, and the return on investment of the second supplier under the current strategy is higher than that of the first supplier, the subsequent data will be suspended from being sent to the first supplier, and the remaining data will be rerouted to the second supplier. The switching between strategies includes: When it is found that the return on investment of the first strategy is trending downward, while the return on investment of the second strategy targeting similar customer groups is steadily increasing, the new data or data already in the queue will be migrated from the first strategy to the best supplier corresponding to the second strategy.

10. A real-time routing switching device based on a multi-rule decision engine, characterized in that, include: The calculation module is used to calculate the return on investment for each node based on the real-time feedback data collected from the combined nodes. The decision generation module is used to perform performance evaluation and comparison of the combined nodes by executing predefined multi-dimensional performance evaluation and decision rules based on the return on investment through the routing decision engine, and generate routing switching decisions. The routing switching module is used to perform routing switching between suppliers or between strategies based on the routing switching decision during a marketing campaign. The storage module is used to record the routing switching decision and the corresponding execution effect to the strategy effect knowledge base.

Images