A method and system for determining driver platform contribution duration by multiple dimensions

Abstract

The application relates to a method and system for determining the contribution time length of a driver platform through multiple dimensions, which comprises the following steps: collecting driver trajectory reporting point data and driver order data in real time; matching the driver trajectory reporting point data with the driver order data, and taking the driver trajectory reporting point outside the order as the order listening reporting point data; screening the effective order listening reporting point data from the order listening reporting point data, determining the ordinary order listening summary time length and the peak order listening summary time length of the driver in the current period based on the pre-configured activity period, the non-time fence, the reward fence and the peak period; determining the ordinary service summary time length and the peak service summary time length of the driver in the current period based on the pre-configured activity period and the peak period through the driver order data; determining the ordinary contribution total time length and the peak contribution total time length of the driver in the current period according to the preset weight, and further matching the corresponding contribution reward for the driver.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for determining the contribution time of a driver platform through multiple dimensions. Background Technology

[0002] In the ride-hailing industry, driver platform contribution is an important performance evaluation mechanism used to measure a driver's dependence on the platform and the value of their services. Through refined evaluation of driver platform contribution, the platform can achieve multi-dimensional management, such as driver service level classification, loyalty assessment, and stickiness analysis, thereby more effectively guiding drivers to continue serving on the platform and improving overall service quality and transportation capacity.

[0003] Currently, the industry assesses drivers' platform contributions based on the following aspects:

[0004] 1) Assess the number of orders driven by the driver

[0005] Drivers are evaluated and rewarded in a refined manner based on indicators such as the number of orders received, the number of orders completed, and the completion rate.

[0006] 2) Assess the driver's contribution amount

[0007] Drivers are evaluated and rewarded based on their GMV (Gross Merchandise Volume) generated on the platform.

[0008] While the aforementioned assessment methods have some effect on increasing platform revenue, their measurement of individual driver contributions is rather one-sided, neglecting drivers' service time outside of order periods and failing to fully reflect drivers' actual input and participation on the platform. This assessment mechanism offers a poor experience for drivers and is unlikely to effectively enhance their sense of belonging and dependence on the platform. Summary of the Invention

[0009] To at least partially overcome the problem that the contribution assessment of ride-hailing drivers by the platform is too one-sided in measuring the individual driver's contribution, this application provides a method and system for determining the duration of the driver's contribution to the platform through multiple dimensions.

[0010] The proposed solution is as follows:

[0011] According to a first aspect of the embodiments of this application, a method for determining the driver platform contribution time through multiple dimensions is provided, including:

[0012] A method for determining driver platform contribution time through multiple dimensions includes:

[0013] The Flink engine collects driver trajectory reporting data uploaded by the driver's app in real time through the MQ (Message Queue) channel; the DTS (Data Transmission Service) collects driver order data uploaded by the passenger's app in real time through the business database.

[0014] The driver trajectory reporting data is matched with the driver order data, and the driver trajectory reporting data that is not in an order is used as the listening order reporting data;

[0015] Based on the duration of each reporting location in the call order reporting data, the valid call order reporting data is filtered from the call order reporting data;

[0016] Based on the effective call reporting data, and according to the pre-configured activity period, non-timed fence, reward fence, and peak period, the driver's normal call summary duration and peak call summary duration within the current period are determined.

[0017] Based on the driver order data and pre-configured activity periods and peak periods, the total duration of normal service and the total duration of peak service for drivers within the current period are determined.

[0018] Based on the weights of the summaries of ordinary call requests and ordinary service requests, the total ordinary contribution time of the driver in the current period is determined. Based on the weights of the summaries of peak call requests and peak service requests, the total peak contribution time of the driver in the current period is determined.

[0019] Drivers will be matched with corresponding contribution rewards based on their total contribution time during normal hours and total contribution time during peak hours.

[0020] Preferably, based on the effective call reporting data and pre-configured activity periods, non-timed fences, reward fences, and peak periods, the total duration of normal call reporting for drivers within the current period and the total duration of peak call reporting are determined, including:

[0021] Determine whether the valid call center data matches the activity period;

[0022] If the activity period is not matched, the listening time will not be counted.

[0023] If the activity period is hit, then determine whether the valid call log data hits the non-timed fence.

[0024] If the fence is hit without a time limit, it will not be counted towards the listening time.

[0025] If the non-timed fence is not hit, then determine whether the valid call point data hits the reward fence;

[0026] If the reward fence is not hit, the listening time will not be counted.

[0027] If the reward fence is hit, determine whether the hit reward fence has a multiplier;

[0028] If the hit reward zone does not have a multiplier, it will be directly included in the total duration of the regular order.

[0029] If the hit reward fence has a multiplier, then determine whether the valid call order data hits the peak period;

[0030] If the peak period is not hit, the duration of the order will be calculated based on the multiplier of the reward fence and then included in the total duration of the regular order.

