Multi-strategy traffic allocation system and method

Abstract

This application discloses a multi-strategy traffic allocation system and method, relating to the field of traffic technology. The system includes: a strategy knowledge base module connected to a configuration management module and a decision engine module, storing a strategy knowledge base including historical strategy cases and strategy templates; the configuration management module configuring traffic experiment parameters according to the strategy templates to generate standardized description files; the decision engine module weighting the standardized description files based on a multi-armed slot machine model and outputting a traffic allocation strategy; and the traffic allocation execution module, upon receiving a user request, allocating traffic according to the traffic allocation strategy and historical strategy cases. Because this application guides parameter adjustments in each module through a strategy knowledge base; and after the decision engine module's multi-armed slot machine model weights the standardized description files, it outputs a traffic allocation strategy to the traffic allocation execution module for traffic allocation, configuration efficiency is improved, enabling dynamic optimal allocation of valuable traffic resources.

Description

Technical Field

[0001] This application relates to the field of traffic technology, and in particular to a multi-strategy traffic allocation system and method. Background Technology

[0002] In current digital operations practices, traffic allocation mechanisms generally employ a combination of static proportional allocation and manual intervention. This model, in terms of resource utilization efficiency, uses a fixed allocation mechanism. For example, using a fixed-cycle (typically 24-hour) data collection and analysis model, the processing time from data generation to strategy adjustment generally exceeds 30 hours. This traffic allocation mechanism suffers from significant response delays, causing operational strategies to fail to respond promptly to market changes. Furthermore, a fixed-proportion allocation model severely restricts resource utilization efficiency. Even if a particular version performs significantly better than others, the system mechanically maintains the preset allocation ratio. This rigid constraint makes it difficult for high-potential versions to exceed the preset traffic limit, while inefficient versions continue to consume valuable traffic resources.

[0003] More importantly, because strategy adjustments rely on human experience and judgment, different operations teams may make contradictory judgments about the same data, and the adjustment logic needs to be redesigned for each experiment. Secondly, successful experiences cannot be standardized into strategies, and each activity requires exploration again, making it difficult to standardize and reuse human experience. This makes it difficult to ensure the scientific nature of decision-making (different operations teams may reach opposite conclusions) and also makes it difficult to form reusable strategy assets.

[0004] Just like the dilemma faced by financial preferential resource management, this extensive traffic allocation method has caused significant efficiency losses. According to experimental data, in a typical A / B testing scenario, about 15%-20% of the traffic is continuously occupied by inefficient versions, while the potential of the optimal version is artificially limited, ultimately resulting in an overall conversion efficiency loss of 8%-12%.

[0005] Therefore, the existing traffic allocation mechanism adopts a combination of static proportional allocation and manual intervention, which easily leads to traffic allocation lag and low configuration efficiency, making it difficult to achieve dynamic optimal allocation of valuable traffic resources. Summary of the Invention

[0006] The main purpose of this application is to provide a multi-strategy traffic allocation system and method, which aims to solve the technical problem that the existing traffic allocation mechanism, which adopts a combination of static proportional allocation and manual intervention, is prone to traffic allocation lag and low configuration efficiency.

[0007] To achieve the above objectives, this application proposes a multi-strategy traffic allocation system, which includes: a strategy knowledge base module, a configuration management module, a decision engine module, and a traffic allocation execution module;

[0008] The strategy knowledge base module is connected to the configuration management module and the decision engine module, and stores a strategy knowledge base, which includes historical strategy cases and strategy templates.

[0009] The configuration management module is used to configure the traffic experiment parameters submitted by the operators according to the strategy template and generate a standardized description file.

[0010] The decision engine module is used to assign weights to the standardized description file based on the multi-armed slot machine model and output a traffic allocation strategy.

[0011] The traffic allocation module is used to allocate traffic to the user request according to the traffic allocation strategy and the historical strategy cases when a user request is received.

[0012] In one embodiment, the configuration management module is further configured to perform multi-level reviews based on the traffic experiment parameters submitted by the operators, and generate initial resources;

[0013] The configuration management module is also used to perform similarity retrieval of the features of the initial resource in the policy knowledge base using cosine similarity to determine similar policy templates;

[0014] The configuration management module is also used to configure parameters according to the similar strategy template, generate a standardized description file, and send the standardized description file to the decision engine module.

[0015] In one embodiment, the decision engine module is further configured to extract features from the user request using a WASM filter when a user request is received, thereby obtaining user feature data;

[0016] The decision engine module is also used to make traffic allocation decisions based on the user feature data and the standardized description file through a multi-armed slot machine model, and generate a traffic allocation strategy.

[0017] The decision engine module is also used to push the traffic allocation strategy to the traffic splitting execution module via Kafka transaction messages.

[0018] In one embodiment, the traffic allocation module is further configured to allocate traffic to the user request according to the traffic allocation strategy and the historical strategy cases, and generate routing results;

[0019] The traffic splitting execution module is also used to monitor the deviation between the routing result and the traffic allocation strategy based on the summary data structure.

[0020] The traffic allocation module is further configured to compensate the allocation probability of the routing result according to a preset compensation strategy when the deviation value reaches a preset deviation threshold, and return to execute the operation of allocating traffic to the user request according to the traffic allocation strategy and the historical strategy case based on the compensated allocation probability.

[0021] In one embodiment, the traffic allocation system further includes a policy optimization module; the policy optimization module includes an indicator evaluation submodule, a policy generation submodule, and a version management submodule;

[0022] The indicator evaluation submodule is used to obtain the user's traffic consumption data, and when the key indicators of the traffic consumption data exceed the preset benchmark value, trigger a strategy optimization instruction and push the strategy optimization instruction to the strategy generation submodule.

[0023] The strategy generation submodule is used to adjust the parameters of the traffic allocation strategy based on the strategy optimization instructions and through a multi-objective optimization algorithm, and generate a parameter adjustment scheme.

[0024] The version management submodule is used to record the entire lifecycle of the traffic allocation strategy changes.

[0025] In one embodiment, the traffic allocation system further includes a real-time monitoring module, which includes an intelligent early warning submodule, a root cause analysis submodule, and a handling feedback submodule.

[0026] The intelligent early warning submodule is used to issue an early warning to the key indicator according to a preset early warning level when abnormal fluctuations of the key indicator are detected.

[0027] The root cause analysis submodule is used to identify user groups and determine abnormal user characteristics through a decision tree algorithm after the warning is triggered.

[0028] The handling feedback submodule is used to search for historical handling cases in the policy knowledge base based on the abnormal user characteristics, and execute the historical handling cases.

[0029] In one embodiment, the traffic allocation system further includes an effect evaluation module; the effect evaluation module includes an indicator calculation submodule, a multidimensional analysis submodule, and a report generation submodule;

[0030] The indicator calculation submodule is used to use a distributed Spark engine to calculate indicators on traffic consumption data and determine key indicators.

[0031] The multidimensional analysis submodule is used to analyze traffic consumption data from multiple dimensions, obtain analysis results, and store the analysis results in the strategy knowledge base. The multiple dimensions include at least one of time dimension, user dimension, and channel dimension.

[0032] The report generation submodule is used to generate a traffic detection report based on the key indicators and the analysis results.

[0033] Furthermore, to achieve the above objectives, this application also proposes a multi-strategy traffic allocation method, which is applied to a multi-strategy traffic allocation system. The system includes a configuration management module, a strategy knowledge base module, a decision engine module, and a traffic allocation execution module. The method includes:

[0034] The strategy knowledge base module is connected to the configuration management module and the decision engine module, and stores a strategy knowledge base, which includes historical strategy cases and strategy templates.

[0035] The configuration management module configures the traffic experiment parameters submitted by the operators according to the policy template and generates a standardized description file.

[0036] The decision engine module assigns weights to the standardized description file based on the multi-armed slot machine model and outputs a traffic allocation strategy.

[0037] Upon receiving a user request, the traffic allocation module allocates traffic to the user request according to the traffic allocation strategy and the historical strategy cases.

[0038] In one embodiment, the step of the configuration management module configuring the traffic experiment parameters submitted by the operators according to the policy template and generating a standardized description file includes:

[0039] The configuration management module performs multi-level reviews based on the traffic experiment parameters submitted by the operations personnel and generates initial resources.

[0040] The configuration management module uses cosine similarity to perform a similarity search on the features of the initial resource in the policy knowledge base to determine similar policy templates;

