Label automatic management method and system in online car-hailing scene

Abstract

The invention relates to a label automatic management method and system in an online car-hailing scene, and the method comprises the steps: monitoring business events in an online car-hailing platform in real time, and the business events comprise a driver behavior event, a vehicle state event, a platform event and an environment event; when the driver behavior event is monitored, inputting a current driver behavior event, a vehicle state event of a vehicle bound with a driver, a platform event of a current time period and an environment event of a current time period of an area where the driver is located into an event analysis model; judging whether the current driver behavior event causes the label change of the driver or not; if the tag change of the driver is caused, querying all tags related to the current driver behavior event; screening a label conforming to the area where the driver is located from all labels related to the current driver behavior event as a target label; adding and / or deleting a target label for the driver; and pushing a label management notice, and a business scene, a business processing mode and a business processing link corresponding to the target label to a driver.

Description

Technical Field

[0001] This application relates to the field of ride-hailing operation management technology, and in particular to an automated tag management method and system for ride-hailing scenarios. Background Technology

[0002] In the ride-hailing operation and management field, driver tags are used to describe a driver's service capabilities, behavioral preferences, service history, and business status, while vehicle tags are used to describe vehicle status, suitable scenarios, and operational conditions. Currently, driver / vehicle tags are mostly added or removed manually, either individually or in batches. This is prone to human error, leading to missed or untimely processing, which can hinder drivers from picking up orders, disrupt the platform's workflow, and cause errors in the overall platform operation and management. Furthermore, the creation, addition, and modification of new tags by business personnel requires assistance from technical developers, consuming significant human resources and communication costs, and offering limited flexibility. Summary of the Invention

[0003] To overcome, to some extent, the problems of low management efficiency of driver / vehicle tags in related technologies, which affect the closed loop of platform processes, make the overall operation and management of the platform prone to errors, and consume a large amount of human resources, this application provides an automated tag management method and system for ride-hailing scenarios.

[0004] The proposed solution is as follows:

[0005] According to a first aspect of the embodiments of this application, a method for automated tag management in a ride-hailing scenario is provided, comprising:

[0006] Real-time monitoring of business events in the ride-hailing platform; the types of business events include: driver behavior events, vehicle status events, platform events, and environmental events;

[0007] When the monitored business event is a driver behavior event, the current driver behavior event, the vehicle status event of the vehicle bound to the driver, the platform event of the current time period, and the environmental event of the area where the driver is located in the current time period are input into the event analysis model;

[0008] The event analysis model is used to determine whether the current driver behavior event has led to a change in the driver's label.

[0009] If the driver's tags change, query all tags related to the current driver's behavior event;

[0010] Select the target tags from all tags related to the current driver behavior event that match the driver's location.

[0011] Add or / or delete the target tags for the driver;

[0012] A tag management notification is pushed to the driver, along with the business scenario, business processing method, and business processing link corresponding to the target tag.

[0013] Preferably, the event analysis model is used to determine whether the current driver behavior event leads to a change in the driver's label, including:

[0014] The event analysis model is used to determine whether the vehicle status events of the vehicle linked to the driver, the platform events of the current time period, and the environmental events of the area where the driver is located at the current time period affect the driver's behavior events.

[0015] If no impact is caused, the output will be the change in the driver's label caused by the current driver behavior event;

[0016] If an impact is caused, the impact score will be calculated based on the vehicle status event of the vehicle bound to the driver, the platform event of the current time period, the impact level of the environmental event of the area where the driver is located at the current time period, and the weight assigned to each business event.

[0017] If the impact score is lower than the preset impact threshold, the output result is the change in the driver's label caused by the current driver behavior event;

[0018] If the impact score is not lower than the preset impact threshold, the output result will be that the current driver behavior event did not cause a change in the driver's label.

[0019] Preferably, the method further includes:

[0020] When the monitored business event is a vehicle status event, query the vehicle, driver, and all tags related to the current vehicle status event;

[0021] Select the target tags from all tags related to the current vehicle status event that match the area where the relevant driver is located;

[0022] Add, and / or delete, the target tags for the relevant vehicles;

[0023] A tag management notification is pushed to the driver, along with the business scenario, business processing method, and business processing link corresponding to the target tag.

[0024] Preferably, the method further includes:

[0025] When the detected business event is a platform event or an environment event, query all tags related to the current platform event or environment event;

[0026] Filter all tags related to current platform events or environmental events to select tags that match the region where the current event occurred as target tags;

[0027] Add and / or delete the target tag for all drivers within the current event area;

[0028] A tag management notification, along with the business scenario, business processing method, and business processing link corresponding to the target tag, is pushed to all drivers in the current event area.