[0031] If the order is placed during a peak period, the duration of the order will be calculated based on the multiplier of the reward zone and then included in the peak period order summary duration.

[0032] Preferably, based on the driver order data and pre-configured activity and peak periods, the total duration of normal service and the total duration of peak service for drivers within the current period are determined, including:

[0033] Determine whether the driver order data matches the activity period;

[0034] If the activity period is not matched, the listening time will not be counted.

[0035] If the activity period is matched, then determine whether the driver order data matches the peak period.

[0036] If the peak period is not hit, the duration will be included in the regular listening session summary.

[0037] If it falls within a peak period, it will be included in the peak listening time summary.

[0038] Preferably, the method further includes:

[0039] Determine whether the driver's total normal contribution time meets the minimum normal contribution time requirement, and determine whether the driver's total peak contribution time meets the minimum peak contribution time requirement.

[0040] If a driver's total normal contribution time does not meet the minimum normal contribution time requirement, or if a driver's total peak contribution time does not meet the minimum peak contribution time requirement, no reward will be calculated.

[0041] If a driver's total normal contribution time does not meet the minimum normal contribution time requirement, but the total peak contribution time meets the minimum peak contribution time requirement, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time and total peak contribution time.

[0042] If a driver's total normal contribution time meets the minimum normal contribution time requirement, but the total peak contribution time does not meet the minimum peak contribution time requirement, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time.

[0043] If a driver's total normal contribution time meets the minimum requirement for normal contribution time, and the total peak contribution time meets the minimum requirement for peak contribution time, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time and total peak contribution time.

[0044] Preferably, the driver trajectory reporting data is matched with the driver order data, and driver trajectory reporting data outside of orders is used as listener report data, including:

[0045] Extract the timestamp of each driver trajectory reporting point from the driver trajectory reporting data;

[0046] Determine the start and end time intervals for all orders in the driver order data;

[0047] The timestamp of each driver's trajectory report is matched with the start and end time intervals of all orders in the driver's order data;

[0048] If the timestamp of the driver's trajectory report falls within the start and end time range of the driver's order data, then the driver's trajectory report is determined to be within the order; otherwise, the driver's trajectory report is determined to be outside the order.

[0049] Preferably, based on the duration of each call point in the call point data, valid call point data is filtered from the call point data, including:

[0050] The call order data is divided into multiple time periods with minute intervals.

[0051] Determine the distance between the starting and ending reporting points and the number of reporting points within the current time period;

[0052] Calculate the average speed and average reporting distance within the current time period;

[0053] If the average speed in the current time period is lower than the first preset speed value and the average reporting distance is lower than the first preset distance value, the call order reporting data in the current time period will be determined as stationary call order reporting data.

[0054] If the average speed in the current time period is between the first preset speed value and the second preset speed value, and the average reporting distance is between the first preset distance value and the second preset distance value, the call order reporting data in the current time period will be determined as mobile call order reporting data.

[0055] The stationary call point data is multiplied by the first coefficient and then included in the valid call point data; the mobile call point data is multiplied by the second coefficient and then included in the valid call point data.

[0056] The remaining call order reporting data will be determined as invalid call order reporting data;

[0057] Wherein, the first preset speed value is less than the second preset speed value;

[0058] The first preset distance value is less than the second preset distance value;

[0059] The first coefficient is less than 1.2, and the second coefficient is less than 1.

[0060] Preferably, the method further includes:

[0061] The driver trajectory reporting data collected in real time through the Flink engine in the MQ channel is stored in MaxCompute and Hologres for downstream real-time and offline computing.

[0062] Driver order data collected in real time in the business database via DTS data transmission service is stored in the data message queue and offline data warehouse MaxCompute for downstream real-time and offline computing.

[0063] Preferably, the method further includes:

[0064] The driver's total normal contribution time, total peak contribution time, and contribution rewards are synchronized in real time to TableStore and Redis using Flink and DataX tools, so that the driver can query, display, and use them.

[0065] The driver's total normal contribution time, total peak contribution time, and contribution rewards are synchronized in real time to the business databases PolarDB MySQL, Redis, and TableStore using Flink and DataX tools, making them accessible to the downstream data platform API.

[0066] Preferably, the method further includes:

[0067] Driver user profiles are constructed based on driver trajectory reporting data, driver order data, total driver contribution time during normal hours, total driver contribution time during peak hours, and contribution rewards, and driver level ratings are then implemented.

[0068] According to a second aspect of the embodiments of this application, a system is provided for determining the driver's platform contribution time through multiple dimensions, including:

[0069] Processor and memory;

[0070] The processor and memory are connected via a communication bus:

[0071] The processor is used to call and execute the program stored in the memory;

[0072] The memory is used to store a program, which is at least used to execute a method for determining the driver platform contribution time from multiple dimensions as described in any of the above.

