Saas platform-based click farming behavior judgment method and system for historical behaviors of designated driver

Abstract

The invention discloses a scalping behavior judgment method and system based on saas platform designated driver historical behaviors. The invention relates to the technical field of saas platforms. Installing and configuring an Flink stream processing system, including setting parameters of a cluster mode, the number of task managers and the number of slots; creating an Flink job, and defining logic of a data source, data conversion and a data sink (Sink); and starting the Flink operation to ensure that the stream processing environment can normally receive and process real-time data. Acquiring driver historical behavior data from a designated driving SaaS platform, wherein the driver historical behavior data comprises order information; according to the method, multiple independent variables such as the order speed, the mileage and the duration are comprehensively considered, the scalping risk assessment model is constructed, and the scalping behavior can be recognized more accurately. The order data is processed and calculated in real time by using the Flink stream processing system, so that risk calculation can be immediately triggered when the driver completes the order, and the timeliness of identification is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of SaaS platform, and in particular to a method for detecting fake orders on a SaaS online car-hailing platform, and in particular to a method and system for judging fake order behavior based on the historical behavior of designated drivers on the SaaS platform. Background Art

[0002] There are significant deficiencies and limitations in the identification strategy for fake orders in designated driver services. Although some methods have tried to identify fake orders by analyzing the overlap between the driver and the passenger's travel trajectory, the actual application effect of this strategy is not ideal. The reason is that the complexity of fake orders far exceeds the scope that such simple overlap analysis can handle.

[0003] In addition, in the environment of the designated driver SaaS (Software-as-a-Service) platform, fake order behavior is more complex and hidden. Because drivers can move between different tenants, their behavior becomes more difficult to track and identify. In this case, the traditional analysis method that relies on the driver's historical behavior data becomes stretched and unable to accurately assess the driver's risk of fake orders. This is because the driver's historical behavior data is often affected by multiple factors, including but not limited to service frequency, service location, passenger type, etc., and these factors become more complex and changeable when the driver moves across tenants.

[0004] To this end, the present invention proposes a method and system for judging the order-brushing behavior based on the historical behavior of designated drivers on a SaaS platform. Summary of the invention

[0005] In view of this, the present invention hopes to provide a method and system for judging order-brushing behavior based on the historical behavior of designated driver on SaaS platform, so as to solve or alleviate the technical problems existing in the prior art, that is, how to receive and process order data in real time through message middleware combined with flink for offline data under the premise of multiple independent variables, and automatically trigger relevant risk calculation when the driver completes the order, and take relevant measures if high risk is hit; the technical solution of the present invention is implemented as follows:

[0006] First, the method of judging the fake order behavior based on the historical behavior of the designated driver on the SaaS platform:

[0007] 1. Overview:

[0008] The present invention aims to achieve accurate identification and effective containment of order-brushing behavior in designated driver services by comprehensively using big data processing technology and machine learning algorithms. The solution first collects and integrates the driver's registration information, historical behavior data and real-time order data, and uses the Flink stream processing system to efficiently process the real-time data to extract key indicators such as driving speed, mileage and duration. At the same time, offline data analysis is used to calculate the driver's historical daily average number of completed orders, market comparison indicators, etc., to build a comprehensive driver behavior portrait. On this basis, the order-brushing risk assessment model is applied, combined with real-time order data and historical indicators, to calculate the driver's order-brushing risk score, and take corresponding disposal measures according to the risk level. In addition, the solution also uses high-performance database technologies such as HBase and Redis to ensure fast storage and access to data, providing strong support for real-time risk calculation and subsequent disposal.

[0009] (II) Technical solution:

[0010] To achieve the above technical objectives, upon receiving identification instructions for offline data analysis and real-time risk monitoring, the present invention selects to execute the following operation steps.

[0011] 2.1 Step S1, data preparation and initialization:

[0012] Load the latest driver registration information, initialize the message middleware and Flink stream processing environment, and prepare for real-time data processing.

[0013] 2.1.1 Step S100, load the latest driver registration information:

[0014] Connect to the database of the designated driver SaaS platform and obtain the latest driver registration information through SQL query or API call.

[0015] Verify and clean the acquired data to ensure data integrity and accuracy. Load the cleaned driver registration information into memory or cache for quick access during subsequent real-time processing.

