Geopropagation management method and system based on multi-role attribution and ladder incentive

Abstract

The application relates to the technical field of data processing, and particularly discloses a field promotion management method and system based on multi-role attribution and ladder incentive, which comprises the following steps: acquiring customer event data, establishing a customer life cycle event chain covering the whole process from touch to conversion and generating life cycle state data; identifying business participation roles in each life cycle stage and constructing a dynamic multi-role attribution model; extracting multi-source abnormal events for correlation matching and fusion to generate a comprehensive abnormal event set and construct an abnormal statistical base; correcting performance statistical results according to the abnormal statistical base, executing ladder incentive matching to generate incentive result data; performing budget control and distribution according to the incentive result, and recalculating customer attribution when the staff organization is changed or the staff leaves to complete asset inheritance; the precise tracing of multi-role performance attribution, the fusion statistics of multi-dimensional abnormal events and the safe inheritance of customer assets are realized, and the efficiency and accuracy of offline field promotion management are improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a ground promotion management method and system based on multi-role affiliation and tiered incentives. Background Technology

[0002] Offline sales promotion is a crucial method for acquiring new customers in industries such as education and training, retail, FMCG, and internet services. In offline sales promotion, the process from initial contact with a specialist to final conversion typically involves multiple stages: specialist contact, adding the customer on WeChat, course access, learning experience, and purchase conversion. Each stage may be handled by different roles, including full-time specialists, part-time specialists, support staff, and mentors. To support the efficient operation of these businesses, various offline sales promotion management systems have emerged in the industry. For example, JD Retail Cloud's "JD Ground Support System" integrates ground team operation and management functions. Frontline staff can use mobile devices to acquire new customers, maintain customer relationships, and promote products. Companies can achieve standardized management of field staff through personnel and performance management. In WeCom Assistant's "Self-Service Promotion Code" solution, when a customer scans an employee's exclusive QR code to add them on WeChat, the system automatically identifies the associated promoter. Backend data can be viewed from multiple dimensions, including individuals, stores, and departments, showing new friend additions and cumulative data. In Youzan's "Employee Distribution" solution, after a distributor adds a customer on WeChat, the customer relationship is automatically bound, and subsequent order performance and commissions are automatically attributed to the corresponding employee. However, the aforementioned existing technical solutions still have the following shortcomings when facing complex scenarios such as multi-role participation, multi-stage transition, multi-dimensional anomaly detection, and dynamic organizational changes in offline promotion business.

[0003] Specifically, existing CRM systems or field sales management platforms typically only record a single field such as "last contact person" or "customer's employee," which cannot support multi-role revenue sharing across the entire "contact-add WeChat-mentor-conversion" chain. A single attribution either assigns all performance to the contact person (leading the WeChat contact person to lack motivation) or all performance to the WeChat contact person (leading the contact person to lack motivation), failing to balance the interests of multiple parties. Furthermore, employees may leave, be transferred, or change their affiliation at any time, and performance must be traced back to the organizational relationship at the time the event occurred. The existing single field cannot achieve historical attribution version tracing.

[0004] Incentive settlement is usually done manually by finance or HR personnel using Excel – exporting data from various business systems, manually verifying performance attribution, and manually calculating incentive amounts according to ranking or tier rules – lacking a unified skip-number ranking process when scores are tied, resulting in low efficiency in tier range matching, and lacking atomicity guarantees when multiple service instances concurrently execute budget deductions, which can easily lead to over-deductions. The entire settlement cycle usually takes 2-3 days, which is time-consuming, labor-intensive, and prone to errors.

[0005] Furthermore, existing anti-fraud systems typically detect and alert on single abnormal indicators (such as fraudulent orders or orders from different locations) separately. When the same behavior simultaneously hits multiple abnormal dimensions, simple addition leads to duplicate counting, and the denominators for each abnormal dimension are different (e.g., the denominator for the rate of classes taken in different locations is the number of classes taken, while the denominator for the abnormal conversion rate is the number of conversions). Direct aggregation will produce statistical distortion, and it also lacks the ability to aggregate hierarchically according to organizational levels. In addition, the `resignedTransferCustomer` interface provided by WeChat Work is an asynchronous interface—after calling it, returning `errcode=0` only indicates that "the request has been accepted", not that the friend has been successfully transferred. The existing solution simply checks the return code after calling it. When the transfer on the WeChat Work side is delayed or fails, the local database has been updated but the friend relationship on the WeChat Work side has not been transferred, resulting in dirty data of "inconsistency between the local owner and the WeChat Work friend relationship". Moreover, when multiple takeovers are involved, there is no automatic equalization mechanism, and the amount of data handled by a single person is uncontrollable. Summary of the Invention

[0006] In view of this, embodiments of the present invention provide a ground promotion management method and system based on multi-role attribution and tiered incentives to solve the problems of low efficiency, poor data consistency and high operating costs in the existing offline ground promotion growth management process. This is because the customer journey from initial contact to final conversion involves multiple business roles such as contact specialists, WeChat specialists, and mentors, as well as multiple business nodes in the process. Furthermore, the employee organizational structure has dynamic characteristics, which makes it difficult to accurately trace the performance attribution of multiple roles, rely on manual statistics for incentive settlement of rankings and tiered intervals, and make it difficult to identify and aggregate abnormal behaviors across multiple dimensions and organizational levels. Additionally, the assets of departing customers are difficult to inherit securely due to inconsistencies between the asynchronous interface of WeChat and local data.

[0007] This invention provides a ground sales management method and system based on multi-role affiliation and tiered incentives, comprising the following steps: S1: Obtain customer event data generated during offline promotion, identify event types, sort events by time, and perform business correlation analysis on the customer event data, establish a lifecycle event chain covering the entire process of customer outreach, adding on WeChat, course acquisition, course learning, course conversion, and organizational changes, and generate corresponding customer lifecycle status data based on the lifecycle event chain. S2: Identify the business participation roles of customers at different lifecycle stages based on the lifecycle status data, and construct a dynamic multi-role attribution model of customers by combining employee identity information, employee organizational relationship and organizational relationship change records, and establish the association mapping relationship between customer lifecycle status data and dynamic multi-role attribution model; S3: Extract multi-source abnormal events generated during the customer lifecycle based on the dynamic multi-role attribution model, perform correlation matching and fusion processing on the multi-source abnormal events to generate a comprehensive set of customer abnormal events, and re-aggregate organizational-level business data based on the comprehensive set of abnormal events to construct an organizational-level abnormal statistical base. S4: Recalculate the performance statistics results corresponding to each organizational level based on the abnormal statistical base of the organizational level, and use the comprehensive abnormal event set to correct the performance statistics results. Perform tiered incentive matching based on the corrected performance statistics results to generate incentive result data for the corresponding employees. S5: Perform budget control and incentive distribution based on the incentive result data, and when a change in employee organizational relationship or employee resignation is detected, recalculate customer ownership relationship based on the dynamic multi-role ownership model, complete customer asset inheritance processing, and update customer lifecycle status data, dynamic multi-role ownership model and customer ownership relationship data.

[0008] The ground sales management method and system based on multi-role affiliation and tiered incentives provided by this invention have the following beneficial effects: In this invention, a three-foreign-key attribution model is constructed for the contact specialist (employeeId), the micro-acquisition specialist (belongerId), and the mentor (mentorId). By combining the organizational relationship change time to establish an attribution relationship version sequence, accurate traceability and historical backtracking of multi-role performance attribution throughout the customer's entire lifecycle are achieved. This solves the problem that traditional single attribution fields cannot support multi-person revenue sharing across the entire chain. The contact specialist and the micro-acquisition specialist each receive 100% performance attribution, and the mentor automatically receives commission, effectively mobilizing the enthusiasm of all parties. On this basis, the SystemRewardStrategy class is used to uniformly handle three settlement modes: ranking tie, tiered interval matching, and budget atomic deduction. This achieves full automation of incentive settlement. Monthly incentive settlement is shortened from 3 days of manual Excel processing to a few hours of automatic distribution by the system on T+1. It supports more than 200 cities and more than 20 rules running simultaneously without over-deduction. Meanwhile, by aggregating statistics by six independent SQL statements according to organizational hierarchy, combined with toMergeVo for deduplication and toAggregateVo for hierarchical recalculation, the problem of duplicate counting and inconsistent denominators in the fusion statistics of multi-dimensional abnormal events was solved. Combined with six-level city matching, the accuracy of cross-regional order identification was improved to over 95%, effectively reducing the false judgment rate. It also solved the technical problems of difficulty in accurately tracing the ownership of multiple roles in offline sales management, low efficiency of incentive settlement, difficulty in fusion statistics of abnormal behavior, and difficulty in securely inheriting customer assets, significantly improving the efficiency of offline growth management, data consistency, and operational compliance. Attached Figure Description

[0009] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, and these are all within the protection scope of the present invention.

[0010] Figure 1 This is a flowchart of a field sales management method based on multiple role affiliations and tiered incentives.

[0011] Figure 2 This is a structural diagram of a ground promotion management system based on multi-role affiliation and tiered incentives. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. In the description of the present invention, it should be understood that the terms "center," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the referred device or element must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements, but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, the element defined by the phrase "comprising..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. Where there is no conflict, embodiments of the present invention and the various features thereof can be combined with each other, all of which are within the scope of protection of the present invention.

[0013] Example 1 Please see Figure 1 This invention provides a ground sales management method based on multi-role affiliation and tiered incentives, comprising the following steps: S1: Obtain customer event data generated during offline promotion, identify event types, sort events by time, and perform business correlation analysis on the customer event data, establish a lifecycle event chain covering the entire process of customer outreach, adding on WeChat, course acquisition, course learning, course conversion, and organizational changes, and generate corresponding customer lifecycle status data based on the lifecycle event chain. Specifically, the system receives `change_external_contact` events (representing customers adding specialists as friends) in real time via the WeChat Work event callback mechanism, obtains course pickup and conversion events through the business system's order interface, acquires course learning progress and completion events through the student management system, and retrieves employee organizational change events through the organizational structure synchronization interface. For each type of event, the system extracts the customer identifier (e.g., the customer's `external_userid` in WeChat Work), event type, event occurrence time, and associated business object information, and establishes a corresponding event set for the customer using the customer identifier as the key.

[0014] Then, the event sets for each customer are sorted in ascending order according to the event occurrence time, and the lifecycle stage to which each event belongs is identified according to the preset lifecycle node rules. The lifecycle node rules divide the entire offline customer acquisition process into the following stages: customer contact stage, WeChat addition stage, course acquisition stage, course learning stage, course conversion stage, and organizational change stage. By mapping the sorted event sequence with the above lifecycle stages, the system establishes a lifecycle event chain covering the entire process from the first contact to the completion of the business.

[0015] Then, the customer lifecycle state transition path is calculated based on the sequential relationships between adjacent events in the lifecycle event chain; for example, transitioning from the "added friend" state to the "claimed course" state and then to the "converted" state. Based on the current lifecycle node, previously reached lifecycle nodes, and the complete state transition path, structured customer lifecycle state data is generated. This lifecycle state data includes at least a unique customer identifier, the current lifecycle stage, the event timestamps corresponding to each stage, and a complete record of the state transition path.

[0016] S2: Identify the business participation roles of customers at different lifecycle stages based on the lifecycle status data, and construct a dynamic multi-role attribution model of customers by combining employee identity information, employee organizational relationship and organizational relationship change records, and establish the association mapping relationship between customer lifecycle status data and dynamic multi-role attribution model; Specifically, employee identifiers are extracted from event records during the customer outreach phase, employee identifiers from event records during the WeChat addition phase, and employee identifiers from event records during the course learning and conversion phase. Then, combined with the identity category information of employees involved in each business, including five work types such as full-time, part-time, on-call, one-to-many, and B2B part-time, a multi-role attribution relationship is established between customers and employees involved in each business.

[0017] Specifically, the customer lead table `og_customers_leads` has three foreign key fields: `employee_id` records the contact specialist, `belonger_id` records the WeChat contact specialist, and `mentor_id` records the mentor. When the system processes the WeChat friend addition event through the `ChangeExternalContactEventHandler`, it calls the `improveInformationOrg` method. First, it queries the employee's report results to obtain their `jobCategory`. Then, it uses the `JobCategoryEnum.notFullTime()` method to determine if the employee is a part-time employee (i.e., part-time, on-call, one-to-many, or B2B part-time). If so, it automatically writes the employee's mentor ID into the `mentor_id` field; if the employee is a full-time employee, the `mentor_id` field is left blank. Through this process, the automatic writing of the three foreign key relationships is completed the instant a customer adds a friend.

[0018] Next, the system retrieves the organizational structure information for each employee involved in the business, including their region, promotion city (manager_org_id), and business team (director_org_id), as well as records of job adjustments, organizational migrations, and changes in mentorship relationships. Since employees in the offline sales industry may leave, be transferred, or change affiliations at any time, and performance must be traced back to the organizational relationship at the time of the event, rather than being calculated based on the current organization, the system establishes a sequence of affiliation versions based on the time of change of each organizational relationship. When it is necessary to determine the affiliation of a customer at a certain lifecycle node, the system uses the valid affiliation version at that time, rather than the latest affiliation, based on the event occurrence time of that node, thus ensuring the historical accuracy of performance attribution.

[0019] Then, establish customer lifecycle status data, dynamic multi-role attribution relationships, and the mapping relationships between organizational levels to form a complete dynamic multi-role customer attribution model. This model takes the customer as the hub and associates the customer's status data at different stages of the lifecycle with the business participants and their organizational attribution relationships at the corresponding time. This ensures that subsequent anomaly detection, performance statistics, and incentive settlement can all be calculated based on the correct attribution relationships.

[0020] S3: Extract multi-source abnormal events generated during the customer lifecycle based on the dynamic multi-role attribution model, perform correlation matching and fusion processing on the multi-source abnormal events to generate a comprehensive set of customer abnormal events, and re-aggregate organizational-level business data based on the comprehensive set of abnormal events to construct an organizational-level abnormal statistical base. In this implementation, multi-source abnormal events generated during the customer lifecycle are extracted based on a dynamic multi-role attribution model. The following six types of abnormal events are extracted from the course receipt details table `og_receive_detail` and the conversion details table `og_convert_detail`: WeChat abnormal events, static QR code abnormal events, abnormal conversion events, high-frequency order events, remote ordering events, and remote course events. For each type of abnormal event, the system obtains its unique customer identifier, unique order identifier, event occurrence time, event type, and corresponding business participation role information.