[0041] The configuration management module configures parameters according to the similar strategy template, generates a standardized description file, and sends the standardized description file to the decision engine module.

[0042] In one embodiment, the step of the decision engine module assigning weights to the standardized description file based on a multi-armed slot machine model and outputting a traffic allocation strategy includes:

[0043] When the decision engine module receives a user request, it extracts features from the user request using a WASM filter to obtain user feature data.

[0044] The decision engine module uses a multi-armed slot machine model to make traffic allocation decisions based on the user feature data and the standardized description file, and generates a traffic allocation strategy.

[0045] The decision engine module pushes the traffic allocation strategy to the traffic distribution execution module via Kafka transaction messages.

[0046] One or more technical solutions proposed in this application have at least the following technical effects: The multi-strategy traffic allocation system of this application includes: a strategy knowledge base module, a configuration management module, a decision engine module, and a traffic allocation execution module; the strategy knowledge base module is connected to the configuration management module and the decision engine module, and stores a strategy knowledge base, which includes historical strategy cases and strategy templates; the configuration management module is used to configure the traffic experiment parameters submitted by the operators according to the strategy templates, and generate a standardized description file; the decision engine module is used to assign weights to the standardized description file based on a multi-armed slot machine model, and output a traffic allocation strategy; the traffic allocation execution module is used to allocate traffic to the user request according to the traffic allocation strategy and the historical strategy cases when a user request is received.

[0047] This application guides parameter adjustments for each module through a strategy knowledge base. After the multi-armed slot machine model in the decision engine module assigns weights to the standardized description files, it outputs a traffic allocation strategy to the traffic distribution execution module for traffic allocation. This interconnected architecture avoids the lag in traffic allocation caused by the static proportional allocation used in existing traffic allocation mechanisms, improving configuration efficiency and enabling dynamic optimal allocation of valuable traffic resources. Attached Figure Description

[0048] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0049] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0050] Figure 1 This is a functional block diagram provided for Embodiment 1 of the multi-strategy traffic allocation system of this application;

[0051] Figure 2 A flowchart illustrating the business processes and relationships of the configuration management module provided in Embodiment 1 of this application;

[0052] Figure 3 A schematic diagram illustrating the decision-making, triage, feedback, and monitoring process provided in Embodiment 1 of this application;

[0053] Figure 4 This is a schematic diagram of the adjustment process and relationships of the decision optimization module provided in Embodiment 2 of this application;

[0054] Figure 5 A schematic diagram of the early warning process provided in Embodiment 2 of this application;

[0055] Figure 6 A schematic diagram of the effect evaluation process provided in Embodiment 2 of this application;

[0056] Figure 7 A schematic diagram illustrating the business processes and relationships of the strategy knowledge base provided in Embodiment 2 of this application;

[0057] Figure 8 This is a flowchart illustrating an embodiment of the multi-strategy traffic allocation method of this application.

[0058] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0059] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0060] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0061] This application provides a multi-strategy traffic allocation system, primarily designed for multi-strategy adaptive traffic allocation in online experiments. (Refer to...) Figure 1 , Figure 1 This is a functional block diagram provided for Embodiment 1 of the multi-strategy traffic allocation system of this application.

[0062] In this embodiment, the system includes: a strategy knowledge base module 10, a configuration management module 20, a decision engine module 30, and a traffic distribution execution module 40.

[0063] The strategy knowledge base module 10 is connected to the configuration management module 20 and the decision engine module 30, and stores a strategy knowledge base, which includes historical strategy cases and strategy templates.

[0064] It's important to note that the strategy knowledge base module serves to store knowledge, including historical strategy cases and strategy templates. Historical strategy cases are examples of strategies used in past operations, recording the strategies employed in different scenarios and their effects. Strategy templates, on the other hand, are pre-defined strategy frameworks that define the basic structure and elements of a strategy, providing a template-based reference for developing new strategies. This allows operations personnel to quickly create and adjust strategies based on these templates.

[0065] Specifically, the strategy knowledge base module is the intelligent strategy asset center of the multi-strategy traffic allocation system. It can adopt an advanced data lake architecture to realize full lifecycle strategy management, and is divided into four parts: data acquisition layer, data processing layer, knowledge service layer and version control layer.

[0066] At the data acquisition layer, a highly available distributed data pipeline can be built based on Apache NiFi (a data ingestion and integration platform). Incremental data is extracted hourly from more than ten business systems, including user profiling systems, A / B testing platforms, and environmental monitoring services. This data includes structured data such as basic user attributes, version feature parameters, and environment variable configurations, as well as unstructured data such as user behavior event sequences, open text feedback, and interface operation logs.

[0067] At the data processing layer, the Spark MLlib (Apache Spark Machine Learning Library) distributed computing framework can be used to construct a policy feature vector space with multiple dimensions. Key feature dimensions include: historical version click pass rate, user lifetime value prediction model output value, sensitivity decay coefficient for different time periods, and other core indicators.

[0068] The knowledge service layer provides RESTful (Representational State Transfer) interfaces and flexible GraphQL (Graph Query Language) query interfaces. This knowledge service layer interacts with the subsequent configuration management module and decision engine module. When operations personnel initiate a new experiment creation request for multi-strategy adaptive traffic allocation for online experiments, the strategy knowledge base module first performs semantic understanding using the BERT (Bidirectional Encoder Representations from Transformers) deep learning model to accurately extract key feature words of the experiment target. Then, it performs similarity retrieval in the knowledge graph of the strategy knowledge base, which stores tens of millions of historical strategy cases, and returns strategy templates with complete configurations of the multiple optimal strategies with the highest matching degree, including detailed information such as parameter settings, rule combinations, and expected effects.

[0069] Furthermore, the strategy knowledge base module features a robust version control layer, supporting the rapid rollback of any experimental configuration to a specified historical version state. It also retains complete version change records and rollback audit logs, ensuring the traceability and security of strategy management. In this way, the strategy knowledge base module reliably enables intelligent management and efficient reuse of strategy assets, significantly improving the efficiency and quality of operational decision-making.

[0070] The configuration management module 20 is used to configure the traffic experiment parameters submitted by the operators according to the policy template and generate a standardized description file.

[0071] It should be noted that the configuration management module is responsible for managing and processing the traffic experiment parameters submitted by operations personnel. This includes configuring core parameters such as basic information settings for the experiment version (e.g., experiment name, business objectives), traffic allocation algorithm selection (e.g., UCB algorithm or Thompson sampling algorithm), and initial traffic ratio settings. Operations personnel can quickly initialize experiment parameters based on policy templates recommended by the policy knowledge base, and also support custom parameter adjustments to meet specific business needs.

[0072] Among them, traffic experiment parameters are various parameters set by operations personnel for conducting traffic-related experiments (such as A / B testing). These parameters include fully configured parameters such as experiment objectives, expected results, and technical parameters, providing initial setup conditions for traffic experiments and serving as the basis for parameter configuration in the configuration management module. Standardized description files are files generated after configuring core parameters such as algorithm type, traffic allocation ratio, and special rules according to the format specified in the policy template.

[0073] In its implementation, the configuration management module receives traffic experiment parameters submitted by operations personnel and compares and matches these parameters with pre-defined policy templates in the policy knowledge base. During the comparison process, it checks whether each parameter conforms to the format, value range, and other requirements specified in the policy template. For parameters that meet the requirements, they are organized according to the rules in the policy template, and a standardized description file is generated using the specific format and structure of the policy template.

[0074] In one feasible implementation, the configuration management module 20 of this embodiment is further configured to perform multi-level review based on the traffic experiment parameters submitted by the operators to generate initial resources; the configuration management module 20 is further configured to perform similarity retrieval of the features of the initial resources in the policy knowledge base through cosine similarity to determine similar policy templates; the configuration management module 20 is further configured to configure parameters according to the similar policy templates, generate standardized description files, and send the standardized description files to the decision engine module 30.

[0075] It should be noted that the initial resources are a type of resource generated based on the traffic experiment parameters submitted by the operations personnel after multiple levels of review. Examples include the initially allocated computing resource quotas and traffic pools.

[0076] Understandably, cosine similarity is a mathematical metric that measures the similarity between two vectors. In a policy knowledge base, the features of an initial resource can be represented as vectors, and then the degree of similarity between these vectors and the vectors in the policy knowledge base is determined by calculating their cosine similarity. When calculating the similarity between the initial resource and elements in the policy knowledge base, cosine similarity can effectively quantify this similarity relationship, thereby finding the most similar policy template.

