Intelligent OTA traffic identification method based on machine learning

Abstract

The invention discloses an intelligent OTA traffic identification method based on machine learning, and relates to the technical field of communication network security and artificial intelligence crossing, and the method comprises the steps: analyzing a hotel search request, and filtering abnormal traffic; predicting the shopping frequency and the conversion rate in real time; key influence factors are determined through SHAP analysis; grouping the requests and removing outliers; tTL is dynamically calculated; dividing the traffic into seven levels from P0 to P6 according to the PDCC and the conversion expression, and executing a differentiated caching or penetrating strategy; generating a structured cache key and writing the structured cache key into Redis; and a closed-loop optimization mechanism is constructed through full-link burying point and regular model retraining. The invention aims to solve the problem of resource mismatching caused by a static cache strategy and coarse-grained flow shunting in a traditional OTA system, obviously improve the cache hit rate and the response speed, reduce the cloud service cost, and realize collaborative optimization of the cost, the performance and the user experience.

Description

Technical Field

[0001] This invention relates to the field of communication network security and artificial intelligence, and in particular to a machine learning-based intelligent OTA traffic identification method. Background Technology

[0002] With the continuous expansion of online travel agency platforms, hotel search requests are growing exponentially, posing a severe challenge to the real-time response capabilities and resource scheduling efficiency of backend systems. Traditional caching mechanisms generally employ static caching time strategies and single-dimensional cache key designs, lacking the ability to dynamically perceive the intrinsic commercial value of traffic. This leads to a dual dilemma of unbalanced resource allocation and uncontrolled costs in high-concurrency scenarios. Especially in cloud-native architectures, the on-demand billing model for computing resources significantly amplifies the erosive effect of invalid or inefficient requests on operating costs, necessitating an intelligent caching system capable of accurately identifying traffic value and implementing differentiated processing accordingly.

[0003] Among these, machine learning-based traffic value identification and caching management technologies have become a key direction for optimizing the resource utilization efficiency of OTA platforms. This technology aims to construct a quantifiable and interpretable traffic value assessment model by analyzing multi-dimensional features in user search behavior, and then use this model to drive the dynamic adjustment of caching strategies. Its core objective is to achieve real-time penetration querying of high-value traffic to ensure user experience, while implementing efficient caching of low-value traffic to reduce the frequency of provider calls, thereby significantly reducing cloud service expenditures while maintaining service quality.

[0004] In current technologies, mainstream OTA platforms still widely rely on rule-based caching strategies, such as setting a fixed TTL for all requests or making coarse-grained caching decisions based solely on request frequency. These methods fail to capture the temporal patterns of user behavior and their correlation with commercial value, leading to high-value traffic being forced to repeatedly query caches due to premature cache expiration, missing optimal pricing windows. Simultaneously, a large number of low-conversion-potential requests continuously trigger real-time calculations, resulting in a severe waste of computing resources. Although some systems attempt to introduce simple statistical metrics as cache weight references, these metrics struggle to comprehensively reflect the true cost-effectiveness of traffic, especially failing to support the achievement of refined cost control targets such as Per Dollar Cloud Cost. Furthermore, existing caching architectures generally lack the ability to fuse and model multi-source behavioral data, failing to effectively utilize high-frequency distribution characteristics such as stay duration and adult count to guide cache key design and TTL calculation, resulting in consistently low cache hit rates and limited overall system performance. Summary of the Invention

[0005] The purpose of this invention is to provide a machine learning-based intelligent OTA traffic identification method to solve the resource mismatch problem caused by static caching strategies and coarse-grained traffic splitting in traditional OTA systems.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0007] A machine learning-based intelligent OTA traffic identification method includes the following specific steps:

[0008] Step 1: Receive hotel search requests from online travel agencies, parse and validate the parameters of the requests, extract key information such as check-in date, check-out date, number of rooms, number of adults, purchase price level and search timestamp, and perform abnormal traffic filtering. When the number of rooms detected is greater than 9, it is determined to be an invalid request and blocked.

[0009] Step 2: Call the deployed traffic value recognition model to evaluate the current request in real time. The model is built based on the LightGBM algorithm. The input includes a multi-dimensional feature vector containing days_since_base, ap, check_in_weekend, check_in_month, day_of_week, and check_in_day. The output is the shopping behavior prediction frequency and the predicted positive price conversion rate corresponding to the request.

[0010] Step 3: Apply the SHAP interpretability analysis framework to decompose the model decision-making process, calculate the contribution of each input feature to the final prediction result φᵢ, and determine the dominant influencing factors according to the contribution ranking. Among them, days_since_base and ap are identified as the features with the highest influence.