[0021] Then, an association index is established between different abnormal events based on the customer's unique identifier and the order's unique identifier. For multiple abnormal events that meet the same customer unique identifier, the same order unique identifier, or preset association conditions, they are matched together. For example, the same customer may trigger both a cross-order event and a high-frequency order event in the same class booking behavior. These two abnormal events are associated through the customer identifier and the order identifier. The associated abnormal events are then merged based on the order of occurrence, lifecycle stage, and dynamic multi-role affiliation relationship, integrating multiple interrelated abnormal events into a single comprehensive abnormal event for that customer, thus avoiding the same abnormal behavior being counted repeatedly in different dimensions.

[0022] In the specific implementation of the fusion processing, the `toMergeVo` method in the `AbnormalOrderStatisticsServiceImpl` service is used for merging and deduplication: When the same specialist is matched by multiple indicator SQL queries, all results are aggregated into a single record. Numerical fields are summed, while the ratio field takes the first non-null value instead of summing them, to avoid statistical distortion caused by duplicate ratio counts. The system also uses the `toAggregateVo` method to achieve organizational-level aggregation: a group of statistical results at the same level are aggregated into a single record. After summing the numerical fields, the ratio field is recalculated using the new numerator and denominator after aggregation; for example, abnormal conversion rate = total abnormal conversions / total conversions. Simply averaging or weighting the ratios of each sub-item is not sufficient, otherwise statistical errors such as ratio sums exceeding 1 may occur.

[0023] Next, based on the dynamic multi-role attribution model, the organizational hierarchy path corresponding to each employee is obtained, including levels such as region, promotion city, and business team, and a hierarchical mapping relationship is established between employees, organizational nodes, and comprehensive abnormal events. Comprehensive abnormal events are mapped to their corresponding organizational levels, and the number of comprehensive abnormal events, the number of normal business events, and the total number of business events corresponding to each organizational level are counted. Specifically, the system uses six independent SQL templates to calculate six types of abnormal indicators. Each SQL statement controls the aggregation granularity of region, team, and specialist through level==2 / 3 / 4, and aggregates level by level according to organizational hierarchy using the three fields manager_org_id, director_org_id, and employee_id.

[0024] Specifically, for identifying cross-regional order events, the system employs a six-tiered city-level matching condition: ① Virtual city approval; ② Originating city includes IP city; ③ District-level city matching; ④ Provincial-level city matching; ⑤ Parent city matching; ⑥ Parent province matching. These six OR conditions effectively cover the complex hierarchical relationships within China's urban administrative divisions, including municipalities, prefecture-level cities, county-level cities, districts, and high-tech zones, thus preventing the misclassification of normal course pickups within the same city but in different districts as cross-regional orders.

[0025] S4: Recalculate the performance statistics results corresponding to each organizational level based on the abnormal statistical base of the organizational level, and use the comprehensive abnormal event set to correct the performance statistics results. Perform tiered incentive matching based on the corrected performance statistics results to generate incentive result data for the corresponding employees. In this implementation, the performance statistics for each organizational level are recalculated based on the statistical baseline of organizational level anomalies. This process obtains business event data, a comprehensive set of anomalies, and organizational level anomaly statistics for each employee. A correlation is established between business events and comprehensive anomalies based on the employee's organizational level. Then, anomaly corrections are applied to each business event based on the anomaly type and impact of the comprehensive anomalies. For example, orders marked as having abnormal conversions are removed when calculating conversion performance; orders marked as having remote class pickups are deducted when calculating pickup performance. The effective business value for each business event is then obtained. The system recalculates the performance score for each employee based on the corrected effective business value and generates employee performance results, team performance results, and city performance results according to organizational level.

[0026] Then, the system performs tiered incentive matching based on the corrected performance statistics, obtains the performance scores corresponding to each organizational level, establishes a mapping relationship between performance scores and incentive levels according to the preset incentive strategy, and ranks employees based on their performance scores. Specifically, the system uses the SystemRewardStrategy class to uniformly handle three settlement modes: For the ranking mode, the system uses the genRankNo method to handle tied scores using a cumulative ranking skipping method, that is, employees with the same score have the same ranking number, and subsequent employees with different scores skip the already occupied ranking number, thus achieving a "1, 1, 3" skipping ranking effect. For the tiered range mode, the system uses the calculateReward method to use a binary search algorithm to locate which tier range [minValue, maxValue] an employee's performance score falls into, and returns the reward points value corresponding to that range; for the target achievement rate mode, the corresponding incentive level is matched according to the ratio of the employee's actual achievement value to the target value.

[0027] During the incentive matching process, a cold start filtering process is also performed: For the course completion conversion rate metric, the system sets a threshold for the number of course completion orders through the Apollo configuration item og.city.incentive.convert_rate_threshold (default value is 50). Only specialists whose number of course completion orders reaches this threshold are eligible to be included in the incentive statistics for course completion conversion rate. This avoids the distortion of conversion rate statistics due to the small sample size of newly hired or low-productivity specialists, thereby reducing the overall accuracy of incentive calculation for the team.

[0028] In this implementation, to automate incentive settlement for tied rankings and tiered intervals, the system uses the SystemRewardStrategy class to uniformly handle the three settlement modes. This strategy class is the main entry point for incentive settlement, triggered by the XXL-Job scheduler in the T+1 scheduled task, executing the giveRewards method to complete the entire process of "metric calculation - ranking / tier matching - budget deduction - account points distribution - exception alarm". The strategy class first queries the incentive budget for the current assessment month using IncentiveBudgetService.selectByMonth. If the budget balance is insufficient, it sends a DingTalk alarm via DingTalkExceptionAlarmWrapper and terminates the current distribution. Then, it retrieves all incentive rules effective within the current period using IncentiveRuleService.listByType. Each rule includes the hierarchical level, triggering metric, statistical period, rule type, and corresponding rule details. For each rule, the `getStatisticalResult` method routes to the corresponding data source based on the rule's `conditionType` to retrieve performance statistics (Leads and GMV are retrieved from `ReceiveDetailMapper`, achievement rate from `FinanceTargetService`, and closing conversion rate from `ReceiveDetailMapper.getConvertOfIncentive`, with a 3-day observation window and cold start threshold filtering applied). Then, matching calculations are performed based on the rule type, and finally, the `doDistributeBySystem` method completes budget deduction and points distribution.

[0029] When handling ties in the ranking mode, the system employs a cumulative ranking skipping mechanism using the `genRankNo` method. This method first sorts the employee list in descending order of performance scores and filters out records with zero or empty scores. Then, it iterates through the sorted list, maintaining two variables: `currentRank` and `cumulativeRank`. When the performance scores of adjacent employees change, `cumulativeRank` is incremented, and `currentRank` is updated to the incremented `cumulativeRank` value. When performance scores are the same, `currentRank` remains unchanged. Through this mechanism, the system generates a skipping ranking in the format "1, 1, 3". This means that when two employees are tied for first place, both are displayed as number 1, and the next rank jumps directly to number 3, rather than a standard ranking of "1, 2, 3" or a dense ranking of "1, 1, 2". The technical significance of this skipping ranking is that when the budget is insufficient to support all qualified employees, the system truncates the distribution according to ranking priority, with higher-ranked employees receiving full points first. When the budget balance is insufficient to support full distribution to all employees in the next ranking level, no distribution is given to any employee in that ranking level, ensuring fair treatment for employees with tied scores.

[0030] When handling the tiered range pattern, the `calculateReward` method employs a binary search algorithm to locate the tier interval into which the performance score falls. This method requires the `ruleDetails` list to be sorted in ascending order by `minValue`. It then maintains two pointers, `left` and `right`, and takes the middle position `mid` each time, comparing the performance score with the `minValue` and `maxValue` of `ruleDetails.get(mid)`: if the score is greater than or equal to `minValue` and less than `maxValue`, the tier interval is matched, and the corresponding point score is returned; if the score is less than `minValue`, the right boundary is reduced by `right = mid - 1`; otherwise, the left boundary is reduced by `left = mid + 1`; if no match is found after traversal, `null` is returned. Binary search optimizes the time complexity of tier interval matching from O(n) of sequential traversal to O(logn), resulting in a significant performance improvement when the number of tiers is large.

[0031] Regarding budget control, a Redis distributed lock is acquired via `DistributedLockHelper.doActionWithLock` before each points distribution. The lock key is generated by `RedisKeyUtils.genIncentiveBudgetLockKey(budgetId)`, in the format `og:city:incentive:budget:lock:{budgetId}`. The lock timeout is 10 seconds, with a 1-second retry interval and a maximum of 3 retries, ensuring the atomicity of the budget deduction operation. Simultaneously, the system employs a single-employee isolation strategy: in the `doDistributeBySystem` method, a try-catch block is used to wrap a single points distribution operation. If a point distribution fails for an employee due to account anomalies or other reasons, the system records an error log and sends an alert via DingTalk, but this does not affect the normal distribution to other employees in the same batch, avoiding a single point of failure that could interrupt the entire distribution process.

[0032] S5: Perform budget control and incentive distribution based on the incentive result data, and when a change in employee organizational relationship or employee resignation is detected, recalculate customer ownership relationship based on the dynamic multi-role ownership model, complete customer asset inheritance processing, and update customer lifecycle status data, dynamic multi-role ownership model and customer ownership relationship data. In this implementation, budget control and incentive distribution are performed based on incentive result data. Before distributing incentive points, the system first queries the incentive budget for the current assessment period (e.g., monthly) through IncentiveBudgetService, including the total budget and the amount of points already distributed (hadDistributed), and calculates the available balance. If the budget balance is insufficient (balance<=0), the system sends a DingTalk alert message to the administrator via DingTalkExceptionAlarmWrapper and suspends the distribution. If the budget is sufficient, when deducting the budget, the system uses the DistributedLockHelper.doActionWithLock utility class and the RedisKeyUtils.genIncentiveBudgetLockKey method to obtain a Redis distributed lock with the budget ID as the key (lock key format is og:city:incentive:budget:lock:{budgetId}), ensuring the atomicity of the budget deduction operation and avoiding budget over-deduction issues when multiple service instances execute concurrently. During the distribution process, if distribution fails for a single employee, the exception is caught separately using try-catch and logged, without affecting the continued distribution to other employees.

[0033] When the system detects a change in an employee's organizational affiliation or an employee's departure, it recalculates customer ownership relationships based on a dynamic multi-role attribution model to complete customer asset inheritance. Specifically, the system first queries all customer leads under the departing employee's name, and then, based on the list of successors, uses the distributeLeads method with a round-robin distribution algorithm (i%n) to evenly distribute the customers among the successors—for example, 100 customers distributed to 2 successors receive 50 each, while distributed to 3 successors receive 34, 33, and 33 customers respectively.

[0034] During the customer asset migration process, the system calls the resignedTransferCustomer interface of WeChat Work to transfer the customer's friend relationships from the departing specialist to the taking-over specialist. Because this interface is asynchronous—an errcode=0 returned after the call only indicates "request accepted," not that the friend transfer was successful—the system processes each customer's errcode individually in the transferResult method: If successful (errcode=0), the system updates the `belonger_id` field in the local `og_customers_leads` table and writes it to the `og_customers_leads_transfer` transfer log table, while also updating the `cpUserId` field in the `og_corp_tag_customers_new` table; if unsuccessful, the system skips that customer, without affecting the transfer of other customers. The `transferStatus` field uses a three-state semantic: 0 indicates transfer failure, 1 indicates transfer success, and 2 indicates transfer in progress.

[0035] Simultaneously, a dual-write mechanism is employed to ensure local data consistency: First, the `og_customers` table is queried by `wechatUserId`, then the `belonger_id` field is modified after joining with the `og_customers_leads` table, followed by writing to the `og_customers_leads_transfer` transaction log table. Finally, the `cpUserId` field of the `og_corp_tag_customers_new` table is updated asynchronously. The first four steps are decoupled from the last step using independent try-catch blocks, achieving eventual consistency—even if the last step update fails, the core ownership relationships and transfer logs have been correctly written, without affecting the core functionality of customer asset inheritance.

[0036] Further, S1 includes: Acquire customer touch events, WeChat addition events, course collection events, course learning events, course completion events, order generation events, and organizational change events generated during the on-the-ground promotion business. Extract customer identifier, event type, event occurrence time, and related business object information for each event, and establish the event set for the corresponding customer based on the customer identifier. The event set is sorted according to the time of occurrence, and the life cycle stage of each event is identified according to the preset life cycle node rules to establish a life cycle event chain covering the entire process from the first contact with the customer to the completion of the business. The customer lifecycle state transition path is calculated based on the sequential relationship between adjacent events in the lifecycle event chain, and customer lifecycle state data is generated based on the current lifecycle node, historical lifecycle nodes, and state transition path. Specifically, the system receives the `change_external_contact` event through the WeChat Work event callback mechanism. When a customer scans a specialist's promotional QR code to add a WeChat Work friend, the WeChat Work server pushes an "Add External Contact" event to the system. The system receives and parses this event through the `ChangeExternalContactEventHandler` event handler, extracting the customer's unique identifier `external_userid` in WeChat Work, the specialist's employee identifier `employee_id`, the event occurrence time, and the source of the added scenario, among other related information. For course claiming events, the system obtains the customer's order information for claiming a trial course through the e-commerce order interface, including the order number `order_num`, the course identifier `course_key`, the claiming time, and promotion channel parameters. For course learning and course completion events, the system obtains the customer's learning progress report data through the student management system's event subscription mechanism, including the course start time, completion status of each chapter, and course end time. For order generation events, the system obtains the customer's order data for purchasing full-price courses through the transaction system's order change message queue, including the order amount, payment time, and refund status. For organizational change events, the system obtains records of organizational relationship changes such as employee job adjustments, departmental relocations, and resignations through regular synchronization with the group's human resources and organizational structure gateway. For each event obtained, the system extracts the customer identifier, event type, event occurrence time, and related business object information, and uses the customer identifier as the key to aggregate all events belonging to the same customer into the event set corresponding to that customer.

[0037] Then, the system sorts each customer's event set in ascending order according to the event occurrence time, from the earliest initial contact event to the latest business completion event. After sorting, the system identifies the lifecycle stage to which each event belongs based on preset lifecycle node rules. Specifically, the system predefines the entire offline customer acquisition process as the following lifecycle stages and their corresponding event type mapping relationships: contact stage, WeChat addition stage, course acquisition stage, course learning stage, course conversion stage, and organizational change stage. For each event in the sorted event sequence, the system looks up the corresponding lifecycle stage in the above mapping table according to its event type, thereby marking each event to the corresponding lifecycle stage. Through the above processing, the system establishes a lifecycle event chain covering the entire process from initial contact to business completion. This event chain records each key business node experienced by the customer in the offline promotion business and its corresponding event details in chronological order.