[0077] For example, to facilitate understanding of the implementation process of the configuration management module, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the business processes and relationships of the configuration management module provided in Embodiment 1 of this application. Figure 2 As shown, the configuration management module includes the experiment project initiation process, template matching process, parameter configuration process, and rule verification process, constructing a four-layer progressive management process of "project review - template matching - parameter configuration - rule verification".

[0078] In the experiment initiation process, operations personnel are required to submit a complete experiment plan, including experiment objectives, expected results, and technical parameters, before creating the experiment. This plan then undergoes tripartite approval, including a multi-level review workflow (e.g., technical feasibility review, business value assessment, and compliance review) to ensure its quality. If rejected, the plan is returned for revision; if approved, a unique experiment ID is automatically generated using the Snowflake algorithm, and initial resources (e.g., computational resource quotas and traffic pools) are allocated. Simultaneously, an electronic archive containing the plan document, review records, and resource list is established. This process provides structured experiment metadata (including industry classification, scenario tags, and other multi-dimensional features) to the strategy knowledge base, ensuring subsequent processes are traceable and compliant with audit requirements.

[0079] Next, in the template matching process, templates are queried through the strategy knowledge base. Specifically, the cosine similarity between the experimental features of the current traffic experiment parameters and the data in the strategy knowledge base is calculated, and a matching score is given. If the matching score is greater than 0.85, the top 10 strategy templates are returned, and the differences are visualized and compared, with intelligent recommendations for similar strategy templates. Operations personnel can determine the applicability of the template. If it can be used directly, a similar strategy template can be selected to quickly initialize the experimental parameters; if not, customized adjustments can be made through parameter comparison tools.

[0080] At this point, the parameter configuration process begins. During template usage, core parameters can be set through a visual configuration interface, such as algorithm type, traffic allocation ratio, special rules, and advanced rules. This transforms business requirements into executable technical solutions and generates standardized experimental description files, which serve as the basis for subsequent execution by the decision engine module.

[0081] Finally, a rule verification process is implemented to automatically check for anomalies in the parameters, such as format verification, business logic verification (e.g., total traffic ≤ 100%), system constraint verification (e.g., resource availability detection), detection of conflict patterns based on the Drools rule engine, and 24-hour traffic prediction in a sandbox environment. If anomalies are found, specific error locations are pushed and risk handling is carried out, such as blocking or terminating the process; or compliance review is conducted through the risk control system, such as simultaneously scanning sensitive parameters (e.g., whether user privacy fields are involved). For high-risk experimental schemes, an additional manual confirmation step is required to ensure the safety and stability of the experiment; or the scheme is downgraded in preparation for release. If the anomaly check passes, a notification is directly issued to the real-time decision engine module. At the same time, after the verification passes, all verification results generate a comprehensive risk score (e.g., 0-10 points). Experiments with a score greater than 7 points are subject to an additional observation period (e.g., 72-hour gradual increase in volume).

[0082] In this implementation, the configuration management module, through multi-level review, ensures the accuracy and rationality of traffic experiment parameters, reducing the risk of experiment failure. Secondly, by utilizing cosine similarity to search for similar policy templates in the policy knowledge base, existing knowledge and experience are fully utilized, improving configuration efficiency and accuracy. Standardized description files are generated based on similar policy templates, making the entire traffic experiment configuration process more standardized and facilitating collaboration and interaction between different modules. This ensures both the standardization of the configuration process and the flexibility of business requirements, achieving a secure and efficient transformation from business needs to technical solutions.

[0083] The decision engine module 30 is used to assign weights to the standardized description file based on the multi-armed slot machine model and output a traffic allocation strategy.

[0084] It should be noted that the decision engine module is responsible for decision-making. As the intelligent hub of the multi-strategy traffic allocation system, it employs a multi-armed slot machine model to achieve fully automated management of the entire process from strategy configuration to allocation instruction generation. Since traffic configuration is performed in an uncertain environment, in this scenario, the decision engine module can assign weights to different strategy options based on the standardized description files generated by the configuration management module.

[0085] Understandably, the multi-armed slot machine model is the mathematical model upon which the decision engine module bases its weight allocation. In this model, different strategy options are analogous to different arms of a slot machine. Each arm (strategy option) has a different probability of winning (generating profit), but this probability is unknown. The model dynamically adjusts the weight allocation of each strategy option by continuously exploring (trying different strategies) and utilizing (selecting the better strategy based on existing information). In the context of traffic allocation, this is equivalent to continuously adjusting the proportion of each strategy in traffic allocation based on the estimated potential profits (such as traffic conversion effects).

[0086] It should be understood that a traffic allocation strategy is a plan used to guide the traffic distribution execution module in allocating user traffic to different targets or business segments. The traffic allocation strategy clarifies which specific services, pages, or functional modules different traffic sources or user groups should be directed to, and specifies the allocation ratios or priorities.

[0087] In its implementation, the decision engine module inputs the standardized description file generated by the configuration management module into the multi-armed slot machine model for evaluating various elements. Based on the model, a corresponding weight is assigned to each element, ultimately forming a traffic allocation strategy.

[0088] In one feasible implementation, the decision engine module 30 of this embodiment is further configured to, upon receiving a user request, extract features from the user request using a WASM filter to obtain user feature data; the decision engine module 30 is further configured to, using a multi-armed slot machine model, make traffic allocation decisions based on the user feature data and the standardized description file to generate a traffic allocation strategy; the decision engine module 30 is further configured to, using a Kafka transaction message, push the traffic allocation strategy to the traffic distribution execution module.

[0089] It's important to note that WASM (WebAssembly) filters extract specific device characteristics from user requests. For example, when a user sends a network request, this request may contain a lot of information, such as the request's origin, type, and parameters. WASM filters can sift through this complex request information and extract user characteristic data relevant to subsequent processing. This user characteristic data can include user device fingerprints, LBS (Location-Based Services Geo-Fencing) geofencing, and user behavior sequence embeddings, among others.

[0090] Understandably, Kafka transactional messages are a messaging mechanism provided by Kafka (a distributed stream processing platform) that guarantees message atomicity, consistency, isolation, and durability. The decision engine module pushes traffic allocation strategies to the traffic distribution execution module via Kafka transactional messages, ensuring that the traffic allocation strategies are accurately received and executed by the traffic distribution execution module.

[0091] Specifically, the core of the decision engine module can adopt an innovative layered architecture design, consisting of a bottom layer, a middle layer, and a top layer. The bottom layer consists of a high-performance Bayesian probability model library, which can use a distributed computing framework to dynamically maintain distribution parameters for each experimental version and update the posterior probability in real time. The middle layer is a dynamically weighted algorithm engine. In the critical first 24 hours after the start of the experiment, the Thompson sampling algorithm can be given an α% dominant weight. Thereafter, its weight is gradually reduced daily at an exponential decay rate of β%, while the decision weight of the UCB (Upper Confidence Bound) algorithm is linearly increased, achieving a smooth transition from exploration to utilization.

[0092] At the top layer is the business rules engine, which deeply integrates 14 types of core business rules, including but not limited to minimum traffic protection, dynamic budget constraints, time-sensitive adjustments, geographic targeting, intelligent device adaptation, precise user segmentation, conversion funnel optimization, intelligent fatigue control, competition isolation management, real-time compliance review, seasonal strategy adjustment, competitor defense response, automatic disaster recovery degradation, and precise cost control.

[0093] The minimum traffic protection rule can employ an innovative probabilistic truncation algorithm to ensure that each experimental version can obtain a basic exposure opportunity of no less than 5% under any circumstances. This, together with the dynamic budget constraint rule, forms a dual protection mechanism to continuously monitor the budget consumption progress of each version and automatically trigger a downgrade process when the consumption reaches a preset threshold.

[0094] The time-sensitive adjustment rules and the geographic-targeted delivery rules together construct an intelligent spatiotemporal decision-making dimension, with built-in refined time window strategies and city-level geofencing functions, which can automatically adjust the strategy weights according to different time periods and geographic location characteristics.

[0095] The intelligent device adaptation rules automatically increase the display weight of key interactive elements for mobile users, continuously optimizing the user experience. The precise user segmentation rules rely on the mature RFM (Recency, Frequency, Monetary; most recent purchase, purchase frequency, purchase amount) user value model to achieve precise customer segmentation and operation.