[0016] 2.1.2 Step S101, initializing the message middleware:

[0017] Configure the server address, port, and topic parameters of the message middleware (such as Kafka). Create or connect the consumer and producer clients of the message middleware.

[0018] 2.1.3 Step S102, initialize the Flink stream processing environment:

[0019] Install and configure the Flink stream processing system, including setting the cluster mode, number of task managers, and number of slots; create a Flink job, define the logic of data source, data transformation, and data sink; start the Flink job and ensure that the stream processing environment can normally receive and process real-time data.

[0020] 2.2 Step S2, offline data collection and storage:

[0021] Collect driver historical behavior data from the designated driver SaaS platform, including order information, driving trajectory and timestamp; clean and organize the collected data and store it in the data warehouse.

[0022] 2.2.1 Step S200, collecting driver historical behavior data:

[0023] Connect to the database or API interface of the designated driver SaaS platform to obtain the driver's historical behavior data; define the scope and time period of data collection; transfer data from the designated driver SaaS platform to the local server or data warehouse;

[0024] 2.2.2 Step S201, data cleaning and organization:

[0025] Preprocess the collected data, including removing duplicate data, filling missing values, converting data formats, etc.

[0026] Screen and filter the data according to analysis requirements, retain the required fields and information; organize the data into a structured format, such as a table or JSON file, for subsequent storage and analysis.

[0027] 2.2.3 Step S202, data is stored in the data warehouse:

[0028] Import data into the data warehouse according to the table structure, index and optimize the data in the data warehouse, and improve the efficiency of data query and analysis.

[0029] 2.3 Step S3, offline data analysis and indicator calculation (T+1):

[0030] The scheduled task is triggered to query the historical data of drivers and orders; calculate the historical average daily number of orders completed by drivers, the average daily number of orders completed by drivers in the market, the average speed, average mileage and average duration of orders in the market; update the calculated indicator data to the indicator library in HBase for subsequent use.

[0031] 2.3.1 Step S300, scheduled task triggering

[0032] Set up scheduled tasks (using Cron expressions) to determine the frequency and time of task execution;

[0033] Configure a task scheduling system that can trigger and execute scheduled tasks on time.

[0034] 2.3.2 Step S301, query driver and order history data:

[0035] Connect to data warehouse or database to obtain historical data of drivers and orders;

[0036] Filter and screen data based on analysis needs; load data into memory or temporary storage.

[0037] 2.3.3 Step S302, calculate index data

[0038] Calculate the average number of orders completed by each driver in the past day.

[0039] Calculate the average number of orders completed per day by all drivers in the market, that is, the average number of orders completed by all drivers in the past day;

[0040] Calculate the average speed, mileage and duration of all orders, that is, the average speed, mileage and duration of all orders;

[0041] The calculated indicator data is written into the HBase indicator library according to the predetermined format and structure.

[0042] 2.4 Step S4, real-time data processing and caching:

[0043] The message middleware receives the order data sent by the designated driver SaaS platform in real time; the Flink stream processing system processes the received order data in real time and calculates the driving speed, mileage and driving time of the order; the processed data is cached in Redis for fast access and subsequent risk calculation.

[0044] 2.4.1 Step S400, the message middleware receives order data:

[0045] Configure the consumer client of the message middleware (Kafka) to receive the order data sent by the designated driver SaaS platform in real time; pass the parsed data to the Flink stream processing system for subsequent processing;

[0046] 2.4.2 Step S401, Flink stream processing system processes data in real time:

[0047] Based on the data stream processing logic predefined in the Flink stream processing system, including data conversion and calculation operations, the received order data is processed in real time to calculate the driving speed, mileage and driving time indicators of the order.

[0048] 2.4.3 Step S402: Cache processed data

[0049] Write the processed data into the Redis cache according to the predetermined format and structure; set the data cache time and expiration policy to ensure the timeliness and effectiveness of the cached data.

[0050] 2.5 Step S5, risk calculation when order is completed:

[0051] When a driver completes an order, the risk calculation process is triggered: the driver's real-time order data and historical indicator data are obtained from Redis; the difference between the driver's order indicator for the day and the market, as well as the difference between the order indicator and the market, is calculated; the calculated difference is input into the order-brushing risk assessment model; the model calculates the driver's order-brushing risk score based on the preset coefficients and formulas; risk classification is performed based on the order-brushing risk score to determine the driver's risk level;