[0011] Step 4: Combine the prediction results with hotel identifier, check-in date, historical shopping frequency and conversion rate indicators to form four-dimensional data points, input them into the pre-trained K-means clusterer for grouping and classification, set the number of clusters to 6, use Euclidean distance as the similarity metric, and output the cluster number (cluster_result) to which the current request belongs.

[0012] Step 5: Perform Z-Score anomaly detection to exclude outlier data. Calculate the standardized score of the observed value x relative to the historical mean μ and standard deviation σ for the two key indicators of historical shopping frequency and conversion rate. If the absolute value exceeds the threshold of 3, it is marked as an anomaly and the subsequent caching process is terminated.

[0013] Step 6: Start the TTL intelligent calculation engine, where TTL is the cache lifecycle. First, query the preset behavior weight coefficient table based on the combination of the number of hotel stay days and the number of adults to obtain the shopping ratio weight of 0.386 and the pricing ratio weight of 0.667 corresponding to the number of hotel stay days = 1 day and the number of adults = 2. Combine this with the base cycle of 769 hours for weighted calculation to generate preliminary cache duration suggestions of 8.23 ​​hours for shopping_ttl and 11.47 hours for pricing_ttl.

[0014] Step 7: Introduce a cluster-driven dynamic adjustment mechanism. Based on the cluster_result value obtained in Step 4, select the TTL correction strategy. When cluster_result belongs to the lowest or second lowest cluster, set the final TTL to 0 minutes. When it belongs to the third lowest cluster, set it to 60 minutes. When it belongs to the popular hotel cluster, set it to 30 minutes. In other cases, use 240 minutes as the default value.

[0015] Step 8: Overlay the time dimension adjustment factor to obtain the hourly time period classification of the current system. If the current time is a high request volume but low success rate interval, introduce a 0.8 times decay coefficient to linearly reduce the TTL obtained in Step 7. Otherwise, keep the original duration unchanged and finally determine the cache life cycle of the data item corresponding to the request.

[0016] Step 9: Construct a hierarchical decision matrix based on PDCC cost metrics and L2B and L2P conversion performance, dividing traffic into seven levels from P0 to P6. Requests with PDCC less than 7% and with booking records are classified as P0 and directly access the pricing query engine to obtain real-time quotes. Requests with PDCC between 7% and 30% are further subdivided into P1 to P3 levels based on whether L2B meets the criteria and a caching priority strategy is implemented. Requests with PDCC greater than or equal to 30% are classified into P4 to P6 levels and subjected to long-term caching. All requests with more than 9 rooms are forcibly classified into P99 level and immediately rejected.

[0017] Step 10: For requests that need to be cached, generate a structured cache key cache_key in the format ota:cache:gtp_group_hotel_id_checkin_checkout_rooms_adults_children. Use the Redis persistent storage system to write the hotel quote data using the setex command. The TTL parameter is converted from the minute value output in step 8 by multiplying it by 60 to the second unit and then passed in.

[0018] Step 11: Embed a data collection module in the entire request processing chain to continuously record core business indicators such as cache hit status, end-to-end response latency, user click behavior, and order conversion results, and synchronize this feedback data to the big data platform in real time to update the training sample set;

[0019] Step 12: Periodically trigger the model retraining task, and re-optimize the LightGBM model parameters θ based on the latest accumulated data points, minimizing the bi-objective loss function. At the same time, strengthen the regularization term To mitigate the risk of overfitting, after training is complete, the new model is pushed to the online service cluster and the SHAP interpretation layer and cluster center configuration are updated.

[0020] The objective function of the LightGBM model in step 2 is defined as follows:

[0021]

[0022] in, To support a composite loss function that outputs both historical purchase frequency and conversion rate metrics, a gradient boosting tree structure is used to jointly optimize the prediction accuracy of the two target variables. This is a regularization term that includes the number of leaf nodes and the sum of squared weights, used to control model complexity and improve generalization ability.

[0023] The calculation of SHAP contribution in step 3 follows the formula:

[0024]

[0025] Where F represents the entire feature set, S is any subset that does not contain feature i, and f(S) represents the result of prediction using only the features in S. This method quantifies the marginal contribution of each feature to the final predicted value by traversing all possible feature combinations, thereby achieving complete transparency of the model's decision-making logic.

[0026] The Z-Score is calculated in step 5 as follows:

[0027]

[0028] Where x is the current observation, μ is the historical average shopping frequency or conversion rate of similar hotels in the past 24 hours, and σ is its corresponding standard deviation. The system updates the statistical values ​​of μ and σ every hour to ensure that the anomaly detection threshold can adapt to business fluctuations. The system immediately determines that the data point deviates from the normal distribution range and triggers a cleaning mechanism to prevent noise from interfering with subsequent clustering and TTL calculations.

[0029] The formula for calculating shopping_ttl in step 6 is as follows:

[0030]