[0073] The technical solution provided in this application may include the following beneficial effects:

[0074] The method for determining driver platform contribution time through multiple dimensions in this application includes: real-time collection of driver trajectory reporting data uploaded by the driver's app in the MQ channel using the Flink engine; real-time collection of driver order data uploaded by the passenger's app in the business database using the DTS data transmission service; matching the driver trajectory reporting data with the driver order data, and using driver trajectory reporting data outside of orders as order reporting data; filtering valid order reporting data from the order reporting data based on the duration of each reporting location in the order reporting data; and using the valid order reporting data, based on pre-configured activity time periods, non-timed fences, etc. The system uses reward zones and peak hours to determine the driver's total regular order duration and peak order duration for the current period. Based on driver order data and pre-configured activity and peak hours, it determines the driver's total regular service duration and peak service duration for the current period. According to the weights of the regular order duration and regular service duration, it determines the driver's total regular contribution time for the current period. Similarly, according to the weights of the peak order duration and peak service duration, it determines the driver's total peak contribution time for the current period. Finally, it matches the driver with corresponding contribution rewards based on their total regular and peak contribution times.

[0075] This technical solution differs from existing ride-hailing driver assessments. It focuses more on the driver's platform contribution time, rather than solely considering the number of rides and the monetary contribution. Specifically, this solution matches route reporting with order data to identify ride request reporting data and incorporates it into the platform contribution evaluation, filling the gap in data on non-service phase contributions and improving the platform's ability to quantify the overall contribution of drivers. It introduces dimensions such as "activity periods," "peak hours," "non-timed areas," and "reward areas"; this not only differentiates the service value of different time periods but also filters low-value areas using spatial information, achieving high-quality and accurate measurement of contribution time.

[0076] This technical solution considers not only the service time drivers spend providing service orders on the platform, but also the time they spend listening to orders. Combining these two aspects allows for a more comprehensive assessment of drivers' platform contribution time. Using platform contribution time as a performance indicator reduces the difficulty for drivers to meet performance targets and ensures that drivers are rewarded for their work, improving their experience. Recognizing service activities outside of order periods (such as contributions during order listening) enhances drivers' perception of platform fairness, strengthens trust between the platform and drivers, improves driver retention and loyalty, and contributes to building a healthy ecosystem.

[0077] Different contribution values ​​are assigned to regular service hours and peak service hours, forming a more incentive-oriented reward mechanism; this helps to encourage drivers to participate in services during high-value periods, optimizing capacity allocation and dispatch efficiency.

[0078] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

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

[0080] Figure 1 This is a flowchart illustrating a method for determining driver platform contribution time from multiple dimensions, as provided in one embodiment of this application.

[0081] Figure 2 This is a schematic diagram of a process for determining the total duration of a driver's call and the total duration of service, provided in one embodiment of this application.

[0082] Figure 3 This is a schematic diagram of a process for matching drivers with corresponding tiers of rewards, provided in one embodiment of this application;

[0083] Figure 4 This is a schematic diagram of a process for collecting driver trajectory reports and driver-bound orders through multiple data sources, provided in one embodiment of this application;

[0084] Figure 5 This is a schematic diagram of a process for synchronizing data from various drivers, provided in one embodiment of this application.

[0085] Figure 6 This is a platform overall architecture diagram provided in one embodiment of this application;

[0086] Figure 7 This is a schematic diagram of the structure of a system for determining the contribution time of a driver platform through multiple dimensions, provided in one embodiment of this application.

[0087] Figure label:

[0088] Processor-21; Memory-22. Detailed Implementation

[0089] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0090] Example 1

[0091] Figure 1 This is a flowchart illustrating a method for determining driver platform contribution time from multiple dimensions, as provided in one embodiment of this application. (Refer to...) Figure 1 A method for determining driver platform contribution time through multiple dimensions includes:

[0092] S11: Real-time collection of driver trajectory reporting data uploaded by the driver's app through the Flink engine in the MQ channel; real-time collection of driver order data uploaded by the passenger's app in the business database through the DTS data transmission service;

[0093] Flink is short for Apache Flink, a distributed, high-performance, always-available stream and batch processing engine.

[0094] "MQ" is an abbreviation for "Message Queue," an asynchronous communication mechanism used for decoupling and efficient data transmission between different systems, services, or modules.

[0095] Driver trajectory reporting data is collected from the driver's mobile phone every second via the driver's mobile app. The coordinates are packaged and uploaded to the server via a socket channel every 2 seconds. After receiving the coordinates, the server first performs noise reduction processing on the coordinates, then cleans them and fits the coordinates with the path before transmitting the valid driver trajectory reporting data to the data acquisition MQ channel.

[0096] The driver order data in the business database is mainly recorded by users' ride-hailing behavior on the passenger-side APP and stored in Alibaba Cloud's PolarDB MySQL database.