[0052] Take appropriate measures based on the driver's risk level, including sending warning messages, restricting orders, and / or suspending services.

[0053] 2.5.1 Step S500, triggering the risk calculation process:

[0054] Monitor order completion events. When the driver completes the order, trigger the risk calculation process in real time. Obtain the unique identifier of the order (such as the order ID) so that relevant data can be queried from Redis later.

[0055] 2.5.2 Step S501, obtain real-time order data and historical indicator data

[0056] Based on the order ID, query the driver's real-time order data from Redis, including driving speed, mileage, and driving time; query the driver's historical indicator data from the HBase indicator library, including the historical average daily number of completed orders, the average daily number of completed orders by drivers in the market, and the average speed, mileage, and duration of orders in the market; load the real-time order data and historical indicator data into memory for subsequent calculations.

[0057] 2.5.3 Step S502, calculate the difference:

[0058] Calculate the difference between the driver's order indicators (number of completed orders, average speed, average mileage and average driving time) on the day and the corresponding indicators of the market; calculate the difference between the indicators of the order (driving speed, mileage and driving time) and the corresponding average of the market;

[0059] 2.5.4 Step S503, input risk assessment model:

[0060] The calculated difference is used as the input feature and input into the fraud risk assessment model;

[0061] The model weights and calculates the input features according to the preset coefficients and formulas to derive the driver's fraud risk score;

[0062] 2.5.5 Step S504, risk classification and disposal:

[0063] According to the risk score, the driver's risk level is divided into different levels (low risk, medium risk, high risk); according to the driver's risk level, take corresponding disposal measures:

[0064] Low risk: no special measures, continue monitoring;

[0065] Medium risk: Send a warning message to the driver to remind him to pay attention to behavioral norms;

[0066] High risk: Limit the number of trips the driver can accept or suspend their service qualifications, and conduct further investigation.

[0067] (III) Mechanism for solving technical problems:

[0068] 3.1 Mechanism Overview:

[0069] The message middleware receives the order data sent by the designated driver SaaS platform in real time. The Flink stream processing system processes the received order data in real time, extracts key indicators such as driving speed, mileage, duration, etc., and caches the processed data in Redis. When the driver completes the order, the risk calculation process is automatically triggered. Get the driver's real-time order data and historical indicator data from Redis. Apply the order-brushing risk assessment model, combine multiple independent variables (such as order speed, mileage, duration, etc.) and historical data to calculate the driver's order-brushing risk score. Risk grading is performed based on the order-brushing risk score. If the driver is judged to be at high risk, the corresponding disposal measures are automatically triggered, such as sending warning messages, restricting orders, suspending services, etc.

[0070] 3.2 Principle explanation:

[0071] The core lies in data. By collecting and analyzing a large amount of offline data, driver behavior profiles are constructed to provide a basis for real-time risk calculation. The access and processing of real-time order data enables risk calculation to be based on the latest order information, improving the accuracy and timeliness of identification. The efficient real-time processing capabilities of the Flink stream processing system are used to process and calculate order data in real time to ensure the timeliness and accuracy of the data. High-performance caching technologies such as Redis are used to improve data access speed and reduce system latency.

[0072] The risk assessment model is built based on multiple independent variables, which can comprehensively consider multiple factors and improve the accuracy of identification. According to the risk classification results, the corresponding disposal measures are automatically triggered to achieve rapid response and effectively curb the behavior of fake orders.

[0073] Secondly, a system for judging fake orders based on the historical behavior of designated drivers on the SaaS platform:

[0074] like Figure 3 As shown, the system is used to implement the above-mentioned method and system for judging the fake order behavior based on the historical behavior of the designated driver on the SaaS platform, which includes:

[0075] (1) Load the latest driver registration information and initialize the data preparation and initialization module of the message middleware (such as Kafka) and Flink stream processing environment: interact with the database of the designated driver SaaS platform to obtain driver registration information; configure and start the message middleware and Flink stream processing environment to provide real-time data processing capabilities for subsequent modules.