[0031] Among them, the proportion of the Shopping distribution with Stay=1 day is 27 / 70, and the proportion of the Adults distribution with 2 people is 52 / 78. After normalization, the weight coefficients are 0.386 and 0.667 respectively. Similarly, pricing_ttl is calculated by cross-weighting the Pricing distribution and the Adults distribution. The two together constitute the dual-channel input source of the TTL initial value.

[0032] In step 9, the traffic value grading matrix is ​​strictly determined according to the Boolean conditions of PDCC numerical range and conversion behavior. The P0 level requires… Furthermore, it must possess genuine booking records and price verification procedures; P1 level requirements. and and Level P2 is within the same PDCC range but both conversion metrics failed to meet the standards; Level P3 has no conversion history; Levels P4 to P6 correspond to... Different combinations of transformation states are used, and each level is bound to a unique strategy type enumeration value to ensure the uniqueness and traceability of routing decisions.

[0033] In step 10, the generation rules for the cache key strictly follow the field order and separator specifications. gtp represents the global transaction protocol version number, group is the business group code, hotel_id is the unique identifier for the hotel, checkin and checkout are represented in YYYYMMDD format, and rooms, adults, and children are all integer values. Each field is connected by an English colon to form a globally unique string index, avoiding data overwriting or query failures due to key conflicts.

[0034] The data items collected in step 11 include, but are not limited to, cache hit flag, total time from receiving a response, whether a click occurred, whether the payment process was initiated, and whether a transaction was completed. All events carry a unique request ID and timestamp and are asynchronously transmitted to the data warehouse via a message queue. Daily aggregation generates reports to monitor the changing trends of key performance indicators such as cache hit rate, average response time, and overall conversion rate.

[0035] In step 12, the model retraining cycle is set to be executed once every 6 hours. The incremental learning mode is used to load only the sample data newly added in the last 6 hours. After training, A / B testing is performed to verify the improvement of the prediction accuracy of the new model on the retained samples. If the improvement is more than 1.5 percentage points relative to the old model, it will be automatically launched. Otherwise, the original model will be retained for further observation. At the same time, the training log will be stored in the audit database for subsequent backtracking analysis.

[0036] Compared with the prior art, the beneficial technical effects of the present invention are as follows:

[0037] This invention fundamentally solves the resource mismatch problem caused by static TTL strategies and coarse-grained traffic splitting mechanisms in traditional OTA systems by constructing an intelligent traffic management system that integrates machine learning and dynamic caching control. By introducing a value recognition architecture that combines LightGBM and SHAP, it achieves accurate quantification and interpretability assessment of the commercial potential of each search request, enabling the system to clearly distinguish between high-value and low-value traffic.

[0038] This invention combines K-means clustering analysis and Z-Score anomaly detection to establish an intelligent grouping mechanism based on user behavior patterns, enabling caching strategies to dynamically evolve with actual business distribution. By designing a dual-channel TTL calculation model driven by the number of hotel stay days and the number of adults, and embedding cluster affiliation and time period adjustment factors, it achieves fine-grained control of the cache lifecycle, significantly improving the balance between cache hit rate and data freshness.

[0039] This invention establishes a complete closed-loop feedback chain from data collection and model training to policy updates, enabling the system to continuously self-optimize and adapt to market changes without manual intervention. Under the guidance of a strict seven-level traffic classification strategy (P0 to P6), high-value traffic receives real-time penetration service to ensure user experience, while low-value traffic is efficiently cached to reduce the frequency of provider calls. Actual test data shows that the cache hit rate is improved by more than 30%, the system response speed is increased by 50%, and cloud service costs are reduced by more than 40%, successfully keeping the Per Dollar Cloud Cost indicator stable below 7%, and comprehensively achieving the triple optimization goals of cost, performance, and experience. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the overall technical solution architecture of the intelligent OTA traffic identification method based on machine learning proposed in this invention;

[0041] Figure 2 This is a schematic diagram of the core principle framework of the traffic value identification and interpretability analysis based on the fusion of LightGBM and SHAP in this invention. Detailed Implementation

[0042] The features and exemplary embodiments of various aspects of the present invention will now be described in detail. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present invention and not to limit the present invention. For those skilled in the art, the present invention can be practiced without some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present invention by illustrating examples of the invention.

[0043] Example 1

[0044] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0045] Currently, with the continuous expansion of online travel agency (OTA) platforms, hotel search requests are experiencing exponential growth, posing a severe challenge to the real-time response capabilities and resource scheduling efficiency of backend systems. Traditional caching mechanisms generally employ static caching time strategies and single-dimensional cache key designs, lacking the ability to dynamically perceive the intrinsic commercial value of traffic. This leads to a dual dilemma of resource allocation imbalance and cost overruns in high-concurrency scenarios. Especially in cloud-native architectures, the on-demand billing model for computing resources significantly amplifies the erosive effect of invalid or inefficient requests on operating costs, necessitating an intelligent caching system capable of accurately identifying traffic value and implementing differentiated processing accordingly. To address these technical issues, this invention proposes constructing an intelligent traffic management system that integrates machine learning and dynamic caching control. This system fundamentally solves the resource mismatch problem caused by static TTL strategies and coarse-grained traffic distribution mechanisms in traditional OTA systems and applies it to a machine learning-based intelligent OTA traffic identification method.