[0029] Preferably, the method further includes:

[0030] Configure tag information, management strategies, and business scenarios;

[0031] Acquire historical driver behavior events, vehicle status events, platform events, and environmental events;

[0032] Configure different impact levels for historical vehicle status events, platform events, and environmental events;

[0033] After establishing a correspondence between the configured tags and historical business events, the event analysis model is trained using the training data.

[0034] The information in a label includes: label name, label category, and label attributes;

[0035] The tag management strategy includes: associated business events, and the addition and deletion strategy when a business event is triggered;

[0036] The business scenarios for the tags include: the corresponding business scenario, as well as the processing method and processing link for the business scenario.

[0037] Preferably, the method further includes:

[0038] Determine the tag configuration method and execute the corresponding historical tag processing strategy based on the tag configuration method, including:

[0039] If the tag configuration method is new version tag configuration, after the new version tag configuration is completed, the historical tags that are the same as the new version tag configuration will be replaced with the new version tags, and the historical tags that are the same as the new version tag configuration will be deleted.

[0040] If the tag configuration method is historical version tag update, then unbind the historical version tag from the driver / vehicle, bind the historical version tag to the driver / vehicle after the historical version tag is updated, and re-enable it according to the updated configuration;

[0041] Detect tag conflicts and disable conflicting tags, including:

[0042] Detect whether there are mutually exclusive tags that automatically add and automatically delete conditions when the same business event is triggered;

[0043] If mutually exclusive tags exist, identify the invalid tags and disable them.

[0044] Preferably, the method further includes:

[0045] When the detected business event is a driver behavior event or a vehicle status event, determine whether the current business event is related to the target group;

[0046] If the current business event is related to the target audience, a special tag management application will be sent to the management personnel;

[0047] The target population is people with disabilities or ethnic minorities.

[0048] Preferably, the method further includes:

[0049] Obtain the driver's historical order behavior data;

[0050] Driver tag information and historical order behavior data are converted into feature vectors and then normalized.

[0051] The processed label feature vector is used as the main clustering dimension, and the driver's historical order behavior feature vector is used as the auxiliary clustering dimension to cluster the drivers;

[0052] Explicit features of an order are generated based on its origin, time, and price. Implicit features of an order are generated based on its popularity and geographical complexity. The explicit and implicit features of the order are then transformed into an order feature vector and normalized.

[0053] The orders are clustered based on the processed order feature vectors;

[0054] Based on the category of the order to be pushed, calculate the matching degree between the order and the various types of drivers, and dispatch orders based on the matching degree calculation results.

[0055] Preferably, the method further includes:

[0056] The driver category with the highest match to the orders to be pushed will be the target driver group;

[0057] Calculate each driver's individual score based on the tag information of each driver in the target driver group;

[0058] Obtain the current location of each driver in the target driver group, and calculate the driver's timeliness score based on the distance between the current location of each driver in the target driver group and the starting point of the order to be pushed;

[0059] Obtain the subjective order-accepting intention of each driver in the target driver group, and calculate the order-accepting intention score of each driver based on the subjective order-accepting intention of each driver in the target driver group;

[0060] Based on the driver's personal rating, timeliness rating, and order acceptance intention rating, as well as the weight assigned to each rating, the comprehensive matching score between each driver in the target driver group and the orders to be pushed is calculated.

[0061] Sort the drivers in the target driver group in descending order of their scores;

[0062] Send the pending orders to the first driver in the queue;

[0063] If the first-priority driver accepts the order, the order will be linked to them;

[0064] If the first-ranked driver refuses the order or fails to accept the order within the specified time, the order will be passed on to the next driver in the queue.

[0065] According to a second aspect of the embodiments of this application, a tag-automated management system for ride-hailing scenarios is provided, comprising:

[0066] Processor and memory;

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

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

[0069] The memory is used to store a program, which is at least used to execute a tag automation management method in a ride-hailing scenario as described in any of the above.

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

[0071] This technical solution eliminates the need for manual tag maintenance, enabling automatic tag addition and deletion, thus improving response speed and accuracy. In implementation, when a driver behavior event is detected, the system does not process the event in isolation but simultaneously considers the following factors: vehicle status events, platform events, and environmental events. These events are jointly input into an event analysis model to determine whether tag management needs to be triggered. By utilizing multi-dimensional data such as driver behavior, vehicle status, platform, and environment, precise control over "whether tag management is needed" is achieved.

[0072] When the event analysis model determines that the current driver behavior event has caused a change in the driver's label, i.e., when label management is required, the system selects the label that matches the driver's region from all the labels related to the current driver behavior event as the target label. This enables the label to be differentiated according to different regions, thus meeting the needs of refined urban operation and management.