[0076] (2) Offline data collection and storage module that collects driver historical behavior data from the designated driver SaaS platform: including order information, driving trajectory and timestamp; cleans and organizes the data and stores it in a data warehouse (such as Hive or HDFS). Interact with the API or database of the designated driver SaaS platform to obtain historical data; use ETL (Extract, Transform, Load) tools to clean and organize the data; write the data into the data warehouse for use by subsequent modules.

[0077] (3) Offline data analysis and index calculation module that calculates the average number of orders completed by drivers on a single day, the average number of orders completed by drivers on a single day, and the average speed, mileage, and duration of orders on a single day: Scheduled task triggering, querying driver and order history data; updating the calculated index data to the index library in HBase. Read historical data from the data warehouse; use data analysis tools and algorithms to calculate indicators; write the calculation results to the HBase index library for use by the real-time data processing and risk calculation modules.

[0078] (4) The real-time data processing and caching module of the message middleware that receives the order data sent by the designated driver SaaS platform in real time: The Flink stream processing system processes the received order data in real time, calculates the driving speed, mileage and driving time of the order; and caches the processed data in Redis. Interact with the message middleware to receive real-time order data; use the Flink stream processing system to process the order data in real time; write the processed data into the Redis cache for quick access by the risk calculation module.

[0079] (5) When the driver completes an order, the risk calculation and disposal module of the risk calculation process is triggered: the driver's real-time order data and historical indicator data in HBase are obtained from Redis; the difference between the driver's order indicator on that day and the market, as well as the difference between the driver's order indicator and the market are calculated; the calculated difference is input into the order-padding risk assessment model; the model calculates the driver's order-padding risk score based on the preset coefficients and formulas; the risk is graded according to the risk score, and corresponding disposal measures are taken.

[0080] Connect with Redis and HBase to obtain real-time and historical data; use the fake order risk assessment model to calculate the risk score; and take corresponding measures based on the risk score, including sending warning messages, restricting orders, and / or suspending services.

[0081] Compared with the prior art, the present invention has the following beneficial effects:

[0082] 1. Improve the accuracy and timeliness of order-brushing behavior identification: This invention builds an order-brushing risk assessment model by comprehensively considering multiple independent variables such as order speed, mileage, and duration, which can more accurately identify order-brushing behavior. The Flink stream processing system is used to process and calculate order data in real time to ensure that risk calculation can be triggered immediately when the driver completes the order, thereby improving the timeliness of identification.

[0083] 2. Maintaining a fair competition environment in the designated driver market: Through automatically triggered risk calculation and disposal measures, it is possible to effectively curb the occurrence of fake orders and maintain a fair competition environment in the designated driver market. Reducing fake orders means more authentic order data and driver service evaluations, which helps improve the overall quality of designated driver services.

[0084] 3. Protect the legitimate rights and interests of drivers and passengers: Fake orders often lead to the normal drivers' opportunities to receive orders being squeezed out. By cracking down on fake orders, the opportunities and income of normal drivers can be protected. Fake orders may involve false orders and services, posing a potential threat to the safety of passengers. Through this invention, it can be ensured that passengers receive real and reliable designated driver services.

[0085] 4. Improve platform operation efficiency and management level: This invention reduces the need for manual intervention and improves the platform's operation efficiency through automated data processing and risk calculation processes. By collecting and analyzing large amounts of data, the platform can more accurately understand the behavior and needs of drivers and passengers, providing strong support for decision-making. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0087] Figure 1 It is a schematic diagram of the method of the present invention;

[0088] Figure 2 It is a schematic diagram of the execution flow of the method of the present invention;

[0089] Figure 3 It is a schematic diagram of the system composition of the present invention. DETAILED DESCRIPTION

[0090] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0091] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0092] Explanation of relevant terms:

[0093] (1) Driver registration information: a data set containing basic information such as driver personal information and identity authentication.

[0094] (2) Flink stream processing environment: a high-performance, distributed computing environment that supports real-time data stream processing.

[0095] (3) Flink stream processing system: a software system that runs in the Flink stream processing environment and is used to process and analyze data streams in real time.

[0096] (4) Order information: data recording the details of each order for the designated driver service, such as the starting point, end point, and fee.

[0097] (5) Driving trajectory: data describing the driving path of the vehicle during the designated driver service.

[0098] (6) Timestamp: A mark that records the time when an event occurs, used to determine the timing of data.

[0099] (7) Historical daily average number of completed orders: the average number of orders completed by the driver per day over a certain period of time in the past.