[0046] refer to Figure 1 This invention presents a schematic diagram illustrating the overall technical architecture of a machine learning-based intelligent OTA traffic identification method. The diagram showcases the complete data flow and control logic, from request reception, feature extraction, model inference, interpretability analysis, clustering, anomaly detection, TTL calculation, traffic classification, to cache writing and feedback loop. The core of this architecture lies in the deep coupling of LightGBM model prediction, SHAP interpretability analysis, K-means clustering, and Z-Score anomaly detection, forming an adaptive, interpretable, and optimizable intelligent decision engine. (Reference) Figure 2 The schematic diagram of the core principle framework of traffic value identification and interpretability analysis based on the fusion of LightGBM and SHAP in this invention further clarifies how the model transforms multi-dimensional behavioral characteristics into quantifiable business value indicators and achieves decision transparency through SHAP value decomposition.

[0047] Step 1: Receive hotel search requests from online travel agencies, parse and validate the parameters of the requests, extract key information such as check-in date, check-out date, number of rooms, number of adults, purchase price level, and search timestamp, and perform abnormal traffic filtering. When more than 9 rooms are detected, the request is deemed invalid and blocked.

[0048] Specifically, in step 1, the system receives hotel search requests encapsulated in standard HTTP / HTTPS protocols through the API gateway. The request body is in JSON format and includes fields such as checkin_date, checkout_date, num_rooms, num_adults, price_level, and timestamp. The parameter parsing module first verifies the data type and value range of each field. For example, checkin_date must be a valid date in YYYY-MM-DD format and cannot be earlier than the current system date; num_rooms must be an integer between 1 and 9. When the value of the num_rooms field is greater than 9, the system immediately returns an HTTP status code 400 and the error message "Requested room limit exceeded," logs the event as malicious crawling or test traffic, and triggers the security alarm module. The goal of this step is to perform preliminary cleaning before the request enters the core business logic, avoiding invalid requests from consuming valuable computing and storage resources. The key information of all legitimate requests is structured and stored in a request context object in memory for subsequent steps to access.

[0049] Step 2: Call the deployed traffic value recognition model to evaluate the current request in real time. The model is built based on the LightGBM algorithm. The input includes a multi-dimensional feature vector containing days_since_base, ap, check_in_weekend, check_in_month, day_of_week, and check_in_day. The output is the shopping behavior prediction frequency (shopping_count_pred) and the predicted positive price conversion rate (pos_rate_pred) corresponding to the request.

[0050] Specifically, in step 2, the feature engineering module first converts the raw parameters extracted in step 1 into standardized features required by the model. Here, `days_since_base` is the number of days between the check-in date and a fixed base date (e.g., January 1, 2020); `ap` is the purchase price level, normalized to the range of 0 to 1; `check_in_weekend` is a boolean value indicating whether the check-in date falls on a weekend; `check_in_month` is the integer value of the check-in month (1 to 12); `day_of_week` is the integer value of the day of the week corresponding to the check-in date (0 to 6); and `check_in_day` is the date of the check-in date (1 to 31). These features together constitute a 6-dimensional input vector. This vector is fed into the LightGBM model instance already loaded into memory. This model is a gradient boosting decision tree ensemble model, internally composed of multiple regression trees. Each tree performs a series of conditional judgments on the input features, and finally, the predicted values ​​of the leaf nodes of all trees are weighted and summed to obtain two continuous outputs: `shopping_count_pred` (predicting the number of times the user will initiate a price quote query in this session) and `pos_rate_pred` (predicting the probability that the user will ultimately complete the transaction at the correct price). The model service interface uses the gRPC protocol to ensure millisecond-level response latency. The training objective of the model is to maximize prediction accuracy while controlling complexity, and its objective function is defined as:

[0051]

[0052] in, To support a composite loss function with two outputs, This is a regularization term.

[0053] Step 3: The SHAP interpretability analysis framework is applied to decompose the model decision-making process, calculate the contribution of each input feature to the final prediction result φᵢ, and determine the dominant influencing factors according to the contribution ranking. Among them, days_since_base and ap are identified as the features with the highest influence.

[0054] Specifically, in step 3, after obtaining the model output from step 2, the SHAP interpreter module immediately initiates the SHAP value calculation process. This process, based on the Shapley value concept in cooperative game theory, precisely quantifies the marginal contribution of each feature to the final predicted value, and its calculation follows the formula:

[0055]

[0056] Where F represents the set of all 6 features, S is any subset excluding feature i, and f(S) represents the prediction result using only the features in S. By traversing all possible feature combinations, the system calculates a SHAP value for each feature. The absolute values ​​of these metrics directly reflect the importance of the feature to the current prediction. The system sorts the SHAP values ​​of all features in descending order of absolute value, and typically finds that days_since_base (reflecting booking lead time) and ap (reflecting price sensitivity) contribute the most. This analysis is not only used for internal debugging but also provides a basis for subsequent TTL calculations. For example, if the SHAP value of ap is extremely high, it indicates that price is the core driving factor for this request, and the caching strategy should focus more on pricing_ttl.

[0057] Step 4: Combine the prediction results with hotel identifier, check-in date, historical shopping frequency and conversion rate indicators to form four-dimensional data points, input them into the pre-trained K-means clusterer for grouping and classification, set the number of clusters to 6, use Euclidean distance as the similarity metric, and output the cluster number (cluster_result) to which the current request belongs.

[0058] Specifically, in step 4, the clustering feature vector consists of four elements: the hotel's unique identifier `hotel_id` (hash-mapped to an integer), the checkin date `checkin_date` (converted to the number of days from the base date), the `shopping_count_pred` output from step 2, and the `pos_rate_pred`. This four-dimensional vector is fed into a K-means clustering model pre-trained on historical data. The number of clusters `k` in this model is set to 6, and these 6 clusters represent different user-hotel interaction patterns, such as "high-value long-stay business travelers," "low-value short-stay leisure travelers," and "high-frequency searches for hotels near popular attractions." The clusterer calculates the Euclidean distance from this vector to the 6 cluster centers and assigns it to the nearest cluster, outputting an integer between 0 and 5 as `cluster_result`. The goal of this step is to group requests with similar behavioral patterns together in order to apply a uniform caching strategy that has been validated by historical data.

[0059] Step 5: Perform Z-Score anomaly detection to exclude outlier data. Calculate the standardized scores of the observed values ​​x relative to the historical mean μ and standard deviation σ for the two key indicators, shopping_count and pos_rate. If the absolute value exceeds the threshold of 3, it is marked as an anomaly and the subsequent caching process is terminated.

[0060] Specifically, in step 5, the system maintains a rolling window statistics module. This module updates four statistics—μ_shopping, σ_shopping, μ_pos, and σ_pos—for each hotel_id every hour. These statistics are calculated based on the historical real values ​​of all requests belonging to that hotel over the past 24 hours. For the current request, the system calculates... and .like or If the prediction result of the request deviates significantly from the normal distribution, it is considered that this may be due to data noise, model drift, or extremely rare events. To predict the standardized outlier score for shopping frequency, To predict the conversion rate of full-price items, a standardized anomaly score is used. μ_shopping represents the historical average actual shopping frequency of all requests for the same hotel over the past 24 hours, σ_shopping represents the standard deviation of the historical actual shopping frequency of all requests for the same hotel over the past 24 hours, μ_pos represents the historical average actual full-price conversion rate of all requests for the same hotel over the past 24 hours, and σ_pos represents the standard deviation of the historical actual full-price conversion rate of all requests for the same hotel over the past 24 hours. At this point, the system marks the request as an anomaly and skips the cache-related logic in steps 6 to 10, directly routing it to the real-time price query engine. This ensures that the user experience is not negatively affected by the anomaly prediction and prevents erroneous cached data from polluting the Redis database.

[0061] Step 6: Activate the cache lifecycle (TTL) intelligent calculation engine. First, query the preset behavior weight coefficient table based on the combination of the number of hotel stay days and the number of adults to obtain the shopping ratio weight of 0.386 and the pricing ratio weight of 0.667 corresponding to the number of hotel stay days = 1 day and the number of adults = 2. Combine the weighted calculation with the base period of 769 hours to generate preliminary cache duration suggestions of 8.23 ​​hours for shopping_tTL and 11.47 hours for pricing_tTL.

[0062] Specifically, in step 6, the TTL intelligent computing engine internally maintains a two-dimensional lookup table with row indices representing the number of nights stayed (1 to 30) and column indices representing the number of adults (1 to 8). Each cell in the table stores two pre-calculated weight coefficients: the proportion of Shopping distribution and the proportion of Pricing distribution. These proportions are derived through statistical analysis of massive amounts of historical data. For example, for a combination of 1 night's stay and 2 adults, its proportion among all requests generating Shopping behavior is 27 / 70≈0.386, and its proportion among all requests generating Pricing behavior is 52 / 78≈0.667. The engine queries this table based on the current request's number of nights stayed (calculated by subtracting the check-in date from the check-out date) and the number of adults to obtain the corresponding two weights. Then, it applies the following formulas for calculation:

[0063]

[0064]

[0065] in, The shopping behavior cache lifetime indicates how long the predicted user shopping interest remains valid. The TTL cache lifetime indicates how long a hotel price remains accurate and valid. The base period of 769 hours is the globally optimal average cache duration derived from historical data analysis. These two calculations constitute the dual-channel input source for the initial TTL value, serving the data freshness requirements of shopping and pricing behaviors, respectively.

[0066] Step 7: Introduce a cluster-driven dynamic adjustment mechanism. Based on the cluster_result value obtained in Step 4, select a TTL correction strategy. When cluster_result belongs to the lowest or second lowest cluster, set the final TTL to 0 minutes. When it belongs to the third lowest cluster, set it to 60 minutes. When it belongs to the popular hotel cluster, set it to 30 minutes. In other cases, use 240 minutes as the default value.

[0067] Specifically, in step 7, the system has a built-in TTL correction strategy mapping table that maps the six possible values ​​(0 to 5) of cluster_result to specific TTL minutes. The mapping rules are as follows: if cluster_result is 0 or 1 (representing the lowest or second lowest value traffic), then TTL_final = 0 minutes, meaning no caching is performed and each request is routed to the backend; if cluster_result is 2 (third lowest cluster), then TTL_final = 60 minutes; if cluster_result is 3 (identified as a popular hotel cluster), then TTL_final = 30 minutes to ensure high data freshness; if cluster_result is 4 or 5 (other high or medium value clusters), then TTL_final = 240 minutes, where TTL_final is the final cache lifetime. The goal of this step is to leverage the collective intelligence inherent in the clustering results to refine and contextualize the general TTL calculated in step 6, making it more aligned with the behavioral patterns of specific user groups.

[0068] Step 8: Overlay the time dimension adjustment factor to obtain the hourly time period classification (hour_cluster) of the current system. If the current time is a high request volume but low success rate interval, introduce a 0.8 times decay coefficient to linearly reduce the TTL obtained in Step 7. Otherwise, keep the original duration unchanged and finally determine the cache life cycle of the data item corresponding to the request.

[0069] Specifically, in step 8, the system maintains a 24-hour time period profile, which divides a day into several hour_clusters, such as "weekday morning peak" and "weekend night off-peak." Each hour_cluster is associated with a success rate metric (such as conversion rate). The system determines the hour_cluster to which an hour_cluster belongs based on the current system timestamp. If the hour_cluster is marked as "high request volume but low success rate" (e.g., late-night hours, with many price comparisons but very few orders), the system multiplies the TTL_final obtained in step 7 by a decay coefficient of 0.8 to shorten the cache time and encourage the system to try to obtain potentially changing real-time quotes more often during inefficient periods, thereby capturing potential conversion opportunities. Conversely, if the current time period is a high success rate period (e.g., weekday afternoon), then TTL_final remains unchanged. This step enables the caching strategy to adapt to time-based business fluctuations.

[0070] Step 9: Construct a hierarchical decision matrix based on the PDCC cost index and L2B and L2P conversion performance, and divide traffic into seven levels from P0 to P6. Requests with a PDCC of less than 7% and with booking records are classified as P0 and directly access the pricing query engine to obtain real-time quotes. Requests with a PDCC between 7% and 30% are further subdivided into P1 to P3 levels based on whether L2B meets the criteria and a caching priority strategy is implemented. Requests with a PDCC of 30% or more are classified into P4 to P6 levels and subjected to long-term caching. All requests with more than 9 rooms are forcibly classified into P99 level and immediately rejected.

[0071] Specifically, in step 9, the traffic tiering decision module first calculates the Per Dollar CloudCost (PDCC) metric for the current request, which combines the estimated cloud resource consumption cost with the expected revenue. Then, it queries the user's historical behavior database to obtain their L2B (lead-to-book conversion rate) and L2P (lead-to-pay conversion rate) metrics. Based on the PDCC value range and the Boolean conditions for L2B / L2P, the system strictly follows a preset matrix for judgment. Level P0 has the highest priority and enjoys cache-free penetration service; levels P1 to P3 have medium priority, prioritizing reading from the cache, and only penetrating if the cache is missed; levels P4 to P6 have low priority, forcing the use of the cache path, returning fallback data or an empty result even if the cache is invalid, to maximize cost savings. This seven-level matrix ensures the granularity and uniqueness of the traffic processing strategy.

[0072] Step 10: For requests that need to be cached, generate a structured cache key (cache_key) in the format ota:cache:gtp_group_hotel_id_checkin_checkout_rooms_adults_children. Use the Redis persistent storage system to write the hotel quote data using the setex command. The TTL parameter is converted from the minute value output in step 8 by multiplying it by 60 to the second unit and then passed in.