[0097] S12: Match driver trajectory reporting data with driver order data, and use driver trajectory reporting data that is not in an order as listener reporting data;

[0098] Specifically, driver trajectory reporting data is matched with driver order data, and driver trajectory reporting data outside of orders is used as order reporting data, including:

[0099] Extract the timestamp of each driver trajectory reporting point from the driver trajectory reporting data;

[0100] Determine the start and end time ranges for all orders in the driver order data;

[0101] Match the timestamp of each driver's route report with the start and end time range of all orders in the driver's order data;

[0102] If the timestamp of the driver's trajectory report falls within the start and end time range of the driver's order data, then the driver's trajectory report is determined to be within the order; otherwise, the driver's trajectory report is determined to be outside the order.

[0103] In evaluating the time drivers contribute to the platform, it is necessary to identify their effective service behavior during non-order-taking periods. By comparing the trajectory reporting data uploaded by drivers with their order execution times, it can be determined whether they are in an idle state (i.e., "waiting for orders"), thereby accurately extracting waiting for orders data that can be used for time calculation.

[0104] This step identifies and extracts the driver's "non-order status" trajectory by comparing the timestamp of the driver's reported trajectory with the start and end times of all orders in the driver's order data. This helps build a quantitative foundation for the platform's understanding of driver order-taking behavior, providing crucial data support for subsequent contribution time calculations, thereby improving the comprehensiveness and fairness of driver contribution evaluation.

[0105] S13: Based on the duration of each call point in the call point data, filter the valid call point data from the call point data;

[0106] Specifically, based on the duration of each callout location in the callout data, valid callout data is filtered from the callout data, including:

[0107] The call order data is divided into multiple time periods with minute intervals.

[0108] Determine the distance between the starting and ending reporting points and the number of reporting points within the current time period;

[0109] Calculate the average speed and average reporting distance within the current time period;

[0110] If the average speed in the current time period is lower than the first preset speed value and the average reporting distance is lower than the first preset distance value, the call order reporting data in the current time period will be determined as stationary call order reporting data.

[0111] If the average speed in the current time period is between the first preset speed value and the second preset speed value, and the average reporting distance is between the first preset distance value and the second preset distance value, the call order reporting data in the current time period will be determined as mobile call order reporting data.

[0112] The stationary call point data is multiplied by the first coefficient and then included in the valid call point data; the mobile call point data is multiplied by the second coefficient and then included in the valid call point data.

[0113] The remaining call order reporting data will be determined as invalid call order reporting data;

[0114] Wherein, the first preset speed value is less than the second preset speed value;

[0115] The first preset distance value is less than the second preset distance value;

[0116] The first coefficient is less than 1.2, and the second coefficient is less than 1.

[0117] In ride-hailing scenarios, a driver's "waiting for orders" status is not entirely equivalent to their effective contribution to the platform. Some drivers may continuously move or traverse low-value areas while waiting for orders, leading to inefficient service. Therefore, it is necessary to perform quality screening on "waiting routes," giving higher weight to higher-quality, stationary waiting behaviors, while giving lower or no weight to frequent, mobile cruising behaviors.

[0118] This step uses "reporting speed and distribution density analysis" to identify the effectiveness of call order behavior.

[0119] First, divide the time period into minutes:

[0120] The single trajectory reporting point is high-frequency data (e.g., one reporting point every 5 to 10 seconds). To avoid judgment fluctuations or errors, the trajectory stream can be divided into multiple independent time periods according to a fixed time window (e.g., 1 minute) to facilitate local behavior recognition.

[0121] For each time period, perform the following calculations:

[0122] The distance between the starting and ending reporting points, the number of reporting points (the number of trajectory points in the same time period), the average speed, and the average reporting distance.

[0123] If the average speed in the current time period is lower than the first preset speed value and the average reporting distance is lower than the first preset distance value, the order reporting data in the current time period is determined as stationary order reporting data, indicating that the driver is basically waiting for orders in place. This waiting state is regarded as a waiting state that contributes more to the overall performance, so a higher coefficient is assigned to it.

[0124] If the average speed in the current time period is between the first preset speed value and the second preset speed value, and the average reporting distance is between the first preset distance value and the second preset distance value, the order reporting data in the current time period is determined as mobile order reporting data, indicating that the driver is cruising on the road or moving slowly, waiting for orders while driving. This waiting state is considered a low-contribution waiting state, so it is assigned a low coefficient.

[0125] For the remaining call order reporting data, it is basically determined that the driver is in a high-speed moving state, and this waiting state is regarded as a non-contributing waiting state, so it is determined to be invalid call order reporting data.

[0126] S14: Based on the effective call reporting data, and according to the pre-configured activity period, non-timed fence, reward fence and peak period, determine the driver's normal call summary duration and peak call summary duration within the current period;