[0100] (8) Average number of orders completed per day by all drivers: This is the overall statistics of the average number of orders completed per day by all drivers in a certain period of time.

[0101] (9) Average speed of market orders: the average speed of vehicles traveling in all orders.

[0102] (10) Average mileage and average service time: refer to the average mileage and average service time of all orders respectively.

[0103] (11) HBase: A distributed, column-based database used to store large-scale structured data and supports fast random read and write.

[0104] (12) Redis: A high-performance key-value storage database, commonly used for caching data and supporting fast data read and write operations.

[0105] (13) Fake order risk score: A numerical value calculated by an algorithm model that reflects the risk level of a driver engaging in fake order behavior.

[0106] Embodiment 1: Figures 1-2 As shown, this embodiment discloses a method for judging the order-brushing behavior based on the historical behavior of the designated driver on the SaaS platform; the process is as follows:

[0107] P1. Driver registration: When a new driver registers on the platform, the system generates a unique ID for the entire platform, called unionId. This ID will serve as the key identifier for all subsequent data processing and association.

[0108] Example: Driver Zhang San registers and the system assigns him unionId U123456.

[0109] P2. Offline collection of driver historical behavior data: The system regularly (such as daily) collects the driver's historical behavior data on the platform from the platform database, including order information, driving trajectory, timestamp, etc., and stores it in the data warehouse after cleaning and sorting.

[0110] Example: Collect the order data of driver Zhang San in the past six months, including order ID, starting and ending points, driving time, mileage, order status, etc.

[0111] P3, T+1 offline scheduled task calculation indicator data:

[0112] A. Get the current drivers: The system queries the unionId list of the current drivers.

[0113] B. Obtain historical data: For each driver in service, the system obtains historical data for the past six months from the data warehouse based on its unionId. Calculate indicators such as the historical average daily number of orders completed by each driver, the average daily number of orders completed by drivers in the market, and the average speed, average mileage, and average duration of orders in the market.

[0114] C. Update the indicator library: Update the calculated indicator data to the indicator library in HBase for use in subsequent real-time risk calculations.

[0115] Example: Calculate the average daily number of orders completed by driver Zhang San in the past six months, which is 10 orders / day, the average daily number of orders completed by drivers in the market is 8 orders / day, the average speed of orders in the market is 30km / h, the average mileage is 10km, and the average duration is 20 minutes, and update these data to HBase.

[0116] P4. Order trip ends, calculate order data: When the driver completes the order, the system calculates the driving speed, mileage, driving time and other data of the order in real time.

[0117] Example: Driver Zhang San completed a trip. The system calculated that the driving speed was 35km / h, the mileage was 12km, and the driving time was 25 minutes.

[0118] P5. Calculate the driver's daily indicator data: The system calculates the driver's daily order volume, average order driving speed, average order mileage, average order driving time and other indicators based on all the driver's order data on that day.

[0119] Example: Driver Zhang San completed 12 orders on that day, with an average driving speed of 34km / h, an average mileage of 11km, and an average driving time of 23 minutes.

[0120] P6. Evaluate the risk of fake orders for this order:

[0121] A. Calculate the difference between the driver's order index for the day and the market:

[0122] Diff driver's completed orders = (driver's completed orders on the day - driver's daily average completed orders in history) = (12-10) = 2;

[0123] Diff driver order average speed = (driver order average speed for the day - market order average speed) = (34-30) = 4km / h;

[0124] Diff driver's average mileage = (driver's average mileage for the day's orders - average mileage for the market's orders) = (11-10) = 1km;

[0125] Diff driver's average driving time = (driver's average driving time for orders on the day - average driving time for orders on the market) = (23-20) = 3 minutes;

[0126] B. Calculate the difference between the order indicator and the market:

[0127] Average speed of Diff orders = (average speed of drivers’ orders on the day - average speed of the market orders) = (35-30) = 5 km / h;

[0128] Average driving mileage of Diff orders = (average driving mileage of drivers’ orders on the same day - average driving mileage of market orders) = (12-10) = 2km;

[0129] Average driving time of Diff orders = (average driving time of drivers’ orders on the day - average driving time of market orders) = (25-20) = 5 minutes;