[0073] Specifically, in step 10, the cache key generator strictly concatenates strings according to the field order. `gtp` is the current global transaction protocol version number, `group` is the business group code, `hotel_id` is the hotel's unique numeric ID, `checkin` and `checkout` are represented in YYYYMMDD format, and `rooms`, `adults`, and `children` are all integer values. Each field is connected with a colon to form a globally unique string index. This design prevents key conflicts caused by incorrect field order or inconsistent formats. The generated `cache_key`, along with the complete hotel quote JSON data obtained from the supplier, is written to the cluster using the `setex` command on the Redis client. The second parameter of the `setex` command is... ,in The final cache lifetime is counted in seconds. Set a timer in minutes for the final cache lifetime to ensure that data expires automatically after the specified time.

[0074] Step 11: Embed a data collection module in the entire request processing chain to continuously record core business metrics such as cache hit status, end-to-end response latency, user click behavior, and order conversion results, and synchronize these feedback data to the big data platform in real time to update the training sample set.

[0075] Specifically, in step 11, the event tracking module is embedded as a lightweight proxy at various key nodes in the request processing. It records events including: cache query start / end time, cache hit / miss flags, backend quote query time, total response latency, whether the user clicked on a hotel card, whether they entered the order form page, and whether payment was completed. Each event carries a globally unique request_id and a timestamp accurate to milliseconds. These events are asynchronously and reliably transmitted to the Hadoop data warehouse via a Kafka message queue. Every morning, the ETL job aggregates these raw events, generating structured training samples. Each sample contains complete request features, model prediction results, actual user behavior tags (such as whether a deal was made), and cost metrics, providing high-quality data for model retraining.

[0076] Step 12: Periodically trigger the model retraining task, and re-optimize the LightGBM model parameters θ based on the latest accumulated data points, minimizing the bi-objective loss function. At the same time, strengthen the regularization term To mitigate the risk of overfitting, after training is complete, the new model is pushed to the online service cluster and the SHAP interpretation layer and cluster center configuration are updated.

[0077] Specifically, in step 12, the model retraining task is triggered every 6 hours by the Airflow workflow scheduler. The training task first loads incremental sample data from the data warehouse for the most recent 6 hours. During training, the optimizer uses a regularized gradient descent algorithm to iteratively update the model parameters θ to minimize the composite loss function. After training, the new model is A / B tested in an isolated shadow traffic environment, running in parallel with the online old model to compare its prediction accuracy on the retained validation set. If the accuracy of the new model is improved by more than 1.5 percentage points, the automated deployment pipeline packages it into a Docker image, pushes it to the Kubernetes cluster, and gracefully replaces the old model instance. At the same time, the new SHAP interpreter configuration and K-means cluster centers are also updated synchronously to ensure the consistency and advancement of the entire intelligent decision-making chain.

[0078] The above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape, and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A machine learning-based intelligent OTA traffic identification method, characterized in that: The specific steps include the following: Step 1: Receive hotel search requests from online travel agencies, and perform parameter parsing and legality verification on the requests; Step 2: Call the deployed traffic value recognition model to evaluate the current request in real time. The model is built based on the LightGBM algorithm. It takes a multi-dimensional feature vector as input and outputs the shopping behavior prediction frequency and full-price conversion rate corresponding to the request. Step 3: Apply the SHAP interpretability analysis framework to decompose the model decision-making process and calculate the contribution of each input feature to the final prediction result. The dominant influencing factors are determined based on their contribution ranking. Step 4: Combine the prediction results with hotel identifier, check-in date, historical shopping frequency and conversion rate indicators to form four-dimensional data points, input them into a pre-trained K-means clusterer for grouping and classification, set the number of clusters to 6, use Euclidean distance as the similarity metric, and output the cluster number to which the current request belongs. Step 5: Perform Z-Score anomaly detection to exclude outlier data. Calculate the standardized score of the observed value x relative to the historical mean μ and standard deviation σ for the two key indicators of historical shopping frequency and conversion rate. If the absolute value exceeds the threshold of 3, it is marked as an anomaly and the subsequent caching process is terminated. Step 6: Start the TTL intelligent calculation engine, query the preset behavior weight coefficient table based on the combination of the number of hotel stay days and the number of adults, obtain the corresponding weight coefficient, and perform weighted calculations in combination with the basic period of 769 hours to generate preliminary cache duration suggestions for shopping_ttl and pricing_ttl respectively, where TTL is the life cycle of the survival cache; Step 7: Introduce a cluster-driven dynamic adjustment mechanism and select a TTL correction strategy based on the cluster number value; Step 8: Overlay the time dimension adjustment factor to obtain the hourly time period classification of the current system, and determine the cache lifecycle of the data item corresponding to the request based on the classification.