[0096] The conversion funnel optimization rules establish an automatic compensation mechanism for key drop-off points, working in conjunction with the fatigue intelligent control rules. The latter enables 7-day deduplication of exposure frequency control, effectively preventing user experience degradation caused by excessive exposure. The competition isolation management rules avoid policy conflicts and mutual interference, while the compliance real-time review rules call the risk control system's OpenAPI interface in real time to perform multi-level sensitive word filtering and security audits on the displayed content.

[0097] The seasonal strategy adjustment rules have a built-in complete library of lunar or Gregorian calendar holiday strategies and can automatically load preset seasonal operation plans. The competitor defense response rules are used to monitor market competition dynamics in real time and trigger preset response plans.

[0098] The disaster recovery automatic degradation rules establish a comprehensive abnormal state handling mechanism. When the anomaly rate of a certain version exceeds the 5% threshold, it automatically switches to a pre-configured backup solution. The precise cost control rules are based on real-time calculated return on investment (ROI) metrics and automatically stop traffic allocation whenever sales costs exceed a preset threshold.

[0099] For example, to facilitate understanding of the implementation process of the decision engine module, please refer to... Figure 3 , Figure 3 This is a schematic diagram illustrating the decision-making, triage, feedback, and monitoring process provided in Embodiment 1 of this application. Figure 3 As shown, in the triggering process of the decision engine module, when a user request is received, the request type is first determined. If the request type is already available locally, the local cache is read, and the traffic allocation process begins. If the request type is unknown, each request needs to undergo multi-dimensional feature extraction and preprocessing. Feature extraction (e.g., device fingerprint, LBS geofence positioning, user behavior sequence embedding, etc.) can be completed within a 50ms window using a customized WASM filter to obtain user feature data in real time. Then, real-time decision calculation is performed, at which point the dynamic routing engine intelligently allocates algorithm weights: for example, based on the experimental parameters and user feature data in the standardized description file mentioned above, the initial stage of the experiment can focus on exploration, using a hybrid strategy of Thompson sampling algorithm and UCB algorithm (e.g., 7:3 weighting). When the cumulative sample size exceeds 100,000, it automatically switches to the UCB algorithm-dominated mode to generate a traffic allocation strategy. The traffic allocation strategy can trigger a batch calculation process every 5 minutes at a fixed cycle. At the beginning of each calculation cycle, a strict data quality check is performed first, using standard deviation analysis and outlier detection algorithms to remove abnormal fluctuation data. The final traffic allocation strategy undergoes a dual verification mechanism, including logical validation (verifying the rationality of the algorithm output) and business validation, before being pushed to the traffic distribution execution module via Kafka transaction messages. The entire processing chain employs an advanced asynchronous non-blocking design, achieving high concurrency through an event-driven architecture. Even in a production environment handling 230 million decision requests daily, it maintains an average latency of 8.7ms, ensuring that 99.9% of requests respond within the strict 50ms service level agreement timeframe, providing efficient and reliable intelligent decision support for the business.

[0100] In this embodiment, the use of the multi-armed slot machine model enables a balance between exploring new allocation methods and utilizing existing experience during the traffic allocation decision-making process. This improves the accuracy and efficiency of decision-making, better adapts to the needs of different users and changes in different business scenarios, and provides efficient and reliable intelligent decision support capabilities for the business.

[0101] The traffic allocation module 40 is used to allocate traffic to the user request according to the traffic allocation strategy and the historical strategy case when a user request is received.

[0102] It's important to note that the traffic allocation module distributes user requests based on the traffic allocation strategy output by the decision engine module and historical strategy cases in the strategy knowledge base. This allows different user requests to be directed to different traffic paths, enabling the application of different strategies on different traffic volumes. For example, in an A / B testing scenario, it can process some user requests according to strategy A and others according to strategy B, allowing for a comparison of the effects of different strategies.

[0103] In its implementation, the traffic allocation module receives a user request and retrieves the pre-defined traffic allocation strategy and historical strategy examples. Then, based on the rules in the traffic allocation strategy and the experience of handling similar requests in the historical strategy examples, it determines the traffic allocation destination for this user request, thereby completing the traffic allocation for the user request.

[0104] In another feasible implementation, the traffic allocation execution module 40 of this embodiment is further configured to allocate traffic to the user request according to the traffic allocation strategy and the historical strategy case, and generate a routing result; the traffic allocation execution module 40 is further configured to monitor the deviation value between the routing result and the traffic allocation strategy according to the summary data structure; the traffic allocation execution module 40 is further configured to compensate the allocation probability of the routing result according to the preset compensation strategy when the deviation value reaches the preset deviation threshold, and return to execute the operation of allocating traffic to the user request according to the traffic allocation strategy and the historical strategy case according to the compensated allocation probability.

[0105] It's important to note that routing results are the actual allocation path or destination obtained after allocating user requests based on traffic distribution policies and historical policy cases. They reflect the actual flow of traffic within the network. For example, if a user request is assigned to a specific server A instead of server B based on these criteria, this "assignment to server A" result is the routing result.

[0106] Understandably, a summary data structure is a structure used to summarize and store relevant data, and can be used to monitor the deviation between routing results and traffic allocation policies. The deviation is a quantitative representation of the degree of difference between the routing results and the traffic allocation policy. For example, if the traffic allocation policy stipulates that a server should receive 30% of the traffic, but the actual routing results show that the server only receives 20% of the traffic, then the deviation is 10%.

[0107] It should be understood that the preset deviation threshold is a pre-set threshold used to determine whether the deviation value has reached a critical value that requires adjustment. If the deviation value exceeds the preset deviation threshold, it means that the current routing result deviates significantly from the traffic allocation strategy, triggering subsequent compensation operations.

[0108] The preset compensation strategy is an adjustment measure that corrects the routing results so that traffic allocation is now in line with the expected traffic allocation strategy. For example, it can increase or decrease the allocation probability of a certain allocation target by a certain proportion, or reallocate some traffic to other targets.

[0109] For example, to facilitate understanding of the implementation process of the traffic splitting execution module, such as Figure 3 As shown, the traffic allocation execution module, as the core execution component for traffic distribution, can adopt a microservice architecture to achieve highly available and high-performance routing decision services. During system initialization, the traffic allocation execution module can load the latest version allocation results from the configuration center and cache them in the local cache. When making allocation decisions for each user request, it will first check the Cookie information in the HTTP request header, parse the experimental group marker, and if the marker exists and is valid, it will directly return the version allocation result cached locally. For requests from new users or those not assigned to experimental groups, the above traffic allocation strategy will be converted into actual user routes. To ensure the accuracy and stability of traffic allocation, a sliding window algorithm can be used to count traffic during execution and monitor the traffic ratio of each version in real time. If normal, classification continues; if a deviation is detected that exceeds the preset deviation threshold (for example, when the actual allocation ratio is detected to deviate from the target value of the traffic allocation strategy by more than 2%), a three-level compensation is triggered: first, new user allocation is temporarily stopped for 10 seconds to stabilize the system state; then, based on the current deviation value, the correction coefficient is calculated using the least squares method with L2 regularization; finally, the allocation probability is dynamically adjusted through the PID controller to achieve gradual deviation compensation and gradually restore the target value.

[0110] During traffic distribution, the status monitoring process continuously tracks system performance metrics, including conversion rate fluctuations across versions, algorithm computation latency, and resource utilization. When an anomaly is detected (e.g., a sudden 30% drop in conversion rate for a particular version), an emergency response is immediately initiated. Traffic allocation for the problematic version is frozen, and the root cause analysis service is invoked for deviation detection. If the system is malfunctioning, the aforementioned traffic counts are alerted to the monitoring center via a real-time dashboard for manual intervention; if it's a temporary fluctuation, automatic recovery is implemented. The data feedback process logs the complete trajectory of each allocation decision, including key information such as user characteristics, allocation results, and execution time. This data is transmitted to the data warehouse via a real-time stream processing pipeline, used for both real-time monitoring dashboard updates and providing analytical support for updating decision engine parameters for strategy optimization. Data feedback during execution drives continuous optimization of the decision engine, and the updated parameters can be accessed via gRPC for real-time decision calculations within the decision engine module.

[0111] In this embodiment, the closed-loop design described above not only ensures millisecond-level real-time response capability but also achieves long-term performance optimization, ultimately reaching a leading level in traffic allocation accuracy and system availability.