[0130] C. Calculate the risk of fraudulent orders through the evaluation model: Calculate the risk score of fraudulent orders for drivers based on the preset coefficients and formulas. Assume that the coefficients are: coefficient 1 = 0.5, coefficient 2 = 0.3, coefficient 3 = 0.2, coefficient 4 = 0.1, coefficient 5 = 0.4, coefficient 6 = 0.3, coefficient 7 = 0.2.

[0131] Driver fraud risk score = 0.52 + 0.3 (4 / 30) + 0.2 (1 / 10) + 0.1 (3 / 20) +

[0132] 0.4(5 / 30)+0.3(2 / 10)+0.2*(5 / 20)=1.0+0.04+0.02+0.015+0.067+0.06+0.05=1.252.

[0133] P7. Risk classification: According to the preset risk thresholds X1 and X2, the risk scores of drivers who cheat on orders are classified. Set the thresholds: X1 = 1.0, X2 = 1.5.

[0134] Classification result: Driver Zhang San’s risk score for fraudulent orders is 1.252, which falls within the interval [X1,X2), so he is judged to be of medium risk.

[0135] P8. Gradually optimize risky drivers: Take appropriate measures based on the risk level of the driver. For medium-risk driver Zhang San, the system can send a warning message to remind him to pay attention to behavioral norms and strengthen monitoring of his subsequent orders.

[0136] It is understandable that through real-time risk calculation and classification, the platform can promptly detect and deal with potential fraudulent behavior and maintain the fairness and order of the platform. At the same time, through gradual optimization measures, it can guide drivers to regulate their behavior and improve the service quality of the platform.

[0137] In risk calculation, the system considers multiple independent variables, including the difference between the driver's order index on the day and the market, and the difference between the order index and the market. These independent variables can fully reflect the driver's behavioral characteristics and improve the accuracy of risk calculation. The system receives order data in real time through message middleware (such as Kafka) and uses the Flink stream processing system to process the received data in real time. This architecture can ensure the real-time and processing efficiency of data and provide timely data support for risk calculation. When the driver completes the order, the system automatically triggers the risk calculation process. This mechanism ensures that each order is subject to timely risk assessment and that potential order-brushing behaviors are discovered and handled in a timely manner. The system classifies drivers according to risk scores and takes corresponding disposal measures based on the classification results. This hierarchical disposal method can ensure the pertinence and effectiveness of the treatment while reducing the impact on normal drivers.

[0138] Embodiment 2: Based on the solution of embodiment 1, this embodiment further provides its Python execution program:

[0139]

[0140]

[0141]

[0142]

[0143]

[0144]

[0145] In the above program, dictionaries and lists are used to simulate driver data and platform data. Each driver has a unique unionId, which is associated with their historical data and current day data. The update_platform_data function executes the update process of platform data; the complete_order function executes the update process of data after the driver completes the order. It adds the data of the new order to the driver's current day data and updates the relevant cumulative values; the calculate_daily_metrics function calculates the average driving speed, average mileage, and average driving time based on the driver's current day order data; the assess_fraud_risk function compares the driver's current day indicator data with the platform data, calculates the difference, and calculates the fraud risk score based on the preset coefficients and formulas. The classify_risk function classifies drivers into three levels: no risk, medium risk, and high risk according to the fraud risk score.

[0146] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0147] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0148] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double-speed data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A method for judging fake orders based on the historical behavior of designated drivers on the SaaS platform, characterized in that: When receiving the identification instruction for offline data analysis and real-time risk monitoring, the following steps are performed: S1, loads the latest driver registration information and initializes the message middleware and Flink stream processing environment; S2, collects driver historical behavior data from the designated driver SaaS platform, including order information, driving trajectory and timestamp; S3, scheduled task triggering, querying driver and order history data; calculating the driver's daily average number of completed orders, the average number of completed orders per day for drivers in the market, and the average speed, average mileage, and average duration of orders in the market; S4, the message middleware receives the order data sent by the designated driver SaaS platform in real time; the Flink stream processing system processes the received order data in real time and calculates the driving speed, mileage and driving time of the order; S5, when the driver completes the order, the risk calculation process is triggered: the driver’s real-time order data and historical indicator data are obtained from Redis to determine the driver’s risk level.