[0073] When a driver's tag changes, a tag management notification is sent to the driver, along with the corresponding business scenario, processing method, and processing link for the target tag. This allows the driver to take appropriate action based on the current tag change, thus achieving closed-loop management.

[0074] 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

[0075] 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.

[0076] Figure 1 This is a flowchart illustrating an automated tag management method for ride-hailing scenarios provided in one embodiment of this application;

[0077] Figure 2 This is a schematic diagram of the structure of an automated tag management system for a ride-hailing scenario provided in one embodiment of this application.

[0078] Reference numerals: Processor-21; Memory-22. Detailed Implementation

[0079] 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.

[0080] Example 1

[0081] Figure 1 This is a flowchart illustrating an automated tag management method for ride-hailing scenarios according to an embodiment of this application. (Refer to...) Figure 1 An automated tag management method for ride-hailing scenarios, comprising:

[0082] S11: Real-time monitoring of business events in the ride-hailing platform; types of business events include: driver behavior events, vehicle status events, platform events, and environmental events;

[0083] Driver behavioral events: such as onboarding, document verification, recruitment verification, order acceptance, order refusal, lateness, overtime, etc.;

[0084] Vehicle status events: such as under repair, low battery, annual inspection required, maintenance abnormality, etc.;

[0085] Platform events: such as the start of peak periods, changes in scheduling rules, etc.;

[0086] Environmental events: such as weather changes, traffic control, etc.

[0087] The system needs to build a high-efficiency real-time listening engine to handle the triggering of business events through message queues or event streaming systems (such as Kafka, RabbitMQ, etc.).

[0088] S12: When the monitored business event is a driver behavior event, input the current driver behavior event, the vehicle status event of the vehicle bound to the driver, the platform event of the current time period, and the environmental event of the area where the driver is located in the current time period into the event analysis model;

[0089] S13: Determine whether the current driver behavior event leads to a change in the driver's label through the event analysis model;

[0090] When a driver behavior event is detected, the system does not process the event in isolation. Instead, it considers the following factors simultaneously: vehicle status events, platform events, and environmental events. These events are jointly input into the event analysis model to determine whether tag management needs to be triggered. By utilizing multi-dimensional data such as driver behavior, vehicle status, platform, and environment, the system achieves precise control over "whether tag management is needed."

[0091] S14: If this results in a change in the driver's label, query all labels related to the current driver's behavior event;

[0092] A single behavioral event by a driver may be associated with multiple tags, for example:

[0093] Driver behavior incident: The driver refused orders twice in a row;

[0094] Event model determination: The current driver behavior event causes a change in the driver's label;

[0095] Searching for all tags related to "order rejection incident" yields:

[0096] Drivers with high risk of order rejection, drivers with regional order rejection, and drivers with decreased service activity;

[0097] S15: Select the target label from all labels related to the current driver behavior event that match the driver's location.

[0098] The system queries all tags related to the current business event and further filters target tags that "match the validity of the current region". For example, if the driver's location is Baoding City, the system needs to exclude valid tags from other regions and only retain tags with Baoding City as the target tags.

[0099] In this embodiment, tags that match the driver's location are selected from all tags related to the current driver behavior event as target tags, so as to realize the strategy differentiation of tags according to different regions and meet the needs of refined urban operation and management.

[0100] S16: Add and / or delete target tags for drivers;

[0101] Current driver behavior events may result in the addition or removal of a driver's label. For example, if a driver completes multiple high-rated orders in a row, the system will automatically add a "good service" label to their account. However, if a driver exhibits a series of negative behaviors such as refusing orders, being late, or filing complaints in the past few days, the system will remove the original "good service" label and add a "bad service" label.

[0102] S17: Push tag management notifications to drivers, along with the business scenarios, processing methods, and processing links corresponding to the target tags.

[0103] The tags are related to the business scenarios. For example, after a driver adds the "driving license expired" tag, the system will stop assigning orders to the driver and push a notification to the driver that the "driving license expired" tag has been added. The corresponding business scenario is that the driver cannot drive, and the business processing method is that the driver needs to renew the driver's license, with an online application link for driver's license renewal attached.

[0104] When a driver's tag changes, a tag management notification is sent to the driver, along with the corresponding business scenario, processing method, and processing link for the target tag. This allows the driver to take appropriate action based on the current tag change, thus achieving closed-loop management.

[0105] This technical solution eliminates the need for manual label maintenance, enabling automatic label addition and deletion, thus improving response speed and accuracy.

[0106] Example 2