2. The intelligent OTA traffic identification method based on machine learning according to claim 1, characterized in that: The parameter parsing in step 1 involves extracting key information such as check-in date, check-out date, number of rooms, number of adults, purchase price level, and search timestamp; the legality verification involves performing abnormal traffic filtering, and when the number of rooms detected is greater than 9, it is determined to be an invalid request and blocked.

3. The intelligent OTA traffic identification method based on machine learning according to claim 1, characterized in that: The multidimensional feature vector in step 2 includes days_since_base, ap, check_in_weekend, check_in_month, day_of_week, and check_in_day. Here, days_since_base is the number of days between the check-in date and a fixed base date; ap is the purchase price level, normalized to the range of 0 to 1; check_in_weekend is a Boolean value indicating whether the check-in date falls on a weekend; check_in_month is an integer value from 1 to 12 of the check-in month; day_of_week is an integer value from 0 to 6 of the day of the week corresponding to the check-in date; and check_in_day is the date from 1 to 31 of the check-in date.

4. The intelligent OTA traffic identification method based on machine learning according to claim 1, characterized in that: In step 7, the TTL correction strategy is as follows: when the cluster number belongs to the lowest or second lowest cluster, the final TTL is set to 0 minutes; when it belongs to the third lowest cluster, it is set to 60 minutes; when it belongs to the popular hotel cluster, it is set to 30 minutes; and in all other cases, 240 minutes is used as the default value. The mapping rule of the correction strategy is: when the cluster number is 0 or 1, the TTL is 0 minutes; when it is 2, the TTL is 60 minutes; when it is 3, the TTL is 30 minutes; and when it is 4 or 5, the TTL is 240 minutes.

5. The intelligent OTA traffic identification method based on machine learning according to claim 1, characterized in that: The method for determining step 8 is as follows: if the current time is in a high request volume but low success rate range, then a 0.8 times attenuation coefficient is introduced to linearly reduce the TTL obtained in step 7; otherwise, the original duration is maintained.

6. The intelligent OTA traffic identification method based on machine learning according to claim 1, characterized in that: The method also includes the following steps: Step 9: Construct a hierarchical decision matrix based on PDCC cost indicators and L2B and L2P conversion performance, and divide traffic into seven levels from P0 to P6; Step 10: For requests that need to be cached, generate a structured cache key in the format ota:cache:gtp_group_hotel_id_checkin_checkout_rooms_adults_children. Use the Redis persistent storage system to write the hotel quote data using the setex command. The TTL parameter is converted from the minute value output in step 8 by multiplying it by 60 to the second unit and then passed in. Step 11: Embed a data collection module throughout the entire request processing chain to continuously record core business metrics and synchronize this feedback data to the big data platform in real time for updating the training sample set; Step 12: Periodically trigger the model retraining task, and re-optimize the LightGBM model parameters θ based on the latest accumulated data points, minimizing the bi-objective loss function. At the same time, strengthen the regularization term To mitigate the risk of overfitting, after training is complete, the new model is pushed to the online service cluster and the SHAP interpretation layer and cluster center configuration are updated.

7. The intelligent OTA traffic identification method based on machine learning according to claim 6, characterized in that, In step 9, PDCC integrates the estimated cloud resource consumption cost and expected benefits; The L2B refers to the conversion rate from lead to booking; the L2P refers to the conversion rate from lead to payment; the traffic grading criteria for the metrics include: P0 level requirements. And must have genuine booking records and price verification; P1 level requirements and and Level P2 is within the same PDCC range but both conversion metrics failed to meet the standards; Level P3 has no conversion history; Levels P4 to P6 correspond to... Different combinations of transformation states.

8. The intelligent OTA traffic identification method based on machine learning according to claim 6, characterized in that: In the cache key generation rule of step 10, gtp is the global transaction protocol version number, group is the business group code, hotel_id is the hotel unique identifier, checkin and checkout are represented in YYYYMMDD format, rooms, adults, and children are all integer values, and the fields are connected by English colons.

9. The intelligent OTA traffic identification method based on machine learning according to claim 6, characterized in that: The core business metrics in step 11 include: cache hit status, end-to-end response latency, user click behavior, and order conversion results; the data items collected by the tracking points include cache hit flag, end-to-end response latency, user click behavior, whether the payment process has been entered, and whether the order has been completed. All events carry a unique request ID and timestamp and are asynchronously transmitted to the data warehouse through a message queue.

10. The intelligent OTA traffic identification method based on machine learning according to claim 6, characterized in that: In step 12, the model retraining cycle is performed every 6 hours. The incremental learning mode is used to load the newly added sample data in the last 6 hours. After training is completed, A / B testing is performed. If the prediction accuracy of the new model on the retained samples is improved by more than 1.5 percentage points compared with the old model, it will be automatically launched.

Images