2. The method for judging fake order behavior according to claim 1, characterized in that: The execution process of S1 includes: S100, connects to the database of the designated driver SaaS platform and obtains the latest driver registration information through SQL query or API call; S101, configure the server address, port and topic parameters of the message middleware; create or connect the consumer and producer clients of the message middleware; S102, configure the Flink stream processing system, including setting the cluster mode, the number of task managers, and the number of slots; create a Flink job, define the logic of data source, data conversion, and data sink; and start the Flink job.

3. The method for judging fake order behavior according to claim 1, characterized in that: The execution process of S2 includes: S200, connects to the database or API interface of the designated driver SaaS platform to obtain the driver's historical behavior data; defines the scope and time period of data collection; S201, screen and filter the data according to the analysis requirements, retain the required fields and information; organize the data into a structured format; S202, importing the data into the data warehouse according to the table structure.

4. The method for determining fake order behavior according to claim 3, characterized in that: The execution process of S3 includes: S300, setting a scheduled task to determine the frequency and time point of task execution; configuring a task scheduling system that can trigger and execute the scheduled task on time; S301, connect to the data warehouse or database to obtain historical data of drivers and orders; select and filter the data according to analysis requirements; load the data into memory or temporary storage; S302, calculate the average number of orders completed by each driver in the past day; calculate the average daily number of orders completed by drivers in the market, that is, the average number of orders completed by all drivers in the past day; calculate the average speed, average mileage and average duration of orders in the market, that is, the average driving speed, mileage and duration of all orders; write the calculated indicator data into the HBase indicator library according to the predetermined format and structure.

5. The method for judging fake order behavior according to claim 1, characterized in that: The execution process of S4 includes: S400, configures the consumer client of the message middleware, receives the order data sent by the designated driver SaaS platform in real time, and passes the parsed data to the Flink stream processing system for subsequent processing; S401, based on the data stream processing logic predefined in the Flink stream processing system, including data conversion and calculation operations, the received order data is processed in real time to calculate the driving speed, mileage and driving time indicators of the order; S402, writing the processed data into the Redis cache according to a predetermined format and structure.

6. The method for judging fake orders according to claim 1, characterized in that: In S5, the calculated difference is input into the fraud risk assessment model; The model calculates the driver’s fraud risk score based on preset coefficients and formulas; Risk classification is carried out based on the risk score of fake orders to determine the risk level of the driver.

7. The method for determining fake order behavior according to claim 6, characterized in that: S500, monitors order completion events. When the driver completes the order, the risk calculation process is triggered in real time. Get the unique ID of the order; S501, according to the order ID, query the real-time order data of the driver from Redis, including driving speed, driving mileage and driving duration; query the historical indicator data of the driver from the HBase indicator database, including the historical daily average number of completed orders, the daily average number of completed orders of the drivers in the market, the average speed, average mileage and average duration of the orders in the market; S502, calculating the difference between the driver's order index on the day and the corresponding index of the market; calculating the difference between the index of the order and the corresponding average of the market; S503, using the calculated difference as an input feature and inputting it into the fraudulent order risk assessment model; The model weights and calculates the input features according to the preset coefficients and formulas to derive the driver's fraud risk score; Based on the risk score, the driver's risk level is divided into different grades.

8. The method for judging fake order behavior according to claim 1, characterized in that: In S5, corresponding disposal measures are taken according to the risk level of the driver, including sending a warning message, restricting orders and / or suspending service.

9. A system for implementing the method for determining fake order behavior as claimed in any one of claims 1 to 8, characterized in that: The system comprises: Load the latest driver registration information and initialize the data preparation and initialization modules of the message middleware and Flink stream processing environment; Offline data collection and storage module that collects drivers’ historical behavior data from the designated driver SaaS platform; Offline data analysis and index calculation module to calculate the average number of orders completed by drivers in a single day, the average number of orders completed by drivers in a single day, and the average speed, mileage and duration of orders in a single day; The message middleware receives the real-time data processing and caching module of the order data sent by the designated driver SaaS platform in real time; When the driver completes the order, the risk calculation and disposal module of the risk calculation process is triggered.

10. The system according to claim 9, characterized in that: The risk calculation and disposal module is connected to Redis and HBase to obtain real-time and historical data; uses the order-brushing risk assessment model to calculate the risk score; and executes corresponding disposal measures according to the risk score, including sending warning information, restricting orders, and / or suspending services.

Images