[0107] It should be noted that the event analysis model determines whether the current driver behavior event leads to a change in the driver's label, including:

[0108] The event analysis model is used to determine whether the vehicle status events of the vehicle linked to the driver, the platform events of the current time period, and the environmental events of the area where the driver is located at the current time period affect the driver's behavior events.

[0109] If no impact is caused, the output will be the change in the driver's label caused by the current driver behavior event;

[0110] If an impact is caused, the impact score will be calculated based on the vehicle status event of the vehicle bound to the driver, the platform event of the current time period, the impact level of the environmental event of the area where the driver is located at the current time period, and the weight assigned to each business event.

[0111] If the impact score is lower than the preset impact threshold, the output result is the change in the driver's label caused by the current driver behavior event;

[0112] If the impact score is not lower than the preset impact threshold, the output result will be that the current driver behavior event did not cause a change in the driver's label.

[0113] When a driver behavior event occurs (such as order refusal, accepting an order after the designated time, or negative passenger feedback), the system does not directly determine whether the event leads to a change in the tag. Instead, it analyzes the contextual influencing factors, including:

[0114] Vehicle status events of the vehicle linked to the driver (such as malfunction, low battery, need for maintenance, etc.);

[0115] Platform events during the current time period (such as whether it is during peak hours, whether there are any adjustments to the platform scheduling strategy, etc.);

[0116] Environmental events in the driver's area at the current time (such as severe weather, traffic congestion, frequent accidents, etc.).

[0117] Conditional branch ①: If no effect is caused

[0118] If the event analysis model determines that the above influencing factors do not significantly interfere with the current driver behavior event, then the driver behavior event is considered to have "independent causality".

[0119] The output is: Driver behavior events will cause driver labels to change.

[0120] For example, if a driver repeatedly refuses orders even when the weather is normal, the vehicle is in normal condition, and the platform is not under pressure, it indicates that their behavior is indeed abnormal and should trigger the "order refusal risk" label.

[0121] Conditional branch ②: If it causes an impact, proceed to the impact score judgment process.

[0122] If the model determines that an environmental or system event has an impact on the behavioral event (e.g., severe weather may lead to passenger complaints, or vehicle malfunction may lead to lateness), then the impact score calculation process begins.

[0123] The process includes:

[0124] 1) Calculation of impact level

[0125] Each type of external event is assigned an impact level, for example:

[0126] Vehicle status = Fault → High impact;

[0127] Platform event = Peak-hour forced order placement → Medium impact;

[0128] Environmental incident = Red alert for heavy rain → High impact;

[0129] You can also set an enumeration level (low=1, medium=2, high=3) as input.

[0130] 2) Weighting mechanism

[0131] The system presets the impact weights for different event types, for example:

[0132] Vehicle status event weight = 0.4;

[0133] Platform event weight = 0.3;

[0134] Environmental event weight = 0.3;

[0135] 3) Calculate the overall impact score

[0136] Calculate using a weighted summation method:

[0137] Impact score = Σ(impact level of each type of event × its weight)

[0138] If the impact score is lower than the preset impact threshold, it indicates that external interference is limited and the driver's behavior is mainly due to himself, which can still trigger label changes.

[0139] If the impact score is higher than or equal to the preset threshold, it indicates that the behavior may be greatly affected by external interference, and it is not advisable to change the label or trigger a label change.

[0140] This embodiment introduces the concept of "influence score" to quantify the degree to which external conditions reasonably explain driver behavior, improve the fairness and rationality of label judgment, prevent mislabeling and unreasonable incentives and penalties, and enhance the credibility of the system.

[0141] It should be noted that the weight and impact threshold of different business events can be adjusted according to different cities / time periods / operational strategies.

[0142] Example 3

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

[0144] When the monitored business event is a vehicle status event, query the vehicle, driver, and all tags related to the current vehicle status event;

[0145] Select the target tags from all tags related to the current vehicle status event that match the area where the relevant driver is located;

[0146] Add and / or delete target tags for relevant vehicles;

[0147] Push tag management notifications to drivers, along with the business scenarios, processing methods, and processing links corresponding to the target tags.

[0148] It should be noted that most vehicle status events originate from objective sensor data or platform periodic detection data, and have clear technical diagnostic standards. For example, events such as "abnormal tire pressure," "low battery," "annual inspection about to expire," and "overdue maintenance" are all directly triggered by hardware monitoring, scheduled tasks, and system rules. The essence of these events is a true reflection of the vehicle's current status, unaffected by other factors, and do not require the intervention of other business events for joint judgment.

[0149] When the detected business event is a vehicle status event, the system first locates the vehicle ID corresponding to the vehicle status event;