[0112] In the technical solution provided in this embodiment, the strategy knowledge base guides the parameter adjustment of each module; the configuration management module configures the parameters of the traffic experiment submitted by the operators and generates standardized description files; the decision engine module assigns weights to the standardized description files based on a multi-armed slot machine model and outputs a traffic allocation strategy; the traffic allocation execution module, upon receiving a user request, allocates traffic to the user request according to the traffic allocation strategy and historical strategy cases, and drives decision optimization through feedback. This interlocking architecture design enables the system to have both real-time response capabilities and a long-term optimization perspective, completing traffic optimization in seconds while continuously accumulating strategy knowledge, ultimately achieving optimal allocation of marketing resources. This avoids the lag in traffic allocation caused by the static proportional allocation of existing traffic allocation mechanisms, improves configuration efficiency, and enables the dynamic optimal allocation of valuable traffic resources.

[0113] Based on the first embodiment of this application described above, a second embodiment of this application is proposed. In this second embodiment, content that is the same as or similar to that in the first embodiment can be referred to the above description and will not be repeated hereafter.

[0114] Based on this, the traffic allocation system also includes a strategy optimization module; the strategy optimization module includes an indicator evaluation submodule, a strategy generation submodule, and a version management submodule.

[0115] The indicator evaluation submodule is used to acquire user traffic consumption data, and when the key indicators of the traffic consumption data exceed the preset benchmark value, trigger a strategy optimization instruction and push the strategy optimization instruction to the strategy generation submodule; the strategy generation submodule is used to adjust the parameters of the traffic allocation strategy based on the strategy optimization instruction through a multi-objective optimization algorithm and generate a parameter adjustment scheme; the version management submodule is used to record the entire lifecycle of the traffic allocation strategy changes.

[0116] It's important to note that traffic consumption data is a collection of data related to user data usage. This includes the total amount of network traffic consumed by a user within a certain timeframe, and the distribution of traffic usage across different time periods. Key metrics are representative and important measures extracted from the traffic consumption data, such as conversion rates for different versions, system latency, and resource consumption. Preset benchmarks are pre-defined standard values ​​used to measure these key metrics.

[0117] Understandably, a strategy optimization command is a signal issued when key metrics of traffic consumption data exceed preset benchmark values, used to optimize the traffic allocation strategy. A multi-objective optimization algorithm is an algorithm that adjusts various parameters of the traffic allocation strategy (such as traffic quotas for different types of users, traffic priorities for different applications, etc.) to obtain a relatively optimal solution while satisfying multiple objectives. The parameter adjustment scheme is the result obtained after adjusting the traffic allocation strategy using the multi-objective optimization algorithm, clarifying which parameters in the traffic allocation strategy were adjusted and how.

[0118] For example, to facilitate understanding of the implementation process of the strategy optimization module, refer to... Figure 4 , Figure 4 This is a schematic diagram illustrating the adjustment process and relationships of the decision optimization module provided in Embodiment 2 of this application. Figure 4 As shown, the decision optimization module is divided into four sub-modules, including the indicator evaluation sub-module, the strategy generation sub-module, the canary release sub-module, and the version management sub-module.

[0119] The metrics evaluation submodule's process includes: real-time analysis of traffic consumption data inserted by the monitoring center, including key metrics such as conversion rates, system latency, and resource consumption for each version. Then, a sliding time window is used to calculate metric trends. When a key metric deviates from a preset benchmark value by more than 15%, a strategy optimization command is automatically triggered, and an evaluation report is generated; otherwise, the current strategy is maintained. During the evaluation process, business objective priorities (e.g., conversion rate weighting 70%) and system health (e.g., latency weighting 30%) are comprehensively considered to generate a comprehensive score as the basis for optimization.

[0120] The strategy generation submodule's process includes: adjusting traffic allocation strategy parameters based on a multi-objective optimization algorithm to generate a parameter adjustment plan. For new versions with consistently low conversion rates, the exploration weight will be increased (maximum adjustment range ±20%); in the face of resource constraints, the algorithm update frequency will be reduced (as low as 5 minutes / time). All strategy changes can be simulated using Monte Carlo simulations to predict their effects, ensuring the scientific validity of the adjustment plan. The generated parameter adjustment plan strategy package can contain complete version information, a set of changed parameters, and an expected impact assessment. Then, the version hash value of the strategy package is transmitted to the version control system for management.

[0121] The canary release submodule's process includes: adopting a gradual deployment strategy, the parameter adjustment plan is first tested on 5% of the traffic, and traffic tests are conducted to compare the differences in core indicators between the experimental group and the control group in real time. If the effect is satisfactory (such as improved conversion rate), it is gradually expanded to full release; if negative effects occur, it is automatically rolled back to the previous stable version. A circuit breaker mechanism is set up during the release process, and the release results are recorded. When the monitored key indicators deteriorate beyond the threshold, the release is immediately stopped.

[0122] The version management submodule's workflow includes: maintaining a complete lifecycle record of all traffic allocation policy changes. Each adjustment generates a unique version hash value, fully recording the change content, execution time, and operators. It supports policy rollback at any point in time, with rollback operations completed within one minute. It also supports version comparison and policy effect analysis, intuitively displaying the differences in performance between different policy versions and assisting in optimizing the policy knowledge base.

[0123] In this implementation, the closed-loop optimization mechanism of the strategy optimization module enables the system to continuously adapt to business changes, achieving an average annual improvement of over 25% in key indicators while ensuring service stability. It ensures that all parameter adjustments are made within preset boundaries, eliminating systemic risks caused by strategy errors.

[0124] Furthermore, the traffic allocation system described in this example also includes a real-time monitoring module, which comprises an intelligent early warning submodule, a root cause analysis submodule, and a handling feedback submodule. The intelligent early warning submodule is used to issue an early warning for the key indicator according to a preset early warning level when abnormal fluctuations of the key indicator are detected. The root cause analysis submodule is used to identify user groups and determine abnormal user characteristics through a decision tree algorithm after the early warning is triggered. The handling feedback submodule is used to search for historical handling cases in the strategy knowledge base based on the abnormal user characteristics and execute the historical handling cases.

[0125] It should be noted that the preset warning levels are pre-defined standards used to measure the severity of abnormal fluctuations in key indicators. For example, the warning levels can be divided into three levels: Level 1 warning indicates slight abnormal fluctuations in key indicators; Level 2 warning indicates moderate abnormal fluctuations; and Level 3 warning indicates severe abnormal fluctuations in key indicators.

[0126] Decision tree algorithms are classification and prediction algorithms capable of extracting user group characteristics related to abnormal fluctuations in key indicators from large amounts of user data. Abnormal user characteristics are unique data possessed by users whose key indicators fluctuate abnormally.

[0127] For example, to facilitate understanding of the early warning process and relationships of the above real-time monitoring module, please refer to... Figure 5 , Figure 5 This is a schematic diagram of the early warning process provided in Embodiment 2 of this application. Figure 5 As shown, the real-time monitoring module includes an intelligent early warning submodule, a root cause analysis submodule, and a response feedback submodule, which construct a three-layer closed-loop system of "intelligent early warning - root cause analysis - response feedback".

[0128] The intelligent early warning submodule's workflow includes: establishing a three-tiered early warning response mechanism. When abnormal fluctuations in indicators are detected, data quality is first reviewed, ignoring fluctuations caused by abnormal data collection or transmission; after confirming the problem, early warnings are issued according to severity: P0 level early warning (indicator drop >50%) triggers an audible and visual alarm and sends an SMS notification to the responsible person, requiring a response within 30 minutes; P1 level early warning (fluctuation >30%) automatically creates a fault work order; P2 level early warning (continuous deviation >10%) generates a to-do item and incorporates it into daily production inspection tasks. The early warning rules support automatic sensitivity adjustment for holiday modes to avoid false alarms.

[0129] The root cause analysis submodule's workflow includes: automatically starting upon alert triggering, it performs multi-dimensional analysis from multiple perspectives such as user profiles, traffic channels, and time dimensions. It identifies abnormal user group characteristics within user profiles using decision tree algorithms; performs time model analysis using Fourier transform to detect periodic fluctuation patterns; and employs hypothesis testing methods for channel comparison analysis to pinpoint problematic channels. The analysis results generate a visual diagnostic report, annotating potential root causes and confidence scores, supporting operations personnel in quickly locating issues.