[0127] S15: Based on driver order data and pre-configured activity and peak periods, determine the total duration of normal service and peak service for drivers in the current period;

[0128] S16: Determine the driver's total normal contribution time in the current period based on the weights of the total normal call duration and the total normal service duration, and determine the driver's total peak contribution time in the current period based on the weights of the total peak call duration and the total peak service duration.

[0129] S17: Match corresponding contribution rewards to drivers based on their total normal contribution time and total peak contribution time.

[0130] The overall platform architecture diagram used in this embodiment to implement the method for determining the driver's platform contribution time from multiple dimensions is as follows: Figure 6 As shown.

[0131] This technical solution differs from existing ride-hailing driver assessments. It focuses more on the driver's platform contribution time, rather than solely considering the number of rides and the monetary contribution. Specifically, this solution matches route reporting with order data to identify ride request reporting data and incorporates it into the platform contribution evaluation, filling the gap in data on non-service phase contributions and improving the platform's ability to quantify the overall contribution of drivers. It introduces dimensions such as "activity periods," "peak hours," "non-timed areas," and "reward areas"; this not only differentiates the service value of different time periods but also filters low-value areas using spatial information, achieving high-quality and accurate measurement of contribution time.

[0132] This technical solution considers not only the service time drivers spend providing service orders on the platform, but also the time they spend listening to orders. Combining these two aspects allows for a more comprehensive assessment of drivers' platform contribution time. Using platform contribution time as a performance indicator reduces the difficulty for drivers to meet performance targets and ensures that drivers are rewarded for their work, improving their experience. Recognizing service activities outside of order periods (such as contributions during order listening) enhances drivers' perception of platform fairness, strengthens trust between the platform and drivers, improves driver retention and loyalty, and contributes to building a healthy ecosystem.

[0133] Different contribution values ​​are assigned to regular service hours and peak service hours, forming a more incentive-oriented reward mechanism; this helps to encourage drivers to participate in services during high-value periods, optimizing capacity allocation and dispatch efficiency.

[0134] Example 2

[0135] Reference Figure 2 Based on effective call reporting data and pre-configured activity periods, non-timed fences, reward fences, and peak hours, the system determines the driver's average call duration and peak call duration for the current period, including:

[0136] Determine whether valid call center data matches the activity period;

[0137] If the activity period is not matched, the listening time will not be counted.

[0138] If the activity period is hit, then determine whether the valid call point data hits the non-timed fence;

[0139] If the fence is hit without a time limit, it will not be counted towards the listening time.

[0140] If the non-timed fence is not hit, then determine whether the valid call point data hits the reward fence;

[0141] If the reward fence is not hit, the listening time will not be counted.

[0142] If the reward fence is hit, determine whether the hit reward fence has a multiplier;

[0143] If the hit reward zone does not have a multiplier, it will be directly included in the total duration of the regular order.

[0144] If the hit reward fence has a multiplier, then determine whether the valid call order data hits the peak period;

[0145] If the peak period is not hit, the duration of the order will be calculated based on the multiplier of the reward fence and then included in the total duration of the regular order.

[0146] If the order is placed during a peak period, the duration of the order will be calculated based on the multiplier of the reward zone and then included in the peak period order summary duration.

[0147] Reference Figure 2 Based on driver order data and pre-configured activity and peak periods, the system determines the total duration of normal service and peak service for drivers within the current period, including:

[0148] Determine if the driver's order data matches the activity period;

[0149] If the activity period is not matched, the listening time will not be counted.

[0150] If the activity period is matched, then determine whether the driver's order data matches the peak period.

[0151] If the peak period is not hit, the duration will be included in the regular listening session summary.

[0152] If it falls within a peak period, it will be included in the peak listening time summary.

[0153] The technical solution for determining the driver's total service time by binding the driver to the order in this embodiment is divided into the following parts:

[0154] 1. Optimize time period determination to ensure data validity.

[0155] Activity Period Determination: First, it is determined whether the driver's bound order falls within the activity period configured by the operations team. Only data within the operational period can be included in service hours. This filtering mechanism ensures that the system's statistical data focuses only on the platform's key activity periods, excluding irrelevant or inefficient data, thus improving the timeliness and effectiveness of the data.

[0156] 2. Introduce peak time period differentiation to improve incentive accuracy.

[0157] Peak Hour Determination: After confirming that the data falls within the activity period, the system further determines whether it falls within a peak period. This determination divides the data into two parts: normal service duration and peak service duration, in order to differentiate and incentivize order service performance across different traffic periods.

[0158] Precise Incentives: For orders placed during peak hours, platforms typically face higher vehicle dispatch requirements and more strained resource allocation. Therefore, including these orders separately in peak service hours helps to accurately identify and incentivize drivers to provide positive service during peak order periods.

[0159] 3. Data aggregation forms a comprehensive service duration indicator.