[0150] Query the driver information currently bound to the vehicle (if there are multiple binding relationships, the currently operating driver can be identified);

[0151] Then obtain all relevant tags corresponding to the vehicle status event. For example, when the "vehicle needs annual inspection" event is detected, the relevant tags include "needs annual inspection", "cannot be dispatched", and "vehicle to be maintained".

[0152] In this embodiment, vehicle status events (such as malfunction, over-inspection, low battery) can automatically drive tag updates without manual labeling.

[0153] By indirectly notifying drivers of changes in vehicle tags, the flow of information is ensured to be correctly synchronized with the responsible parties, thereby improving the efficiency of closed-loop management.

[0154] The vehicle tag management also applies to the regional adaptation mechanism, which helps to refine regional operation and management.

[0155] Example 4

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

[0157] When the detected business event is a platform event or an environment event, query all tags related to the current platform event or environment event;

[0158] Filter all tags related to current platform events or environmental events to select tags that match the region where the current event occurred as target tags;

[0159] Add and / or delete target tags for all drivers within the current event area;

[0160] Push tag management notifications to all drivers in the area where the current event occurred, along with the business scenario, business processing method, and business processing link corresponding to the target tag.

[0161] The system selects suitable tags for the current region from the tag set based on the region where the event occurred (such as city, administrative region, heat grid, etc.) to form a target tag set; this mechanism prevents mislabeling in areas not affected by the event and achieves regional-level fine-grained control.

[0162] Perform tag addition and deletion operations on all online drivers or recently active drivers within the affected area: if the target tag is "add category", add the tag for drivers of that category; if the target tag is "remove category", remove the relevant tag for them (e.g., when the event ends).

[0163] example:

[0164] Platform event: "Peak-hour order allocation strategy activated", related tags: "Peak hours", "Reward hours";

[0165] Environmental event: "High Temperature Orange Alert", associated tags: "Driving in High Temperature Weather", "Short-Term Order Restriction", "Safety Reminder", etc.

[0166] After the "high temperature orange alert" environmental event is triggered, the system will label all drivers in the area as "driving in high temperature weather";

[0167] After the peak-hour forced dispatch order is lifted, the system automatically removes the "peak hours" and "reward hours" tags.

[0168] This embodiment supports centralized updates of driver tags at the regional level, enabling rapid response to event-driven events at the city and regional levels.

[0169] The "regional adaptation + full addition and deletion" mechanism ensures that only drivers within the affected area are impacted, avoiding interference with unrelated operating areas.

[0170] Each batch update is accompanied by a notification, reducing manual scheduling and customer service intervention.

[0171] Example 5

[0172] The method also includes:

[0173] Configure tag information, management strategies, and business scenarios;

[0174] Acquire historical driver behavior events, vehicle status events, platform events, and environmental events;

[0175] Configure different impact levels for historical vehicle status events, platform events, and environmental events;

[0176] After establishing a correspondence between the configured tags and historical business events, the event analysis model is trained using the training data.

[0177] The information in a label includes: label name, label category, and label attributes;

[0178] The tag management strategy includes: associated business events, and the addition and deletion strategy when a business event is triggered;

[0179] The business scenarios for the tags include: the corresponding business scenario, as well as the processing method and processing link for the business scenario.

[0180] It should be noted that the label name is a unique identifier that cannot be repeated.

[0181] Example of tag categorization:

[0182] Activity tags: Tags that are temporarily created and dynamically bound for specific operational activities, incentive programs, or promotional projects.

[0183] Control tags: Tags that indicate that a driver or vehicle is currently subject to some kind of restriction, control, or high-risk monitoring by the platform.

[0184] Identity tags: Tags used to identify the relatively stable, basic, and core "identity" attributes of a driver or vehicle.

[0185] Warning labels: Labels used to provide information, suggestions or warnings to relevant systems (order dispatch, customer service, operations) or the driver, but do not directly trigger mandatory control measures.

[0186] Other: Other types of tags.

[0187] Specifically, driver-level tag categories can include:

[0188] Basic attributes (compliant driver, non-compliant driver, novice driver, etc.);

[0189] Service capabilities (high-rated drivers, zero-complaint drivers, high-cancellation-rate drivers, etc.);

[0190] Behavioral preferences (preference for long-distance trips, preference for short-distance trips, etc.);

[0191] Safety risks (high-risk driving behavior, detours / refusals to carry passengers, etc.);

[0192] Honors / ranks (Gold Medal Driver, City Hero, etc.);

[0193] The same applies to vehicle tags.

[0194] It should be noted that the above classification is an example and can be freely configured in practice.