[0130] The processing flow of the handling feedback submodule includes: for known problem patterns (such as CDN node failures), it automatically executes preset handling solutions by searching historical handling cases in the policy knowledge base; for new problem types, it recommends handling records of similar historical cases for reference; finally, it performs production inspection tasks. All handling actions and effect feedback are recorded and a case closure report is generated, including key information such as the scope of the problem's impact, handling timeliness, and recovery status. This report can be saved to the case knowledge base for optimizing the early warning model and the early warning knowledge base.

[0131] In this implementation, the intelligent early warning submodule can promptly detect abnormal fluctuations in key indicators and issue warnings according to their severity, enabling the system to react quickly to potential problems and prevent further escalation that could impact network operation and user experience. The root cause analysis submodule uses a decision tree algorithm to determine abnormal user characteristics, helping to accurately pinpoint the root cause of the problem. The handling feedback submodule searches and executes historical handling cases from the strategy knowledge base, leveraging past experience to quickly and effectively resolve current abnormal fluctuations in key indicators, reducing the time and cost of problem-solving.

[0132] Furthermore, the traffic allocation system described in this embodiment also includes an effect evaluation module; the effect evaluation module includes an indicator calculation submodule, a multidimensional analysis submodule, and a report generation submodule; the indicator calculation submodule is used to use a distributed Spark engine to calculate indicators on traffic consumption data and determine key indicators; the multidimensional analysis submodule is used to analyze traffic consumption data from multiple dimensions, obtain analysis results, and store the analysis results in the strategy knowledge base, wherein the multiple dimensions include at least one of time dimension, user dimension, and channel dimension; the report generation submodule is used to generate a traffic detection report based on the key indicators and the analysis results.

[0133] It's important to note that the distributed Spark engine is a computing framework for large-scale data processing. When handling massive amounts of traffic consumption data, it can efficiently perform computational operations on the data. The traffic monitoring report is a document or data report generated based on key metrics and analysis results. It integrates important information extracted from the traffic consumption data, including the overall situation of traffic consumption (reflected by key metrics) and traffic consumption characteristics under different dimensions (reflected by analysis results).

[0134] For example, to facilitate understanding of the implementation process of the effect evaluation module, refer to... Figure 6 , Figure 6 This is a schematic diagram of the effect evaluation process provided in Embodiment 2 of this application. Figure 6 As shown, the effect evaluation module includes a data preparation submodule, an indicator calculation submodule, a multidimensional analysis submodule, and a report generation submodule.

[0135] The data preparation submodule aggregates complete behavioral data from various experimental versions through a distributed acquisition system, including raw data sources such as exposure logs, clickstreams, and conversion orders. It employs a Lambda architecture to process the data stream, with a real-time channel handling the latest 5 minutes of data and batch processing handling all historical data daily. All data undergoes standardized cleaning, including user deduplication, outlier filtering, and field normalization, ultimately generating a wide-table dataset which is then stored in the data warehouse.

[0136] The metric calculation submodule automatically generates core metrics based on a predefined evaluation framework. The system has built-in multiple metric engine calculation templates, including basic metrics (such as conversion rate and click-through rate), composite metrics (such as ROI and user LTV), and custom metrics (supporting SQL expressions). The calculation process uses a distributed Spark engine, and tens of millions of data points can be fully calculated within minutes to generate a key metric cube, supporting real-time incremental updates to the metric library.

[0137] The multidimensional analysis submodule provides a comprehensive evaluation perspective. The time dimension supports granular analysis of trend changes at the minute / hour / day level; the user dimension supports hierarchical analysis based on the RFM model; and the channel dimension distinguishes the effectiveness differences between organic traffic and paid sources through comparative analysis.

[0138] The report generation submodule transforms analysis results into decision-making recommendations. It can automatically generate a complete conclusion report based on a report template engine, comprising four parts: "Experiment Overview - Core Findings - Detailed Insights - Action Recommendations." Employing dynamic layout technology, important conclusions are prioritized (e.g., significantly improved metrics are pinned), and the system automatically and intelligently suggests marking statistical and business significance, generating a traffic monitoring report, and saving it to the strategy knowledge base. The report supports both PDF and PPT output formats, and key charts include data source tags to ensure auditable results.

[0139] In this implementation, the quality of data during the preparation phase determines the computational accuracy, problems discovered through multidimensional analysis drive in-depth drilling, and automated reports encapsulate analytical insights. This closed-loop evaluation system shortens the experimental effect evaluation cycle from the traditional 3 days to 2 hours, while ensuring the comparability of results between different experiments through a standardized analytical framework.

[0140] Furthermore, the traffic allocation system described in this embodiment also includes a knowledge accumulation module, such as... Figure 7 As shown, Figure 7 This is a schematic diagram illustrating the business processes and relationships of the strategy knowledge base provided in Embodiment 2 of this application. The knowledge accumulation module is used to update the strategy knowledge base, including feature extraction, knowledge modeling, intelligent recommendation, and version management processes.

[0141] The feature extraction process utilizes an automated feature factory to process massive amounts of raw experimental data, transforming unstructured decision-making processes into analyzable knowledge assets. This process employs a three-layer feature extraction architecture: a foundation layer extracts multi-dimensional structured configuration parameters; an effect layer calculates key metrics; and a context layer labels semantic tags such as industry, scenario, and target audience. All features undergo standardized encoding and importance filtering, ultimately generating a unified knowledge representation vector, which is stored in a vector database, supporting millisecond-level similarity retrieval.

[0142] The knowledge modeling process constructs a knowledge management system for training multimodal models. Semantic encoding is performed on the experimental description text to capture abstract concepts such as "promotional sensitivity"; a strategy relationship graph is constructed using graph neural networks to analyze the derivative relationships between different solutions; and time series models are used to track and analyze the decay patterns of strategy effectiveness, thus forming a knowledge graph.

[0143] The intelligent recommendation process enables precise matching and delivery of knowledge. When operations personnel create new experimental requirements, the target text can be analyzed in real time to identify key intents such as "increasing repurchase rate." Similarity searches are performed in a knowledge base of tens of millions of entries to obtain similar cases. These similar cases are then mixed and sorted, and an interpretable report is generated and recommended to the vector database, taking into account performance metrics, scenario matching, and strategy novelty.

[0144] Version control processes ensure the continuous evolution of knowledge assets. Semantic version control records the changes made with each knowledge update: a three-dimensional comparison of corrections, revision numbers, and updates. A unique knowledge preservation mechanism periodically eliminates outdated strategies and automatically labels knowledge confidence levels.

[0145] In this implementation, feature extraction provides standardized input for knowledge modeling, intelligent recommendation feeds back into feature engineering optimization, and version management ensures the traceability of knowledge iteration. This closed-loop design increases the strategy reuse rate from the industry average of 20% to 65%, and shortens the new strategy development cycle by 60%. Through the four-dimensional knowledge governance system of "feature extraction - knowledge modeling - intelligent recommendation - version management," multimodal representation learning and intelligent recommendation are deeply integrated in terms of technical implementation.

[0146] In summary, the aforementioned multi-strategy traffic allocation system effectively solves the core problems in existing technologies, such as lagging traffic allocation, inefficient resource allocation, extensive strategy management, and lack of intelligent decision-making.

[0147] refer to Figure 8 Based on the aforementioned multi-strategy traffic allocation system, this application proposes a first embodiment of the multi-strategy traffic allocation method. Figure 8 This is a flowchart illustrating an embodiment of the multi-strategy traffic allocation method of this application.

[0148] In this embodiment, the method is applied to a multi-policy traffic allocation system, which includes a configuration management module, a policy knowledge base module, a decision engine module, and a traffic allocation execution module. The policy knowledge base module is connected to the configuration management module and the decision engine module, and stores a policy knowledge base, which includes historical policy cases and policy templates. The method includes steps S10 to S30:

[0149] Step S10: The configuration management module configures the traffic experiment parameters submitted by the operators according to the policy template and generates a standardized description file.

[0150] It's important to note that the strategy knowledge base module serves to store knowledge, including historical strategy cases and strategy templates. Historical strategy cases are examples of strategies used in past operations, recording the strategies employed in different scenarios and their effects. Strategy templates, on the other hand, are pre-defined strategy frameworks that define the basic structure and elements of a strategy, providing a template-based reference for developing new strategies. This allows operations personnel to quickly create and adjust strategies based on these templates.