[0038] Finally, the system calculates the customer lifecycle state transition path based on the sequential relationships between adjacent events in the lifecycle event chain. For example, when the event chain sequentially includes "Add Friend Event - Course Claim Event - Course Completion Event - Order Payment Event," the system identifies the customer's state as transitioning from "Added Friend" to "Course Claimed," then to "Course Completed," and finally to "Converted." Specifically, the system maintains a state transition table that defines the legal transition directions between each lifecycle stage; for example, "Course Claimed" can transition to "Course in Progress" or "Course Dropped," "Course in Progress" can transition to "Course Completed" or "Course Dropped," and "Course Completed" can transition to "Converted" or "Not Converted." When adjacent events exist in the event chain, the system checks whether a legal transition path exists between the corresponding lifecycle stages of these two events. If it exists, the system records the transition relationship; otherwise, it marks it as an abnormal transition path for subsequent analysis. The system generates structured customer lifecycle state data based on the current lifecycle node, historical lifecycle nodes, and the complete state transition path. The lifecycle state data is stored in JSON format or relational data table format, and includes at least a unique customer identifier, the current lifecycle stage code, an array of historical stages and their corresponding timestamps, a complete description of the state transition path, and a legality flag for the state transition, providing complete state context information for subsequent multi-role attribution modeling and abnormal event detection.