[0195] The tag attributes are divided into driver tags and vehicle tags.

[0196] It should be noted that the label management strategy also configures the applicable cities for the label, and a label can be configured to apply to one or more cities.

[0197] The training instructions for the event analysis model are as follows:

[0198] The system obtains historical behavior and state event datasets from the data platform, including but not limited to:

[0199] Historical driver behavior events: accepting orders, refusing orders, being late, exceeding time limits, ratings, complaints, etc.;

[0200] Historical vehicle status events: malfunctions, maintenance, annual inspection, abnormal battery level, system warnings, etc.;

[0201] Historical platform events: Order dispatch strategy adjustments, peak operating periods, reward activities, etc.;

[0202] Historical environmental events: severe weather, holidays, traffic congestion, temporary road closures, etc.

[0203] Each history entry should include:

[0204] Structured information such as event type, time of occurrence, location, associated parties (driver / vehicle), and duration of impact;

[0205] The actual changes in the tags assigned during the same period as the event (whether they were changed, and to which tag).

[0206] The configured tags are associated with historical business event records to form a standard training sample dataset;

[0207] Sample structure diagram:

[0208]

[0209] Using the training data mentioned above, an event analysis model is trained using supervised learning methods (such as XGBoost, LightGBM, random forest, neural networks, etc.) to determine whether the current driver behavior event should trigger a label change.

[0210] Example 6

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

[0212] Determine the tag configuration method and execute the corresponding historical tag processing strategy based on the tag configuration method, including:

[0213] If the tag configuration method is new version tag configuration, after the new version tag configuration is completed, the historical tags that are the same as the new version tag configuration will be replaced with the new version tags, and the historical tags that are the same as the new version tag configuration will be deleted.

[0214] If the tag configuration method is historical version tag update, then unbind the historical version tag from the driver / vehicle, bind the historical version tag to the driver / vehicle after the historical version tag is updated, and re-enable it according to the updated configuration;

[0215] Detect tag conflicts and disable conflicting tags, including:

[0216] Detect whether there are mutually exclusive tags that automatically add and automatically delete conditions when the same business event is triggered;

[0217] If mutually exclusive tags exist, identify the invalid tags and disable them.

[0218] This embodiment implements versioned management of tag configurations, supports closed-loop control for tag upgrades, replacements, and activation, and ensures consistent tag logic.

[0219] When historical version tags change, the old version tags are automatically replaced and the history is deleted to avoid accidental triggering by old tags. After historical version tags are unbound, the binding is re-evaluated according to the new rules, and dynamic adjustments to the configuration are supported.

[0220] By performing conflict detection, we can prevent the coexistence of logically mutually exclusive tags from causing confusion in business rules, thereby improving system stability and correctness. We can also control abnormal and redundant tags through a disabling mechanism, optimizing the tag system's quality and operational performance.

[0221] Example 7

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

[0223] When the detected business event is a driver behavior event or a vehicle status event, determine whether the current business event is related to the target group;

[0224] If the current business event is related to the target audience, a special tag management application will be sent to the management personnel;

[0225] The target population is people with disabilities or ethnic minorities.

[0226] When the system detects a business event as a driver behavior event or a vehicle status event, it will perform the following judgment:

[0227] Based on the driver ID or vehicle ID involved in the business event;

[0228] Access the user profile database or registration information database;

[0229] Determining whether the driver belongs to a special group includes, but is not limited to:

[0230] Accessible populations (such as people with disabilities and those marked with special functional impairments);

[0231] Ethnic minorities (such as those who are marked as a specific ethnic group during registration, or those who enjoy policy-protected labels, etc.).

[0232] If the system determines that the driver or vehicle involved in the business event belongs to the aforementioned target group, it will not automatically perform tag addition or deletion operations, but will instead proceed to the manual review process.

[0233] An "Application for Special Label Management" is automatically generated and sent to the designated administrator or label review group on the platform, who will then manually confirm whether the label operation is permitted.

[0234] Special labels include, for example, "special ethnicity" for drivers, or "accessible vehicle" or "equipped with a child safety seat" for vehicles. These special labels need to be manually added or deleted by administrators for drivers / vehicles.

[0235] Example 8

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

[0237] Obtain the driver's historical order behavior data;

[0238] Driver tag information and historical order behavior data are converted into feature vectors and then normalized.

[0239] The processed label feature vector is used as the main clustering dimension, and the driver's historical order behavior feature vector is used as the auxiliary clustering dimension to cluster the drivers;

[0240] Explicit features of an order are generated based on its origin, time, and price. Implicit features of an order are generated based on its popularity and geographical complexity. The explicit and implicit features of the order are then transformed into an order feature vector and normalized.