[0151] Specifically, the strategy knowledge base module is the intelligent strategy asset center of the multi-strategy traffic allocation system. It can adopt an advanced data lake architecture to realize full lifecycle strategy management, and is divided into four parts: data acquisition layer, data processing layer, knowledge service layer and version control layer.

[0152] At the data acquisition layer, a highly available distributed data pipeline can be built based on Apache NiFi (a data ingestion and integration platform). Incremental data is extracted hourly from more than ten business systems, including user profiling systems, A / B testing platforms, and environmental monitoring services. This data includes structured data such as basic user attributes, version feature parameters, and environment variable configurations, as well as unstructured data such as user behavior event sequences, open text feedback, and interface operation logs.

[0153] At the data processing layer, the Spark MLlib (Apache Spark Machine Learning Library) distributed computing framework can be used to construct a policy feature vector space with multiple dimensions. Key feature dimensions include: historical version click pass rate, user lifetime value prediction model output value, sensitivity decay coefficient for different time periods, and other core indicators.

[0154] The knowledge service layer provides RESTful (Representational State Transfer) interfaces and flexible GraphQL (Graph Query Language) query interfaces. This knowledge service layer interacts with the subsequent configuration management module and decision engine module. When operations personnel initiate a new experiment creation request for multi-strategy adaptive traffic allocation for online experiments, the strategy knowledge base module first performs semantic understanding using the BERT (Bidirectional Encoder Representations from Transformers) deep learning model to accurately extract key feature words of the experiment target. Then, it performs similarity retrieval in the knowledge graph of the strategy knowledge base, which stores tens of millions of historical strategy cases, and returns strategy templates with complete configurations of the multiple optimal strategies with the highest matching degree, including detailed information such as parameter settings, rule combinations, and expected effects.

[0155] Furthermore, the strategy knowledge base module features a robust version control layer, supporting the rapid rollback of any experimental configuration to a specified historical version state. It also retains complete version change records and rollback audit logs, ensuring the traceability and security of strategy management. In this way, the strategy knowledge base module reliably enables intelligent management and efficient reuse of strategy assets, significantly improving the efficiency and quality of operational decision-making.

[0156] It should be noted that the configuration management module is responsible for managing and processing the traffic experiment parameters submitted by operations personnel. This includes configuring core parameters such as basic information settings for the experiment version (e.g., experiment name, business objectives), traffic allocation algorithm selection (e.g., UCB algorithm or Thompson sampling algorithm), and initial traffic ratio settings. Operations personnel can quickly initialize experiment parameters based on policy templates recommended by the policy knowledge base, and also support custom parameter adjustments to meet specific business needs.

[0157] Among them, traffic experiment parameters are various parameters set by operations personnel for conducting traffic-related experiments (such as A / B testing). These parameters include fully configured parameters such as experiment objectives, expected results, and technical parameters, providing initial setup conditions for traffic experiments and serving as the basis for parameter configuration in the configuration management module. Standardized description files are files generated after configuring core parameters such as algorithm type, traffic allocation ratio, and special rules according to the format specified in the policy template.

[0158] In its implementation, the configuration management module receives traffic experiment parameters submitted by operations personnel and compares and matches these parameters with pre-defined policy templates in the policy knowledge base. During the comparison process, it checks whether each parameter conforms to the format, value range, and other requirements specified in the policy template. For parameters that meet the requirements, they are organized according to the rules in the policy template, and a standardized description file is generated using the specific format and structure of the policy template.

[0159] In one feasible implementation, step S10 of this embodiment includes the following steps: the configuration management module performs multi-level review based on the traffic experiment parameters submitted by the operators to generate initial resources; the configuration management module performs similarity retrieval on the features of the initial resources in the policy knowledge base using cosine similarity to determine similar policy templates; the configuration management module configures parameters according to the similar policy templates to generate standardized description files, and sends the standardized description files to the decision engine module.

[0160] It should be noted that the initial resources are a type of resource generated based on the traffic experiment parameters submitted by the operations personnel after multiple levels of review. Examples include the initially allocated computing resource quotas and traffic pools.

[0161] Understandably, cosine similarity is a mathematical metric that measures the similarity between two vectors. In a policy knowledge base, the features of an initial resource can be represented as vectors, and then the degree of similarity between these vectors and the vectors in the policy knowledge base is determined by calculating their cosine similarity. When calculating the similarity between the initial resource and elements in the policy knowledge base, cosine similarity can effectively quantify this similarity relationship, thereby finding the most similar policy template.

[0162] In this implementation, the configuration management module, through multi-level review, ensures the accuracy and rationality of traffic experiment parameters, reducing the risk of experiment failure. Secondly, by utilizing cosine similarity to search for similar policy templates in the policy knowledge base, existing knowledge and experience are fully utilized, improving configuration efficiency and accuracy. Standardized description files are generated based on similar policy templates, making the entire traffic experiment configuration process more standardized and facilitating collaboration and interaction between different modules. This ensures both the standardization of the configuration process and the flexibility of business requirements, achieving a secure and efficient transformation from business needs to technical solutions.

[0163] Step S20: The decision engine module assigns weights to the standardized description file based on the multi-armed slot machine model and outputs a traffic allocation strategy.

[0164] It should be noted that the decision engine module is responsible for decision-making. As the intelligent hub of the multi-strategy traffic allocation system, it employs a multi-armed slot machine model to achieve fully automated management of the entire process from strategy configuration to allocation instruction generation. Since traffic configuration is performed in an uncertain environment, in this scenario, the decision engine module can assign weights to different strategy options based on the standardized description files generated by the configuration management module.

[0165] Understandably, the multi-armed slot machine model is the mathematical model upon which the decision engine module bases its weight allocation. In this model, different strategy options are analogous to different arms of a slot machine. Each arm (strategy option) has a different probability of winning (generating profit), but this probability is unknown. The model dynamically adjusts the weight allocation of each strategy option by continuously exploring (trying different strategies) and utilizing (selecting the better strategy based on existing information). In the context of traffic allocation, this is equivalent to continuously adjusting the proportion of each strategy in traffic allocation based on the estimated potential profits (such as traffic conversion effects).

[0166] It should be understood that a traffic allocation strategy is a plan used to guide the traffic distribution execution module in allocating user traffic to different targets or business segments. The traffic allocation strategy clarifies which specific services, pages, or functional modules different traffic sources or user groups should be directed to, and specifies the allocation ratios or priorities.

[0167] In its implementation, the decision engine module inputs the standardized description file generated by the configuration management module into the multi-armed slot machine model for evaluating various elements. Based on the model, a corresponding weight is assigned to each element, ultimately forming a traffic allocation strategy.

[0168] In one feasible implementation, step S20 of this embodiment includes the following steps: when the decision engine module receives a user request, it extracts features from the user request through a WASM filter to obtain user feature data; the decision engine module makes a traffic allocation decision based on the user feature data and the standardized description file through a multi-armed slot machine model to generate a traffic allocation strategy; and the decision engine module pushes the traffic allocation strategy to the traffic distribution execution module through a Kafka transaction message.

[0169] It's important to note that WASM (WebAssembly) filters extract specific device characteristics from user requests. For example, when a user sends a network request, this request may contain a lot of information, such as the request's origin, type, and parameters. WASM filters can sift through this complex request information and extract user characteristic data relevant to subsequent processing. This user characteristic data can include user device fingerprints, LBS (Location-Based Services Geo-Fencing) geofencing, and user behavior sequence embeddings, among others.

[0170] Understandably, Kafka transactional messages are a messaging mechanism provided by Kafka (a distributed stream processing platform) that guarantees message atomicity, consistency, isolation, and durability. The decision engine module pushes traffic allocation strategies to the traffic distribution execution module via Kafka transactional messages, ensuring that the traffic allocation strategies are accurately received and executed by the traffic distribution execution module.

[0171] Specifically, the core of the decision engine module can adopt an innovative layered architecture design, consisting of a bottom layer, a middle layer, and a top layer. The bottom layer consists of a high-performance Bayesian probability model library, which can use a distributed computing framework to dynamically maintain distribution parameters for each experimental version and update the posterior probability in real time. The middle layer is a dynamically weighted algorithm engine. In the critical first 24 hours after the start of the experiment, the Thompson sampling algorithm can be given an α% dominant weight. Thereafter, its weight is gradually reduced daily at an exponential decay rate of β%, while the decision weight of the UCB (Upper Confidence Bound) algorithm is linearly increased, achieving a smooth transition from exploration to utilization.