[0160] Duration Summary: Separating regular service duration and peak service duration provides a more comprehensive reflection of drivers' actual input in the order service process. This not only considers the total number of orders but also refines the time periods in which orders occur, offering strong indicative value for differentiating business pressure and driver performance during different time periods.

[0161] Example 3

[0162] Reference Figure 3 The methods also include:

[0163] Determine whether the driver's total normal contribution time and total peak contribution time meet the minimum reward time;

[0164] If the minimum reward duration is not met, no reward will be calculated.

[0165] If the minimum reward duration is met, the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution duration and total peak contribution duration.

[0166] Specifically, it is determined whether the driver's total normal contribution time meets the minimum normal contribution time requirement, and whether the driver's total peak contribution time meets the minimum peak contribution time requirement.

[0167] If a driver's total normal contribution time does not meet the minimum normal contribution time requirement, or if a driver's total peak contribution time does not meet the minimum peak contribution time requirement, no reward will be calculated.

[0168] If a driver's total normal contribution time does not meet the minimum normal contribution time requirement, but the total peak contribution time meets the minimum peak contribution time requirement, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time and total peak contribution time.

[0169] If a driver's total normal contribution time meets the minimum normal contribution time requirement, but the total peak contribution time does not meet the minimum peak contribution time requirement, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time.

[0170] If a driver's total normal contribution time meets the minimum requirement for normal contribution time, and the total peak contribution time meets the minimum requirement for peak contribution time, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time and total peak contribution time.

[0171] It should be noted that if a driver's total normal contribution time does not meet the minimum normal contribution time requirement, but the total peak contribution time meets the minimum peak contribution time requirement, the driver will still be matched with the corresponding contribution reward based on the total normal contribution time, taking into account the peak contribution made by the driver.

[0172] It should be noted that if a driver's total normal contribution time meets the minimum requirement for normal contribution time, but the total peak contribution time does not meet the minimum requirement for peak contribution time, then the driver will be matched with the corresponding contribution reward only based on the driver's total normal contribution time.

[0173] In practice, the operations team calculates peak hours based on the time contributed by drivers and sets up six tiers of rewards, with reward conditions including but not limited to monetary rewards and preferential order allocation.

[0174] Before calculating rewards, the system first determines whether a driver's total contribution time and peak hours meet the preset minimum reward requirements. Only drivers who meet the minimum reward requirements receive incentive rewards, avoiding the problem of awarding rewards to drivers with insufficient contribution. This setting effectively filters out noisy data, ensuring that rewards are distributed only to drivers who truly make continuous and effective contributions to the platform, thus guaranteeing the scientific and rigorous nature of the reward system.

[0175] After meeting the minimum reward requirements, the system then matches the corresponding reward tiers based on the driver's total contribution time and peak hours. This design not only encourages drivers to extend their service time as much as possible but also fully reflects the principle of "more work, more pay." The more time a driver contributes, the higher the reward level they receive, creating a positive incentive mechanism that further encourages drivers to actively participate during peak hours and improves overall transportation efficiency.

[0176] Setting a minimum reward threshold prevents drivers with only a few hours of driving time from receiving rewards, thus avoiding overly dispersed reward distribution and weakening the incentive effect. Meanwhile, tiered rewards differentiate between drivers of different contribution levels, demonstrating a clear proportional relationship between input and reward and enhancing the fairness of the reward mechanism. Evaluating drivers based on their total contribution hours and peak hours provides a more detailed reflection of their work performance at different times. Peak hours inherently represent higher service pressure and resource competition; therefore, providing additional rewards during peak hours is both reasonable and helps balance regional supply and demand, thereby improving the platform's overall service responsiveness.

[0177] Example 4

[0178] It should be noted that, referring to Figure 4 The methods also include:

[0179] The driver trajectory reporting data collected in real time through the Flink engine in the MQ channel is stored in MaxCompute and Hologres for downstream real-time and offline computing.

[0180] Driver order data collected in real time in the business database via DTS data transmission service is stored in the data message queue and offline data warehouse MaxCompute for downstream real-time and offline computing.

[0181] The collected trajectory reporting data is written to the Hologres real-time data engine in real time to support subsequent real-time processing scenarios such as second-level online query, indicator calculation, and driving behavior analysis. At the same time, the data is also archived in batches to MaxCompute (a big data computing platform) for subsequent offline processing scenarios such as historical data statistical analysis, model training, and periodic indicator aggregation.

[0182] Through the DTS data transmission service, driver order-related data, including order ID, driver ID, order start and end time, order status, and other information, are synchronized in real time from the business database.

[0183] The synchronized data, after being transformed and processed, is pushed to a message queue (such as Kafka or RocketMQ) for downstream stream processing engines to perform near real-time processing and matching logic execution; on the other hand, it is synchronously written to the MaxCompute data warehouse for business needs such as offline analysis, periodic contribution evaluation, historical reconciliation and statistical backtracking.