[0241] The orders are clustered based on the processed order feature vectors;

[0242] Based on the category of the order to be pushed, calculate the matching degree between the order and the various types of drivers, and dispatch orders based on the matching degree calculation results.

[0243] Furthermore, the methods also include:

[0244] The driver category with the highest match to the orders to be pushed will be the target driver group;

[0245] Calculate each driver's individual score based on the tag information of each driver in the target driver group;

[0246] Obtain the current location of each driver in the target driver group, and calculate the driver's timeliness score based on the distance between the current location of each driver in the target driver group and the starting point of the order to be pushed;

[0247] Obtain the subjective order-accepting intention of each driver in the target driver group, and calculate the order-accepting intention score of each driver based on the subjective order-accepting intention of each driver in the target driver group;

[0248] Based on the driver's personal rating, timeliness rating, and order acceptance intention rating, as well as the weight assigned to each rating, the comprehensive matching score between each driver in the target driver group and the orders to be pushed is calculated.

[0249] Sort the drivers in the target driver group in descending order of their scores;

[0250] Send the pending orders to the first driver in the queue;

[0251] If the first-priority driver accepts the order, the order will be linked to them;

[0252] If the first-ranked driver refuses the order or fails to accept the order within the specified time, the order will be passed on to the next driver in the queue.

[0253] In this embodiment, considering that relying solely on label features for driver clustering may overlook the differences in drivers' actual operational behavior, historical order behavior features are introduced as an auxiliary feature dimension into the clustering process. This can effectively enhance the discriminative power and robustness of the clustering model, making the group profile closer to the actual operational characteristics, thereby improving the efficiency of order push adaptation.

[0254] All features need to be normalized to avoid weight shifts caused by differences in the numerical values ​​of labels and behavioral features.

[0255] After clustering, each group of drivers has a significant combination of features, for example:

[0256] Category A: Fast order processing, preference for short orders, and high service ratings;

[0257] Category B: High activity at night, frequent long-term orders, and large income fluctuations;

[0258] Category C: Airports with concentrated traffic, high ratings, and low cancellation rates.

[0259] The characteristics of the current order to be pushed are matched with the profile of each group to find the driver group that is most similar to the characteristics of the order, and the target audience is selected from the group first.

[0260] Preferably, drivers are ranked using individual ratings within the driver category matched by the current order to be pushed, thus implementing a hybrid recommendation strategy of "group screening + individual ranking".

[0261] Finally, the automatic postponement mechanism improves the order dispatch success rate, reduces user waiting time, and achieves a flexible scheduling closed loop.

[0262] Example 9

[0263] Figure 2 This is a schematic diagram of the structure of an automated tag management system for a ride-hailing scenario provided in one embodiment of this application, with reference to... Figure 2 An automated tag management system for ride-hailing scenarios includes:

[0264] Processor 21 and memory 22;

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

[0266] Among them, processor 21 is used to call and execute programs stored in memory;

[0267] The memory 22 is used to store a program, which is used to execute at least one of the tag automation management methods in a ride-hailing scenario as described in any of the above embodiments.

[0268] 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.

[0269] 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.

[0270] 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.

[0271] 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.

[0272] 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.

[0273] 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.

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

[0275] 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.

[0276] 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 automated tag management in a ride-hailing scenario, characterized in that, include: Real-time monitoring of business events on ride-hailing platforms; The types of business events include: driver behavior events, vehicle status events, platform events, and environmental events; When the monitored business event is a driver behavior event, the current driver behavior event, the vehicle status event of the vehicle bound to the driver, the platform event of the current time period, and the environmental event of the area where the driver is located in the current time period are input into the event analysis model; The event analysis model is used to determine whether the current driver behavior event has led to a change in the driver's label. If the driver's tags change, query all tags related to the current driver's behavior event; Select the target tags from all tags related to the current driver behavior event that match the driver's location. Add or / or delete the target tags for the driver; A tag management notification is pushed to the driver, along with the business scenario, business processing method, and business processing link corresponding to the target tag.

2. The method according to claim 1, characterized in that, The event analysis model determines whether the current driver behavior event leads to a change in the driver's label, including: The event analysis model is used to determine whether the vehicle status events of the vehicle linked to the driver, the platform events of the current time period, and the environmental events of the area where the driver is located at the current time period affect the driver's behavior events. If no impact is caused, the output will be the change in the driver's label caused by the current driver behavior event; If an impact is caused, the impact score will be calculated based on the vehicle status event of the vehicle bound to the driver, the platform event of the current time period, the impact level of the environmental event of the area where the driver is located at the current time period, and the weight assigned to each business event. If the impact score is lower than the preset impact threshold, the output result is the change in the driver's label caused by the current driver behavior event; If the impact score is not lower than the preset impact threshold, the output result will be that the current driver behavior event did not cause a change in the driver's label.