[0172] At the top layer is the business rules engine, which deeply integrates 14 types of core business rules, including but not limited to minimum traffic protection, dynamic budget constraints, time-sensitive adjustments, geographic targeting, intelligent device adaptation, precise user segmentation, conversion funnel optimization, intelligent fatigue control, competition isolation management, real-time compliance review, seasonal strategy adjustment, competitor defense response, automatic disaster recovery degradation, and precise cost control.

[0173] In this embodiment, the use of the multi-armed slot machine model enables a balance between exploring new allocation methods and utilizing existing experience during the traffic allocation decision-making process. This improves the accuracy and efficiency of decision-making, better adapts to the needs of different users and changes in different business scenarios, and provides efficient and reliable intelligent decision support capabilities for the business.

[0174] Step S30: Upon receiving a user request, the traffic allocation module allocates traffic to the user request according to the traffic allocation strategy and the historical strategy case.

[0175] It's important to note that the traffic allocation module distributes user requests based on the traffic allocation strategy output by the decision engine module and historical strategy cases in the strategy knowledge base. This allows different user requests to be directed to different traffic paths, enabling the application of different strategies on different traffic volumes. For example, in an A / B testing scenario, it can process some user requests according to strategy A and others according to strategy B, allowing for a comparison of the effects of different strategies.

[0176] In its implementation, the traffic allocation module receives a user request and retrieves the pre-defined traffic allocation strategy and historical strategy examples. Then, based on the rules in the traffic allocation strategy and the experience of handling similar requests in the historical strategy examples, it determines the traffic allocation destination for this user request, thereby completing the traffic allocation for the user request.

[0177] In the technical solution provided in this embodiment, the strategy knowledge base guides the parameter adjustment of each module; the configuration management module configures the parameters of the traffic experiment submitted by the operators and generates standardized description files; the decision engine module assigns weights to the standardized description files based on a multi-armed slot machine model and outputs a traffic allocation strategy; the traffic allocation execution module, upon receiving a user request, allocates traffic to the user request according to the traffic allocation strategy and historical strategy cases, and drives decision optimization through feedback. This interlocking architecture design enables the system to have both real-time response capabilities and a long-term optimization perspective, completing traffic optimization in seconds while continuously accumulating strategy knowledge, ultimately achieving optimal allocation of marketing resources. This avoids the lag in traffic allocation caused by the static proportional allocation of existing traffic allocation mechanisms, improves configuration efficiency, and enables the dynamic optimal allocation of valuable traffic resources.

[0178] Other embodiments or specific implementations of the multi-strategy traffic allocation method of this application can be found in the above-described system embodiments, and will not be repeated here.

[0179] The multi-strategy traffic allocation method provided in this application, applied to the multi-strategy traffic allocation system in the above embodiments, can solve the technical problem that the existing traffic allocation mechanism, which adopts a combination of static proportional allocation and manual intervention, is prone to traffic allocation lag and low configuration efficiency. Compared with the prior art, the beneficial effects of the multi-strategy traffic allocation method provided in this application are the same as those of the multi-strategy traffic allocation system provided in the above embodiments, and other technical features in the multi-strategy traffic allocation method are the same as those disclosed in the system of the above embodiments, and will not be repeated here.

[0180] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-strategy traffic allocation system and method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0181] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A multi-strategy traffic allocation system, characterized in that, The system includes: a strategy knowledge base module, a configuration management module, a decision engine module, and a traffic distribution and execution module; The strategy knowledge base module is connected to the configuration management module and the decision engine module, and stores a strategy knowledge base, which includes historical strategy cases and strategy templates. The configuration management module is used to configure the traffic experiment parameters submitted by the operators according to the strategy template and generate a standardized description file. The decision engine module is used to assign weights to the standardized description file based on the multi-armed slot machine model and output a traffic allocation strategy. The traffic allocation module is used to allocate traffic to the user request according to the traffic allocation strategy and the historical strategy case when a user request is received. The decision engine module is further configured to extract features from the user request using a WASM filter when a user request is received, thereby obtaining user feature data. The decision engine module is also used to make traffic allocation decisions based on the user feature data and the standardized description file through a multi-armed slot machine model, and generate a traffic allocation strategy. The decision engine module is also used to push the traffic allocation strategy to the traffic splitting execution module via Kafka transaction messages; The traffic allocation module is further configured to allocate traffic to the user request based on the traffic allocation strategy and the historical strategy cases, and generate routing results. The traffic splitting execution module is also used to monitor the deviation between the routing result and the traffic allocation strategy based on the summary data structure. The traffic allocation module is further configured to compensate the allocation probability of the routing result according to a preset compensation strategy when the deviation value reaches a preset deviation threshold, and return to execute the operation of allocating traffic to the user request according to the traffic allocation strategy and the historical strategy case based on the compensated allocation probability.

2. The system as described in claim 1, characterized in that, The configuration management module is also used to perform multi-level reviews based on the traffic experiment parameters submitted by the operators and generate initial resources. The configuration management module is also used to perform similarity retrieval of the features of the initial resource in the policy knowledge base using cosine similarity to determine similar policy templates; The configuration management module is also used to configure parameters according to the similar strategy template, generate a standardized description file, and send the standardized description file to the decision engine module.

3. The system as described in claim 1, characterized in that, The traffic allocation system also includes a strategy optimization module; the strategy optimization module includes an indicator evaluation submodule, a strategy generation submodule, and a version management submodule. The indicator evaluation submodule is used to obtain the user's traffic consumption data, and when the key indicators of the traffic consumption data exceed the preset benchmark value, trigger a strategy optimization instruction and push the strategy optimization instruction to the strategy generation submodule. The strategy generation submodule is used to adjust the parameters of the traffic allocation strategy based on the strategy optimization instructions and through a multi-objective optimization algorithm, and generate a parameter adjustment scheme. The version management submodule is used to record the entire lifecycle of the traffic allocation strategy changes.

4. The system as described in claim 3, characterized in that, The traffic distribution system also includes a real-time monitoring module, which includes an intelligent early warning submodule, a root cause analysis submodule, and a handling feedback submodule. The intelligent early warning submodule is used to issue an early warning to the key indicator according to a preset early warning level when abnormal fluctuations of the key indicator are detected. The root cause analysis submodule is used to identify user groups and determine abnormal user characteristics through a decision tree algorithm after the warning is triggered. The handling feedback submodule is used to search for historical handling cases in the policy knowledge base based on the abnormal user characteristics, and execute the historical handling cases.

5. The system as described in any one of claims 1 to 4, characterized in that, The traffic allocation system also includes an effectiveness evaluation module; the effectiveness evaluation module includes an indicator calculation submodule, a multidimensional analysis submodule, and a report generation submodule; The indicator calculation submodule is used to use a distributed Spark engine to calculate indicators on traffic consumption data and determine key indicators. The multidimensional analysis submodule is used to analyze traffic consumption data from multiple dimensions, obtain analysis results, and store the analysis results in the strategy knowledge base. The multiple dimensions include at least one of time dimension, user dimension, and channel dimension. The report generation submodule is used to generate a traffic detection report based on the key indicators and the analysis results.

6. A multi-strategy traffic allocation method, characterized in that, The method is applied to the multi-strategy traffic allocation system as described in claim 1, the system comprising a configuration management module, a strategy knowledge base module, a decision engine module, and a traffic allocation execution module; the method includes: The strategy knowledge base module is connected to the configuration management module and the decision engine module, and stores a strategy knowledge base, which includes historical strategy cases and strategy templates. The configuration management module configures the traffic experiment parameters submitted by the operators according to the policy template and generates a standardized description file. The decision engine module assigns weights to the standardized description file based on the multi-armed slot machine model and outputs a traffic allocation strategy. Upon receiving a user request, the traffic allocation module allocates traffic to the user request according to the traffic allocation strategy and the historical strategy cases.

7. The method as described in claim 6, characterized in that, The configuration management module configures the traffic experiment parameters submitted by the operations personnel according to the policy template and generates a standardized description file in the following steps: The configuration management module performs multi-level reviews based on the traffic experiment parameters submitted by the operations personnel and generates initial resources; The configuration management module uses cosine similarity to perform a similarity search on the features of the initial resource in the policy knowledge base to determine similar policy templates; The configuration management module configures parameters according to the similar strategy template, generates a standardized description file, and sends the standardized description file to the decision engine module.

Images