[0184] Example 5

[0185] It should be noted that the method also includes:

[0186] The driver's total normal contribution time, total peak contribution time, and contribution rewards are synchronized in real time to TableStore and Redis using Flink and DataX tools, so that the driver can query, display, and use them.

[0187] The driver's total normal contribution time, total peak contribution time, and contribution rewards are synchronized in real time to the business databases PolarDB MySQL, Redis, and TableStore using Flink and DataX tools, making them accessible to the downstream data platform API.

[0188] Reference Figure 5 In this embodiment, the total duration of normal contribution, the total duration of peak contribution, and the corresponding contribution reward data calculated based on trajectory reporting and order data are cleaned and structured in real time using the Flink stream processing engine in conjunction with the DataX data synchronization tool.

[0189] Part of the data is synchronized to TableStore (time-series structured storage service) and Redis caching system to support data read requests from the driver's app, achieving second-level response and dynamic display, and meeting the interactive needs of drivers for querying, displaying, and using in real time;

[0190] Another portion of the data is synchronized to the business back-end system, including:

[0191] PolarDB is a MySQL database used for persistent storage and transaction control.

[0192] Redis is a caching system used to support high-concurrency read scenarios.

[0193] TableStore is used for complex structured queries and time-series metric backtracking;

[0194] All of the above data entry operations serve the calls to the downstream data platform API, providing standardized data output capabilities for the management backend, reporting system, service analysis platform, etc.

[0195] Furthermore, the methods also include:

[0196] Driver user profiles are constructed based on driver trajectory reporting data, driver order data, total driver contribution time during normal hours, total driver contribution time during peak hours, and contribution rewards, and driver level ratings are then implemented.

[0197] In this embodiment, the driver trajectory reporting data, driver order data, total driver contribution time, total driver peak contribution time and contribution rewards are analyzed. Based on the analysis results, characteristic variables such as driver service time preference, regional service tendency, activity level and efficiency index are extracted to form a structured driver tag system and construct driver user profiles.

[0198] Based on this, by setting rule models or introducing machine learning scoring mechanisms, drivers can be rated in terms of service level, such as ordinary drivers, active drivers, high-contribution drivers, and platform-partnered star drivers. The rating results can be fed back into application scenarios such as driver incentive systems, operational strategy formulation, and regional capacity scheduling optimization.

[0199] Example 6

[0200] Figure 7 This is a schematic diagram of the structure of a system for determining the contribution time of a driver platform through multiple dimensions, provided in one embodiment of this application. (Refer to...) Figure 7 A system for determining driver platform contribution time through multiple dimensions includes:

[0201] Processor 21 and memory 22;

[0202] Processor 21 and memory 22 are connected via a communication bus:

[0203] The processor 21 is used to call and execute the program stored in the memory 22;

[0204] Memory 22 is used to store a program, which is used to execute at least one of the above methods for determining the driver platform contribution time through multiple dimensions.