3. The method according to claim 1, characterized in that, The method further includes: When the monitored business event is a vehicle status event, query the vehicle, driver, and all tags related to the current vehicle status event; Select the target tags from all tags related to the current vehicle status event that match the area where the relevant driver is located; Add, and / or delete, the target tags for the relevant vehicles; A tag management notification is pushed to the driver, along with the business scenario, business processing method, and business processing link corresponding to the target tag.

4. The method according to claim 1, characterized in that, The method further includes: When the detected business event is a platform event or an environment event, query all tags related to the current platform event or environment event; Filter all tags related to current platform events or environmental events to select tags that match the region where the current event occurred as target tags; Add and / or delete the target tag for all drivers within the current event area; A tag management notification, along with the business scenario, business processing method, and business processing link corresponding to the target tag, is pushed to all drivers in the current event area.

5. The method according to claim 1, characterized in that, The method further includes: Configure tag information, management strategies, and business scenarios; Acquire historical driver behavior events, vehicle status events, platform events, and environmental events; Configure different impact levels for historical vehicle status events, platform events, and environmental events; After establishing a correspondence between the configured tags and historical business events, the event analysis model is trained using the training data. The information in a label includes: label name, label category, and label attributes; The tag management strategy includes: associated business events, and the addition and deletion strategy when a business event is triggered; The business scenarios for the tags include: the corresponding business scenario, as well as the processing method and processing link for the business scenario.

6. The method according to claim 5, characterized in that, The method further includes: Determine the tag configuration method and execute the corresponding historical tag processing strategy based on the tag configuration method, including: If the tag configuration method is new version tag configuration, after the new version tag configuration is completed, the historical tags that are the same as the new version tag configuration will be replaced with the new version tags, and the historical tags that are the same as the new version tag configuration will be deleted. If the tag configuration method is historical version tag update, then unbind the historical version tag from the driver / vehicle, bind the historical version tag to the driver / vehicle after the historical version tag is updated, and re-enable it according to the updated configuration; Detect tag conflicts and disable conflicting tags, including: Detect whether there are mutually exclusive tags that automatically add and automatically delete conditions when the same business event is triggered; If mutually exclusive tags exist, identify the invalid tags and disable them.

7. The method according to claim 1, characterized in that, The method further includes: When the detected business event is a driver behavior event or a vehicle status event, determine whether the current business event is related to the target group; If the current business event is related to the target audience, a special tag management application will be sent to the management personnel; The target population is people with disabilities or ethnic minorities.

8. The method according to claim 1, characterized in that, The method further includes: Obtain the driver's historical order behavior data; Driver tag information and historical order behavior data are converted into feature vectors and then normalized. The processed label feature vector is used as the main clustering dimension, and the driver's historical order behavior feature vector is used as the auxiliary clustering dimension to cluster the drivers; Explicit features of an order are generated based on its origin, time, and price. Implicit features of an order are generated based on its popularity and geographical complexity. The explicit and implicit features of the order are then transformed into an order feature vector and normalized. The orders are clustered based on the processed order feature vectors; Based on the category of the order to be pushed, calculate the matching degree between the order and the various types of drivers, and dispatch orders based on the matching degree calculation results.

9. The method according to claim 8, characterized in that, The method further includes: The driver category with the highest match to the orders to be pushed will be the target driver group; Calculate each driver's individual score based on the tag information of each driver in the target driver group; Obtain the current location of each driver in the target driver group, and calculate the driver's timeliness score based on the distance between the current location of each driver in the target driver group and the starting point of the order to be pushed; Obtain the subjective order-accepting intention of each driver in the target driver group, and calculate the order-accepting intention score of each driver based on the subjective order-accepting intention of each driver in the target driver group; Based on the driver's personal rating, timeliness rating, and order acceptance intention rating, as well as the weight assigned to each rating, the comprehensive matching score between each driver in the target driver group and the orders to be pushed is calculated. Sort the drivers in the target driver group in descending order of their scores; Send the pending orders to the first driver in the queue; If the first-priority driver accepts the order, the order will be linked to them; If the first-ranked driver refuses the order or fails to accept the order within the specified time, the order will be passed on to the next driver in the queue.

10. An automated tag management system for ride-hailing scenarios, 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 the automated tag management method in a ride-hailing scenario as described in any one of claims 1-9.

Images