[0039] In this implementation, to achieve accurate tracking and historical tracing of multi-role performance attribution throughout the customer lifecycle, the system sets three foreign key fields in the customer lead table `og_customers_leads`: `employee_id` (the specialist who first contacts the customer through door-to-door sales), `belonger_id` (the specialist who adds the customer as a friend via WeChat), and `mentor_id` (the mentor responsible for following up on the customer's learning progress and guiding conversion). By storing the attribution information of three orthogonal dimensions in parallel in a single data record, the system expands the traditional one-to-one attribution model of "one customer belongs to one employee" in CRM to a multi-role attribution model of "one customer is simultaneously associated with a contact, a WeChat contact, and a mentor," allowing the performance contribution of each role to be independently counted and calculated. The three foreign key fields correspond to different statistical dimensions—`employee_id` is used to calculate contact performance, `belonger_id` is used to calculate WeChat contact performance, and `mentor_id` is used to calculate mentor commission—the three do not interfere with each other, solving the data modeling problem of multi-role revenue sharing from the data structure level.

[0040] The system executes the `improveInformationOrg` method in the callback chain of adding a friend in WeChat Work via the `ChangeExternalContactEventHandler` event handler, automatically completing the writing of the three foreign key attribution relationships. This method first queries the `EmployeeReportResult` to obtain the employee's `jobCategory` (job type code) based on the currently adding specialist's ID. This code is defined by the `JobCategoryEnum` enumeration, which specifies five employee identities: 1 for full-time, 2 for part-time, 3 for "hands-on" (transfer-only), 4 for one-to-many, and 5 for B2B part-time. Then, the method calls `JobCategoryEnum.notFullTime()` to determine whether the employee is part-time (i.e., part-time, "hands-on," one-to-many, or B2B part-time), automatically retrieving the employee's mentor ID from the `EmployeeReportResult` and writing it to the `mentor_id` field; if it is a full-time employee, `mentor_id` is left blank, indicating that the full-time employee works independently and does not need a mentor. Simultaneously, the method uses ServiceCommonUtil.getOrgIdByOrgPath to parse the promotion city architecture manager_org_id and business team architecture director_org_id from the employee's organizational path orgPath and writes them into the customer lead table. Through this process, the three foreign key attribution relationships and organizational hierarchy information are automatically filled in the instant a customer adds a friend. The entire process requires no manual configuration by HR or supervisors afterward, achieving instant automatic writing of attribution relationships when a customer enters the system.

[0041] Specifically, the system also periodically synchronizes with the group's HR organizational structure gateway to obtain organizational relationship change events such as employee job adjustments, organizational migrations, and mentorship changes. Each change is recorded with an effective timestamp, forming a version sequence of employee affiliation relationships. When it is necessary to determine the affiliation of a customer at a certain lifecycle node, such as when a customer completes a course conversion at a certain time and it is necessary to determine which mentor should be responsible for that conversion, the system searches for the valid affiliation version at that time in the affiliation relationship version sequence based on the occurrence time of the conversion event, rather than using the employee's current latest affiliation. That is, the system uses the event occurrence time as a query condition to obtain the employee's true affiliation with the organizational hierarchy at that moment, thereby ensuring that the attribution calculation of historical performance is not distorted due to subsequent employee departures, job transfers, or changes in mentorship relationships.

[0042] Furthermore, S2 specifically includes: Based on the customer lifecycle event chain, identify the contacting employees, employees added via WeChat, and mentoring employees corresponding to each node of the customer lifecycle, and establish a multi-role attribution relationship between customers and employees involved in various business activities based on employee identity categories. Obtain organizational structure information, job adjustment records, organizational migration records, and mentorship relationship change records for employees involved in each business. Establish a sequence of attribution relationship versions based on the time of each organizational relationship change, and call the corresponding version of the attribution relationship based on the event occurrence time corresponding to each customer lifecycle node to generate dynamic multi-role attribution relationships for each stage of the customer lifecycle. Establish customer lifecycle status data, dynamic multi-role attribution relationships, and the mapping relationships between organizational levels to form a dynamic multi-role attribution model for customers.

[0043] Specifically, the system extracts the contact employee identifier from the contact stage event records in the customer lifecycle event chain. This identifier is recorded in the `employee_id` field of the `og_customers_leads` table, indicating the specialist who first contacted the customer through door-to-door sales. The system extracts the WeChat addition employee identifier from the event records of the WeChat addition stage. This identifier is recorded in the `belonger_id` field of the same table, indicating the specialist who actually added the customer as a friend through WeChat. The system extracts the mentor employee identifier from the course learning and conversion stage event records. This identifier is recorded in the `mentor_id` field of the same table, indicating the mentor supervisor responsible for following up on the customer's learning progress and guiding conversion. While extracting the above employee identifiers, the system queries the employee's identity category information, i.e., the `jobCategory` field, through the `EmployeeReportResultService`. This field defines five employee identities through the `JobCategoryEnum` enumeration: 1 represents a full-time employee, 2 represents a part-time employee, 3 represents a "hands-on" employee, 4 represents a one-to-many employee, and 5 represents a B2B part-time employee.

[0044] Based on the three foreign key fields mentioned above: employee_id, predecessor_id, and mentor_id, as well as the employee's identity category, a multi-role attribution relationship is established between the customer and the employees involved in each business. Specifically, when the system processes the WeChat friend addition event through the ChangeExternalContactEventHandler event handler, the improveInformationOrg method is called to automatically complete the writing of the three foreign keys: This method first queries the employee's report results to obtain their jobCategory, and then uses the JobCategoryEnum.notFullTime() method to determine—if the employee is a part-time employee, the mentor_id field is automatically written; if the employee is a full-time employee, the mentor_id field is left empty.

[0045] Then, the system obtains the employee's organizational structure tree path (orgPath) through `departmentTreeClient`, and uses the `ServiceCommonUtil.getOrgIdByOrgPath` method to parse the employee's promotion city structure identifier (`manager_org_id`) and business team structure identifier (`director_org_id`) from this path, recording them in the corresponding fields of the customer lead table. Simultaneously, the system obtains employee job adjustment records, organizational migration records, and mentorship change records through periodic synchronization with the group's human resources organizational structure gateway. Since employees in the offline sales industry may leave, be transferred, or change affiliations at any time, and performance must be traced back to the organizational relationship at the time of the event rather than calculated based on the current organization, the system establishes an affiliation version sequence based on the time of each organizational relationship change. Specifically, the system stores each employee's organizational relationship change record in the `og_employee_org_history` history table. Each record includes the employee identifier, organizational structure information before the change, organizational structure information after the change, change effective timestamp, and change type (onboarding, transfer, promotion, resignation, etc.). When it's necessary to determine a customer's affiliation at a specific lifecycle point, the system searches for a valid organizational relationship version in the affiliation version sequence based on the event time corresponding to that point, such as when the customer added a friend or when the customer claimed a course, rather than simply using the latest organizational relationship. Through this time-point version matching mechanism, the system ensures that the affiliation of historical performance is always strictly aligned with the employee's organizational status at the time the event occurred.

[0046] Next, the system establishes a mapping relationship between customer lifecycle status data, dynamic multi-role attribution, and organizational hierarchy. The customer lead table `og_customers_leads` stores both three foreign key attribution information and organizational hierarchy information, and uses the `spread_type` field to distinguish business promotion types: 0 represents specialist promotion, 1 represents ground promotion / community promotion, 2 represents grid-based community promotion, 3 represents direct promotion by private domain teachers, and 4 represents others. This allows different types of promotion businesses to follow different attribution logics. The system uses the customer identifier as the primary key, associating lifecycle status data with the three foreign key attribution information and organizational hierarchy information to form a unified dynamic multi-role customer attribution model view.

[0047] Furthermore, the association matching and fusion processing of the multi-source abnormal events includes: Based on customer lifecycle status data, extract the following events generated during the customer lifecycle: WeChat abnormal events, static QR code abnormal events, abnormal conversion events, high-frequency order events, remote ordering events, and remote course events. Obtain the customer unique identifier, order unique identifier, event occurrence time, event type, and business participation role information corresponding to each abnormal event. Establish an association index between different abnormal events based on the customer's unique identifier and the order's unique identifier, and perform association matching on multiple abnormal events that meet the same customer's unique identifier, the same order's unique identifier, or preset association conditions; Based on the order of occurrence, lifecycle stage, and dynamic multi-role attribution, related abnormal events are merged and processed to integrate multiple interrelated abnormal events into a comprehensive abnormal event corresponding to the customer. Based on the dynamic multi-role attribution model, the association between comprehensive abnormal events and corresponding employees and organizational nodes is established to form a comprehensive abnormal event set, providing a unified data input for the reconstruction of the statistical base of organizational hierarchy. Specifically, six types of abnormal events are respectively extracted from the course receiving detail table og_receive_detail and the conversion detail table og_convert_detail through the AbnormalOrderStatisticsServiceImpl service. The WeChat addition abnormal event is acquired via the getAbnormalOrderWechatStatistics method; the system performs a left join on the og_receive_detail table and the og_customers_leads table, and determines that the WeChat addition behavior is abnormal when leads.id IS NULL or rec.received_time < leads.create_time, and marks it as a WeChat addition abnormal event. The static QR code abnormal event is acquired in the same method, and the system counts friend adding behaviors using static non-positioning codes, and marks the behavior as a static QR code abnormal event when a specialist uses a fixed static code to be scanned to add a friend and the behavior does not conform to the normal promotion mode. The abnormal conversion event is acquired via the getAbnormalOrderConvertStatistics method — the system counts orders of which the course_key in the conversion orders is NOT IN the specified excluded course list, and marks them as abnormal conversion events. The high-frequency order event is acquired via the getAbnormalOrderFrequencyCountStatistics method — the system uses DATE_FORMAT to perform aggregation statistics on the number of course receiving orders of a single specialist by hourly sliding window, and marks the orders within the time period as high-frequency order events when the number of orders in a certain hour exceeds the threshold og.city.abnormal.monitor.receive.time.num configured in Apollo. The cross-location order placement event is acquired via the getAbnormalOrderDifferentPlaceStatistics method; the system compares the IP-attributed city when the parent receives the course with the city where the point of responsibility of the specialist is located, and marks the event as a cross-location order placement event when the two are inconsistent and do not meet the six-level city hierarchy matching condition. The cross-location course event is acquired via the getAbnormalConvertOrderDifferentPlaceStatistics method; the system adopts the same city hierarchy matching logic as that for the cross-location order placement event in the conversion detail table, and marks orders of which the receiving address or IP geographic location is inconsistent with the ground promotion point in the paid course conversion orders as cross-location course events. For each type of extracted abnormal event, the system respectively acquires the unique customer identifier, unique order identifier, event occurrence time, event type and business participating role information Then, a multi-level index structure for abnormal events is constructed using the customer's unique identifier as the primary index key and the order's unique identifier as the secondary index key. When multiple abnormal events exist under the same customer identifier, the system further determines whether these abnormal events belong to the same business behavior through the order identifier; for example, the same course order from the same customer may simultaneously trigger a cross-order event and a high-frequency order event, and the system associates these two abnormal events through the customer identifier and the order identifier. For abnormal events that cannot be directly associated through the order identifier but have preset association conditions, such as the same customer triggering a micro-transaction abnormal event and an abnormal conversion event in a short period of time, it indicates that there is an anomaly in the customer's entire conversion chain—the system performs association matching according to preset association rules.

[0048] Next, multiple abnormal events that meet the same customer unique identifier, the same order unique identifier, or preset association conditions are grouped into an abnormal event group. Then, the events within the group are sorted according to their occurrence time. Based on the customer's current lifecycle stage and corresponding business participation role, a dynamic multi-role attribution model is used to query the contact specialist, WeChat specialist, and mentor corresponding to the customer at the time of the abnormal event, and comprehensively determine the attribution of the abnormal event. During the fusion process, the system integrates multiple interrelated abnormal events into a single comprehensive abnormal event record for the customer. This record includes: the customer's unique identifier, the event occurrence time range (the time span from the first event to the last event), a list of associated abnormal event types (such as including both DIFFERENT_PLACE_RECEIVE and ABNORMAL_FREQUENCY_COUNT), the corresponding business participation role information, and a description of the fused abnormal event. To avoid the same abnormal behavior being counted repeatedly in statistics across different dimensions, the system employs a deduplication and merging strategy when generating comprehensive abnormal events. This means that even if multiple abnormal indicators are triggered for the same customer, provided that the same customer identifier and order identifier are met, the event will only be counted once in the subsequent reconstruction of the organizational-level abnormal statistical base.

[0049] Then, using the three foreign key fields of employee_id (reach specialist), predecessor_id (WeChat specialist), and mentor_id (mentor) recorded in the customer lead table og_customers_leads, combined with manager_org_id (promotion city architecture ID) and director_org_id (business team architecture ID), the system maps comprehensive anomaly events to the corresponding specialists, business teams, and promotion cities. The system aggregates all comprehensive anomaly events according to the above mapping relationship, forming a comprehensive anomaly event set. This set is stored in structured data format, with each record containing a comprehensive anomaly event ID, customer identifier, a list of associated original anomaly event IDs, a merged anomaly description, the corresponding specialist identifier, the corresponding team identifier, the corresponding city identifier, and the event occurrence time. This provides a unified and deduplicated data input for subsequent reconstruction of the organizational-level anomaly statistical base.

[0050] Furthermore, the step of re-aggregating organizational-level business data based on a comprehensive set of abnormal events to construct an organizational-level anomaly statistical base includes: The organizational hierarchy path corresponding to each employee is obtained based on the dynamic multi-role attribution model, and a hierarchical mapping relationship is established between employees, organizational nodes, and comprehensive abnormal events. Based on the hierarchical mapping relationship, the comprehensive abnormal events are mapped to the corresponding organizational levels, and the number of comprehensive abnormal events, the number of normal business events, and the total number of business events corresponding to each organizational level are counted respectively. The statistical base for anomalies at each organizational level was reconstructed based on the total number of abnormal events and the total number of business events. Using the reconstructed anomaly statistics base, the anomaly ratio, anomaly contribution value and anomaly impact coefficient corresponding to each organizational level are recalculated to generate organizational level anomaly statistics results. The anomaly ratio for each organizational level is calculated independently based on the reconstructed anomaly statistical base.

[0051] Specifically, the system queries the organizational structure information of each employee through the EmployeeReportResultService to obtain their complete organizational hierarchy path (orgPath). This path is organized according to a four-level tree structure of "Region - Promotion City - Business Team - Specialist". The system uses the ServiceCommonUtil.getOrgIdByOrgPath method to parse the promotion city architecture identifier (manager_org_id) and business team architecture identifier (director_org_id) to which the employee belongs from the orgPath. Simultaneously, the system retrieves each comprehensive exception event in the comprehensive exception event set based on its associated specialist identifier (obtained through the specialist field in the comprehensive exception event record), associates it with the corresponding employee, and then groups it to the corresponding promotion city and business team according to the employee's organizational hierarchy path. Through the above processing, the system establishes a four-level hierarchical mapping relationship of "Specialist - Business Team - Promotion City - Region", with each level node associated with all comprehensive exception events and corresponding employees within its jurisdiction.

[0052] Furthermore, six independent SQL templates from the AbnormalOrderStatisticsServiceImpl service are used for statistical analysis. Each SQL template corresponds to a type of anomaly indicator (minor anomalies, static code anomalies, anomaly conversions, high-frequency orders, orders placed remotely, and courses placed remotely). Each SQL statement uses control parameters of level==2 / 3 / 4 to achieve three aggregation granularities: group, city, and region. Taking the statistics of remote order events as an example, the system uses the SQL corresponding to the getAbnormalOrderDifferentPlaceStatistics method to...<iftest="level==4"> Conditional judgment controls the aggregation granularity: When level=4, statistics are grouped and counted by rec.manager_org_id, rec.director_org_id, and rec.employee_id, respectively counting the number of abnormal events for each group, city, and specialist; when level=3, aggregation is performed at the city level, counting the total number of comprehensive abnormal events and the total number of business events for all groups under each city; when level=2, aggregation is performed at the region level. The system simultaneously counts the total number of comprehensive abnormal events and the total number of business events in each SQL statement, and further counts the number of normal business events. For cases where the same specialist is hit by multiple abnormal indicator SQL statements, the system uses the toMergeVo method to merge and deduplicate when counting the total number of abnormal events—this method groups the statistical results of the same specialist under multiple abnormal indicators by a composite key, sums the numerical fields, and takes the first non-null value of the ratio field instead of adding them, to avoid the same abnormal behavior being counted repeatedly on different indicator dimensions. Based on the total number of abnormal events and the total number of business events, the system reconstructs the statistical base for each organizational level. This statistical base, with the organizational node as the dimension, records the total number of abnormal events, the total number of normal business events, and the total number of business events under that node, serving as the basis for subsequent calculations of the abnormal ratio and abnormal contribution value.

[0053] The system recalculates the anomaly ratio, contribution value, and impact coefficient for each organizational level using the reconstructed anomaly statistics base, generating organizational-level anomaly statistics. Specifically, the system uses the `toAggregateVo` method to perform aggregated calculations at the organizational level—this method aggregates a set of statistical results at the same level into a single record, sums the numerical fields, and recalculates the ratio fields using the new numerator and denominator after aggregation. For example, for the anomaly conversion rate of multiple specialists within a group, the system first sums the anomaly conversions of each specialist to obtain the total number of anomaly conversions for the group, then sums the conversions of each specialist to obtain the total number of conversions for the group, and finally divides the total number of anomaly conversions for the group by the total number of conversions for the group to obtain the group's anomaly conversion rate, rather than simply averaging the conversion rates of the specialists. If a simple average is used, when the conversion bases of different specialists differ significantly (e.g., specialist A converts 1 order and all are anomalies, specialist B converts 100 orders and none are anomalies, the average will be erroneously high, reaching as high as 50%), leading to statistical distortion.

[0054] Specifically, for the statistics of cross-regional order events, the system uses a six-tiered city-level matching condition in the SQL for accurate identification. The CASEWHEN statement in the SQL sequentially checks the following six cases: ① Virtual city allows the order, i.e., virtual cities are not considered cross-regional; ② The home city includes the IP city; ③ District-level city matching; ④ Provincial-level city matching; ⑤ Parent city matching; ⑥ Parent province matching. When any of the above conditions are met, the system determines that the order is not a cross-regional order; when none of the above six conditions are met, the system determines that it is a cross-regional order event. Through the hierarchical matching of the above six OR conditions, the system can cover the complex hierarchical relationships in China's urban administrative divisions, such as municipalities, prefecture-level cities, county-level cities, districts, and high-tech zones. For example, if the employee's home city is "Chengdu-High-tech Zone" and the customer's IP is "Chengdu", the third condition (district-level city matching) determines that it is not a cross-regional order, effectively avoiding misjudgments caused by simple comparison.

[0055] Furthermore, the recalculation of performance statistics for each organizational level based on the statistical base of organizational level anomalies includes: Obtain business event data for each employee, a comprehensive set of abnormal events, and organizational-level anomaly statistics. Establish the correlation between business events and comprehensive abnormal events based on the organizational hierarchy to which the employee belongs; Based on the anomaly type, degree of impact and impact coefficient of the comprehensive anomaly event, anomaly correction is performed on each business event to obtain the effective business value of the corresponding business event. The performance scores of each employee are recalculated based on the revised effective business values, and employee performance results, team performance results, and city performance results are generated separately according to organizational level. Specifically, the system retrieves course collection order data for each specialist from the course collection details table `og_receive_detail`, including fields such as order number `order_num`, course identifier `course_key`, collection time `received_time`, activation status `has_activation`, and refund status `has_refund`. It also retrieves conversion order data for each specialist from the conversion details table `og_convert_detail`, including fields such as conversion order number, purchase amount `turnover`, refund amount `refundAmount`, and conversion time `convert_time`. Furthermore, it retrieves all associated anomaly records for the employee from the comprehensive anomaly event set, including anomaly type, occurrence time, and corresponding order identifier. Finally, it retrieves the overall anomaly level data for the employee's organizational level from the organizational-level anomaly statistics results, including the anomaly ratio, anomaly contribution value, and anomaly impact coefficient for the employee's business team and promotion city.

[0056] Then, each business event under an employee's name is associated with and matched against a set of comprehensive abnormal events: if the order number of a business event is the same as the unique order identifier in a comprehensive abnormal event, or if the customer identifier of a business event is the same as the unique customer identifier in a comprehensive abnormal event and the event occurred within a preset time window, then an association is established between the business event and the corresponding comprehensive abnormal event. The system maintains an `abnormal_flag` field in the `og_receive_detail` and `og_convert_detail` tables, respectively, to mark whether the business event is associated with a comprehensive abnormal event and the associated abnormal event ID.

[0057] Next, based on the anomaly type, impact level, and impact coefficient of the comprehensive anomaly events, the system performs anomaly corrections on each business event to obtain the effective business value for the corresponding event. Specifically, the system employs differentiated correction strategies for different types of anomalies: For WeChat-adding anomalies and static QR code anomalies, the system removes the corresponding WeChat-adding customers from the effective customer count, meaning this WeChat-adding behavior is not included in the effective customer count; for abnormal conversion events, the system removes the corresponding converted orders from the effective conversion count, and this conversion is not included in the conversion rate calculation; for high-frequency order events, the system removes excess orders exceeding the threshold within the corresponding time period from the effective course enrollment count to prevent fraudulent order placement and inflated performance figures; for cross-regional ordering events and cross-regional course events, the system performs weighted corrections based on the anomaly impact coefficient, i.e., the proportion of cross-regional orders in the employee's city tier. For example, when the proportion of cross-regional orders is low, it is only marked but not removed; when the proportion of cross-regional orders exceeds a preset threshold, the corresponding orders are completely removed from the effective business value. The system uses the BigDecimal type for numerical calculations during the correction process to avoid the loss of floating-point precision. In cases where a business event is associated with multiple abnormal events (such as a course order being marked as both a high-frequency order and an order placed in a different location), the system corrects the abnormal event based on the type with the highest impact. Furthermore, the business event is only deducted once in subsequent statistics, without repeated deductions, ensuring the rationality of the correction logic.

[0058] Furthermore, based on the revised effective business values ​​such as the number of effective classes, effective conversions, and effective GMV, the performance scores of each employee are recalculated, including core performance indicators such as effective conversion rate, effective GMV achievement rate, and effective customer acquisition. When calculating the closing conversion rate, the system adopts a "closing date + 3-day observation window" criterion, that is, it counts the conversion rate of users who successfully purchased full-price courses within 3 days after the closing date if the closing date falls within the assessment period. A cold start threshold is applied, and only specialists whose number of closing orders reaches this threshold are eligible to participate in the closing conversion rate performance statistics, avoiding statistical distortion due to insufficient sample size for newly hired or low-productivity specialists. After recalculating the performance scores at the employee level, the system aggregates upwards according to the organizational hierarchy: using the toAggregateVo method, the performance scores of each specialist within the same business group are summarized to generate group performance results—numerical fields are summed, and ratio fields (such as conversion rate) are recalculated with new numerators and denominators; similarly, the performance results of each group within the same promotion city are summarized to generate city performance results.

[0059] In this embodiment, to achieve accurate fusion statistics of multi-dimensional abnormal events, the system uses the AbnormalOrderStatisticsServiceImpl service to adopt 6 sets of independent SQL templates to respectively count 6 types of abnormal indicators: WeChat-addition abnormal events (via the getAbnormalOrderWechatStatistics method, using LEFT JOIN og_customers_leads to determine that leads.id IS NULL or rec.received_time < leads.create_time), static QR code abnormal events (counting abnormal WeChat-addition behaviors using static non-location codes in the same method), abnormal conversion events (via the getAbnormalOrderConvertStatistics method, excluding specified courses with course_key NOT IN), high-frequency order events (via the getAbnormalOrderFrequencyCountStatistics method, using DATE_FORMAT(received_time,'%Y-%m-%d-%H') to perform aggregation by hourly sliding window, screening with HAVING COUNT( )>#{frequencyLimit}, the threshold is dynamically controlled by the Apollo configuration og.city.abnormal.monitor.receive.time.num, with a default value of 10), cross-location order events (via the getAbnormalOrderDifferentPlaceStatistics method, determined using 6 layers of city-level matching conditions) and cross-location course events (via the getAbnormalConvertOrderDifferentPlaceStatistics method, extracted from the conversion detail table using the same city matching logic). The 6 sets of SQL run independently, respectively returning statistical results of different abnormal dimensions. Each set of SQL controls the aggregation granularity through the <if test="level==2 / 3 / 4"> condition, and outputs numerical fields (such as the number of abnormal customers wechatAbnormalCustomerNum, the number of abnormal conversions abnormalConvertNum, the number of cross-location course claims differentPlaceReceiveNum, etc.) and corresponding business total fields (such as the total number of customers customerNum, the total number of conversions convertNum, the total number of course claims receiveNum, etc.). The ratio fields are calculated on the Java side through the ServiceCommonUtil.getDivideRate method, so as to avoid the problem of inconsistent denominators caused by directly calculating the ratio in SQL.

[0060] Furthermore, the system uses the `toMergeVo` method to address the issue of duplicate counts where the same specialist is simultaneously matched by multiple abnormal indicators. When the same specialist appears in the statistical results of multiple SQL queries, the system groups and merges these results using the (managerOrgId, directorOrgId, employeeId) key combination. During the merging process, numeric fields (such as customerNum, wechatAbnormalCustomerNum, convertNum, abnormalConvertNum, abnormalFrequencyCount, differentPlaceReceiveNum, receiveNum, etc.) are summed; while ratio fields (such as wechatAbnormalRate, abnormalConvertRate, differentPlaceReceiveRate, etc.) are selected based on the first non-null value rather than summed or averaged, because ratio fields are the result of division operations, and adding multiple ratios would produce meaningless statistical values. Through the above-mentioned merging and deduplication strategy, the system ensures that even if the same specialist triggers multiple types of abnormal events within the same assessment period, they will only be counted once in the final comprehensive abnormality statistics, thus avoiding statistical distortion caused by duplicate counting.

[0061] Furthermore, the system addresses the issue of ratio recalculation during organizational-level aggregation using the `toAggregateVo` method. When it's necessary to aggregate a group of statistical results from the same level into a single upper-level statistical record, this method first sums the numerical fields. For example, the number of abnormal conversions in a group = the sum of the abnormal conversions of each specialist, and the total number of conversions in a group = the sum of the total number of conversions of each specialist. Then, the ratio field is recalculated using the new numerator and denominator after aggregation, i.e., the abnormal conversion rate of a group = the sum of the abnormal conversions in the group / the sum of the total number of conversions in the group. The innovation of this aggregation method lies in its avoidance of statistical biases that may result from the conventional practice of "averaging or weighted averaging the ratios of each sub-item." When the business base of different specialists varies significantly, recalculating with a new numerator and denominator can accurately reflect the overall abnormality level of that level.

[0062] For identifying out-of-town orders, the system employs a six-tiered city-level matching condition: ① Virtual city approval; ② Originating city includes the IP city; ③ District-level city matching; ④ Provincial-level city matching; ⑤ Parent city matching; ⑥ Parent province matching. When any one of these conditions is met, the system classifies it as a non-out-of-town order; when none of the six conditions are met, it is classified as an out-of-town order. Through this hierarchical matching of the six OR conditions, the system covers the complex hierarchical relationships within China's urban administrative divisions, including municipalities, prefecture-level cities, county-level cities, districts, and high-tech zones, effectively resolving the misjudgment problem caused by simple IP-city comparison.

[0063] Furthermore, the step of performing tiered incentive matching based on the revised performance statistics includes: Obtain the performance scores corresponding to each organizational level, establish a mapping relationship between performance scores and incentive levels based on the preset incentive strategy, sort employees according to performance scores, and identify the set of employees who meet the same performance score. For sets of employees with the same performance rating, a unified sorting process is adopted, and the incentive level and incentive amount of the corresponding employees are calculated in combination with the preset tiered incentive range. Obtain the current incentive budget data, perform budget verification on each incentive result based on the budget balance, complete the budget deduction and generate incentive result data when the budget meets the issuance conditions, and reallocate the incentive amount according to the preset budget adjustment strategy when the budget is insufficient. Specifically, the system obtains all incentive rules in effect within the current assessment period from the `IncentiveRuleService` through the `SystemRewardStrategy` strategy class. Each rule includes the hierarchical level, trigger indicator type, statistical period, rule type, and corresponding rule details. The system routes data to the corresponding data source by calling the `getStatisticalResult` method based on the `conditionType` of the rule: when the condition type is `0` (number of Leads) or `1` (GMV), it retrieves statistical data from `ReceiveDetailMapper`; when the condition type is `2` or `3`, it retrieves target achievement data from `FinanceTargetService`; when the condition type is `4`, it retrieves the camp completion conversion data from `ReceiveDetailMapper.getConvertOfIncentive`—this SQL uses the "camp completion date + 3-day observation window" caliber and filters out specialists whose number of completed courses is less than the threshold (Apollo configuration `og.city.incentive.convert_rate_threshold` defaults to 50) using `WHEREtemp.closeNum>=#{leads}` to avoid small sample bias; when the condition type is `5`, it retrieves the surge in orders data from `EmployeeWorkReportMapper.selectLimit`.

[0064] Furthermore, the `genRankNo` method employs a cumulative ranking skipping mechanism: it iterates through the sorted employee list, maintaining two variables: `currentRank` (current ranking) and `cumulativeRank` (cumulative ranking). When the performance scores of adjacent employees change, `cumulativeRank` is incremented, and `currentRank` is updated to the incremented `cumulativeRank` value; when performance scores are the same, `currentRank` remains unchanged. Through this mechanism, the system generates a skipping ranking in the format "1, 1, 3" (i.e., when two people are tied for first place, both are displayed as first place, and the next place jumps directly to third place). For the ranking mode (`sortType=0`), the system retrieves the ranking number from the rule details' `Map`.<Integer,Long> The system directly searches for the corresponding incentive score value in the `convertRuleToMap` method. This Map is pre-constructed by the `convertRuleToMap` method, which maps the rule details list according to the mapping relationship of `rankNo->point`, achieving a table lookup with an O(1) time complexity. For the tiered range mode (`sortType=1`), the system uses the `calculateReward` method to locate the tiered interval into which the performance score falls using a binary search algorithm. This method maintains two pointers, `left` and `right`, and takes the middle position `mid` each time. It compares the performance score with `minValue` and `maxValue` of `ruleDetails.get(mid)`: if the score is greater than or equal to `minValue` and less than `maxValue` (or `maxValue` is null, indicating positive infinity), then the tiered interval is hit and the corresponding `point` score value is returned; if the score is less than `minValue`, then the right boundary is narrowed; otherwise, the left boundary is narrowed until the hit interval is found or the traversal is completed. For the target achievement rate mode, the system maps the ratio of the employee's actual achievement value to the target value to the corresponding tiered interval and uses the same binary search logic as above to calculate the incentive amount. For the course completion conversion rate metric, the system only performs tiered matching for specialists whose number of completed courses reaches the cold start threshold when calculating incentive amounts. Specialists who do not reach the threshold are automatically skipped from incentive distribution to ensure statistical confidence.

[0065] Furthermore, the `IncentiveBudgetService.selectByMonth` method queries the incentive budget record `IncentiveBudgetDo` corresponding to the current assessment month. This record includes the total budget `total`, the amount of points already distributed `hadDistributed`, and the available balance. Before each incentive rule is executed, the system checks if the available balance is greater than 0. If the available balance is insufficient, the system sends an alarm message to the administrator's DingTalk account using the `DingTalkExceptionAlarmWrapper.sendMessage` method and skips the distribution of that rule. If the budget is sufficient, the system obtains a Redis distributed lock using `DistributedLockHelper.doActionWithLock` when deducting the budget. The lock key is generated by `RedisKeyUtils.genIncentiveBudgetLockKey(budgetId)`, with the format `og:city:incentive:budget:lock:{budgetId}`. The lock timeout is set to 10 seconds, the retry interval is 1 second, and the maximum number of retries is 3, ensuring the atomicity of the budget deduction operation. During the distribution process, the system adopts a single-employee isolation strategy: a try-catch block is used to wrap a single points distribution operation. When a certain employee fails to distribute points due to account abnormality or other reasons, the system records an error log and sends an alarm through DingTalk, but does not affect the normal distribution of other employees, thus avoiding the interruption of the entire distribution due to a single point of failure.

[0066] When the budget is sufficient, the system completes the budget deduction and generates incentive result data; when the budget is insufficient, the system reallocates incentive amounts according to a preset budget adjustment strategy. In the ranking-based incentive mode, if the available budget is insufficient to distribute the full amount of points according to the rules, the system will truncate the distribution based on ranking priority, meaning higher-ranked employees will receive the full amount first. When the budget balance is insufficient to support the full distribution to all employees in the next ranking level, no points will be distributed to any employees in that ranking level, rather than distributing partial points to some employees, to ensure fair treatment for employees with the same score. In the tiered incentive mode, if the available budget is insufficient to cover all qualified employees, the system distributes incentives sequentially from highest to lowest performance score until the budget balance is insufficient to pay the full incentive for the next employee, at which point neither that employee nor subsequent employees will receive incentives.

[0067] Further, S5 includes: Obtain the customer set corresponding to employees who have undergone job adjustments, organizational restructuring, or resignation, and obtain the business participation roles and affiliation versions of each customer at different lifecycle stages based on the dynamic multi-role affiliation model; Based on the customer's current lifecycle status, ownership version, and organizational adjustment information, the customer inheritance relationship is recalculated to generate customer migration data. Perform customer asset migration based on customer migration data, and synchronously update customer lifecycle status data, dynamic multi-role attribution model and customer attribution relationship; When there are customers whose asset migration fails during the process, only the original ownership relationship of the corresponding customer is retained and a record to be migrated is generated, while the remaining customers continue to complete the asset inheritance. Specifically, the system retrieves the customer set corresponding to employees who have undergone job adjustments, organizational restructuring, or resignation. Specifically, when the system detects an employee organizational change event, it retrieves the list of customers to be transferred under that employee's name using the `CustomersLeadsServiceImpl.transferCustomers` method. Based on the `handoverEmployeeId` (original employee identifier), `assignEnum` (assignment method, 0 for all transfers, 1 for a specified number), and `customerNum` (number of customers to be transferred) parameters in `EmployeeTransferCustomersDTO`, the system queries the `CustomersLeadsMapper.queryTransferCustomers` method to retrieve all currently valid customer lead records under that employee's name from the customer lead table `og_customers_leads`. For each customer retrieved, the system uses a dynamic multi-role attribution model to obtain the customer's corresponding business roles at different lifecycle stages—including the outreach specialist (`employee_id`), the WeChat specialist (`belonger_id`), and the mentor (`mentor_id`), as well as the corresponding organizational hierarchy information (`manager_org_id` for promotion city structure, `director_org_id` for business team structure). It also retrieves the customer's attribution version record at each stage from the attribution relationship version sequence. Simultaneously, the system uses `EmployeeReportResultMapper.getReportResultList` to batch query the report results information (including employee ID, job nature, organizational path, etc.) of the original specialist and all supervising specialists, providing foundational data for subsequent customer allocation and attribution recalculation.

[0068] Furthermore, the customer inheritance relationship is recalculated based on the customer's current lifecycle status, ownership version, and organizational adjustment information to generate customer migration data. The system uses the `distributeLeads` method with a round-robin algorithm to evenly distribute customers to be transferred among the transferors. This method receives a list of customers and a list of transferor IDs as input, iterates through the customer list, and for the `i`th customer, calculates its assigned transferor index using `i%n` (where `n` is the total number of transferors), thus achieving a uniform distribution of customers among the transferors—for example, 100 customers allocated to 2 transferors receive 50 each, while allocated to 3 transferors receive 34, 33, and 33 respectively. After allocation, the system generates customer migration data records for each transferor pair. Each migration data record includes the original specialist ID, the transferor specialist ID, the customer ID, the customer's current lifecycle status, ownership version information, and a migration timestamp. The system groups the customers to be transferred by transferor, with each group consisting of a maximum of 100 customers forming a migration batch, which is then processed asynchronously by the subsequent `asyncTransferCustomers` method.

[0069] Furthermore, customer asset migration is performed based on customer migration data, and customer lifecycle status data, dynamic multi-role attribution model, and customer attribution relationships are updated synchronously. Specifically, the system adopts a dual-write mechanism to ensure the consistency of local data. In the asynchronous transfer process, the system calls the `resignedTransferCustomer` interface (for resignation scenarios) or the `transferCustomer` interface (for job transfer scenarios) of WeChat Work. This interface receives a `WxCpUserTransferCustomerReq` request object, which contains the WeChat Work user ID of the original specialist (`handOverUserid`), the WeChat Work user ID of the taking-over specialist (`takeOverUserid`), and a list of external contact IDs of the customers to be transferred (`externalUserid`). This transfers the customer's friend relationships from the original specialist to the taking-over specialist. Because this interface is asynchronous, the `errcode=0` returned after the call only indicates that "the request has been accepted" and does not mean that the friend transfer has been completed. In the `transferResult` method, the system processes the transfer results one by one according to the `errcode` of each customer. For customers whose transfers are successful (errcode=0), the system updates the `belonger_id` field of the local `og_customers_leads` table to the takeover specialist's ID, sets `transferStatus=2` (transfer in progress), and writes the transfer history to the `og_customers_leads_transfer` transaction table. At the same time, it asynchronously updates the `cpUserId` field of the `og_corp_tag_customers_new` table to the enterprise WeChat user ID of the takeover specialist.In the specific implementation of the dual-write mechanism, the `CustomersLeadsTransferServiceImpl.doTransferCustomers` method performs local table updates in the following order: First, it queries the customer main table `og_customers` to obtain a list of customer IDs using `CustomersService.queryListByWechatId`. Then, it queries the customer lead table `og_customers_leads` to retrieve customer records belonging to the original specialist using `CustomersLeadsService.queryListByCsIdAndBelongerId`. Next, it batch updates the `belonger_id` field to the taking-over specialist ID and batch writes it to the `og_customers_leads_transfer` transaction table (`transferStatus=1` indicates successful synchronization). Finally, it asynchronously updates the `cpUserId` and `bizSequenceKey` fields of the `og_corp_tag_customers_new` table—where `bizSequenceKey` is composed of `{employeeId}+{wechatUserId}+{type}`, and must be synchronously modified during the update to ensure the validity of the unique key. The first four steps are decoupled from the last step through independent `try-catch` blocks. Even if the last step fails due to network or enterprise interface anomalies, the core ownership relationships and transfer logs have been correctly written, without affecting the core functionality of customer asset inheritance. After the migration is completed, the system synchronously updates the customer lifecycle status data (marking that the customer has undergone an ownership change, recording the specialist information before and after the change and the change time) and the dynamic multi-role ownership model (updating the business participation role corresponding to the customer in each lifecycle stage to the takeover specialist and their organizational ownership information).

[0070] When a customer's asset migration fails, the system only retains the original ownership relationship of that customer and generates a record to be migrated, while the remaining customers continue to complete the asset inheritance. Specifically, during the process of processing the enterprise transfer results one by one in the `transferResult` method, when a customer's `errcode!=0`, the system records the transfer failure log for that customer, skips the local update operation for that customer, keeps the `belonger_id` in its `og_customers_leads` table unchanged (still the original specialist), keeps `transferStatus` at `0` (failure status), and generates a transfer log record with `transferStatus=0`, recording the reason for the failure. The system skips the failed customer using the `continue` statement and continues processing the next customer in the batch, ensuring that the transfer failure of a single customer does not affect the normal transfer of other customers in the same takeover batch. Simultaneously, the system records customers whose transfers failed to complete the migration process in a pending migration record table. Subsequent scheduled compensation tasks will retry these records. The compensation task periodically scans for pending migration records with `transferStatus=0` and a creation time exceeding a preset threshold, re-initiating the enterprise transfer interface call until the transfer is successful or the maximum number of retries is exceeded, triggering a manual intervention alarm. Through this failure isolation and compensation retry mechanism, the system maximizes the integrity and eventual consistency of customer asset inheritance.

[0071] In this implementation, to ensure the secure inheritance of customer assets in the asynchronous transfer scenario of enterprise and micro-enterprise, the system uses two services, CustomersLeadsServiceImpl and CustomersLeadsTransferServiceImpl, to collaboratively complete the customer asset migration. When the system detects an employee's departure or job adjustment, the transferCustomers method first queries the list of customers to be transferred under that employee's name using CustomersLeadsMapper.queryTransferCustomers. This method retrieves the currently valid customer lead records from the customer lead table og_customers_leads based on the parameters handoverEmployeeId (original specialist ID), assignEnum (allocation method), and customerNum (number of transferred customers). Then, the distributeLeads method uses a round-robin even distribution algorithm to allocate customers: iterates through the customer list, and for the i-th customer, calculates its assigned receiver index using i%n (where n is the total number of receivers), and evenly distributes the customer among the receivers (for example, 100 customers allocated to 2 receivers receive 50 each, and allocated to 3 receivers receive 34, 33, and 33 respectively). After allocation, the system groups the customers to be transferred according to the transferee, with each group consisting of a maximum of 100 customers forming a migration batch, which is then processed asynchronously by the asyncTransferCustomers method.

[0072] In this embodiment, a three-state transfer status management mechanism is used to accurately match the asynchronous semantics of the WeChat Work interface. In the `asyncTransferCustomers` method, the system calls the WeChat Work resignedTransferCustomer interface (for resignation scenarios) or the transferCustomer interface (for job transfer scenarios). This interface returns a `WxCpUserTransferCustomerResp` response object, where each customer's errcode=0 only indicates "request accepted" rather than "friend successfully transferred". In the `transferResult` method, the system processes each customer's errcode one by one: when the transfer is successful (errcode=0), the system updates the `belonger_id` in the local `og_customers_leads` table to the takeover specialist ID and sets `transferStatus=2` (transfer in progress), while simultaneously writing the transfer history to the `og_customers_leads_transfer` log table; when the transfer fails (errcode!=0), the system skips the customer, its `belonger_id` remains unchanged, `transferStatus` remains 0 (failed), and a failed transfer log record is generated. The `transferStatus` field uses a three-state semantic system: 0 indicates transfer failure (retry with compensation), 1 indicates transfer success (synchronously completed, written by the `doTransferCustomers` dual-write mechanism), and 2 indicates transfer in progress (asynchronously in progress, written by `asyncTransferCustomers`). This precisely matches the lifecycle of the WeChat Work interface from "request accepted" to "transfer completed." When a single customer fails, the `continue` method skips the transfer, ensuring the normal transfer of other customers in the same batch and avoiding the manual intervention cost of a failed batch.

[0073] Specifically, the system achieves eventual consistency between local and enterprise WeChat data through a double-write mechanism. This mechanism is controlled by the Apollo configuration item `og.city.customers.double.write`, is enabled by default, and is executed through the `CustomersLeadsTransferServiceImpl.doTransferCustomers` method. The system performs local table updates in the following order: First, it queries the main customer table `og_customers` using `CustomersService.queryListByWechatId` to obtain a list of customer IDs. Then, it queries the customer lead table `og_customers_leads` using `CustomersLeadsService.queryListByCsIdAndBelongerId` to retrieve customer records belonging to the original specialist. Next, it batch updates the `belonger_id` field to the taking-over specialist ID and batch writes it to the `og_customers_leads_transfer` transaction table. Finally, it asynchronously updates the `cpUserId` field of the `og_corp_tag_customers_new` table and updates the `bizSequenceKey` to `{employeeId}+{wechatUserId}+{type}` to ensure the validity of the unique key. The first four steps are decoupled from the last step through independent try-catch blocks—even if the tag table update fails due to network jitter or interface frequency control, the core ownership relationship and transfer log have been correctly written, without affecting the core functionality of customer asset inheritance. The compensation task periodically scans for records to be migrated with transferStatus=0 and creation time exceeding a preset threshold, re-initiates the Enterprise WeChat transfer interface call, and triggers a manual intervention alarm until the transfer is successful or the maximum number of retries is exceeded.

[0074] Example 2 Please see Figure 1 and Figure 2 This invention provides a ground promotion management system based on multi-role affiliation and tiered incentives, including a processor and a memory, wherein the memory stores a computer program; When the processor executes the computer program stored in the memory, it implements the method as described in any one of claims 1 to 8; In this embodiment, the system further includes: The event data management module is used to acquire customer touch data, WeChat addition data, course learning data, order data, employee organization data and organization change data generated during offline promotion, to manage various types of business data in a unified manner, and to perform the customer lifecycle event chain construction process described in claims 1 and 2 to generate customer lifecycle status data. The dynamic attribution management module is used to obtain the business participation roles corresponding to each stage of the customer's life cycle based on the customer life cycle status data, and to establish a dynamic multi-role attribution model by combining employee identity information, organizational relationship information and organizational relationship change records. At the same time, it establishes an association mapping relationship between the customer life cycle status data and the dynamic multi-role attribution model, and performs the dynamic multi-role attribution model construction process described in claims 1 and 3. The abnormal event fusion module is used to extract multi-source abnormal events generated during the customer lifecycle based on the dynamic multi-role attribution model, establish an abnormal event association index, and perform abnormal event association matching, abnormal event fusion and comprehensive abnormal event generation processing. At the same time, it establishes the correspondence between comprehensive abnormal events and employees and organizational nodes, and performs the abnormal event fusion processing described in claims 1 and 4. The statistical analysis module is used to establish organizational hierarchy mapping relationships based on the comprehensive abnormal event set and dynamic multi-role attribution model, perform organizational hierarchy re-aggregation on the comprehensive abnormal events, reconstruct the organizational hierarchy abnormal statistical base, calculate the organizational hierarchy abnormality ratio, abnormal contribution value and abnormality influence coefficient, and perform the organizational hierarchy statistical base reconstruction processing described in claims 1 and 5. The performance incentive management module is used to correct employee business values ​​based on the statistical results of organizational hierarchy anomalies, recalculate performance scores, and complete performance ranking, identification of employees with the same score, tiered incentive matching, budget verification and incentive result generation based on the corrected performance scores, and perform the performance correction and tiered incentive processing described in claims 1, 6 and 7. The customer asset management module is used to recalculate customer inheritance relationships based on the dynamic multi-role ownership model, and to complete customer asset migration, customer ownership update, lifecycle status update and dynamic multi-role ownership model update, and to perform the customer asset inheritance processing described in claims 1 and 8. The modules interact with each other through customer lifecycle status data, dynamic multi-role attribution model, comprehensive abnormal event set, organizational hierarchical abnormal statistics and incentive result data to realize the ground promotion management method based on multi-role attribution and tiered incentive as described in any one of claims 1 to 8. Specifically, the system adopts a microservice architecture of Java 21 + Spring Boot + Dubbo at the software architecture level. Following the DDD (Domain-Driven Design) layered design principle, the code structure is organized into four layers: the access layer (city-admin management backend, city-api C-end business interface, city-ua-server user authentication service), the application layer (city-application application service and event handlers), the domain layer (city-domain domain entities and value objects), and the infrastructure layer (city-repository data access, Redis caching, DubboRPC, Apollo configuration center, XXL-Job task scheduling). During runtime, the computer program implements the aforementioned methods through the collaborative work of the following functional modules. Each module of the system is deployed independently based on the microservice architecture. Modules interact with each other through customer lifecycle status data, dynamic multi-role attribution models, comprehensive abnormal event sets, organizational hierarchical abnormal statistics results, and incentive result data, forming a complete data loop. The following provides a detailed explanation of the specific implementation of each module.

[0075] The event data management module corresponds to the core data access and preprocessing functions of the access layer and application layer. It is used to acquire customer reach data, WeChat Work addition data, course learning data, order data, employee organization data, and organizational change data generated during offline promotion activities, and to manage these various business data in a unified manner. In its implementation, this module receives event callbacks from WeChat Work via `WorkWechatCallBackController`—including `change_external_contact` events for adding external contacts and `change_external_chat_scene` events for modifying customer scenarios—and parses, identifies the type of, and performs business correlation analysis on the callback events using event handlers such as `ChangeExternalContactEventHandler`. Simultaneously, this module uses DubboRPC to call the e-commerce transaction service and student management service to obtain course order data and course learning progress data, and obtains employee organization data and organizational change data through scheduled synchronization with the group's human resources and organizational structure gateway. At the data management level, this module calls the `CustomersLeadsServiceImpl` service to persist various business event data to core data tables in the MySQL database, such as `og_customers_leads` (customer lead table), `og_receive_detail` (course collection details table), and `og_convert_detail` (conversion details table). This module also performs the customer lifecycle event chain construction process described in claim 2—that is, sorting the event sets of each customer according to the event occurrence time, identifying the lifecycle stage to which each event belongs according to preset lifecycle node rules, establishing a lifecycle event chain covering the entire process from the customer's first contact to the completion of the business, and generating customer lifecycle status data, thereby providing standardized customer lifecycle status data input for the dynamic attribution management module.

[0076] The dynamic attribution management module corresponds to the attribution relationship management function in the application layer. It is used to obtain the business participation roles corresponding to each stage of the customer's life cycle based on the customer's life cycle status data, and to establish a dynamic multi-role attribution model by combining employee identity information, organizational relationship information and organizational relationship change records. In its implementation, this module uses the `CustomersLeadsServiceImpl` service to achieve dynamic attribution management based on a three-foreign-key attribution model. It sets three foreign-key fields in the customer lead table `og_customers_leads`: `employee_id` (reach specialist), `belonger_id` (WeChat specialist), and `mentor_id` (mentor). The `ChangeExternalContactEventHandler.improveInformationOrg` method automatically writes these three foreign-key fields during the WeChat friend-adding event processing. This method first queries the employee's report results to obtain their `jobCategory` (job type), then uses the `JobCategoryEnum.notFullTime()` method to determine if the employee is part-time (part-time / hands-on / one-to-many / B2B part-time). If so, it automatically writes the mentor's ID into the `mentor_id` field. Simultaneously, it parses the promotion city architecture `manager_org_id` and the business team architecture `director_org_id` from the employee's organizational path `orgPath` and writes them as well. This module also maintains records of employee organizational relationship changes (job adjustments, organizational migrations, mentorship changes, etc.) through `EmployeeReportResultServiceImpl`, and establishes a sequence of attribution relationship versions based on the time of each organizational relationship change. When it is necessary to determine the attribution relationship of a customer at a certain lifecycle node, the corresponding version of the attribution relationship is called based on the event occurrence time of that node, rather than simply using the latest attribution relationship. This module performs the dynamic multi-role attribution model construction process described in claim 3 above, establishing the association mapping relationship between customer lifecycle status data, dynamic multi-role attribution relationships, and organizational levels, forming a complete dynamic multi-role customer attribution model, providing attribution relationship data support for the abnormal event fusion module and the customer asset management module.

[0077] The abnormal event fusion module corresponds to the anti-fraud and anomaly detection functions in the application layer. It extracts multi-source abnormal events generated during the customer lifecycle based on a dynamic multi-role attribution model, establishes an abnormal event association index, and performs abnormal event association matching, abnormal event fusion, and comprehensive abnormal event generation processing. In its specific implementation, this module uses the `AbnormalOrderStatisticsServiceImpl` service to extract and fuse six types of abnormal events. This module includes an abnormal event extraction unit, an abnormal association index establishment unit, an abnormal event fusion unit, and a comprehensive abnormal event generation unit. The abnormal event extraction unit uses five methods—`getAbnormalOrderWechatStatistics` (extracts micro-abnormalities and static code abnormalities), `getAbnormalOrderConvertStatistics` (extracts abnormal conversions), `getAbnormalOrderFrequencyCountStatistics` (extracts high-frequency orders), `getAbnormalOrderDifferentPlaceStatistics` (extracts orders placed in different locations), and `getAbnormalConvertOrderDifferentPlaceStatistics` (extracts courses placed in different locations)—from the course order details table and conversion table to extract abnormal events. The module extracts various abnormal events from the detailed table and obtains the customer unique identifier, order unique identifier, event occurrence time, event type, and business participation role information corresponding to each event. The abnormal event association index building unit establishes association indexes between different abnormal events based on the customer unique identifier and order unique identifier, and performs association matching on multiple abnormal events that meet the same customer identifier, the same order identifier, or preset association conditions. The abnormal event fusion unit fuses related abnormal events according to the event occurrence order, lifecycle stage, and dynamic multi-role attribution relationship—using the `toMergeVo` method to merge and deduplicate when the same specialist is hit by multiple indicator SQL queries (summing numerical fields and taking the first non-null value for ratio fields), integrating multiple interrelated abnormal events into a comprehensive abnormal event for the corresponding customer. The comprehensive abnormal event generation unit establishes the association relationship between the comprehensive abnormal event and the corresponding employee and organizational node based on the dynamic multi-role attribution model, forming a comprehensive abnormal event set. This module performs the abnormal event fusion processing described in claim 4 above, providing the statistical analysis module with unified and deduplicated comprehensive abnormal event data input.

[0078] The statistical analysis module corresponds to the data statistics and aggregation analysis functions in the application layer. It is used to establish organizational hierarchy mapping relationships based on the comprehensive abnormal event set and the dynamic multi-role attribution model, perform organizational hierarchy re-aggregation of comprehensive abnormal events, and reconstruct the organizational hierarchy anomaly statistical base. In its specific implementation, this module includes an organizational mapping unit, a statistical base reconstruction unit, and an anomaly analysis unit. The organizational mapping unit uses the `ServiceCommonUtil.getOrgIdByOrgPath` method to parse `manager_org_id` (promotion city architecture) and `director_org_id` (business team architecture) from the employee's `orgPath` organizational path, establishing a mapping relationship between employees and organizational levels. The statistical base reconstruction unit aggregates comprehensive abnormal events according to the above mapping relationship to the corresponding specialists, business teams, and promotion cities, and uses six independent SQL templates to statistically analyze various anomaly indicators. Each SQL statement uses `level`... `l==2 / 3 / 4` controls the aggregation granularity of groups / cities / regions, and uses the `toAggregateVo` method to achieve aggregation calculation at the organizational level—after summing the numerical fields, the ratio fields are recalculated using the new numerator and denominator after aggregation (instead of averaging or weighting the ratios of each sub-item); the anomaly analysis unit calculates the anomaly ratio (number of anomaly events / total number of business events), anomaly contribution value (the proportion of the number of anomaly events at this level to the total number of anomaly events at its parent level), and anomaly impact coefficient (the degree of influence of the anomaly events at this level on the overall anomaly level of the parent level) corresponding to each organizational level based on the reconstructed anomaly statistical base. This module performs the organizational level statistical base reconstruction processing described in claim 5 above, and the generated anomaly statistical results serve as input data for performance correction by the performance incentive management module.

[0079] The performance incentive management module corresponds to the performance calculation and incentive strategy execution functions in the application layer. It is used to correct employee performance values ​​based on organizational hierarchical anomaly statistics and recalculate performance scores. Based on the corrected performance scores, it performs performance ranking, identifies sets of employees with the same score, matches tiered incentives, verifies budgets, and generates incentive results. In its implementation, this module uses the `SystemRewardStrategy` class to uniformly handle incentive matching logic. This module includes a performance correction unit, a performance calculation unit, a tiered matching unit, and a budget control unit. The performance correction unit corrects each business event based on the anomaly type corresponding to the comprehensive anomaly events—removing micro-behaviors corresponding to micro-behaviors and static code anomalies from the effective customer count; removing orders corresponding to abnormal conversions from the effective conversion count; removing excess orders corresponding to high-frequency orders from the effective course enrollment count; and weighting and correcting cross-regional orders and cross-regional courses based on the anomaly impact coefficient—to obtain the effective business value for each business event. The performance calculation unit recalculates the performance score (effective conversion rate, effective GMV achievement rate, effective customer acquisition number, etc.) for each employee based on the corrected effective business value, applying a cold start threshold (default 50 orders in Apollo configuration) to filter out specialists with insufficient sample size when calculating the closing conversion rate. The tiered matching unit sorts employees in descending order based on their performance scores, using `genRa The `nkNo` method uses a cumulative ranking skipping number mechanism to identify the set of employees with the same score (generating a skipping number ranking in the format of "1, 1, 3"). For the ranking mode, it retrieves the points from the rule details Map in O(1) time. For the tiered range mode, it uses the `calculateReward` method to locate the tiered range using a binary search algorithm and returns the corresponding point value. The budget control unit obtains a Redis distributed lock (lock key is `og:city:incentive:budget:lock:{budgetId}`) through `DistributedLockHelper.doActionWithLock` to perform atomic control on budget deduction. When the budget is insufficient, it sends a DingTalk alarm to the administrator through `DingTalkExceptionAlarmWrapper` and skips the issuance of the rule. This module executes the performance correction processing described in claim 6 and the tiered incentive matching processing described in claim 7. The generated incentive result data is used as the input of the customer asset management module and the budget change flow and points account flow are updated synchronously.

[0080] The Customer Asset Management module corresponds to the Customer Asset Inheritance and Ownership Update function in the application layer. It recalculates customer inheritance relationships based on a dynamic multi-role ownership model and completes customer asset migration, customer ownership update, lifecycle status update, and dynamic multi-role ownership model update. In its implementation, this module uses two services, `CustomersLeadsServiceImpl` and `CustomersLeadsTransferServiceImpl`, to collaboratively implement customer asset inheritance. This module includes an inheritance relationship calculation unit, a customer migration unit, and an ownership update unit: When an employee organization change is detected, the inheritance relationship calculation unit retrieves the set of customers under that employee's name using `CustomersLeadsMapper.queryTransferCustomers`, and then uses the `distributeLeads` method to evenly distribute the customers to each transferee using a round-robin distribution algorithm (`i%n`). The customer migration unit asynchronously calls the `resignedTransferCustomer` (resignation) or `transferCustomer` (on-the-job transfer) interface of WeChat Work using the `asyncTransferCustomers` method to perform customer friend relationship transfer. The `transferResult` method then updates the transfer results for each customer's... The errcode is processed line by line. If successful (errcode=0), a double-write mechanism is executed (first updating the `belonger_id` of `og_customers_leads`, writing it to the `og_customers_leads_transfer` log table, and then asynchronously updating the `cpUserId` of `og_corp_tag_customers_new`). If it fails, the customer is skipped, and a record to be migrated with `transferStatus=0` is generated. After migration, the attribution update unit synchronously updates the customer lifecycle status data (marking attribution change records), the dynamic multi-role attribution model (updating the customer's business participation roles at each lifecycle stage), and the customer attribution relationship data (updating `belonger_id` and `cpUserId`). This module performs the customer asset inheritance processing described in claim 8, ensuring eventual consistency of customer asset inheritance through failure isolation (a single customer failure does not affect other customers) and a compensation retry mechanism (periodically scanning the records to be migrated and re-initiating the transfer).

[0081] Each of the above modules is deployed and runs independently based on a microservice architecture, and the modules communicate with each other through clearly defined data interfaces: the customer lifecycle status data output by the event data management module serves as input to the dynamic attribution management module; the dynamic multi-role attribution model output by the dynamic attribution management module is simultaneously supplied to the abnormal event fusion module, the statistical analysis module, and the customer asset management module; the comprehensive abnormal event set output by the abnormal event fusion module is supplied to the statistical analysis module and the performance incentive management module; the organizational hierarchy abnormality statistical results output by the statistical analysis module are supplied to the performance incentive management module; and the incentive result data output by the performance incentive management module is supplied to the customer asset management module (for updating account transaction records) and the external email gateway (for sending incentive notifications). Through the above data interaction links, the modules collaboratively implement the ground sales management method based on multi-role attribution and tiered incentives as described in any one of claims 1 to 8.

[0082] Furthermore, the abnormal event fusion module includes an abnormal event extraction unit, an abnormal association index establishment unit, an abnormal event fusion unit, and a comprehensive abnormal event generation unit. The abnormal event extraction unit is used to extract various abnormal events generated during the customer lifecycle. The abnormal association index establishment unit is used to establish an association index between various abnormal events based on the customer's unique identifier and the order's unique identifier; The abnormal event fusion unit is used to perform association matching and fusion processing on multiple abnormal events based on the association index to generate a comprehensive abnormal event; The comprehensive abnormal event generation unit is used to establish the correspondence between comprehensive abnormal events and employees and organizational nodes based on the dynamic multi-role attribution model; The statistical analysis module includes an organizational mapping unit, a statistical base reconstruction unit, and an anomaly analysis unit. The organizational mapping unit is used to establish a mapping relationship between employees and organizational levels. The statistical base reconstruction unit is used to reconstruct the organizational-level anomaly statistical base based on comprehensive anomaly events; The anomaly analysis unit is used to calculate the organizational hierarchy anomaly ratio, anomaly contribution value, and anomaly impact coefficient based on the reconstructed statistical base. The performance incentive management module includes a performance correction unit, a performance calculation unit, a tiered matching unit, and a budget control unit. The performance correction unit is used to correct employee business values ​​based on comprehensive abnormal events. The performance calculation unit is used to calculate a performance score based on the corrected business value; The tiered matching unit is used to perform tiered incentive matching based on performance scores; The budget control unit is used to perform budget verification and budget deduction based on the budget balance; The customer asset management module includes an inheritance relationship calculation unit, a customer migration unit and an attribution update unit, wherein the inheritance relationship calculation unit is configured to recalculate the customer inheritance relationship according to the dynamic multi-role attribution model; The customer migration unit is configured to perform customer asset migration; The attribution update unit is configured to synchronously update customer lifecycle state data, the dynamic multi-role attribution model and customer attribution relationship data; The abnormal event fusion module includes an abnormal event extraction unit, an abnormal association index establishment unit, an abnormal event fusion unit and a comprehensive abnormal event generation unit. The abnormal event extraction unit is configured to separately extract various types of abnormal events generated during the customer lifecycle. In a specific implementation, this unit extracts six types of abnormal events from the lesson receiving detail table `og_receive_detail` and the conversion detail table `og_convert_detail` through six statistical methods of the `AbnormalOrderStatisticsServiceImpl` service: the `getAbnormalOrderWechatStatistics` method extracts WeChat adding abnormal events and static QR code abnormal events through `LEFT JOIN og_customers_leads` and judging that `leads.id IS NULL` or `rec.received_time < leads.create_time`; the `getAbnormalOrderConvertStatistics` method extracts abnormal conversion events by excluding specified courses through `course_key NOT IN`; the `getAbnormalOrderFrequencyCountStatistics` method performs aggregation by hourly sliding window through `DATE_FORMAT(received_time,'%Y-%m-%d-%H')`, and filters through `HAVING COUNT( The `#{frequencyLimit}` method extracts high-frequency order events (the frequency threshold is dynamically controlled by Apollo configuration `og.city.abnormal.monitor.receive.time.num`, with a default value of 10); the `getAbnormalOrderDifferentPlaceStatistics` method extracts out-of-town order events using 6-level city-level OR matching conditions; the `getAbnormalConvertOrderDifferentPlaceStatistics` method uses the same city matching logic as the former to extract out-of-town course events from the conversion details table. When extracting abnormal events, each of the above methods simultaneously obtains the customer's unique identifier, the order's unique identifier, the event occurrence time, the event type, and the business participation role information (including the contact specialist `employee_id`, the WeChat specialist `belonger_id`, and the mentor `mentor_id`). The abnormal association index building unit is used to build association indexes between various abnormal events based on the customer's unique identifier and the order's unique identifier. In the specific implementation, this unit uses the customer's unique identifier as the first-level index key and the order's unique identifier as the second-level index key to construct a multi-level index structure. When multiple abnormal events exist under the same customer identifier, the order identifier is used to further determine whether these abnormal events belong to the same business behavior. For example, if the same course order from the same customer triggers both a cross-order event and a high-frequency order event, the two are associated using a combination key of customer identifier + order identifier. For abnormal events that cannot be directly associated using order identifier but meet preset time window conditions (such as micro-exceptions and conversion anomalies occurring successively within 7 days for the same customer), this unit performs extended association matching based on preset association rules (combination of abnormality types + time window threshold). The abnormal event fusion unit is used to perform association matching and fusion processing on multiple abnormal events based on the association index to generate a comprehensive abnormal event. In its implementation, this unit groups multiple abnormal events that meet the same customer unique identifier, the same order unique identifier, or preset association conditions into an abnormal event group. After sorting by event occurrence time, the `toMergeVo` method is used to merge and deduplicate events when the same specialist is hit by multiple indicator SQL queries. Numerical fields (such as `customerNum`, `convertNum`, `abnormalFrequencyCount`, etc.) are summed, while ratio fields (such as `wechatAbnormalRate`, `abnormalConvertRate`, etc.) are selected based on the first non-null value rather than being summed to avoid duplicate ratio counting. The merged comprehensive abnormal event record includes the customer unique identifier, the event occurrence time range, a list of associated abnormal event types, and the corresponding business participation role information.The comprehensive anomaly generation unit is used to establish the correspondence between comprehensive anomalies and employees and organizational nodes based on a dynamic multi-role attribution model. In its specific implementation, this unit uses the three foreign key fields `employee_id`, `belonger_id`, and `mentor_id` recorded in the customer lead table `og_customers_leads`, combined with `manager_org_id` (promotion city architecture ID) and `director_org_id` (business team architecture ID), to map the merged comprehensive anomalies to the corresponding specialists, business teams, and promotion cities, forming a structured set of comprehensive anomalies and providing unified data input for the statistical analysis module.

[0083] The statistical analysis module includes an organization mapping unit, a statistical base reconstruction unit, and an anomaly analysis unit. The organization mapping unit establishes the mapping relationship between employees and organizational levels. Specifically, this unit queries the organizational structure information of each employee through `EmployeeReportResultService` to obtain their `orgPath` organizational path (organized according to a four-level tree structure of "Region - Promotion City - Business Team - Specialist"), and uses the `ServiceCommonUtil.getOrgIdByOrgPath` method to parse the promotion city architecture identifier `manager_org_id` (corresponding to the "city" level in the organizational hierarchy path) and the business team architecture identifier `director_org_id` (corresponding to the "team" level in the organizational hierarchy path) from `orgPath`, thereby establishing a four-level mapping relationship of "Specialist - Business Team - Promotion City - Region". The statistical base reconstruction unit is used to reconstruct the organizational hierarchy anomaly statistical base based on comprehensive anomaly events. In its implementation, this unit aggregates comprehensive abnormal events according to the aforementioned hierarchical mapping relationship, assigning them to the corresponding specialists, business teams, and promotion cities. It then uses six independent SQL templates to statistically analyze various abnormal indicators—each SQL statement using ``<iftest="level==2 / 3 / 4"> The aggregation granularity is controlled by conditions at the group / city / region level, and aggregated hierarchically according to organizational level using the `manager_org_id`, `director_org_id`, and `employee_id` fields. During statistics, the total number of abnormal events, normal business events, and total business events at each organizational level are calculated separately. Then, the `toAggregateVo` method is used to perform organizational-level aggregation calculations. This method aggregates a group of statistical results at the same level into a single record. Numerical fields (such as the number of abnormal events of each type) are summed, and ratio fields (such as the abnormality rate) are recalculated using the new numerator and denominator after aggregation (e.g., group abnormality conversion rate = total number of abnormal conversions in the group / total number of conversions in the group), rather than averaging or weighting the ratios of each sub-item, thus ensuring the statistical accuracy of the aggregation results. The abnormality analysis unit is used to calculate the organizational-level abnormality ratio, abnormality contribution value, and abnormality impact coefficient based on the reconstructed statistical base. In its implementation, this unit calculates the anomaly ratio (total number of abnormal events / total number of business events), anomaly contribution value (the proportion of the number of abnormal events at this level to the total number of abnormal events at its parent level), and anomaly impact coefficient (the degree of influence of the abnormal events at this level on the overall anomaly level of the parent level, obtained by weighting the anomaly contribution value with the level weight) for each organizational level, and generates complete organizational level anomaly statistics.

[0084] The performance incentive management module includes a performance correction unit, a performance calculation unit, a tiered matching unit, and a budget control unit. The performance correction unit is used to correct employee business values ​​based on comprehensive abnormal events. In its implementation, this unit adopts differentiated correction strategies for different types of abnormal events: for WeChat-added abnormal events and static QR code abnormal events, the corresponding WeChat-added customers are removed from the number of valid customers; for abnormal conversion events, the corresponding converted orders are removed from the number of valid conversions; for high-frequency order events, excess orders exceeding the threshold within the corresponding time period are removed from the number of valid course registrations; for cross-regional order events and cross-regional course events, a weighted correction is performed based on the abnormal impact coefficient—when the abnormal impact coefficient is lower than a preset threshold, it is only marked as not included in the abnormal statistical base but the business value is retained; when the abnormal impact coefficient exceeds the preset threshold, the corresponding order is completely removed from the valid business value. In cases where a business event is associated with multiple abnormal events, correction is performed according to the abnormal type with the highest degree of impact, and this business event is only deducted once in subsequent statistics, without repeated deductions. The performance calculation unit is used to calculate performance scores based on the corrected business values. In its implementation, this unit recalculates each employee's performance score based on the revised effective number of classes completed, effective conversions, and effective GMV—including core performance indicators such as effective conversion rate (effective conversions / effective completed classes), effective GMV achievement rate (effective GMV / target GMV), and effective customer acquisition. When calculating the completion conversion rate, a "completion date + 3-day observation window" metric is used, along with a cold start threshold (Apollo configuration `og.city.incentive.convert_rate_threshold` default value 50). Only specialists whose completed classes reach this threshold are eligible to participate in the completion conversion rate performance statistics. The tiered matching unit is used to execute tiered incentive matching based on performance scores. In its implementation, this unit uses the `SystemRewardStrategy` class to uniformly handle three settlement modes: for the ranking mode, the `genRankNo` method employs a cumulative ranking skipping mechanism to handle tied scores—employees with the same score have the same ranking number (achieving a "1, 1, 3" skipping effect), and then retrieves the score value from the rule detail Map in O(1) time; for the tiered range mode, the `calculateReward` method uses a binary search algorithm to locate the tiered interval `[minValue, maxValue)` into which the performance score falls and returns the corresponding score value; for the target achievement rate mode, the ratio of the actual achieved value to the target value is mapped to the corresponding tiered interval, and the same binary search logic is used to calculate the incentive amount. The budget control unit is used to perform budget verification and budget deduction based on the budget balance.In its implementation, before each incentive rule is executed, this unit queries the available budget balance for the current assessment month using `IncentiveBudgetService.selectByMonth`. If the balance is insufficient, it sends a DingTalk alert via `DingTalkExceptionAlarmWrapper` and skips the rule. If the budget is sufficient, it acquires a Redis distributed lock (lock key `og:city:incentive:budget:lock:{budgetId}`) via `DistributedLockHelper.doActionWithLock` to ensure atomic control over budget deduction. If a single employee's disbursement fails, it isolates the issue using `try-catch` to prevent it from affecting other employees.

[0085] The customer asset management module includes an inheritance relationship calculation unit, a customer migration unit, and an attribution update unit. The inheritance relationship calculation unit recalculates customer inheritance relationships based on a dynamic multi-role attribution model. Specifically, when an employee organizational change is detected, this unit retrieves the set of customers to be transferred under that employee's name and their corresponding attribution version information using `CustomersLeadsMapper.queryTransferCustomers`. Then, it uses the `distributeLeads` method with a round-robin distribution algorithm (`i%n`, where `n` is the total number of transferors) to evenly distribute the customers among the transferors—for example, 100 customers distributed among 2 transferors receive 50 each, while those distributed among 3 transferors receive 34, 33, and 33 respectively. For each customer to be transferred, this unit recalculates their attribution relationship under the new organizational structure based on their current lifecycle status and the attribution version at each lifecycle stage. The customer migration unit performs customer asset migration. In its implementation, this unit asynchronously calls the `resignedTransferCustomer` interface (for resignation scenarios) or the `transferCustomer` interface (for job transfer scenarios) of WeChat Work via the `asyncTransferCustomers` method to perform customer friend relationship transfer. In the `transferResult` method, each customer's `errcode` is processed sequentially: if the transfer is successful (`errcode=0`), a double-write mechanism is executed—first, the `belonger_id` in the `og_customers_leads` table is updated to the takeover specialist ID and `transferStatus=2` (transfer in progress); then, the transfer history is recorded in the `og_customers_leads_transfer` log table (`transferStatus=2`); finally, the `cpUserId` and `bizSequenceKey` fields in the `og_corp_tag_customers_new` table are updated asynchronously; if the transfer fails (`errcode!=0`), the customer is skipped and a pending migration record with `transferStatus=0` is generated for retry by subsequent compensation tasks. The attribution update unit is used to synchronously update customer lifecycle status data, dynamic multi-role attribution model, and customer attribution relationship data.In its implementation, after customer asset migration is complete, this unit uses `updateBatchById` to batch update the `belonger_id` field in the customer lead table `og_customers_leads` to the takeover specialist ID, and uses `customersLeadsTransferMapper.batchSave` to batch write data to the transfer log table. After the transaction is committed, it asynchronously updates the customer lifecycle status data (marking that the customer's ownership has changed, recording specialist information before and after the change, and the change time) and the dynamic multi-role ownership model (updating the customer's corresponding business participation role at each lifecycle stage to the takeover specialist and their organizational ownership information). These units collaborate in a hierarchical manner—the inheritance relationship calculation unit determines the migration plan, the customer migration unit executes the migration operation, and the ownership update unit completes data synchronization, collectively achieving a complete closed loop for customer asset inheritance.

[0086] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A field sales management method based on multi-role affiliation and tiered incentives, characterized in that, Includes the following steps: S1: Obtain customer event data generated during offline promotion, identify event types, sort events by time, and perform business correlation analysis on the customer event data, establish a lifecycle event chain covering the entire process of customer outreach, adding on WeChat, course acquisition, course learning, course conversion, and organizational changes, and generate corresponding customer lifecycle status data based on the lifecycle event chain. S2: Identify the business participation roles of customers at different lifecycle stages based on the lifecycle status data, and construct a dynamic multi-role attribution model of customers by combining employee identity information, employee organizational relationship and organizational relationship change records, and establish the association mapping relationship between customer lifecycle status data and dynamic multi-role attribution model; S3: Extract multi-source abnormal events generated during the customer lifecycle based on the dynamic multi-role attribution model, perform correlation matching and fusion processing on the multi-source abnormal events to generate a comprehensive set of customer abnormal events, and re-aggregate organizational-level business data based on the comprehensive set of abnormal events to construct an organizational-level abnormal statistical base. S4: Recalculate the performance statistics results corresponding to each organizational level based on the abnormal statistical base of the organizational level, and use the comprehensive abnormal event set to correct the performance statistics results. Perform tiered incentive matching based on the corrected performance statistics results to generate incentive result data for the corresponding employees. S5: Perform budget control and incentive distribution based on the incentive result data, and when a change in employee organizational relationship or employee resignation is detected, recalculate customer ownership relationship based on the dynamic multi-role ownership model, complete customer asset inheritance processing, and update customer lifecycle status data, dynamic multi-role ownership model and customer ownership relationship data.

2. The ground sales management method based on multi-role affiliation and tiered incentives according to claim 1, characterized in that, S1 includes: Acquire customer touch events, WeChat addition events, course collection events, course learning events, course completion events, order generation events, and organizational change events generated during the on-the-ground promotion business. Extract customer identifier, event type, event occurrence time, and related business object information for each event, and establish the event set for the corresponding customer based on the customer identifier. The event set is sorted according to the time of occurrence, and the life cycle stage of each event is identified according to the preset life cycle node rules to establish a life cycle event chain covering the entire process from the first contact with the customer to the completion of the business. The customer lifecycle state transition path is calculated based on the sequential relationship between adjacent events in the lifecycle event chain, and customer lifecycle state data is generated based on the current lifecycle node, historical lifecycle nodes, and state transition path.

3. The ground promotion management method based on multi-role affiliation and tiered incentives according to claim 1, characterized in that, S2 specifically includes: Based on the customer lifecycle event chain, identify the contacting employees, employees added via WeChat, and mentoring employees corresponding to each node of the customer lifecycle, and establish a multi-role attribution relationship between customers and employees involved in various business activities based on employee identity categories. Obtain organizational structure information, job adjustment records, organizational migration records, and mentorship relationship change records for employees involved in each business. Establish a sequence of attribution relationship versions based on the time of each organizational relationship change, and call the corresponding version of the attribution relationship based on the event occurrence time corresponding to each customer lifecycle node to generate dynamic multi-role attribution relationships for each stage of the customer lifecycle. Establish customer lifecycle status data, dynamic multi-role attribution relationships, and the mapping relationships between organizational levels to form a dynamic multi-role attribution model for customers.

4. The ground sales management method based on multi-role affiliation and tiered incentives according to claim 1, characterized in that, The process of correlation matching and fusion of the multi-source abnormal events includes: Based on customer lifecycle status data, extract the following events generated during the customer lifecycle: WeChat abnormal events, static QR code abnormal events, abnormal conversion events, high-frequency order events, remote ordering events, and remote course events. Obtain the customer unique identifier, order unique identifier, event occurrence time, event type, and business participation role information corresponding to each abnormal event. Establish an association index between different abnormal events based on the customer's unique identifier and the order's unique identifier, and perform association matching on multiple abnormal events that meet the same customer's unique identifier, the same order's unique identifier, or preset association conditions; Based on the order of occurrence, lifecycle stage, and dynamic multi-role attribution, related abnormal events are merged and processed to integrate multiple interrelated abnormal events into a comprehensive abnormal event corresponding to the customer. Based on the dynamic multi-role attribution model, the association between comprehensive abnormal events and corresponding employees and organizational nodes is established to form a comprehensive abnormal event set, providing a unified data input for the reconstruction of the statistical base of organizational hierarchy.

5. The ground promotion management method based on multi-role affiliation and tiered incentives according to claim 4, characterized in that, The process of re-aggregating organizational-level business data based on a comprehensive set of abnormal events to construct an organizational-level anomaly statistical base includes: The organizational hierarchy path corresponding to each employee is obtained based on the dynamic multi-role attribution model, and a hierarchical mapping relationship is established between employees, organizational nodes, and comprehensive abnormal events. Based on the hierarchical mapping relationship, the comprehensive abnormal events are mapped to the corresponding organizational levels, and the number of comprehensive abnormal events, the number of normal business events, and the total number of business events corresponding to each organizational level are counted. The abnormal statistical base corresponding to each organizational level is reconstructed based on the number of comprehensive abnormal events and the total number of business events. Using the reconstructed anomaly statistics base, the anomaly ratio, anomaly contribution value and anomaly impact coefficient corresponding to each organizational level are recalculated to generate organizational level anomaly statistics results. The anomaly ratio for each organizational level is calculated independently based on the reconstructed anomaly statistical base.

6. The ground sales management method based on multi-role affiliation and tiered incentives according to claim 1, characterized in that, The recalculation of performance statistics for each organizational level based on the organizational level anomaly statistical base includes: Obtain business event data for each employee, a comprehensive set of abnormal events, and organizational-level anomaly statistics. Establish the correlation between business events and comprehensive abnormal events based on the organizational hierarchy to which the employee belongs; Based on the anomaly type, degree of impact and impact coefficient of the comprehensive anomaly event, anomaly correction is performed on each business event to obtain the effective business value of the corresponding business event. The performance scores for each employee are recalculated based on the revised effective business values, and employee performance results, team performance results, and city performance results are generated separately according to organizational level.

7. The ground sales management method based on multi-role affiliation and tiered incentives according to claim 6, characterized in that, The step of matching tiered incentives based on the revised performance statistics includes: Obtain the performance scores corresponding to each organizational level, establish a mapping relationship between performance scores and incentive levels based on the preset incentive strategy, sort employees according to performance scores, and identify the set of employees who meet the same performance score. For sets of employees with the same performance rating, a unified sorting process is adopted, and the incentive level and incentive amount of the corresponding employees are calculated in combination with the preset tiered incentive range. Obtain the current incentive budget data, verify the budget for each incentive result based on the budget balance, complete the budget deduction and generate incentive result data when the budget meets the issuance conditions, and reallocate the incentive amount according to the preset budget adjustment strategy when the budget is insufficient.

8. The ground sales management method based on multi-role affiliation and tiered incentives according to claim 1, characterized in that, S5 includes: Obtain the customer set corresponding to employees who have undergone job adjustments, organizational restructuring, or resignation, and obtain the business participation roles and affiliation versions of each customer at different lifecycle stages based on the dynamic multi-role affiliation model; Based on the customer's current lifecycle status, ownership version, and organizational adjustment information, the customer inheritance relationship is recalculated to generate customer migration data. Perform customer asset migration based on customer migration data, and synchronously update customer lifecycle status data, dynamic multi-role attribution model and customer attribution relationship; When a customer fails to migrate their assets, only the original ownership relationship of the corresponding customer is retained and a record to be migrated is generated, while the remaining customers continue to complete the asset inheritance.

9. A ground promotion management system based on multi-role affiliation and tiered incentives, comprising a processor and a memory, wherein the memory stores a computer program; when the processor executes the computer program stored in the memory, it implements the method as described in any one of claims 1 to 8; characterized in that, Also includes: The event data management module is used to acquire customer touch data, WeChat addition data, course learning data, order data, employee organization data and organization change data generated during offline promotion, to manage various types of business data in a unified manner, and to perform the customer lifecycle event chain construction process described in claims 1 and 2 to generate customer lifecycle status data. The dynamic attribution management module is used to obtain the business participation roles corresponding to each stage of the customer's life cycle based on the customer life cycle status data, and to establish a dynamic multi-role attribution model by combining employee identity information, organizational relationship information and organizational relationship change records. At the same time, it establishes an association mapping relationship between the customer life cycle status data and the dynamic multi-role attribution model, and performs the dynamic multi-role attribution model construction process described in claims 1 and 3. The abnormal event fusion module is used to extract multi-source abnormal events generated during the customer lifecycle based on the dynamic multi-role attribution model, establish an abnormal event association index, and perform abnormal event association matching, abnormal event fusion and comprehensive abnormal event generation processing. At the same time, it establishes the correspondence between comprehensive abnormal events and employees and organizational nodes, and performs the abnormal event fusion processing described in claims 1 and 4. The statistical analysis module is used to establish organizational hierarchy mapping relationships based on the comprehensive abnormal event set and dynamic multi-role attribution model, perform organizational hierarchy re-aggregation on the comprehensive abnormal events, reconstruct the organizational hierarchy abnormal statistical base, calculate the organizational hierarchy abnormality ratio, abnormal contribution value and abnormality influence coefficient, and perform the organizational hierarchy statistical base reconstruction processing described in claims 1 and 5. The performance incentive management module is used to correct employee business values ​​based on the statistical results of organizational hierarchy anomalies, recalculate performance scores, and complete performance ranking, identification of employees with the same score, tiered incentive matching, budget verification and incentive result generation based on the corrected performance scores, and perform the performance correction and tiered incentive processing described in claims 1, 6 and 7. The customer asset management module is used to recalculate customer inheritance relationships based on the dynamic multi-role ownership model, and to complete customer asset migration, customer ownership update, lifecycle status update and dynamic multi-role ownership model update, and to perform the customer asset inheritance processing described in claims 1 and 8. The modules interact with each other through customer lifecycle status data, dynamic multi-role attribution model, comprehensive abnormal event set, organizational hierarchical abnormal statistics and incentive results data to realize the ground promotion management method based on multi-role attribution and tiered incentives as described in any one of claims 1 to 8.

10. The ground promotion management system based on multi-role affiliation and tiered incentives according to claim 9, characterized in that, The abnormal event fusion module includes an abnormal event extraction unit, an abnormal association index establishment unit, an abnormal event fusion unit, and a comprehensive abnormal event generation unit. The abnormal event extraction unit is used to extract various abnormal events generated during the customer lifecycle. The abnormal association index establishment unit is used to establish an association index between various abnormal events based on the customer's unique identifier and the order's unique identifier; the abnormal event fusion unit is used to perform association matching and fusion processing on multiple abnormal events based on the association index to generate a comprehensive abnormal event; the comprehensive abnormal event generation unit is used to establish the correspondence between the comprehensive abnormal event and employees and organizational nodes based on the dynamic multi-role attribution model. The statistical analysis module includes an organization mapping unit, a statistical base reconstruction unit, and an anomaly analysis unit. The organization mapping unit is used to establish a mapping relationship between employees and organizational levels. The statistical base reconstruction unit is used to reconstruct the organizational level anomaly statistical base based on comprehensive anomaly events. The anomaly analysis unit is used to calculate the organizational level anomaly ratio, anomaly contribution value, and anomaly impact coefficient based on the reconstructed statistical base. The performance incentive management module includes a performance correction unit, a performance calculation unit, a tiered matching unit, and a budget control unit. The performance correction unit is used to correct employee performance values ​​based on comprehensive abnormal events; the performance calculation unit is used to calculate performance scores based on the corrected performance values; the tiered matching unit is used to perform tiered incentive matching based on performance scores; and the budget control unit is used to perform budget verification and budget deduction based on the budget balance. The customer asset management module includes an inheritance relationship calculation unit, a customer migration unit, and an attribution update unit. The inheritance relationship calculation unit is used to recalculate customer inheritance relationships based on a dynamic multi-role attribution model. The customer migration unit is used to perform customer asset migration. The attribution update unit is used to synchronously update customer lifecycle status data, dynamic multi-role attribution model, and customer attribution relationship data.

Images