[0205] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0206] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0207] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0208] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0209] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0210] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0211] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0212] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0213] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for determining driver platform contribution time through multiple dimensions, characterized in that, include: The driver trajectory reporting data uploaded by the driver's mobile app is collected in real time through the Flink engine in the MQ channel; The DTS data transmission service collects driver order data uploaded by passengers via the app in real time from the business database. The driver trajectory reporting data is matched with the driver order data, and the driver trajectory reporting data that is not in an order is used as the listening order reporting data; Based on the duration of each reporting location in the call order reporting data, the valid call order reporting data is filtered from the call order reporting data; Based on the effective call reporting data, and according to the pre-configured activity period, non-timed fence, reward fence, and peak period, the driver's normal call summary duration and peak call summary duration within the current period are determined. Based on the driver order data and pre-configured activity periods and peak periods, the total duration of normal service and the total duration of peak service for drivers within the current period are determined. Based on the weights of the summaries of ordinary call requests and ordinary service requests, the total ordinary contribution time of the driver in the current period is determined. Based on the weights of the summaries of peak call requests and peak service requests, the total peak contribution time of the driver in the current period is determined. Drivers will be matched with corresponding contribution rewards based on their total contribution time during normal hours and total contribution time during peak hours. Based on the valid call reporting data and pre-configured activity periods, non-timed fences, reward fences, and peak periods, the total duration of normal call requests and the total duration of peak call requests for drivers within the current period are determined, including: Determine whether the valid call center data matches the activity period; If the activity period is not matched, the listening time will not be counted. If the activity period is hit, then determine whether the valid call log data hits the non-timed fence. If the fence is hit without a time limit, it will not be counted towards the listening time. If the non-timed fence is not hit, then determine whether the valid call point data hits the reward fence; If the reward fence is not hit, the listening time will not be counted. If the reward fence is hit, determine whether the hit reward fence has a multiplier; If the hit reward zone does not have a multiplier, it will be directly included in the total duration of the regular order. If the hit reward fence has a multiplier, then determine whether the valid call order data hits the peak period; If the peak period is not hit, the duration of the order will be calculated based on the multiplier of the reward fence and then included in the total duration of the regular order. If the peak period is hit, the listening time will be calculated based on the multiplier of the reward fence and then included in the peak listening time summary. Based on the driver order data and pre-configured activity and peak periods, the total duration of normal service and the total duration of peak service for drivers within the current period are determined, including: Determine whether the driver order data matches the activity period; If the activity period is not matched, the listening time will not be counted. If the activity period is matched, then determine whether the driver order data matches the peak period. If the peak period is not hit, the duration will be included in the regular listening session summary. If it falls within a peak period, it will be included in the peak listening time summary. Based on the duration of each call point location in the call order reporting data, valid call order reporting data is filtered from the call order reporting data, including: The call order data is divided into multiple time periods with minute intervals. Determine the distance between the starting and ending reporting points and the number of reporting points within the current time period; Calculate the average speed and average reporting distance within the current time period; If the average speed in the current time period is lower than the first preset speed value and the average reporting distance is lower than the first preset distance value, the call order reporting data in the current time period will be determined as stationary call order reporting data. If the average speed in the current time period is between the first preset speed value and the second preset speed value, and the average reporting distance is between the first preset distance value and the second preset distance value, the call order reporting data in the current time period will be determined as mobile call order reporting data. The stationary call point data is multiplied by the first coefficient and then included in the valid call point data; the mobile call point data is multiplied by the second coefficient and then included in the valid call point data. The remaining call order reporting data will be determined as invalid call order reporting data; Wherein, the first preset speed value is less than the second preset speed value; The first preset distance value is less than the second preset distance value; The first coefficient is less than 1.2, and the second coefficient is less than 1.

2. The method according to claim 1, characterized in that, The method further includes: Determine whether the driver's total normal contribution time meets the minimum normal contribution time requirement, and determine whether the driver's total peak contribution time meets the minimum peak contribution time requirement. If a driver's total normal contribution time does not meet the minimum normal contribution time requirement, or if a driver's total peak contribution time does not meet the minimum peak contribution time requirement, no reward will be calculated. If a driver's total normal contribution time does not meet the minimum normal contribution time requirement, but the total peak contribution time meets the minimum peak contribution time requirement, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time and total peak contribution time. If a driver's total normal contribution time meets the minimum normal contribution time requirement, but the total peak contribution time does not meet the minimum peak contribution time requirement, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time. If a driver's total normal contribution time meets the minimum requirement for normal contribution time, and the total peak contribution time meets the minimum requirement for peak contribution time, then the driver will be matched with the corresponding contribution reward based on the driver's total normal contribution time and total peak contribution time.

3. The method according to claim 1, characterized in that, Matching the driver trajectory reporting data with the driver order data, and using driver trajectory reporting data outside of orders as listener report data, includes: Extract the timestamp of each driver trajectory reporting point from the driver trajectory reporting data; Determine the start and end time intervals for all orders in the driver order data; The timestamp of each driver's trajectory report is matched with the start and end time intervals of all orders in the driver's order data; If the timestamp of the driver's trajectory report falls within the start and end time range of the driver's order data, then the driver's trajectory report is determined to be within the order; otherwise, the driver's trajectory report is determined to be outside the order.

4. The method according to claim 1, characterized in that, The method further includes: The driver trajectory reporting data collected in real time through the Flink engine in the MQ channel is stored in MaxCompute and Hologres for downstream real-time and offline computing. Driver order data collected in real time in the business database via DTS data transmission service is stored in the data message queue and offline data warehouse MaxCompute for downstream real-time and offline computing.

5. The method according to claim 2, characterized in that, The method further includes: The driver's total normal contribution time, total peak contribution time, and contribution rewards are synchronized in real time to TableStore and Redis using Flink and DataX tools, so that the driver can query, display, and use them. The driver's total normal contribution time, total peak contribution time, and contribution rewards are synchronized in real time to the business databases PolarDB MySQL, Redis, and TableStore using Flink and DataX tools, making them accessible to the downstream data platform API.

6. The method according to claim 1, characterized in that, The method further includes: Driver user profiles are constructed based on driver trajectory reporting data, driver order data, total driver contribution time during normal hours, total driver contribution time during peak hours, and contribution rewards, and driver level ratings are implemented.

7. A system for determining driver platform contribution time through multiple dimensions, characterized in that, include: Processor and memory; The processor and memory are connected via a communication bus: The processor is used to call and execute the program stored in the memory; The memory is used to store a program, which is at least used to execute a method for determining the driver platform contribution time from multiple dimensions as described in any one of claims 1-6.

Images