A recommended link fission tracking method

Abstract

The application discloses a kind of recommended link fission tracking methods, it is related to computer data processing technical field.The method includes: the data of enterprise relationship, recommendation event and conversion event is gathered, and industry chain recommendation base atlas is generated;According to the candidate recommended link formed by recommendation event;Search business undertaking path, verify validity and direction continuity to generate recommended link undertaking degree;According to link event update state, backfill conversion event that meets subject, state and time undertaking condition to generate conversion backfill matching degree;The fission attribution locking value of the same recommended enterprise candidate link is generated, and the only effective attribution link is locked, and it is marked to be verified when unable to lock uniquely;Along parent link backtracking determines fission level, and generates recommended link fission tracking record.Through enterprise subject collection, parent link inheritance, business undertaking path verification, conversion event backfill, unique attribution locking and fission level backtracking, form continuous, accurate and traceable recommended link fission tracking result.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, specifically to a recommended link fission tracing method. Background Technology

[0002] With the development of supply chain marketing and collaborative business expansion among enterprise clients, referral customer acquisition systems have gradually expanded from recording single-recommendation relationships to multi-level viral referrals. Existing systems typically record the correspondence between the referrer and the referred party through referral codes, referral links, or referral entry points, and verify the conversion status based on the referral records after the referred company completes registration, account opening, or business transactions. Some systems can also calculate rewards and perform performance statistics based on referral time, referral level, or conversion results.

[0003] However, enterprise relationship data, recommendation event data, and conversion event data are typically stored separately in different business systems. Even within the same enterprise, differences in name format, entity number, or business account can create independent records, making it difficult to stably link recommendation events with subsequent conversion events. For multi-level referral programs, subsequent recommendation behaviors may also be stored independently of the previous level's recommendation record, resulting in missing parent links and making it impossible to continuously determine the inheritance order and referral level of the recommendation relationship.

[0004] Furthermore, the same recommended company may be reached by different companies at different times through different recommendation entry points, resulting in separate candidate recommendation records. Existing technologies often use the earliest recommendation time, the last entry trigger, or a single recommendation code as the attribution basis, without verifying the business relationship between the recommender and the recommended company, the direction of the recommendation chain, and the continuity of the parent chain. This easily leads to attribution records without a business connection basis. There may also be a long time interval between public account registration and the first transaction, making it impossible to promptly backfill the conversion event to the original recommendation chain, further causing chain status interruptions, duplicate attribution, or hierarchical mismatches.

[0005] Therefore, existing recommendation link tracing methods still have shortcomings in cross-system entity aggregation, business acceptance path verification, delayed conversion event backfilling, unique attribution of multiple candidate links, and continuous backtracking of fission levels. Summary of the Invention

[0006] Based on the shortcomings of the prior art described above, the purpose of this invention is to provide a recommended link splitting tracing method to solve the above-mentioned technical problems.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a recommended link fission tracing method, comprising: Acquire enterprise relationship data, recommendation event data, and conversion event data; and aggregate the records of the same enterprise in the business system based on the enterprise entity identifier to generate a basic industry chain recommendation map. Candidate recommendation link records are formed based on recommendation event data. Each candidate recommendation link record carries the parent link identifier. Non-first-level recommendations inherit the identifier of the confirmed recommendation link of the previous level. Search the candidate recommendation link record for the corresponding business undertaking path in the basic graph of the industry chain recommendation, verify the validity and directional continuity of the business undertaking path when the recommendation is initiated, and generate the recommendation link undertaking degree. Update the candidate recommendation link status based on the link event triggered by the recommendation entry to the occurrence of the first business transaction, and backfill the candidate recommendation link record with conversion events of the same enterprise that meet the status and time continuation conditions, and generate conversion backfill matching degree. When the same recommended enterprise corresponds to more than two candidate recommendation link records, a fission attribution lock value is generated based on the recommendation link acceptance degree and conversion backfill matching degree. Candidate recommendation links whose fission attribution lock value meets the unique locking condition are determined as valid attribution links; if no unique locking condition is formed, a link status pending verification is generated. The fission level is determined by tracing back level by level according to the parent link identifier of the valid home link, and the valid home link, fission level, backfill conversion event and link status are written into the recommended link fission tracking record.

[0008] The present invention is further configured such that the step of acquiring enterprise relationship data, recommendation event data, and conversion event data, and generating a basic industry chain recommendation map by grouping the records of the same enterprise in the business system according to the enterprise entity identifier, includes: The original business records are extracted from the business data source, and the original business records are marked with source and time to generate business records to be collected. The original business records include enterprise relationship data, recommendation event data and conversion event data. The format of the enterprise entity identifier in the business records to be collected is validated and made consistent to generate an enterprise entity index. Based on the enterprise entity index, the business records to be collected that point to the same enterprise are merged to generate enterprise master records. Extract enterprise node attributes from enterprise master records, and generate enterprise nodes by performing node encoding and node attachment processing on the enterprise node attributes. Extract the relationship subject field, relationship direction field, and relationship time field from the enterprise relationship data, match the relationship subject field to the corresponding enterprise node, and perform directional connection and time attachment on the matched enterprise nodes to generate business relationship edges between enterprises; Extract the recommender subject field, the recommended subject field, and the recommend time field from the recommendation event data. Match the recommender subject field and the recommended subject field to the corresponding enterprise node. Generate recommendation behavior edges by performing recommendation connection and time attachment on the matched enterprise nodes. Extract the conversion subject field and conversion time field from the conversion event data, match the conversion subject field to the corresponding enterprise node, and generate conversion event edges by attaching conversion events to the matched enterprise nodes. The basic graph of the industry chain recommendation is generated by writing the subject correspondence and time sequence between enterprise nodes, inter-enterprise business relationship edges, recommendation behavior edges, and conversion event edges into the graph structure.

[0009] The present invention is further configured such that forming candidate recommendation link records based on recommendation event data includes: Perform event integrity verification on the recommendation event data, and extract the recommender entity, the recommended enterprise entity, the recommendation entry identifier, and the recommendation initiation time to generate recommendation events to be processed; Match the recommending entity and the recommended enterprise entity in the pending recommendation event to the enterprise nodes in the basic graph of the industry chain recommendation to generate corresponding records of the recommendation nodes; Organize the recommendation direction of the records corresponding to the recommendation nodes, take the enterprise node corresponding to the recommender as the starting point of the link, and the enterprise node corresponding to the recommended enterprise as the ending point of the link, and generate a recommendation link direction record; An initial link status record is established based on the recommended link direction record, the recommended entry identifier, and the recommended initiation time. The initial link status record is marked as recommended. The recommended node corresponding record, recommended link direction record, and link state initial record are encapsulated to generate candidate recommended link records.

[0010] The present invention is further configured such that the candidate recommendation link record carries the parent link identifier, and the non-first-level recommendation inherits the identifier of the confirmed recommendation link of the previous level, including: Based on the recommender entity in the candidate recommendation link record, retrieve the confirmed recommendation link record to generate the recommender link source record; The confirmation status and time sequence of the referrer's link source record are verified, and the confirmed referral link record with the confirmation time earlier than the current referral initiation time is retained; If no confirmed recommended link record is found that has passed the verification of confirmation status and time sequence, the candidate recommended link record is marked as a first-level recommended record and the parent link identifier is set to empty; When a confirmed recommended link record that has passed the confirmation status verification and time sequence verification is retrieved, the corresponding confirmed recommended link identifier is written into the parent link identifier field of the candidate recommended link record to generate a non-first-level candidate recommended link record. When a parent link identifier cannot form a single correspondence, the candidate recommended link record is marked as a parent pending verification status.

[0011] The present invention is further configured such that the step of retrieving the business undertaking path corresponding to the candidate recommendation link record in the basic graph of the industry chain recommendation, verifying the validity and directional continuity of the business undertaking path at the time of recommendation initiation, and generating the recommendation link undertaking degree includes: Locate the recommending entity and the recommended enterprise entity in the candidate recommendation link record to the corresponding enterprise node in the basic graph of the industry chain recommendation, and generate the path retrieval start point and path retrieval end point; Starting from the path retrieval starting point and ending from the path retrieval ending point, the path is extended along the business relationship edge between enterprises in the basic graph of the industry chain recommendation. The candidate business undertaking path is generated by sequentially recording the enterprise nodes and business relationship edges passed through. Perform time verification on the inter-enterprise business relationship edges in the candidate business acceptance path, retain the inter-enterprise business relationship edges that are in effect at the time of recommendation initiation, and generate time-verification paths; Perform directional verification on the business relationship edges between enterprises in the timeliness verification path, and generate a directional verification path by continuously matching the directional order of the business relationship edges with the link direction from the recommender to the recommended enterprise. Perform path-level verification on the direction verification path, determine the direction verification path that meets the fission level limit as the valid business acceptance path, and mark the candidate business acceptance path that does not meet the time verification, direction verification or path-level verification as the acceptance abnormal path. Based on the valid business acceptance paths and the abnormal acceptance paths, acceptance path verification records are generated. The acceptance level is mapped to the acceptance path verification records to generate the acceptance degree of the recommended link corresponding to the candidate recommended link record.

[0012] The present invention is further configured such that updating the candidate recommendation link status based on the link event triggered by the recommendation entry to the occurrence of the first service includes: Based on the recommendation entry identifier in the candidate recommendation link record, the recommendation entry trigger event is matched with the candidate recommendation link record. The recommended enterprise entity is matched and the time sequence is verified for the recommendation entry trigger event after the entry is matched to generate the link response record. Based on the recommended enterprise entity and the trigger time of the recommendation entry in the link response record, the account opening and registration event is processed with the candidate recommendation link record for account opening acceptance. The account opening and registration event is verified for entity consistency, account opening order, and account opening status acceptance to generate the link account opening record. Based on the recommended enterprise entity and account opening registration time in the link account opening record, the first business event is converted and connected with the candidate recommended link record. The first business event is verified for entity consistency, business occurrence sequence and conversion status connection to generate the link conversion record. Following the generation order of link response records, link account opening records, and link conversion records, the link status in the candidate recommended link records is progressively updated to generate link status change records.

[0013] The present invention is further configured such that the conversion events of the same enterprise that meet the conditions of status and time continuity are backfilled into the candidate recommendation link record, and the conversion backfill matching degree is generated, including: Based on the recommended enterprise entity in the link status change record, conversion events with the same entity in the conversion event data are grouped into the candidate recommended link record to generate a set of conversion events with the same entity; Based on the link status in the link status change record, the same subject conversion event set is filtered for status succession, and conversion events that meet the progressive relationship of being responded to to being opened and being opened to being converted are identified as conversion events to be backfilled. Based on the recommendation initiation time, recommendation entry trigger time, account registration time, and conversion event time to be filled in the link status change record, perform time continuity verification on the conversion event to be filled in to generate a conversion time continuity record; The conversion events to be backfilled that have passed the subject attribution verification, status acceptance filtering, and time acceptance verification will be written into the candidate recommendation link record to generate conversion event backfilling records; The verification items of the subject attribution verification results, status inheritance screening results, and time inheritance verification results in the conversion event backfill record are merged, integrity verified, and conflict verified to generate backfill availability record; Based on the backfill availability record, the candidate recommendation link record is marked with a matching level to generate the conversion backfill matching degree corresponding to the candidate recommendation link record.

[0014] The present invention is further configured such that, when the same recommended enterprise corresponds to two or more candidate recommendation link records, generating a fission attribution lock value based on the recommendation link connectivity and conversion backfill matching degree includes: For candidate recommendation link records corresponding to the same recommended enterprise, generate a set of conflicting links by grouping them together under the same subject. Based on the acceptance degree of the recommended link record corresponding to the candidate recommended link record in the set of conflicting links, the acceptance qualification of the candidate recommended link record is screened to generate acceptance qualification record; Based on the matching degree of the acceptance qualification record and the conversion backfill, the candidate recommendation link record that has passed the acceptance qualification screening is used to generate backfill qualification record; Based on the parent link identifier in the backfill qualification record and the candidate recommendation link record, perform parent continuity verification on the candidate recommendation link record that has passed the backfill qualification verification to generate a parent continuity record; The acceptance qualification record, backfill qualification record, and parent continuity record are merged according to the candidate recommendation link record to generate a locking condition combination record; Perform condition integrity verification on the locked condition combination record, write the candidate recommendation link record that meets the acceptance qualification, backfill qualification and parent continuity into the locked candidate record, and write the candidate recommendation link record with the condition not met into the excluded candidate record. Based on the locked candidate records and excluded candidate records, the fission ownership lock value is generated by assigning ownership status values ​​to the candidate recommended link records in the ownership conflict link set.

[0015] The present invention is further configured such that the candidate recommended links whose fission attribution lock values ​​satisfy the unique locking condition are determined as valid attribution links; the generation of a link to be verified status when no unique locking condition is formed includes: Based on the fission attribution lock value, candidate recommended link records with lockable attribution status are filtered to generate a set of lockable links; Perform quantity verification on the set of lockable links to generate a lock quantity verification record; When there is only one candidate recommended link record in the locked quantity verification record, the candidate recommended link record is determined as a valid belonging link; When there is no candidate recommended link record in the locked quantity verification record, the link status to be verified is generated according to the invalid conditions in the excluded candidate record. When there are more than two candidate recommended link records in the locked quantity verification record, the set of lockable links is marked with ownership conflict to generate the status of the link to be verified. Write the status of the valid home link or the link to be verified into the corresponding candidate recommended link record.

[0016] The present invention is further configured such that, in determining the fission level by tracing back level by level according to the parent link identifier of the valid home link, and writing the valid home link, fission level, backfill conversion event, and link status into the recommended link fission tracking record, the following steps are taken: Using the valid home link as the starting link for backtracking, hierarchical pointing matching is performed on the parent link identifier in the valid home link to generate a parent pointing record; Perform link identifier mapping between the parent-level pointing record and the confirmed recommendation link record, determine the upper-level recommendation link corresponding to the current level, and generate the upper-level link corresponding record. The corresponding records of the upper-level links are confirmed for status verification and time sequence verification. The upper-level recommended links that pass the verification are connected to the backtracking link sequence to generate hierarchical backtracking records. Repeat the process of matching parent link identifiers, processing corresponding link identifiers, and accessing hierarchical backtracking records until the parent link identifier is empty or a parent pending verification status appears, generating a fission hierarchical path. The fission hierarchy path is sorted hierarchically, the location of the effective belonging link is determined as the last level link, and the link with an empty parent link is determined as the starting link, and a fission hierarchy record is generated. The effective attribution link, fission level record, conversion event backfill record and link status change record are processed to generate a tracking field combination record; The combined tracking field records are encapsulated with link identifiers and status information and written into the recommended link splitting tracking records.

[0017] This invention provides a method for tracking the fission of recommendation links. The method acquires enterprise relationship data, recommendation event data, and conversion event data. Based on the enterprise entity identifier, it aggregates records of the same enterprise in the business system to generate a basic industry chain recommendation graph. Based on the recommendation event data, it forms candidate recommendation link records, each carrying a parent link identifier. Non-first-level recommendations inherit the identifier of the confirmed recommendation link from the previous level. It retrieves the business connection path corresponding to the candidate recommendation link record in the basic industry chain recommendation graph, verifies the validity and directional continuity of the business connection path at the time of recommendation initiation, and generates the recommendation link connection degree. Based on the link event from the recommendation entry trigger to the first business transaction, it further refines the link connection. The new candidate recommendation link status involves backfilling conversion events from the same enterprise that meet the status and time continuity conditions into the candidate recommendation link record, generating a conversion backfill matching degree. When the same recommended enterprise corresponds to more than two candidate recommendation link records, a fission attribution lock value is generated based on the recommendation link continuity and conversion backfill matching degree. Candidate recommendation links whose fission attribution lock value meets the unique locking condition are determined as valid attribution links. If no unique locking condition is formed, a link status pending verification is generated. The fission level is determined by tracing back level by level according to the parent link identifier of the valid attribution link. The valid attribution link, fission level, backfilled conversion events, and link status are written into the recommendation link fission tracking record. The beneficial effects include: 1. Improve the continuity of the recommendation chain: By aggregating enterprise entities, inheriting parent chain identifiers, and progressively updating chain status, scattered recommendation events and conversion events are associated with the same candidate recommendation chain, forming a multi-level fission relationship that can be traced back step by step; 2. Improve the accuracy of conversion event attribution: By verifying the business acceptance path and processing conversion event backfilling, candidate links are screened by combining the acceptance degree of recommended links with the matching degree of conversion backfilling, reducing attribution deviations caused by no business acceptance relationship or abnormal time acceptance. 3. Reduce duplicate attribution and hierarchical mismatch: The uniqueness of the candidate recommendation link corresponding to the same recommended enterprise is verified by the fission attribution lock value, and the fission level is determined step by step along the effective attribution link to form a structured recommendation link fission tracking record.

[0018] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings: Figure 1 The flowchart illustrates a recommended link fragmentation tracking method as an exemplary embodiment of the present invention. Detailed Implementation

[0020] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0021] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0022] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the invention.

[0023] Example 1: A recommended link splitting tracing method, such as Figure 1 As shown, it includes: Acquire enterprise relationship data, recommendation event data, and conversion event data; and aggregate the records of the same enterprise in the business system based on the enterprise entity identifier to generate a basic graph of the industry chain recommendation. Candidate recommendation link records are formed based on recommendation event data. Each candidate recommendation link record carries the parent link identifier. Non-first-level recommendations inherit the identifier of the confirmed recommendation link of the previous level. Search the candidate recommendation link record for the corresponding business undertaking path in the basic graph of the industry chain recommendation, verify the validity and directional continuity of the business undertaking path when the recommendation is initiated, and generate the recommendation link undertaking degree. Update the candidate recommendation link status based on the link event triggered by the recommendation entry to the occurrence of the first business transaction, and backfill the candidate recommendation link record with conversion events of the same enterprise that meet the status and time continuation conditions, and generate conversion backfill matching degree. When the same recommended enterprise corresponds to more than two candidate recommendation link records, a fission attribution lock value is generated based on the recommendation link acceptance degree and conversion backfill matching degree. Candidate recommendation links whose fission attribution lock value meets the unique locking condition are determined as valid attribution links; if no unique locking condition is formed, a link status pending verification is generated. The fission level is determined by tracing back level by level according to the parent link identifier of the valid home link, and the valid home link, fission level, backfill conversion event and link status are written into the recommended link fission tracking record.

[0024] The present invention is further configured such that the step of acquiring enterprise relationship data, recommendation event data, and conversion event data, and generating a basic industry chain recommendation map by grouping the records of the same enterprise in the business system according to the enterprise entity identifier, includes: This embodiment applies to the bank's corporate client supply chain recommendation business. The deployment includes a corporate client information system, a corporate relationship management system, a recommendation business system, an account opening and registration system, and a business transaction system. The corporate client information system stores the enterprise's main identifier and master file. The corporate relationship management system stores transactions or upstream / downstream relationships between enterprises. The recommendation business system records the recommender, the recommended enterprise, the recommendation entry point, and the recommendation initiation time. The account opening and registration system records account opening events. The business transaction system records the first business event. Corporate relationship data is collected incrementally daily, with the collection cycle set to 1 hour to 24 hours based on the relationship data update cycle; this embodiment uses 24 hours. Recommendation event data and conversion event data are collected incrementally via event interfaces, with the collection cycle set to 1 minute to 10 minutes based on event timeliness requirements; this embodiment uses 5 minutes. The system extracts raw business records from the business data source, marks these records with source and time tags to generate business records to be aggregated. These raw business records include enterprise relationship data, recommendation event data, and conversion event data. Specifically, it obtains enterprise relationship data, recommendation event data, and conversion event data through a business data interface, performing field type validation, null value validation, and time format conversion on the acquired data. Enterprise relationship data includes the identifiers of both parties, the relationship direction, the relationship type, and the relationship validity period. Recommendation event data includes the identifier of the recommender, the identifier of the recommended enterprise, the recommendation entry identifier, and the recommendation initiation time. Conversion event data includes the identifier of the converting enterprise, the conversion event type, and the conversion event time. A source tag and time tag are written to each raw business record. Timestamps are used; source markers are taken from the source code of the business data source; timestamps are uniformly converted to timestamps with the same time zone and precision; when the original record has only low time precision, the original time precision flag is retained, and the missing time component is not inferred; according to the three data types of enterprise relationship, recommendation event, and conversion event, the original business records with completed source and timestamps are partitioned and stored to form business records to be collected; records with missing fields, missing subject identifiers, or abnormal time formats are written to the abnormal record area and do not enter the subsequent subject collection process; for example, if a batch of collection obtains several original business records, one of the conversion event records is missing an enterprise subject identifier, this record enters the abnormal record area, and the remaining records are formed into business records to be collected after format verification; The process involves format validation and standardization of enterprise entity identifiers in the business records to be aggregated, generating an enterprise entity index. Based on this index, business records pointing to the same enterprise are merged to generate enterprise master records. Specifically, the enterprise entity identifiers in the business records are standardized, including removing whitespace characters, standardizing character case, converting full-width characters, and deleting non-entity identifier separators. When the enterprise entity identifier uses the Unified Social Credit Code, validity validation is performed according to character length, character range, and checksum rules. When using internal customer numbers from the business system, the corresponding Unified Social Credit Code is associated with a pre-stored entity mapping table. This mapping table originates from customer master records in the enterprise customer information system that have already undergone identity verification. If a valid Unified Social Credit Code exists, it is used as the enterprise entity index. If the Unified Social Credit Code is missing but the internal customer number can be mapped to a valid entity identifier, the mapping result is used as the enterprise entity index. Business entity index; when a valid mapping relationship cannot be formed, the corresponding record is written to the entity verification area; based on the business entity index, business records pointing to the same enterprise are grouped into the same aggregation group; the enterprise name, business status, and source record identifier in the aggregation group are organized into master files: the valid registration name in the enterprise customer information system is used as the master file name, the names in other business systems are written into the source alias field, and the valid business status with the later effective time is written into the master file status field to generate enterprise master file records; the enterprise master file record is a data record formed by centrally associating records of the same enterprise in different business systems with the enterprise entity index as the unique primary key; for example, the same enterprise uses the full name, abbreviation, and organization name records in the enterprise customer information system, recommendation business system, and account registration system, but the three records carry the same entity identifier; after format validation and matching with the entity index, the three records are grouped into the same enterprise master file, and the name difference is retained in the source alias field; Enterprise node attributes are extracted from the enterprise master records. These attributes are then encoded and linked to generate enterprise nodes. Specifically, the enterprise entity index and business tenant identifier are sequentially concatenated and hashed to generate enterprise node identifiers. ,in, This serves as the tenant identifier for the current business environment. For enterprise entity index; symbol Indicates sequential concatenation of strings; This represents a deterministic hash encoding; the business tenant identifier originates from the system deployment configuration; the master name, subject index, business status, and source alias in the enterprise master record are converted into a unified field format and encapsulated with the enterprise node identifier to form an enterprise node; the time field uses the unified timestamp formed in step one, and the status field uses a preset status code; a node mapping relationship is established between the source record primary key and the enterprise node identifier, and the source system code and source record primary key corresponding to the enterprise master record are written into the node source mapping table; subsequent enterprise relationship records, recommendation event records, and conversion event records are located to the corresponding enterprise nodes through the node source mapping table; for example, the business records to be collected involve enterprise A, enterprise B, and enterprise C; after subject collection, three enterprise master records are formed, and three enterprise nodes are generated accordingly; when the same enterprise has different name formats, only one enterprise node is generated; The relationship data is extracted from enterprise relationship data, including the relationship subject field, relationship direction field, and relationship time field. The relationship subject field is matched to the corresponding enterprise node. Directional connections and time-based joins are then performed on the matched enterprise nodes to generate inter-enterprise business relationship edges. Specifically, the relationship initiator and recipient entities in the enterprise relationship data are matched with the enterprise subject index, and the corresponding enterprise node is located using the node source mapping table. If any relationship subject cannot be located, the corresponding enterprise relationship record is written to the relationship verification area. Directed connections are performed on the matched enterprise nodes based on the relationship direction in the enterprise relationship data. Supply relationships are established according to the supplier pointing to the purchaser; financial transaction relationships are established according to the payer pointing to the payee; when the source data only records undirected cooperative relationships, the relationship is marked as a bidirectional relationship. The relationship's effective and ineffective times are written to the validity period of the relationship edge. Time intervals; when the relationship expires at an empty time but is still valid, the end position of the valid time interval is marked as open; for relationship records with the same subject, type, and direction, a continuity check is performed on the time interval; when the start position of the later time interval does not exceed the sum of the end position of the previous time interval and the data time resolution, the two time intervals are merged; the data time resolution comes from the collection accuracy of enterprise relationship data and can be hourly or daily; relationship records that have completed subject matching, direction connection, and time attachment are coded with edge identifiers to form inter-enterprise business relationship edges; duplicate snapshot records with the same content are deduplicated according to edge identifiers; for example, if there are supply relationship snapshots with the same content and overlapping time intervals between enterprise A and enterprise B, after subject matching and interval continuity check, they are merged to form an inter-enterprise business relationship edge; The recommendation event data is used to extract the recommender subject, recommended subject, and recommendation time fields. The recommender subject and recommended subject fields are matched to their corresponding enterprise nodes. Recommendation links and time-based connections are then applied to the matched enterprise nodes to generate recommendation behavior edges. Specifically, the recommender subject and recommended enterprise subject in the recommendation event data are matched to their corresponding enterprise nodes. The recommender's corresponding enterprise node is used as the starting point of the recommendation behavior edge, and the recommended enterprise's corresponding enterprise node is used as the ending point. Integrity verification is performed on the recommendation entry identifier and the recommendation initiation time. The recommendation entry identifier is derived from the unique identifier assigned when the recommendation link, recommendation code, or business recommendation entry is generated. The recommendation initiation time uses the actual recorded time of the recommendation event in the recommendation business system. Recommendations without an entry identifier cannot be verified. Records with complete primary keys for recommended events are written to the recommendation verification area. When a global event primary key exists in the recommended event data, it is encoded as the recommendation behavior edge identifier. When no global event primary key exists, the recommender node identifier, the recommended enterprise node identifier, the recommendation entry identifier, and the recommendation initiation time are concatenated sequentially and hashed to form the recommendation behavior edge identifier. The recommendation initiation time and source marker are attached to the recommendation behavior edge. For duplicate records corresponding to the same recommendation behavior edge identifier, only one primary record is retained, and the remaining records are associated with the primary record as source copies. For example, if enterprise A initiates a recommendation to enterprise B through recommendation entry R1, with enterprise A node as the starting point and enterprise B node as the ending point, recommendation entry R1 and recommendation initiation time are written into the edge attribute to form a recommendation behavior edge from enterprise A to enterprise B. The conversion subject field and conversion time field are extracted from the conversion event data. The conversion subject field is matched to the corresponding enterprise node, and conversion event edges are generated by attaching conversion events to the matched enterprise nodes. Specifically, the conversion enterprise subject in the conversion event data is matched to the corresponding enterprise node. The conversion event types include account opening and registration events and first transaction events. The event type adopts the event code in the source business system and is not reclassified according to transaction amount or transaction name. The conversion event is attached to the corresponding enterprise node as a self-loop event edge. The start and end points of the self-loop event edge are both the enterprise node where the conversion occurred. The conversion event type, conversion event time, source tag, and source event primary key are written into the self-loop event edge. The conversion event edge identifier is formed according to the enterprise node identifier, conversion event type, and source event primary key. Duplicate records with the same source event primary key generate only one conversion event edge. Account opening and registration events and first transaction events formed by the same enterprise at different times generate independent conversion event edges. For example, if enterprise B has an account opening and registration event and a first transaction event, the two types of events form an account opening and registration self-loop edge and a first transaction self-loop edge attached to the enterprise B node, respectively, and the time order of the events is retained. The graph structure is written according to the subject correspondence and time sequence between enterprise nodes, inter-enterprise business relationship edges, recommendation behavior edges, and conversion event edges to generate the basic graph of the industry chain recommendation. Specifically, the graph structure is written in the order of enterprise nodes, inter-enterprise business relationship edges, recommendation behavior edges, and conversion event edges. Enterprise nodes are uniquely indexed with enterprise node identifiers, inter-enterprise business relationship edges are uniquely indexed with relationship edge identifiers, and recommendation behavior edges and conversion event edges are uniquely indexed with their corresponding event edge identifiers. The graph structure is written using batch transaction processing. Before submitting the graph structure, node uniqueness verification, edge endpoint existence verification, and time stamp integrity verification are performed. Node uniqueness verification is used to check whether duplicate nodes are generated for the same enterprise subject index. Edge endpoint existence verification is used to check whether the start and end points of relationship edges and recommendation behavior edges have been written. Graph structure; time stamp integrity check is used to check whether relationship edges and event edges have valid time stamps; if any check fails, the current batch will not be submitted, and the exception record will be written to the corresponding pending verification area; when all checks pass, the current graph version will be submitted, and the graph version identifier and batch identifier will be recorded; taking the example of company A recommending company B, the business relationship edge between company A and company B, the recommendation behavior edge from company A to company B, the account opening registration event edge corresponding to company B, and the first business event edge are all attached to a unified enterprise node; when nodes are directly established using company names, company B may form duplicate nodes due to different name formats, causing the recommendation behavior edge and conversion event edge to be separated; after using the enterprise entity index for aggregation, the recommendation behavior edge and conversion event edge are attached to the same enterprise node, forming a continuous graph structure of enterprise relationships, recommendation events, and conversion events.

[0025] The present invention is further configured such that forming candidate recommendation link records based on recommendation event data includes: The recommended event data undergoes event integrity verification, extracting the recommender entity, recommended enterprise entity, recommendation entry identifier, and recommendation initiation time to generate pending recommended events. Specifically, after a recommended event enters the event processing service, the existence of the event identifier, recommender entity identifier, recommended enterprise entity identifier, recommendation entry identifier, and recommendation initiation time is verified. This verification uses a mandatory field table, configured according to the recommendation business interface specifications. If any mandatory field is empty, the corresponding recommended event is written to the event verification area. Recommended events that pass the field existence verification undergo format verification. The recommender entity identifier and recommended enterprise entity identifier are standardized according to the enterprise entity identifier format. The recommendation entry identifier is verified according to the identifier length and character range configured in the recommendation business system. The recommendation initiation time is converted to a unified timestamp consistent with the industry chain recommendation basic graph. Duplicate event filtering is performed on the format-verified recommended events. The event identifier is used as the primary deduplication key. When an event identifier is missing or reused, the recommender entity identifier, recommended enterprise entity identifier, recommendation entry identifier, and recommendation initiation time are concatenated sequentially and hashed to form an event fingerprint. ,in, For event fingerprinting; The main identifier of the recommending party; The main identifier of the recommended enterprise; Recommended entry point identifier; The recommendation initiation time is used; when the same event fingerprint appears repeatedly in the interface retransmission window, the first record is retained, and subsequent records are marked as retransmission copies; the retransmission window is set according to the maximum automatic retry cycle of the recommendation business system, with a value range of 1 minute to 10 minutes, and 5 minutes in this embodiment; the recommended events that have passed field existence verification, format verification, and duplicate event filtering are written into the pending event area to generate pending recommended events; this process ensures that field missing events and interface retransmission events do not enter the candidate link construction process; The process involves matching the recommending entity and the recommended enterprise entity in the pending recommendation event to enterprise nodes in the industry chain recommendation basic graph, generating corresponding records for each recommendation node. Specifically, based on the recommending entity identifier in the pending recommendation event, the corresponding enterprise node identifier is retrieved from the enterprise entity index. The same retrieval is performed based on the recommended enterprise entity identifier, resulting in recommending node matching results and recommended enterprise node matching results. When an entity identifier and an enterprise node form a unique correspondence, the corresponding enterprise node identifier is written into the node matching result. If the entity identifier cannot match an enterprise node, the enterprise entity index corresponding to the customer number within the business system is retrieved based on the node source mapping table, and then the enterprise node is located using the enterprise entity index. If it still cannot be located, the corresponding pending recommendation event is written into the entity pending verification area. When an entity identifier corresponds to more than two enterprise nodes, verification is performed. Verify the subject index and validity status of the enterprise node, and only retain enterprise nodes with consistent subject indexes and valid status; if a unique node correspondence cannot be formed, no candidate recommendation link is established; associate the pending recommendation event identifier, recommender enterprise node identifier, recommended enterprise node identifier, and node matching status to generate a recommendation node corresponding record; the node matching status in the recommendation node corresponding record includes matching completed, recommender pending verification, and recommended enterprise pending verification, and only records with completed matching proceed to the next step; for example, the recommender in the recommendation event uses the internal customer number of the business system, and the recommended enterprise uses the unified social credit code; convert the internal customer number into an enterprise subject index through the node source mapping table, and then locate the two subjects to enterprise A node and enterprise B node respectively, forming a recommendation node corresponding record from enterprise A to enterprise B; The recommendation direction is organized for the records corresponding to the recommendation nodes. The recommender's corresponding enterprise node is used as the link start point, and the recommended enterprise's corresponding enterprise node is used as the link end point, generating a recommendation link direction record. Specifically, based on the recommendation node records, the recommender's enterprise node is set as the link start point, and the recommended enterprise node is set as the link end point, forming a unidirectional link from the recommender to the recommended enterprise. A same node verification is performed on the link start and end points. If the link start and end points are the same, the corresponding recommendation event is marked as a self-recommendation event and not written into the candidate recommendation link. If the link start and end points are different, the link direction is retained. A consistency check is performed between the recommendation direction and the role field in the original recommendation event. The link start point corresponding to the recommender's role... The recommended party's role corresponds to the endpoint of the link. When the role field is reversed, the initiating entity of the recommendation operation in the recommendation event is taken as the link start point, and the reverse configuration record is written to the source correction field. The link start point identifier, link end point identifier, recommendation direction, recommendation event identifier, and direction verification status are written to the recommendation link direction record. The recommendation direction in the recommendation link direction record is fixed as the link start point to the link end point, and the recommendation direction is not changed according to the inter-enterprise transaction direction. The inter-enterprise transaction direction is handled separately in the subsequent business acceptance path verification. For example, if enterprise A initiates a recommendation to enterprise B through the recommendation entry, enterprise A's node is set as the link start point, and enterprise B's node is set as the link end point, forming a recommendation link direction record from enterprise A to enterprise B. An initial link status record is established based on the recommendation link direction record, recommendation entry identifier, and recommendation initiation time, and this initial record is marked as "recommended". Specifically, based on the recommendation link direction record, the recommendation event identifier, link start point, link end point, recommendation entry identifier, and recommendation initiation time are written into the link status record. The link status code is set to "recommended", the status effective time is set to the recommendation initiation time, and the status sequence number is set to the initial sequence number. The link status code is derived from the recommendation link status table, which at least includes the following statuses: recommended, responded, opened, converted, and expired. The initial sequence number is 1, and subsequent recommendation entry triggering, account opening, and registration are recorded as 1. The registration and first business event are sequentially numbered in order of occurrence; the effective time of the status and the time of receiving the recommendation event are checked for order; if the recommendation initiation time is later than the event reception time and the time difference exceeds the allowable offset range of the interface, the event is written into the time verification area; the allowable offset range of the interface is set according to the clock synchronization accuracy of the recommendation business system and the event processing service, and the value range is from 1 second to 60 seconds, and 30 seconds is used in this embodiment; the link status record that passes the order check is marked as a valid initial status, and an initial link status record is generated; the initial link status record provides a unified status transition starting point for subsequent recommendation entry trigger events, account registration events and the first business event. The recommended node corresponding record, recommended link direction record, and link status initial record are encapsulated to generate candidate recommended link records. Specifically, the recommender enterprise node identifier and recommended enterprise node identifier in the recommended node corresponding record, the link start and link end point in the recommended link direction record, and the status code and status effective time in the link status initial record are mapped to corresponding fields. Candidate recommended link identifiers are generated based on the recommended event identifier. When the recommended event identifier cannot be used as a globally unique identifier, the candidate recommended link identifier is generated according to the following formula: ,in, Identifier for candidate recommendation links; Identifier of the starting node of the link; Identifier of the endpoint node of the link; Recommended entry point identifier; Recommended initiation time; This is used as an event fingerprint; when the same business event is processed repeatedly, the same candidate recommendation link identifier is generated to avoid duplicate candidate link creation; the candidate recommendation link identifier, recommending enterprise node identifier, recommended enterprise node identifier, recommendation entry identifier, recommendation initiation time, recommendation direction, and recommended status are encapsulated into a candidate recommendation link record; the candidate recommendation link record is written to the candidate link library, and a corresponding recommendation link index is created in the industry chain recommendation basic graph for parent link inheritance, business undertaking path retrieval, and conversion event backfilling; taking a batch of recommendation events as an example, the batch contains a valid event of enterprise A recommending enterprise B, an interface retransmission copy of the event, an abnormal event lacking the recommended enterprise main identifier, and a valid event of enterprise B recommending enterprise C; step one includes the retransmission copy into the... The source copy writes the missing field event to the event verification area, retaining two pending recommendation events; Step 2 matches Enterprise A, Enterprise B, and Enterprise C to their respective enterprise nodes; Step 3 forms two recommendation link direction records: Enterprise A to Enterprise B and Enterprise B to Enterprise C; Step 4 establishes a recommended status for each; Step 5 forms two candidate recommendation link records; When establishing links directly using unverified original recommendation events, the interface retransmission copy will form duplicate candidate links, and the missing field event will form a link record with an empty endpoint; After adopting this embodiment, the two valid recommendation events each form a unique candidate recommendation link, duplicate events and missing subject events do not enter the candidate link library, and the candidate recommendation link records form a stable correspondence with the enterprise nodes in the basic graph of the industry chain recommendation.

[0026] The present invention is further configured such that the candidate recommendation link record carries the parent link identifier, and the non-first-level recommendation inherits the identifier of the confirmed recommendation link of the previous level, including: Based on the recommender entity in the candidate recommendation link record, confirmed recommendation link records are retrieved to generate recommender link source records. Specifically, in the corporate fission recommendation scenario, the recommendation business system transmits candidate recommendation link records in real time through the recommendation event interface, and the link tracing service accesses the recommendation link library through the confirmed link query interface. The recommendation event interface uses an event-triggered transmission method. When the interface is interrupted, missing events are retrieved according to a replenishment cycle of 1 to 5 minutes, with the replenishment cycle based on the data delay configuration allowed by the recommendation business system, and does not participate in the parent link determination. The candidate recommendation link record must at least include the current recommender entity, the recommended enterprise entity, the recommendation initiation time, and the candidate recommendation link identifier. The confirmed recommendation link record must at least include the historical recommender entity, the historical recommended enterprise entity, the link identifier, the confirmation status, and the confirmation time. Using the current recommender entity as the link source retrieval object, records in the confirmed recommendation link record where the historical recommended enterprise entity is consistent with the current recommender entity are retrieved. This matching relationship limits the current recommender to those who have entered the recommendation system as recommended enterprises in historical recommendation links, avoiding incorrectly using other recommendation links previously initiated by the current recommender as parent sources. The candidate source set is represented as follows: ,in, Indicates the current recommending entity; Indicates the first One confirmed recommendation link record; This indicates the historical recommended enterprise entities in the confirmed recommendation link; the search results are deduplicated by link identifier; when duplicate records are formed due to interface retransmission with the same link identifier, only records with complete confirmation time and valid source event primary key are retained; for records with different link identifiers but the same source event primary key, the first write record is retained, and the remaining records are marked as source copies; the current recommender entity, candidate recommendation link identifier, historical recommended enterprise entities, confirmation status, and confirmation time are associated according to the link identifier to generate the recommender link source record; the "recommender link source record" refers to the data record that stores the historical recommendation links that the current recommender may inherit and their confirmation information, as the data basis for subsequent status verification and parent link inheritance; for example, if enterprise B initiates a recommendation to enterprise C, and a historical link of enterprise A recommending enterprise B exists in the confirmed recommendation link library, then this historical link is included in enterprise B's recommender link source record; links formed by enterprise B's previous recommendations of other enterprises are not included in this source record. The system verifies the confirmation status and time sequence of the referrer's link source records, retaining confirmed referral link records whose confirmation time is earlier than the current referral initiation time. Specifically, the system filters the confirmation status in the referrer's link source records for validity. The confirmed status is derived from the referral link status table, which is maintained by the link event handling process. In this embodiment, records whose affiliation is locked and whose link status has reached "account opened" or "converted" are considered confirmed referral links. Records in the "recommended," "responded," "pending verification," "invalid," or "affiliation conflict" states do not pass the confirmation status verification. After completing the confirmation status filtering, the historical link confirmation time and the current referral initiation time are converted to a unified time zone and a unified time precision. The time field prioritizes the actual occurrence time of the business event. When the actual occurrence time is missing, the business system confirmation time is used, and a time source mark is written. When the time precision of different data sources is inconsistent, the time is truncated and aligned according to the lower precision time unit, and the missing time component is not estimated. The time interval is calculated for each source record that passes the confirmation status verification. in, Indicates the time when the current recommendation was initiated; Indicates the first The confirmation time of the source record; Indicates the time interval between the parent link confirmation and the current recommendation initiation; when If the confirmation time is earlier than the current recommendation initiation time, the corresponding source record will be retained; when... If the recommended time sequence of confirmation before continuation is not met, the corresponding source record will be written into the time anomaly record; the time interval only serves to verify the order of events and is not used for link priority scoring; after confirmation status verification and time sequence verification, a valid bundle set is formed: ,in, This represents a set of confirmed statuses consisting of accounts that have been opened and those that have been converted. This set of statuses comes directly from the referral link status table and is not assigned any additional weight. The link identifier, confirmation time, and confirmation status that have passed verification are written into the valid referrer link source record, while the reason for failing verification is also recorded. This process ensures that the current referral only inherits historical links that were established before the current referral was initiated. If no confirmed recommendation link record is found that has passed both the confirmation status verification and time sequence verification, the candidate recommendation link record is marked as a first-level recommendation record, and the parent link identifier is set to empty; specifically, the number of independent link identifiers in the valid recommender link source records is counted: ,in, This indicates the number of valid parent links corresponding to the current recommender; when When a query result for a confirmed link is obtained, an integrity check is performed to verify that the query batch has ended, the link index version is consistent with the current batch, and the current recommender entity is not in a pending verification state. If the query fails or the index version is outdated, the candidate recommended link record is kept in the retry queue and is not directly marked at the hierarchical level. If the query result is complete and there is no valid parent link, the recommendation type field of the candidate recommended link record is written to the first-level recommendation flag, the parent link identifier field is set to null, and the original recommender entity, recommended enterprise entity, recommendation entry identifier, and recommendation method of the candidate recommended link are retained. Starting from the time, a first-level candidate recommendation link record is generated; a null parent link identifier indicates that the current candidate recommendation link has not inherited a historical recommendation link, and will be used as the starting position of the link in the subsequent fission level backtracking process; null values ​​are represented by a pre-set null reference in the link data structure, and the character "0" or any virtual link identifier is not used to avoid confusion with the real link identifier; for example, if company A initiates a recommendation to company B, and it has been confirmed that no valid historical link formed by company A as a recommended company has been found in the link database, then the candidate recommendation link from company A to company B is marked as a first-level recommendation record, and the parent link identifier remains null; When a confirmed recommended link record that has passed both the confirmation status verification and time sequence verification is retrieved, the corresponding confirmed recommended link identifier is written into the parent link identifier field of the candidate recommended link record, generating a non-first-level candidate recommended link record; specifically, when When inheriting a link, the unique link identifier in the valid recommender link source record is determined as the parent link identifier to be inherited. A referential integrity check is performed on the parent link identifier to be inherited to confirm that the corresponding confirmed recommender link still exists in the recommender link library, the confirmation status has not been revoked, and the historically recommended enterprise entity is consistent with the current recommender entity. After the referential integrity check passes, the parent link identifier to be inherited is written into the parent link identifier field of the current candidate recommender link record, and a parent-child correspondence is established between the parent link identifier and the current candidate recommender link identifier. ,in, Indicates the parent link identifier; Indicates the identifier of the current candidate recommendation link; This indicates the corresponding record for the parent-child link. The recommendation type field of the current candidate recommendation link is written to the non-first-level recommendation flag, and the corresponding record for the parent-child link is written to the link index, generating a non-first-level candidate recommendation link record. The fission level is not assigned a value in the current processing; it is determined uniformly by subsequent parent links through step-by-step backtracking. For example, company A recommends company B to form a link. After Company B completes the account registration, the link The process has been confirmed; Company B then recommends Company C to form a supply chain. The search results only contained links. If the confirmation status and time sequence conditions are met, then... Write The parent link identifier field forms The parent-child link relationship; after adopting this inheritance method, a continuous data correspondence is formed between Enterprise B as a historical recommended enterprise and the current recommender, and it can be traced back to the starting recommendation link corresponding to Enterprise A along the parent link identifier; When a parent link identifier cannot form a single correspondence, the candidate recommended link record is marked as a parent pending verification status. Specifically, when... When the link source record of the valid recommender is updated, the link identifier deduplication and source event consistency verification are performed again. If more than two different link identifiers still exist after deduplication, it is determined that the parent link corresponding to the current recommender cannot form a single correspondence. The different parent candidate link identifiers, corresponding confirmation status, confirmation time, and historical recommender entities are written into the parent conflict record. The parent conflict record is associated according to the current candidate recommendation link identifier, and evidence of the link causing the non-uniqueness of the parent source is saved. The parent link identifier field in the current candidate recommendation link record is kept empty, and automatic selection is not performed from two or more candidate parent links based on the earliest or most recent confirmation time. The link status is written into the parent pending verification status, the parent conflict record is written into the pending verification task queue, and the automatic hierarchical backtracking of the candidate recommendation link is paused. The parent pending verification status means that the current recommendation behavior has formed a candidate recommendation link, but the current recommender corresponds to two or more historical source links that meet the confirmation status and time order requirements. The data state has not yet formed a unique parent-pointing state; for example, Company B has two different link identifiers due to historical data migration, and both links record Company B as the recommended company, and both have reached the confirmation state, with the confirmation time being earlier than the initiation time of Company B's current recommendation of Company C; after deduplication, two valid source links are still retained, so the candidate recommendation link from Company B to Company C is marked as the parent pending verification state, and no parent link identifier is written; compared with the processing method of inheriting the parent link only according to the most recent historical record, this embodiment completes automatic inheritance when the parent source is unique, forms a first-level recommendation record when there is no valid source, and retains conflict evidence and suspends automatic inheritance when there is a real parent conflict; with the link example containing Company A, Company B and Company C for verification, a single valid parent source scenario can form continuous parent-child links; in the case of duplicate sources, only one parent identifier is retained after deduplication; when different parent sources are established at the same time, a parent pending verification state is generated, and no incorrect automatic hierarchical classification is formed.

[0027] The present invention is further configured such that the step of retrieving the business undertaking path corresponding to the candidate recommendation link record in the basic graph of the industry chain recommendation, verifying the validity and directional continuity of the business undertaking path at the time of recommendation initiation, and generating the recommendation link undertaking degree includes: The recommending entity and the recommended enterprise entity in the candidate recommendation link record are located to the corresponding enterprise nodes in the basic industry chain recommendation graph, generating the path retrieval start point and path retrieval end point. Specifically, in the corporate fission recommendation scenario, the link tracing service is deployed on the application server, and the basic industry chain recommendation graph is stored in the graph database. Enterprise relationship data is incrementally written to the graph database periodically through the enterprise relationship interface, with the update cycle consistent with the update frequency of the enterprise relationship data source, which can be set from 1 hour to 24 hours. Candidate recommendation link records are transmitted in real time through the recommendation event interface. The enterprise relationship update cycle only controls the graph version refresh and does not participate in the calculation of recommendation link continuity. When performing business continuity path retrieval on candidate recommendation link records, a non- The latest graph version, later than the recommendation initiation time, prevents newly added enterprise relationships after recommendation initiation from being applied inversely to the current recommendation chain; based on the recommender entity in the candidate recommendation chain record, locate the corresponding enterprise node in the enterprise entity index; perform the same location based on the recommended enterprise entity to form a correspondence between recommender nodes and recommended enterprise nodes; when the enterprise entity index and enterprise node form a unique correspondence, set the recommender node as the starting point of the path retrieval and the recommended enterprise node as the ending point of the path retrieval; if any entity cannot locate an enterprise node, or if the same entity corresponds to more than two valid enterprise nodes, stop the automatic path retrieval of the current chain, and write the node correspondence anomaly into the candidate recommendation chain record; let the recommender node be... The recommended enterprise nodes are Then the path retrieval endpoint is represented as: ,in, Indicates the first The path retrieval task corresponding to each candidate recommendation link; This indicates the time the recommendation was initiated. The path retrieval task saves the start point, end point, and recommendation initiation time as a unified data object for subsequent path expansion and time verification. For example, if company A initiates a recommendation to company B, and both company A and company B have formed unique enterprise nodes in the basic graph of the industry chain recommendation, then company A's node is set as the starting point of the path retrieval, and company B's node is set as the ending point of the path retrieval, thus generating the corresponding path retrieval task. Starting from the path retrieval origin and ending at the path retrieval destination, the path is expanded along the business relationship edges between enterprises in the basic industry chain recommendation graph. Candidate business acceptance paths are generated by sequentially recording the enterprise nodes and business relationship edges encountered. Specifically, starting from the path retrieval origin, a restricted breadth-first search method is used to expand layer by layer along the business relationship edges between enterprises. The restricted breadth-first search proceeds sequentially from the first-level nodes adjacent to the origin to the second-level nodes adjacent to the first-level nodes, until the path retrieval destination is reached or the maximum search level is reached. The maximum search level is the upper limit of the allowed tracking levels in the fission business configuration. For public recommendation services, this value is typically set to 2 to 3; in this embodiment, it is set to 3. This value is derived from the number of parent-child link layers allowed in the recommendation activity, ensuring that the retrieval range of the business acceptance path remains consistent with the subsequent fission level backtracking range. During the path expansion process, a current path node set is established. Once an expansion node already exists in the current path node set, the node is no longer added to the current path to avoid forming a circular path. Each expansion records the current enterprise node, the next enterprise node, the identifier of the business relationship edge between enterprises, the relationship direction, and the effective time interval of the relationship. When the expansion reaches the path retrieval endpoint, the sequence of enterprise nodes and the sequence of business relationship edges between enterprises are encapsulated into a candidate business acceptance path. ,in, Indicates the first Candidate business acceptance paths; Indicates the first in the path Inter-company business relationship boundary; Indicates the number of edges contained in the path and Candidate business connection paths refer to the sequence of enterprise relationships connecting recommender nodes and recommended enterprise nodes within a limited level. At this point, only the graph structure connection is completed, and it does not mean that the path has met the requirements of recommendation time and direction. For example, if there is a direct business relationship between enterprise A and enterprise B in the graph, and there is also an indirect business relationship consisting of enterprise A, enterprise C, and enterprise B, then a one-level candidate path and a two-level candidate path are formed. Relationship sequences that exceed the maximum retrieval level stop expanding and are not written into the candidate path set. The time of inter-enterprise business relationship edges in the candidate business undertaking paths is verified, and inter-enterprise business relationship edges that are in effect at the time of recommendation are retained, generating time-verified paths; specifically, the effective time verification is performed on the inter-enterprise business relationship edges in each candidate business undertaking path; each inter-enterprise business relationship edge carries the relationship's effective time. and relationship expiration time If the relationship is still valid and no expiration time has been recorded, the relationship expiration time is considered the open end time; The timeliness status of an inter-enterprise business relationship edge at the time of recommendation initiation is represented as follows: ,in, For the timeliness verification results of the relationship edge; The recommendation initiation time is recorded in the candidate recommendation link record; the time field uniformly adopts the time precision in the industry chain recommendation basic graph; when the enterprise relationship data only has daily precision, the comparison is performed using the natural day boundary; when it has hourly precision, the comparison is performed using the hourly boundary, and time information with lower precision than the data source is not supplemented; all relationship edges of a candidate business undertaking path satisfy the following conditions. When this happens, the path is added to the timeliness verification path set; if any relation edge satisfies... When this happens, the path is written to the temporary storage area for accepting abnormal paths, and the identifier of the failed relationship edge and the reason for the failure are recorded; the path timeliness verification result is expressed as: ,when When, the candidate path is continuously valid when the recommendation is initiated; when At that time, there are business relationships in the candidate path that have not yet taken effect or have expired; for example, if company A is connected to company B through company C, the business relationship from company A to company C is valid when the recommendation is initiated, but the business relationship from company C to company B has expired. In this case, the two-layer path will not be included in the timeliness verification path set. By verifying each side of the entire path, it is possible to avoid the continued use of historically expired paths caused by only checking the starting point or ending point relationship. The process involves directional verification of business relationship edges between enterprises in the timeliness verification path. A directional verification path is generated by continuously matching the directional order of the business relationship edges with the link direction from the recommender to the recommended enterprise. Specifically, directional matching processing is performed on the business relationship edges between enterprises in the timeliness verification path. The starting and ending points of each relationship edge are stored in the basic graph of the industry chain recommendation. Supply relationships are recorded according to the supplier pointing to the buyer, and financial transaction relationships are recorded according to the payer pointing to the payee. Two-way cooperation relationships confirmed by the source system are marked with two-way tags. Adjacent enterprise nodes in the path are also included. and When the direction of the relation edge is from point to If the relation edge has a bidirectional label, then the relation edge is determined as a direction match; the direction of the relation edge is determined by... point to If there is no bidirectional label, the relation edge is determined to be a direction mismatch; the relation edge direction matching result is expressed as: The continuous directional state of the entire path is represented as: ,when When the relationship direction in the path can continuously reach the recommended enterprise node from the recommender node, the path is written into the direction verification path set; when When this happens, the path is written to the temporary storage area for abnormal paths, and the position of the first directional interruption is recorded. Directional continuity means that the directions of business relationship edges are connected continuously according to the order of path nodes. If any relationship edge is reversed, the connection of the path will be interrupted. Using edge-by-edge directional verification can eliminate paths that are connected in the graph structure and whose business flow is opposite to the recommendation direction. For example, if company A makes a recommendation to company B, and the two relationship edges from company A to company C and from company C to company B are both set along the recommendation direction, the path passes the directional verification. If the second relationship edge is only from company B to company C, the path is marked as a directional abnormal path. The directional verification paths undergo path-level verification. Paths that meet the fission level restrictions are identified as valid business acceptance paths, while candidate business acceptance paths that do not meet the time verification, directional verification, or path-level verification are marked as abnormal acceptance paths. Specifically, the number of inter-enterprise business relationship edges in the directional verification path is counted, and the edge count is used as the path level. The path hierarchy represents the number of business relationship segments traversed between the recommender node and the recommended enterprise node, and is stored separately from the fission hierarchy of the candidate recommendation link; the path hierarchy verification rules are expressed as follows: Candidate business acceptance paths that simultaneously meet the requirements of time validity, directional continuity, and hierarchical constraints are added to the set of valid business acceptance paths: Candidate service acceptance paths that fail any verification condition are added to the acceptance exception path set: ,in, This represents the set of candidate service acceptance paths; each abnormal acceptance path is written with an exception reason code: invalid time is denoted as Directional interruption is denoted as The path super-level is denoted as When two types of anomalies exist on the same path, the corresponding reason codes are retained simultaneously; when the set of valid business acceptance paths is empty, the current candidate recommended link is marked as having no valid acceptance path, and it will not be considered as a link with acceptance qualifications in the subsequent fission attribution locking process; when the set of valid business acceptance paths is not empty, the acceptance degree generation process is entered. Based on valid business acceptance paths and abnormal acceptance paths, acceptance path verification records are generated. These verification records are then mapped to acceptance levels to generate the acceptance degree of the corresponding candidate recommendation link records. Specifically, the candidate business acceptance path identifier, path level, time verification result, direction verification result, level verification result, and abnormal reason code are merged according to the candidate recommendation link identifier to generate acceptance path verification records. Each acceptance path verification record is a data record that stores all candidate paths and verification results under the current candidate recommendation link. Its content includes the set of valid business acceptance paths. , collection of abnormal paths And the hierarchy of each path; perform normalized acceptance calculation on the acceptance path verification records; considering that shorter paths have more direct business connections, the path contribution of each candidate business acceptance path is set as the reciprocal of its path hierarchy: This calculation does not incorporate manual weights; the path hierarchy is directly derived from the number of inter-enterprise business relationship edges contained in the graph path. When not empty, the recommended link capacity is calculated as follows: ,when When empty, ,in, Indicates the first The recommendation link connectivity of each candidate recommendation link, with a value range of [value range missing]. The reciprocal of the level of the effective path is entered into the numerator, and the reciprocal of the level of all candidate paths is entered into the denominator; 0 is used when there are no candidate paths; the acceptance level adopts an interval mapping method without additional thresholds. The time marker is marked as complete acceptance, indicating that all retrieved candidate paths have passed verification; The time marker is marked as partial continuation, indicating that both valid and abnormal paths exist simultaneously; The time marker is set to "No Connection," indicating that no path has passed all verifications. The connection level and recommendation link connection degree are written to the corresponding candidate recommendation link record. An example of path verification is given: three candidate paths are formed from the recommender node to the recommended enterprise node. One first-level path passes all verifications, one second-level path passes all verifications, and one second-level path is marked as an abnormal path due to a break in the relationship direction. Then: The corresponding candidate recommendation link is marked as partially accepted; if only the processing method of "passing if any business path exists" is adopted, the candidate link will be directly identified as fully valid, and abnormal paths will not be reflected in the results; after the edge-by-edge verification and normalized acceptance calculation of this embodiment, both valid paths and abnormal paths are included in the acceptance path verification record. The acceptance degree of the recommended link retains the effective proportion of the path and the path level difference, and can subsequently participate in the fission affiliation locking together with the conversion backfill matching degree.

[0028] The present invention is further configured such that updating the candidate recommendation link status based on the link event triggered by the recommendation entry to the occurrence of the first service includes: Based on the recommendation entry identifier in the candidate recommendation link record, the recommendation entry trigger event is matched with the candidate recommendation link record for entry mapping. The matched recommendation entry trigger event is then matched with the recommended enterprise entity and its time sequence is verified to generate a link response record. Specifically, in the corporate fission recommendation scenario, the recommendation business system forms candidate recommendation link records, and the recommendation entry service collects recommendation entry trigger events generated by recommendation link access, recommendation code verification, or recommendation page entry. The link tracing server receives both types of data. Recommendation entry trigger events are transmitted in real-time via a message interface. If the interface is interrupted, data is collected again at a cycle of 1 to 5 minutes, with the collection cycle determined by the event processing delay allowed by the recommendation entry service. The candidate recommendation link record includes the candidate recommendation link identifier, recommendation entry identifier, and... The system includes the recommending entity, the recommended enterprise entity, the recommendation initiation time, and the link status (initial link status: recommended). The recommendation entry trigger event includes a trigger event identifier, a recommendation entry identifier, the accessing enterprise entity, the entry trigger time, and the event source identifier. The system performs event identifier deduplication, enterprise entity identifier consistency, and time correction on the recommendation entry trigger event. Event identifier deduplication uses the trigger event primary key assigned by the recommendation entry service; only the first received record is retained for identical primary keys. Enterprise entity identifier consistency uses the enterprise entity index in the industry chain recommendation basic graph. Time correction uses the clock offset between the recommendation entry service and the link tracing server, obtained from the system time synchronization log, with an allowable range of 1 to 60 seconds based on the clock synchronization accuracy of the deployment environment. The candidate recommendation link record is set as follows: The corresponding recommended entry point is identified as follows: The recommended enterprise is Recommended launch time is The recommended entry trigger event is The corresponding recommended entry point is identified as follows: The entity accessing the enterprise is The corrected entry trigger time is The entry point corresponds to the following result: Validate the execution time sequence of the recommended entry point trigger events for entries with a result of 1: ,when At that time, the entry trigger event is checked for time sequence; when When, mark it as an event triggered before the recommendation is initiated; when When this occurs, it is marked as a triggered event that has exceeded the validity period of the recommended entry point; The validity period of the recommendation entry point is derived from the validity period of the recommendation link or code in the recommendation activity configuration, and can be set to 1 to 30 days. This parameter limits the time range within which the recommendation entry point trigger event can accept candidate recommendation links, and does not participate in the weighted calculation of subsequent acceptance or attribution values. When there are more than two trigger events that pass the entry point correspondence and time sequence verification, they are arranged in ascending order of entry point trigger time, and the earliest trigger event is determined as the link response event. The remaining trigger events are attached to the same candidate recommendation link as duplicate access records. The candidate recommendation link identifier, link response event identifier, recommended enterprise entity, recommendation entry point identifier, recommendation initiation time, and recommendation entry point trigger time are matched and written into the link response record, and the candidate recommendation link status is updated from recommended to responded. For example, if the validity period of the recommendation entry point of a candidate recommendation link is set to 7 days, and the recommended enterprise enters the business page through the corresponding recommendation entry point 2 hours after the recommendation is initiated, then: 0 < 2 hours < 7 days. This recommendation entry point trigger event passes the entry point correspondence and time sequence verification and forms a link response record. The trigger event formed by another entity using the same entry point is not written into the candidate recommendation link because the enterprise entities are different. Based on the recommended enterprise entity and the trigger time of the recommendation entry in the link response record, the account opening registration event and the candidate recommendation link record are processed for account opening acceptance. The account opening registration event undergoes entity consistency verification, account opening sequence verification, and account opening status acceptance verification to generate the link account opening record. Specifically, the account opening registration system transmits the account opening result through the account opening registration event interface. The account opening registration event interface uses an event-triggered transmission method. When the event interface only provides batch data, it acquires data incrementally at a cycle of 5 to 30 minutes, with the collection cycle derived from the data refresh cycle of the account opening registration system. The account opening registration event includes an account opening event identifier, the account opening enterprise entity, the account identifier, the account opening registration time, and the account opening result status. The event opening registration event is processed by deduplicating the event identifier, unifying the enterprise entity identifier, and filtering the account opening result. Events with an account opening result status of "account opening completed and account status valid" enter the account opening acceptance processing. Events such as account opening application submission, document return, or account opening cancellation are saved as process records and do not trigger link status updates. Let the recommended enterprise entity corresponding to the link response record be... The recommended entry trigger time is The corporate entity corresponding to the account opening and registration event is... The account opening and registration time is The subject consistency result is represented as: For account opening registration events with a subject consistency result of 1, perform an account opening sequence check: ;when At that time, the account opening and registration events are verified by the order in which they occur; The observation period for account opening acceptance is derived from the business cycle from historical referral events to account opening and registration completion events of similar corporate clients, or from the account opening confirmation period configured in the referral activity. The value range can be set to 7 to 180 days. Specifically, the value can be a preset percentile position from the referral entry trigger to the account opening and registration completion cycle in the historical valid samples, avoiding expanding the observation range due to a few abnormal long-cycle records. Account opening status acceptance verification is performed according to the progressive relationship of the candidate referral link's status. When the candidate referral link status is "responded," the account opening and registration event is allowed to trigger the state transition from "responded" to "account opened." When the candidate referral link is still in the "recommended" state, the account opening and registration event is temporarily stored in the account opening pending acceptance area, and acceptance verification is re-executed after a link response record is formed. If the candidate referral link is already in the "account opened" or "converted" state, the status update is not triggered repeatedly. Within the same referral enterprise, during the account opening acceptance observation period... When there are two or more valid account opening and registration events, the earliest completed valid account opening and registration event is identified as the link account opening and registration event, and the remaining account opening events are linked as supplementary account opening records. This avoids the same candidate recommendation link from repeatedly entering the account-opened state due to the opening of multiple accounts. The candidate recommendation link identifier, link response event identifier, account opening event identifier, recommended enterprise entity, recommendation entry trigger time, account opening and registration time, and account opening result status are mapped to form a link account opening record. For example, if the recommended enterprise completes account opening and registration 12 days after the recommendation entry is triggered, and the account opening acceptance observation period is set to 90 days, then: 0 < 12 days < 90 days. If the enterprise entity is consistent and the candidate recommendation link status is "responded", the account opening and registration event is written into the link account opening record. Historical account opening and registration events that existed before the recommendation entry was triggered are not accepted into the current candidate recommendation link because the time sequence is not valid. Based on the recommended enterprise entity and account registration time in the link account opening record, the first business event is converted and connected with the candidate recommended link record. The first business event undergoes entity consistency verification, business occurrence sequence verification, and conversion status connection verification to generate a link conversion record. Specifically, the business transaction system transmits the processing results of settlement, credit, bill, or supply chain business through the business event interface. Business events are transmitted in real-time after transaction completion; if real-time transmission is not possible, incremental collection is performed at intervals of 5 to 60 minutes, with the collection cycle derived from the settlement confirmation frequency of the business transaction system. The first business event includes a business event identifier, the business enterprise entity... The system includes the business entity, business type, business occurrence time, and business validity status; it performs event identifier deduplication, event cancellation exclusion, and enterprise entity identifier consistency for business events; events with a business status of "completed" or "effective" enter the conversion and acceptance processing; events that have been cancelled, reversed, or failed to process are written to the invalid business event area; the first business event refers to the earliest valid business event that occurs within the first business observation period after the recommended enterprise completes account registration; the business type range of the first business is configured by the business catalog corresponding to the current recommendation activity; ordinary queries or non-business operations not listed in the business catalog are not included in the first business event; let the recommended enterprise entity corresponding to the link account opening record be... The account opening and registration time is The business entity corresponding to the business event is The business occurred at the time of The subject consistency result is represented as: Perform a business occurrence sequence check on business events with a subject consistency result of 1: ;when At this time, the business event enters the conversion state for verification; The observation period for the first transaction is derived from the historical period from account opening to the first actual transaction for different business types, and can be set to 30 to 365 days. Settlement-type transactions can use a shorter observation period, while credit-type or supply chain finance transactions can use a longer observation period. The specific value is configured according to the historical processing period corresponding to the business catalog. When the candidate recommendation link status is "account opened," a valid first transaction event is allowed to trigger the transition from "account opened" to "converted." When the candidate recommendation link has not yet formed a link account opening record, the business event is written to the conversion pending acceptance area. When the candidate recommendation link is already in the "converted" state, subsequent business events are attached as continuous business records, and the first business event is not duplicated. There must be two or more transactions that satisfy the requirements of entity consistency and business validity. When business events are subject to sexual and temporal continuity conditions, they are sorted by occurrence time, and the earliest valid business event is identified as the first business event. A link conversion record is formed by mapping the candidate recommendation link identifier, link account opening record identifier, first business event identifier, recommended enterprise entity, account opening / registration time, business occurrence time, and business validity status. For example, if the recommended enterprise has its first valid settlement transaction 23 days after account opening / registration, and the observation period for the first transaction is set to 180 days, then: 0 < 23 days < 180 days. This business event is verified for entity consistency, business occurrence order, and conversion status, and then written into the link conversion record. Existing business events that occurred before account opening / registration are not included in the current candidate recommendation link. Following the generation order of link response records, link account opening records, and link conversion records, the link status in the candidate recommendation link records is progressively updated to generate link status change records. Specifically, a candidate recommendation link status sequence is established: ,in, This indicates that it has been recommended. This indicates that a response has been received. This indicates that an account has been opened. This indicates that the transformation has occurred; each state corresponds to a unique state number, and the state numbers are as follows: , , and The link response records, link account opening records, and link conversion records are arranged in ascending order of event occurrence time to form a link event sequence: ,in, Indicates a link response event. This refers to an account opening and registration event. This indicates the first business event; the event time should meet the following requirements: ,in, To recommend the launch time, The recommended entry trigger time, For account registration time, The time of the first transaction; the link status is updated progressively according to the following rules: Status updates are only allowed to move from a lower status sequence number to an adjacent higher status sequence number; when the first business event is received but the link account opening record is missing, it is not directly updated from "responded" to "converted"; when the account registration event is received but the link response record is missing, it is not directly updated from "recommended" to "account opened"; temporary events will be re-executed for sequence verification and status acceptance verification after the preceding records are completed; each time the status changes, the candidate recommendation link identifier, the status before the change, the status after the change, the trigger event identifier, the status effective time, and the verification result are written into a status change detail; the status change details are sorted according to the status effective time to form a link status change record, and the latest valid status is written back to the candidate recommendation link record; taking the candidate recommendation link of enterprise A recommending enterprise B as an example, the validity period of the recommendation entry is set to 7 days, the account opening acceptance observation period is set to 90 days, and the first business observation period is set to 180 days; enterprise B triggers the recommendation entry 2 hours after the recommendation is initiated, completes the account opening registration 12 days after the entry is triggered, and the first valid business occurs 23 days after the account opening registration, then the link status is formed in sequence: recommended. Response received Account opened The data has been transformed; the same data batch also includes a duplicate entry trigger event, an account opening / registration event that occurred before the recommendation was initiated, and a reversed business event; the duplicate entry trigger event is saved as a source copy after being deduplicated by the event identifier; the account opening / registration event before the recommendation was initiated failed the time sequence verification; the reversed business event failed the business validity status screening; ultimately only three consecutive valid events enter the link status change record; if the latest business event is directly used to cover the candidate recommendation link status, historical account opening / registration events or reversed business events may cause the status to be updated out of order; after adopting the above subject correspondence, time succession, and adjacent status transfer processing, each status change has a preceding link record and trigger event, and the link status change record completely saves the event sequence from the recommendation to the occurrence of the first business.

[0029] The present invention is further configured such that the conversion events of the same enterprise that meet the conditions of status and time continuity are backfilled into the candidate recommendation link record, and the conversion backfill matching degree is generated, including: Based on the recommended enterprise entity in the link status change record, conversion events with the same entity in the conversion event data are grouped into the candidate recommendation link record to generate a set of conversion events with the same entity. Specifically, the link status change record stores the candidate recommendation link identifier, the recommended enterprise entity identifier, the recommendation initiation time, the recommendation entry trigger time, the account opening / registration time, and the link status. The account opening / registration interface and the business transaction interface transmit account opening / registration events and business events respectively. When the interface supports real-time transmission, it uses event-triggered collection; when using batch synchronization, it performs incremental collection according to the data refresh cycle of the source system. The conversion events are processed for event identifier deduplication, event status filtering, and enterprise entity identifier consistency. Only one valid record is retained for the same event identifier. Events that are cancelled, reversed, or fail to process are recorded in the invalid event record; the enterprise entity identifier in the conversion event is mapped to the enterprise entity index in the basic graph of the industry chain recommendation, and then compared item by item with the recommended enterprise entity index in the candidate recommendation link record; when the enterprise entity index is consistent, the corresponding conversion event is assigned to the candidate recommendation link; when the enterprise entity index is inconsistent, no association is established between the conversion event and the candidate recommendation link; the account opening registration event and the first business event assigned to the same candidate recommendation link are arranged according to the event occurrence time to form a set of conversion events of the same entity; the set of conversion events of the same entity refers to the set of conversion events that have passed the enterprise entity consistency verification and are yet to undergo status and time inheritance verification. Based on the link status in the link status change record, the set of conversion events for the same entity is filtered for status acceptance. Conversion events that meet the progressive relationship from "responded" to "account opened" and from "account opened" to "converted" are identified as conversion events to be backfilled. Specifically, a status transition relationship is established between link status and conversion event type. When a candidate recommended link is in the "responded" state, account opening / registration events are allowed to enter the backfilling range. When a candidate recommended link is in the "account opened" state, the first business event is allowed to enter the backfilling range. When a candidate recommended link is in the "recommended" state, account opening / registration events are not accepted. When a candidate recommended link has not formed an account opening / registration record, the first business event is not directly accepted. For conversions of the same entity... For each event in the event set, based on the event occurrence time, the last effective link state before the event occurred is found in the link state change record. Then, the link state is matched with the preceding state required by the event type. If the preceding state is consistent, the corresponding event is identified as a conversion event to be backfilled. If the preceding state is inconsistent, the abnormal state acceptance is recorded according to the reasons for missing preceding state, state skipping, or link completion. When the first business event is transmitted to the link tracing database before the account opening and registration event, the first business event is temporarily stored in the conversion waiting area. After the account opening and registration event is backfilled and the candidate recommended link is updated to the account opening status, the state acceptance screening is re-executed for the temporarily stored first business event. Based on the recommendation initiation time, recommendation entry trigger time, account registration time, and pending conversion event time in the link status change record, a time continuity verification is performed on the pending conversion events to generate a conversion time continuity record. Specifically, the account registration event uses the recommendation entry trigger time as the time continuity starting point, and the first business event uses the account registration time as the time continuity starting point. The occurrence time of the pending conversion events is compared sequentially with the corresponding time continuity starting point. If the occurrence time of the account registration event is not earlier than the recommendation entry trigger time, and the time interval between the two does not exceed the account registration continuity observation period, the account registration event is determined to meet the time continuity condition. If the occurrence time of the first business event is not earlier than the account registration time, and the time interval between the two does not exceed the first business event's observation period, the first business event is determined to meet the time continuity condition. Business events must meet the time continuity conditions; the account opening observation period is set according to the period distribution from the recommended entry trigger to the completion of account registration in the historical valid links, with a value range of 7 to 180 days; the first business observation period is set according to the period distribution from account registration to the first business transaction, with a value range of 30 to 365 days; when historical samples are insufficient, the business confirmation period configured by the recommended activity is used; the observation period only limits the time range in which the event can be backfilled and does not participate in the weighting of subsequent attribution results; the event type, time continuity start point, event occurrence time, applicable observation period, and verification result are written into the conversion time continuity record; when there are more than two events of the same type that meet the time continuity conditions, the record with the earliest occurrence time and valid event status is determined as the main backfill event, and other records are saved as supplementary events; Conversion events awaiting backfilling that pass subject attribution verification, status continuity filtering, and time continuity verification will be written into the candidate recommendation link record to generate conversion event backfilling records. Specifically, the subject attribution result, status continuity result, and time continuity result of the conversion events awaiting backfilling will be verified sequentially. If all three verifications are true, the corresponding conversion event will be written into the candidate recommendation link record. If any verification fails, automatic backfilling will not be performed, and the failed verification item will be recorded. After the account opening and registration event passes verification, the account opening event identifier and account opening and registration time will be written into the candidate recommendation link record, and the link status will be updated from "responded" to "completed". Account opening; after the first business event passes verification, the business event identifier and the business occurrence time are written into the candidate recommendation link record, and the link status is updated from "account opened" to "converted"; each backfill records the candidate recommendation link identifier, the recommended enterprise entity, the conversion event identifier, the conversion event type, the link status before backfill, the link status after backfill, and three verification results, generating a conversion event backfill record; the status effective time is the actual occurrence time of the conversion event; the entity attribution verification results, status continuity screening results, and time continuity verification results in the conversion event backfill record are merged and their completeness is checked. Verification and conflict checks generate backfill availability records. Specifically, backfill records for conversion events corresponding to the same candidate recommendation link are sorted according to the event occurrence time, with the account opening / registration event placed before the first business event, forming a backfill verification sequence. The backfill verification sequence undergoes integrity verification. When only an account opening / registration event exists, the recommendation entry trigger time is verified to be earlier than or equal to the account opening / registration time. When both an account opening / registration event and the first business event exist simultaneously, the account opening / registration time is further verified to be earlier than or equal to the first business event time. The backfill verification sequence undergoes conflict verification, including cases where the same conversion event is duplicated. If there are duplicate backfills, two main backfill events of the same event type, the first business event lacks an account opening / registration event, or the corresponding entity of a conversion event is inconsistent with the enterprise master file; and the entity, status, and time verifications are all valid, the event sequence is complete, and there are no conflicts, the backfill availability status is recorded as fully available; if only the account opening / registration event has been validly backfilled and the first business has not yet occurred, it is recorded as partially available; if there are duplicate events, sequence conflicts, or entity conflicts, it is recorded as conflict pending verification; if no valid backfill event is formed, it is recorded as unavailable; the backfill availability status, valid backfill events, and conflict reasons are written into the backfill availability record; Based on the availability of backfill records, candidate recommendation link records are matched and tagged to generate the corresponding conversion backfill matching degree. Specifically, the completion status of backfill availability records is verified according to the account opening / registration stage and the first transaction stage that the conversion event should complete. When both stages generate valid backfill records and there are no outstanding conflicts, the conversion backfill matching degree is recorded as a complete match. When only the account opening / registration stage generates valid backfill records and there are no conflicts, the conversion backfill matching degree is recorded as a partial match. When no valid backfill records are generated or there are outstanding conflicts, the conversion backfill matching degree is recorded as a no match. When numerical values ​​are needed for subsequent fission attribution locking, a complete match can be mapped to 1, a partial match can be mapped to 0.5 according to the proportion of one completed valid stage and expected to include two stages, and a no match can be mapped to 0. This mapping is based on the actual number of completed valid conversion stages and does not involve manual intervention. Weighting; Taking the candidate recommendation link formed by Company A recommending Company B as an example, the conversion event data includes Company B's valid account opening and registration events, valid first business events, duplicate account opening and registration events, and business events of other companies; after subject attribution processing, events of other companies are excluded, and after event deduplication, duplicate account opening records are excluded; valid account opening and registration events satisfy the status continuity relationship from "responded to account opened", and valid first business events satisfy the status continuity relationship from "account opened" to "converted". Both types of events are within their corresponding observation periods and are in continuous time order; therefore, the backfill availability status is fully available, and the conversion backfill matching degree is fully matched, which is recorded as 1 when using numerical recording; when another candidate recommendation link has only completed valid account opening and registration and has not yet formed the first business event, the backfill availability status is partially available, and the conversion backfill matching degree is partially matched, which is recorded as 0.5 when using numerical recording; this can distinguish whether the event backfill is valid and whether the conversion stage is complete.

[0030] The present invention is further configured such that, when the same recommended enterprise corresponds to two or more candidate recommendation link records, generating a fission attribution lock value based on the recommendation link connectivity and conversion backfill matching degree includes: For candidate recommendation link records corresponding to the same recommended enterprise, a set of conflicting links is generated by grouping them together under the same subject. Specifically, the link attribution processing service is set up on the recommendation business server and connected to the candidate recommendation link library, enterprise master database, acceptance path verification library, and conversion event backfilling library. When the status of the candidate recommendation link, the acceptance degree of the recommendation link, or the conversion backfilling matching degree changes, the attribution processing is triggered by the message interface. When the message interface is interrupted, unprocessed records are scanned at a cycle of 1 to 5 minutes, with the scanning cycle adopting the attribution processing delay allowed by the link tracing system. The input objects for attribution processing include candidate recommendation link identifier, recommender subject, recommended enterprise subject, recommendation initiation time, recommendation link acceptance degree, conversion backfilling matching degree, parent link identifier, and link status. The recommended enterprise subject identifier is standardized in format and mapped to the enterprise subject index, and candidate recommendation links that point to the same enterprise but have different name formats, business system customer numbers, or organization numbers are grouped into the same enterprise subject index. Uniqueness verification is performed on candidate recommendation link identifiers. When duplicate records are generated due to interface retransmission of the same link identifier, only the record with the newest link status version is retained. The enterprise entity index is used as the grouping key to count the number of candidate recommendation link records in each group. When there is only one candidate recommendation link, no attribution conflict is formed. When there are two or more candidate recommendation links, the corresponding records are sorted according to the recommendation initiation time to generate an attribution conflict link set. The attribution conflict link set refers to the set of candidate recommendation links that correspond to two or more candidate recommendation links whose valid attribution relationship is yet to be determined for the same recommended enterprise. This set stores the candidate link identifier, recommender entity, receiving verification result, backfilling verification result, and parent link information to avoid cross-enterprise candidate links entering the same attribution judgment process. For example, enterprise D forms three candidate recommendation links through enterprises A, B, and C respectively. The recommended enterprise entities in the three records are all mapped to the enterprise entity index corresponding to enterprise D. After aggregation, an attribution conflict link set containing the three candidate links is formed. Based on the acceptance degree of the candidate recommended link records in the home conflict link set, acceptance qualification records are generated by screening the candidate recommended link records for acceptance eligibility. Specifically, the acceptance degree, acceptance level, number of valid business acceptance paths, and reasons for acceptance anomalies of each candidate recommended link in the home conflict link set are obtained from the acceptance path verification database. Acceptance eligibility is screened according to the formation criteria of the recommended link acceptance degree. If a candidate recommended link has at least one valid business acceptance path that passes time verification, direction verification, and path level verification simultaneously, and the acceptance degree of the recommended link is marked as fully accepted or partially accepted, the acceptance qualification is recorded as established. If no business acceptance path is found, or if all candidate paths are marked as invalid in time, interrupted in direction, or exceeded in level, the acceptance qualification is recorded as not established. The acceptance degree of the recommended link is stored in numerical form. When the acceptance rate is greater than 0, it indicates that there is at least one valid business acceptance path, and the path can be included in the acceptance qualification range; the acceptance rate equal to 0 indicates that there is no valid business acceptance path. This boundary directly corresponds to whether a valid path exists, and no additional empirical threshold is set. The candidate recommended link identifier, recommended link acceptance rate, number of valid paths, number of abnormal paths, acceptance qualification, and reason for failure are written into the acceptance qualification record. The acceptance qualification record is used to save whether the candidate recommended link has business relationship support and its verification basis. For example, the first candidate link has one directly valid business relationship path, and the acceptance level is full acceptance; the second candidate link has one valid path and one directional abnormal path, and the acceptance level is partial acceptance; the business relationships of the third candidate link all expired before the recommendation was initiated; the acceptance qualification of the first two links is established, and the acceptance qualification of the third link is not established. Based on the acceptance qualification record and conversion feedback matching degree, feedback qualification records are generated for candidate recommendation link records that have passed the acceptance qualification screening. Specifically, only for candidate recommendation links with established acceptance qualifications, conversion feedback matching degree, feedback availability status, valid account opening and registration records, valid first transaction records, and feedback conflict reasons are obtained. Feedback qualification corresponds to the current conversion stage of the candidate recommendation link. When the candidate recommendation link is in the converted state, valid feedback records are required in both the account opening and registration stages and the first transaction stage, and the conversion feedback matching degree reaches a complete match. When the candidate recommendation link is in the account opening state, valid feedback records are required in the account opening and registration stage, and the conversion feedback matching degree reaches a partial match or a complete match. When the candidate recommendation link is only in the recommended or responded state, and no feedback event supporting conversion attribution has been formed, feedback qualification is not available. If there are subject mapping conflicts, status overstepping, abnormal time sequence, duplicate backfilling of the same conversion event, or two main backfilling events in the same stage, the backfilling qualification will still be recorded as invalid, and the corresponding conflict reason will be written into the record. The candidate recommendation link identifier, current link status, conversion backfilling matching degree, effective backfilling stage, backfilling availability status, backfilling qualification, and conflict reason will be written into the backfilling qualification record. For example, if the first candidate link has formed a valid account opening and registration record and a valid first business record, and the backfilling status is fully available, the backfilling qualification is established; if the second candidate link has only formed a valid account opening and registration record, and the current link status is account opened, and the backfilling status is partially available, the backfilling qualification is established; if the first business event of the third candidate link is earlier than the account opening and registration event, there is a time sequence conflict, and the backfilling qualification is invalid. Based on the parent link identifiers in the backfill qualification record and the candidate recommendation link record, a parent continuity verification is performed on the candidate recommendation link record that has passed the backfill qualification verification to generate a parent continuity record. Specifically, for candidate recommendation links that have passed both the acceptance qualification screening and the backfill qualification screening, the parent link identifier is read. When a candidate recommendation link is marked as a first-level recommendation, the parent link identifier is checked to see if it is empty. When the parent link identifier is empty and the recommender entity does not have a valid historical recommended link, the parent continuity is established. When a candidate recommendation link is marked as a non-first-level recommendation, the confirmed recommendation link record is retrieved through the parent link identifier, and the following contents are verified in sequence: the parent link record exists; the parent link is in a confirmed state; the recommended enterprise entity in the parent link is consistent with the recommender entity in the current candidate link; the parent link confirmation time is earlier than the current recommendation initiation time; a circular reference verification is performed on the parent link identifier; starting from the current candidate link, the search proceeds level by level along the parent link identifier, and the corresponding link identifier is written into the visited link table for each parent link retrieved. If a previously written link identifier reappears, it indicates a circular parent-child relationship, and parent continuity is recorded as invalid. When the search continues level by level until the parent link identifier is empty and no duplicate link identifiers appear, it indicates that the parent relationship can be traced back continuously. Parent continuity refers to the current candidate link being able to connect to a real and confirmed previous-level recommended link through the parent link identifier, while simultaneously satisfying the requirements of subject inheritance, time inheritance, and no circular references. The candidate recommended link identifier, parent link identifier, parent confirmation status, subject inheritance result, time inheritance result, circular reference result, and parent continuity are written into the parent continuity record. For example, after company B, as a recommended company in a historical link, completes confirmation, it then initiates a recommendation to company D. The current candidate link inherits the identifier of this historical link. The recommended company in the historical link and the current recommender are both company B. The confirmation time is earlier than the current recommendation initiation time, and no duplicate identifiers appear when tracing back along the parent link; therefore, parent continuity is valid. If the recommended company in the parent link is another entity, parent continuity is invalid. The acceptance qualification record, backfill qualification record, and parent continuity record are merged according to the candidate recommendation link record to generate a locking condition combination record. Specifically, the candidate recommendation link identifier is used as the association field to match the acceptance qualification record, backfill qualification record, and parent continuity record one by one. Before association, the three types of records are verified using the same map version, the same link status version, and the same enterprise entity index version. When the versions are inconsistent, the acceptance path verification result and conversion backfill result of the newer version are obtained first. When the update is not yet completed, the candidate recommendation link is marked as a condition to be synchronized and will not enter the locking condition judgment. This process prevents the old version acceptance result from being confused with the new version backfill. The results are used in combination; three condition bits are set for the records that have completed version alignment, namely, the qualification bit, the backfill qualification bit, and the parent continuity bit; when the condition is true, the corresponding condition bit is recorded as 1, and when the condition is false, it is recorded as 0; for example, "111" means that all three conditions are true, and "110" means that the qualification to accept and the qualification to backfill are true, but the parent continuity is false; the three condition bits, the verification basis of each condition, the reason for the failure, and the data version are written into the locked condition combination record; the locked condition combination record refers to the data record that centrally stores the attribution locked conditions and their evidence sources in units of candidate recommendation links, so that subsequent attribution judgments can locate the specific false conditions; Perform a condition integrity check on the lock condition combination record. Write the candidate recommended link record that meets the acceptance qualification, backfill qualification, and parent continuity into the lock candidate record, and write the candidate recommended link record with invalid conditions into the exclusion candidate record. Specifically, perform an integrity check on the three condition bits in the lock condition combination record. When all three records have been formed, the data versions are consistent, and all three condition bits are 1, write the corresponding candidate recommended link into the lock candidate record. When any condition bit is 0, write the corresponding candidate recommended link into the exclusion candidate record, and write the exclusion reason according to the invalid condition. When the acceptance qualification is invalid, the exclusion reason is recorded as lack of valid business acceptance path. When the backfill qualification is not established, the reason for exclusion is recorded as lack of effective conversion backfill or backfill conflict; when the parent continuity is not established, the reason for exclusion is recorded as missing parent, subject break, time inversion or circular reference; when all three types of verification records have not been formed, the corresponding candidate recommendation link is not written into the exclusion candidate record, but marked as condition pending verification; after the acceptance path verification or conversion event backfill is completed, the condition integrity verification is re-executed to avoid premature exclusion due to data processing delay; the locked candidate record shall at least save the candidate recommendation link identifier, the three establishment conditions and the corresponding verification record identifier; the exclusion candidate record shall at least save the candidate recommendation link identifier, the condition combination code and the reason for exclusion. Based on the locked candidate records and excluded candidate records, a fission attribution lock value is generated by assigning attribution status to the candidate recommended link records in the attribution conflict link set. Specifically, a fission attribution lock value is assigned to each candidate recommended link in the attribution conflict link set according to the locked candidate records, excluded candidate records, and condition pending verification status. The fission attribution lock value is represented by a combination of a three-digit condition code and the attribution status. The condition code is arranged according to the acceptance qualification bit, the backfill qualification bit, and the parent consecutive bit. The attribution status includes locked, excluded, and pending verification. When the condition code is "111" and has been written into the locked candidate record, the fission attribution is locked. The value is recorded as "111-Lockable"; when the condition code contains 0 and has been written into the exclusion candidate record, the fission attribution lock value is recorded as the corresponding condition code plus "Excluded"; when the verification record is missing, the version is not synchronized, or the parent conflict has not been eliminated, the fission attribution lock value is recorded as "Pending Verification"; this lock value does not use a simple weighted sum of acceptance degree and backfill matching degree, but fully retains the three conditions of acceptance qualification, conversion backfill qualification, and parent continuity, so that different exclusion reasons can be directly identified from the lock value; the subsequent unique lock processing counts the number of "111-Lockable" records, and when only one exists, a unique valid attribution link can be formed; when two exist, the lock value is not valid. If there are more than one conflicting link, the conflicting link will be retained; if none exists, it will proceed to the verification stage. For example, if the same recommended company has three candidate recommendation links: the first candidate link has a valid business connection path, both account opening and the first transaction are successfully completed, and the parent link can be continuously traced back; the three condition bits are "111", and the fission attribution lock value is "111-lockable"; the second candidate link has a valid business connection path, and the conversion event is fully completed, but the recommended company entity in the parent link is inconsistent with the current recommender entity; the three condition bits are "110", and the fission attribution lock value is "110-excluded"; the third candidate... The link does not form a valid business undertaking path. Although the account opening and registration event can be backfilled and the parent link is continuous, the three condition bits are "011", and the fission attribution lock value is "011-excluded". In the attribution conflict link set, only the first candidate link forms the "111-lockable" state. The subsequent unique locking process determines it as a valid attribution link. When selecting the attribution link only according to the occurrence time of the conversion event, the second candidate link may be selected because the conversion event was formed earlier. This embodiment retains business undertaking evidence, conversion backfill evidence and parent continuity evidence at the same time, thereby excluding candidate links with broken parent links or lacking business undertaking relationships.

[0031] The present invention is further configured such that the candidate recommended links whose fission attribution lock values ​​satisfy the unique locking condition are determined as valid attribution links; the generation of a link to be verified status when no unique locking condition is formed includes: Based on the fission attribution lock value, candidate recommended link records with lockable attribution status are filtered to generate a set of lockable links. Specifically, the link attribution processing service receives candidate recommended link records corresponding to the same recommended enterprise. The input data includes candidate recommended link identifier, recommended enterprise subject index, fission attribution lock value, undertaking qualification record, backfill qualification record, parent continuity record, and data version identifier. When the fission attribution lock value is updated, attribution processing is triggered through the link status message interface. In case of message transmission abnormality, candidate recommended links that have not yet completed attribution processing are scanned at a cycle of 1 to 5 minutes, with the scanning cycle taken from the processing delay allowed by the link tracing system. Before attribution processing, subject consistency, link identifier deduplication, and data version alignment are performed on the candidate recommended link records. Subject consistency maps the business system customer number, organization number, or other subject identifier of the recommended enterprise to the unified subject index in the enterprise master file. Link identifier deduplication retains only the record with the newest status version for the same candidate recommended links formed by interface retransmission. Data version alignment verifies the undertaking corresponding to the fission attribution lock value. The same enterprise master file version, map version, and link status version are used for qualification, backfill qualification, and parent continuity. Records whose versions are not synchronized are marked as pending synchronization and will not be included in this unique locking process. After the versions are consistent, the ownership status in the fission ownership lock value is checked one by one. When the ownership status is lockable and the qualification, backfill qualification, and parent continuity are all valid, the corresponding candidate recommended link is written into the lockable link set. When the ownership status is excluded or pending verification, it is not written into the lockable link set. The lockable link set refers to the set of links in the candidate recommended links corresponding to the same recommended enterprise that have completed all ownership condition verifications and currently have ownership lock qualifications. This set uses the recommended enterprise main index as the group identifier and saves the candidate recommended link identifier, fission ownership lock value, and three types of qualification record identifiers. For example, if the same recommended enterprise corresponds to three candidate recommended links, where the ownership status of the first link is lockable, the second link is marked as excluded because the parent continuity is not valid, and the third link is marked as excluded because it lacks a valid business acceptance path, then the lockable link set will only include the first link. The lockable link set is verified to generate a lock count verification record. Specifically, the candidate recommended link identifiers in the lockable link set are counted independently. Before counting, duplicates are removed again based on the candidate recommended link identifiers to avoid duplicate counting of the same link due to repeated transmission of status messages. The verification results are divided into three categories: when there is only one lockable link, it is recorded as a single lockable link; when there is zero lockable links, it is recorded as no lockable links; when there are two or more lockable links, it is recorded as multiple lockable links. The recommended enterprise entity index, the total number of conflicting links, the number of lockable links, and the lockable link identifiers are also recorded. The list, the exclusion list, the list of links to be verified, and the quantity verification type are written into the lockable quantity verification record. The lockable quantity verification record refers to the data record that stores the number of lockable links corresponding to the same recommended enterprise and their composition. This record does not use the order of recommendation initiation time, the value of acceptance, or the timing of conversion to replace quantity verification, so that the unique attribution condition remains a verifiable single link condition. Taking the aforementioned three candidate recommended links as an example, after deduplication, the number of lockable links is one, the lockable quantity verification type is recorded as single lockable, and the first candidate recommended link identifier is written into the lockable link identifier list. When only one candidate recommended link record exists in the lock quantity verification record, that candidate recommended link record is determined as a valid belonging link. Specifically, when the lock quantity verification type is single lockable, a unique candidate recommended link is obtained from the set of lockable links. A pre-locking integrity review is performed on this link to check that the candidate recommended link is still in a valid state, the fission belonging lock value has not been revoked by subsequent verification results, the recommended enterprise entity index is consistent with the current belonging group, and there are no new conflicts in the parent link. After the integrity review is passed, the belonging status of the candidate recommended link is updated to valid belonging, and the belonging status of the remaining candidate recommended links with the same entity remains excluded or pending verification, thus forming a valid belonging link record. The path record includes at least the index of the recommended enterprise, the identifier of the valid candidate recommendation link, the recommender entity, the identifier of the parent link, the time of attribution locking, the record identifier of the locking basis, and the current status version. A valid attribution link refers to the only candidate recommendation link that simultaneously meets the requirements of undertaking qualification, backfill qualification, and parent continuity among the candidate recommendation links corresponding to the same recommended enterprise, and forms a single-pointing recommendation link after quantity verification. Taking the aforementioned example, the first candidate recommendation link is updated to a valid attribution link after passing the integrity review before locking. The second candidate recommendation link retains the reason for exclusion due to the discontinuity of the parent, and the third candidate recommendation link retains the reason for exclusion due to the lack of a valid undertaking path, thus forming one valid attribution link and two traceable exclusion links. When no candidate recommended link record exists in the lock quantity verification record, a link status to be verified is generated based on the invalid conditions in the excluded candidate record. Specifically, when the lock quantity verification type is "no lockable links", invalid conditions are collected from the excluded candidate record and the condition to be verified record. The collected content includes invalid acceptance qualification, invalid backfill qualification, invalid parent continuity, missing verification record, and data version pending synchronization. The reasons for pending verification are formed according to the invalid conditions. When there is no valid business acceptance path, it is marked as acceptance relationship pending verification. When the conversion event is missing, the event time sequence is abnormal, or the subject ownership is conflicting, it is marked as conversion backfill pending verification. When the parent link is missing, the subject acceptance is interrupted, or there is a circular link, it is marked as conversion backfill pending verification. When the time is up, mark it as a parent relationship pending verification; when all three types of qualification records are not yet formed, mark it as a verification condition pending completion; when there are more than two invalid conditions for the same candidate recommendation link, save the corresponding reasons for pending verification at the same time, and do not use one of them to cover the other reasons; write the recommended enterprise entity index, candidate recommendation link identifier, invalid conditions, reasons for pending verification, data types to be supplemented, and status update time into the status of the link pending verification; for example, if none of the candidate recommendation links corresponding to the same recommended enterprise have formed a valid receiving path, and the number of lockable links is zero, then the corresponding candidate link is marked as a receiving relationship pending verification status; after the enterprise relationship data is supplemented, the receiving path verification and attribution locking processing are re-executed; When there are more than two candidate recommendation link records in the lock quantity verification record, the lockable link set is marked with a category conflict to generate a link status to be verified. Specifically, when the lock quantity verification type is multi-link lockable, the candidate recommendation links in the lockable link set are grouped into the same conflict group according to the recommended enterprise entity index, and a category conflict identifier is generated. The category conflict identifier is formed by combining the recommended enterprise entity index and the current category processing batch identifier, and is used to associate candidate links in the same round of conflict verification. The conflict content is sorted out for the lockable link set, and the recommender entity, recommendation initiation time, effective business acceptance path, conversion event backfill record, parent link identifier, and fission category lock value are recorded for each candidate recommendation link. When two or more links meet all locking conditions, the earliest recommendation time, higher acceptance degree, or later conversion time is not considered. Early automatic selection is performed; relevant candidate recommendation links are uniformly marked as belonging conflict pending verification status, and the number of conflicting links, the list of conflicting link identifiers, and the record of conflict evidence are written; when the enterprise entity mapping, parent relationship, or conversion event attribution changes in the future, the fission attribution lock value generation and quantity verification are re-executed; the belonging conflict pending verification status refers to the state where there are two or more candidate recommendation links for the same recommended enterprise that both meet the current locking conditions, and the existing business evidence has not yet formed a link with a unique attribution; for example, if the same recommended enterprise corresponds to two candidate recommendation links, both links have valid business undertaking paths, both have completed conversion event backfilling, and both parent links are also continuous, then both links enter the lockable link set at the same time; the quantity verification result is recorded as multiple links can be locked, and both links are marked as belonging conflict pending verification, and do not form a valid attribution link. The status of valid attribution links or links awaiting verification is written to the corresponding candidate recommended link record. Specifically, the status of valid attribution links or links awaiting verification is written to the candidate recommended link database using a transactional approach. Before writing, the candidate recommended link record corresponding to the same recommended enterprise is locked to prevent other status updates during the attribution process from causing the same enterprise to have two valid attribution results written simultaneously. When a valid attribution link is formed, the attribution status of the unique candidate recommended link is updated to valid attribution, the valid attribution link identifier is written to the current attribution field of the recommended enterprise, and the lock quantity verification record identifier and fission attribution lock value are also written. When a link awaiting verification status is formed, the type to be verified, the invalid condition, or the conflicting link identifier is written to the corresponding candidate recommended link, without updating the current valid attribution field. Each write saves the status before the change, the status after the change, the trigger record identifier, the status version, and the processing batch, generating an attribution status change record. If the candidate recommended link subsequently experiences updates to the receiving path, supplementation of conversion events, or changes to the parent path, the record will be updated accordingly. When the hierarchical relationship is corrected, the status version is incremented, and the unique locking verification is retried. Verification is performed using an example of three candidate recommendation links corresponding to the same recommended enterprise: the fission attribution locking value of the first candidate recommendation link is lockable; the second candidate recommendation link is excluded because parent continuity is not established; the third candidate recommendation link is excluded because the undertaking qualification is not established; the lockable link set only includes the first candidate recommendation link, and the quantity verification result is single lockable. After integrity review, the first candidate recommendation link is written into the valid attribution field, and the other two links retain their corresponding exclusion reasons. If quantity verification is not performed, and status is written only based on whether the candidate recommendation link has locking qualification, duplicate attribution may occur when more than two links are qualified simultaneously. This embodiment uses lockable link filtering, quantity branch verification, and transaction writing to ensure that the same recommended enterprise forms at most one valid attribution link under the same status version; when a single link cannot be formed, complete evidence of no candidate reason or multiple link conflict is retained.

[0032] The present invention is further configured such that, in determining the fission level by tracing back level by level according to the parent link identifier of the valid home link, and writing the valid home link, fission level, backfill conversion event, and link status into the recommended link fission tracking record, the following steps are taken: Using the valid attribution link as the starting link for backtracking, hierarchical pointing matching is performed on the parent link identifiers in the valid attribution link to generate parent pointing records; specifically, the recommendation link attribution service initiates hierarchical backtracking processing after a candidate recommendation link is determined to be a valid attribution link; this service is connected to the recommendation link library, the confirmed recommendation link library, the conversion event backfilling library, and the link status change library; when a valid attribution link is generated or the parent link status changes, backtracking is triggered in real time through the status message interface; when the message interface is interrupted, valid attribution links that have not completed backtracking are scanned at a cycle of 1 to 5 minutes, with the scanning cycle adopting the status synchronization delay allowed by the link tracing system; the input valid attribution link includes at least the valid attribution link identifier, the recommender entity, the recommended enterprise entity, the recommendation initiation time, the parent link identifier, the attribution status, and the status version; before backtracking, the link identifier is checked for format uniformity and uniqueness, the enterprise entity identifier is mapped to the unified entity index in the enterprise master file, and the valid attribution link status is verified to still be valid attribution; the valid attribution link is then... The attribution link is marked as the current backtracking link, and the current backtracking position is initialized as the end position. The parent link identifier of the current backtracking link is read, and the current link identifier, parent link identifier, current recommender entity, current recommendation initiation time, and backtracking position are written into the parent pointing record. The parent link identifier is the identifier of the previous confirmed recommendation link inherited by the candidate recommendation link when it is formed. It is used to indicate the link source from which the current recommender previously entered the recommendation system as a recommended enterprise. The parent pointing record is used to store the direct pointing relationship required for this backtracking and does not directly represent that the parent link has passed the status and time verification. When the parent link identifier is empty, the parent pointing result is marked as reaching the link start point. When the parent link identifier is not empty, it is marked as the corresponding parent link to be entered into the previous level link retrieval. For example, if the third recommendation link is determined to be a valid attribution link and its parent link identifier points to the second recommendation link, then the parent pointing record stores the third recommendation link identifier, the second recommendation link identifier, the recommender entity of the third recommendation link, and the recommendation initiation time. The parent-pointing record is matched with the confirmed recommendation link record using link identifier mapping to determine the corresponding upper-level recommendation link for the current level and generate the corresponding upper-level link record. Specifically, the parent link identifier in the parent-pointing record is used as the precise search key to retrieve the corresponding link record in the confirmed recommendation link library. The confirmed recommendation link library uses a unique index of link identifiers, and the record content includes link identifier, recommending entity, recommended enterprise entity, recommendation initiation time, confirmation time, confirmation status, parent link identifier, and status version. Before retrieval, the data version of the confirmed recommendation link library is verified to be consistent with the link status version used by the valid attribution link. If there is a version difference, the backtracking task is written to the version synchronization queue, and the retrieval is re-executed after the link status is synchronized to avoid using historical links that have been withdrawn or have not yet been confirmed. When a record with a consistent link identifier is retrieved, this record is used as the upper-level recommendation link to be verified. When duplicate versions of the same link identifier are generated due to interface retransmission, they are first sorted by status version number, and the record with the larger status version number is retained. Then, the consistency between the primary key of the source event and the subject information is verified. If no corresponding record is found, the parent-level pointing status is marked as a missing parent link. If two or more records with the same link identifier but different subject information or source events are found, the parent-level pointing status is marked as a parent identifier conflict. In both cases, a parent-level pending verification status is formed, and automatic backtracking is not continued. When the search result is unique, the current link identifier, parent link identifier, the recommender entity of the previous level, the recommended enterprise entity of the previous level, the confirmation status of the previous level, the confirmation time of the previous level, and the data version are written into the corresponding record of the upper-level link. The corresponding record of the upper-level link refers to the data record formed after the correspondence between the parent link identifier and the historical recommended link entity is completed. It is used to save the direct correspondence between the current link and the upper-level link to be accessed. The system performs confirmation status verification and time sequence verification on the corresponding records of the superior links. Links that pass verification are then added to the backtracking link sequence to generate hierarchical backtracking records. Specifically, confirmation status verification is performed on the corresponding records of the superior links. The attribution status of the superior recommended links should be confirmed or valid; links in candidate, pending verification, excluded, withdrawn, or invalid states are not added to the backtracking link sequence. Subject acceptance verification is performed on superior recommended links that pass confirmation status verification. The recommended enterprise entity in the superior recommended link and the recommending entity in the current link are converted into a unified enterprise entity index. If the two entity indices match, it indicates that the current recommender originates from the superior recommended link. If the entity indices do not match, the verification result is marked as a parent-child entity break. Time sequence verification continues. The confirmation time of the superior recommended link and the recommendation initiation time of the current link are converted to a unified time zone and unified time. Time precision: When the confirmation time of the previous-level recommendation link is earlier than the current link's recommendation initiation time, it conforms to the time succession relationship of entering the recommendation system first and then continuing to recommend downwards; when the confirmation time is equal to or later than the current link's recommendation initiation time, the verification result is marked as parent-child link time reversal; when the confirmation status, subject succession, and time sequence are all correct, the previous-level recommendation link is added to the backtracking link sequence, and the current link identifier, the previous-level link identifier, the subject succession result, the time verification result, and the access order are recorded to generate a hierarchical backtracking record; when any verification is incorrect, the previous-level recommendation link is not added to the backtracking link sequence, and the incorrect project, abnormal link identifier, and abnormal reason are written into the hierarchical backtracking record, and the backtracking status is updated to parent level pending verification; this process ensures that each link has three aspects of succession basis: confirmation status, enterprise subject, and time sequence, avoiding the formation of incorrect hierarchical relationships based solely on the parent link identifier; Repeatedly execute parent link identifier matching, link identifier correspondence processing, and hierarchical backtracking record access until the parent link identifier is empty or a parent pending verification status appears, generating a fission hierarchical path; specifically, after the upper-level recommended link passes verification and is accessed into the backtracking link sequence, the upper-level recommended link is updated to the current backtracking link, its parent link identifier is obtained again, and parent pointer matching, upper-level link correspondence, confirmation status verification, subject acceptance verification, and time sequence verification are executed in sequence; to prevent circular references in historical data, an accessed link identifier table is established at the beginning of backtracking; each accessed link identifier is accessed in a specific manner. When a new parent link is added, its link identifier is written to the visited link identifier table. If a newly retrieved parent link identifier already exists in this table, it indicates a circular reference between links. The backtracking status is updated to circular reference pending verification, and backtracking stops. The number of backtracking levels is also constrained by the upper limit of the fission levels allowed by the recommendation activity. The upper limit of fission levels is derived from the recommendation activity rule configuration and can be set from 2 to 10 levels. In this embodiment, the activity configuration value is used as the maximum number of backtracking levels. If a parent link identifier still exists after reaching the maximum number of backtracking levels, the current result is marked as... The next layer needs verification to prevent boundless retrieval caused by abnormal parent data. The current backtracking ends when any of the following conditions are met: the parent link identifier of the current link is empty, indicating that the first-level recommended link has been reached; the parent link record is missing or the parent identifier conflicts; the previous level link fails the verification of confirmation status, subject inheritance, or time sequence; a circular reference is found; the upper limit of the fission level is reached. The already connected link identifiers, link subjects, access order, parent pointing relationships, and termination reasons are merged according to this backtracking task to generate a fission level path; the fission level path refers to the path from the effective... The home link is an ordered link sequence formed upwards along the parent link identifier; when tracing back to the point where the parent link identifier is empty, the path is marked as a complete path; when terminated due to abnormal conditions, the path is marked as a path to be verified, and the partially verified link relationships are retained; for example, the third recommended link points to the second recommended link, the second recommended link points to the first recommended link, and the parent link identifier of the first recommended link is empty; after the verification is passed at each level, the backtracking link sequence is recorded as the third recommended link, the second recommended link, and the first recommended link according to the access order, and the termination reason is reaching the link starting point; The fission hierarchy paths are organized hierarchically, with the location of the valid attribution link determined as the final link and the link with an empty parent link as the starting link, generating fission hierarchy records. Specifically, the fission hierarchy paths are formed in the direction from the final link to the starting link during the backtracking process. The complete path is reversed in order, with the link with an empty parent link in the first position and the valid attribution link in the last position. Hierarchy counting starts from the starting link. The fission hierarchy of the starting link is recorded as level one. Each time the path moves to the next child link, the fission hierarchy increases by one level until a valid attribution link is reached. When the path contains three consecutive links, levels one, two, and three are formed respectively, with the fission hierarchy of the valid attribution link being level three. For each link level, the hierarchy number, link identifier, recommender entity, and recommended enterprise entity are written. The parent link identifier, the parent link identifier, and the hierarchical status form a fission hierarchical record. The hierarchical status includes confirmed hierarchical status and pending verification hierarchical status. When a fission hierarchical path terminates prematurely due to the parent link being pending verification status, only the relative hierarchical order that has been verified is recorded. At the same time, the absolute fission hierarchical level of the valid parent link is marked as pending verification, and the number of local links is not directly used as the final fission hierarchical level. After the parent relationship is repaired, a complete backtracking is performed again, and the fission hierarchical record is updated. For example, if the parent link identifier of the first recommended link is empty, the second recommended link inherits from the first recommended link, and the third recommended link inherits from the second recommended link. After the order is sorted, the first recommended link is recorded as level 1, the second recommended link as level 2, and the third recommended link as level 3. The third recommended link is the currently valid parent link, so its fission hierarchical record is written to level 3 and the confirmed hierarchical status. The system generates a tracking field combination record by performing field mapping processing on valid attribution links, fission level records, conversion event backfill records, and link status change records. Specifically, the valid attribution link identifier is used as the main associated field, and corresponding data is obtained from the valid attribution link record, fission level record, conversion event backfill record, and link status change record. The valid attribution link field includes the valid attribution link identifier, recommender entity, recommended enterprise entity, recommendation initiation time, parent link identifier, and attribution confirmation status. The fission level field includes the starting link identifier, level path, level of the valid attribution link, and level verification status. The conversion event backfill field includes the account opening / registration event identifier, account opening / registration time, first transaction event identifier, first transaction time, and conversion backfill matching status. The link status change field includes the recommended, responded, opened, and converted statuses and their corresponding effective times. Version consistency verification is performed before field mapping. Hierarchical records, conversion event backfill records, and link status change records should correspond to the same status version of the valid attribution link; when old version records exist, the historical version should be retained but not written into the current tracking result; when records that have not yet been updated exist, the current tracking record should be marked as fields to be synchronized; conversion events and status change records should be arranged according to the event occurrence time; the recommendation entry trigger event should be after the recommendation initiation event, the account opening and registration event should be after the recommendation entry trigger event, and the first business event should be after the account opening and registration event; when the event order conflicts, the conflict field and the source event identifier should be written into the tracking exception field; the corresponding link subject, hierarchical path, conversion event, and status change should be merged according to the valid attribution link identifier to form a tracking field combination record; the tracking field combination record refers to the intermediate record formed by centrally associating the recommendation source, fission level, business conversion, and link status, providing a complete field source for the final tracking record; The tracking field combination record is encapsulated with link identifiers and status and written into the recommended link fission tracking record. Specifically, link identifier encapsulation is performed on the tracking field combination record; the valid attribution link identifier is used as the current tracking object identifier; the link identifiers in the fission hierarchy path are written into the link path field in order from the first level to the last level; the parent link identifier and hierarchy number are written into the corresponding link node field; status encapsulation is performed on the link status; the current valid status is written into the main status field; all status changes are written into the status trajectory field in order of occurrence; the account opening registration event and the first business event are written into the conversion trajectory field; when the hierarchy path is complete, the tracking status is recorded as tracking complete; if there are parent unverified, event sequence conflict or data... When a version is pending synchronization, the tracking status is recorded as "tracking pending verification," and the corresponding reason for the exception is saved. The recommended link fission tracking record should include at least: tracking record identifier, valid home link identifier, recommended enterprise entity index, starting link identifier, parent link identifier sequence, fission level, conversion event backfill record, link status change trajectory, level verification status, tracking status, and status version. The tracking record identifier uses a combination of the valid home link identifier and the status version for encoding, ensuring that the same valid home link forms a new traceable version after a status update. Writing uses a transaction commit method; the tracking completion flag in the candidate recommended link is updated only after the current tracking record is successfully written. If writing fails, the original status is retained and the link enters the retry queue. A three-level fission... Verification using an example: The first company recommends the second company to form the first recommendation link, with the parent link identifier of the first recommendation link being empty. After the second company completes its confirmation, it recommends the third company to form the second recommendation link, which inherits the identifier of the first recommendation link. After the third company completes its confirmation, it recommends the fourth company to form the third recommendation link, which inherits the identifier of the second recommendation link. The third recommendation link corresponding to the fourth company becomes a valid attribution link after attribution verification. Backtracking begins from the third recommendation link, sequentially locating the second and first recommendation links. The confirmation status, subject connection, and time sequence of the three links all pass verification, and the parent link identifier of the first recommendation link is empty. After sorting the order, the first recommendation link is the first level. The second recommendation link is the second level, and the third recommendation link is the third level. The third recommendation link has both valid account registration backfill records and valid first business backfill records. The link status goes through recommended, responded, account opened, and converted in sequence. The final recommendation link fission tracking record saves the complete three-level link path, the valid home status of the third recommendation link, two conversion events, and four link status nodes. If the parent link record of the second recommendation link is missing, the parent pending verification status is generated back at the second recommendation link, and the third recommendation link is not written into the definite absolute fission level. This process can prevent the partial link length from being incorrectly recorded as the complete fission level when the parent data is broken, and retain the position of the parent link to be supplemented and the reason for the anomaly.

[0033] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A recommended link splitting tracing method, characterized in that, include: Acquire enterprise relationship data, recommendation event data, and conversion event data; and aggregate the records of the same enterprise in the business system based on the enterprise entity identifier to generate a basic industry chain recommendation map. Candidate recommendation link records are formed based on recommendation event data. Each candidate recommendation link record carries the parent link identifier. Non-first-level recommendations inherit the identifier of the confirmed recommendation link of the previous level. Search the candidate recommendation link record for the corresponding business undertaking path in the basic graph of the industry chain recommendation, verify the validity and directional continuity of the business undertaking path when the recommendation is initiated, and generate the recommendation link undertaking degree. Update the candidate recommendation link status based on the link event triggered by the recommendation entry to the occurrence of the first business transaction, and backfill the candidate recommendation link record with conversion events of the same enterprise that meet the status and time continuation conditions, and generate conversion backfill matching degree. When the same recommended enterprise corresponds to more than two candidate recommendation link records, a fission attribution lock value is generated based on the recommendation link acceptance degree and conversion backfill matching degree. Candidate recommendation links whose fission attribution lock value meets the unique locking condition are determined as valid attribution links. A link status pending verification is generated when no unique locking condition is formed. The fission level is determined by tracing back level by level according to the parent link identifier of the valid home link, and the valid home link, fission level, backfill conversion event and link status are written into the recommended link fission tracking record.

2. The recommended link splitting tracking method according to claim 1, characterized in that, Acquire enterprise relationship data, recommendation event data, and conversion event data. Based on the enterprise entity identifier, aggregate records of the same enterprise in the business system to generate a basic industry chain recommendation map, including: The original business records are extracted from the business data source, and the original business records are marked with source and time to generate business records to be collected. The original business records include enterprise relationship data, recommendation event data and conversion event data. The format of the enterprise entity identifier in the business records to be collected is validated and made consistent to generate an enterprise entity index. Based on the enterprise entity index, the business records to be collected that point to the same enterprise are merged to generate enterprise master records. Extract enterprise node attributes from enterprise master records, and generate enterprise nodes by performing node encoding and node attachment processing on the enterprise node attributes. Extract the relationship subject field, relationship direction field, and relationship time field from the enterprise relationship data, match the relationship subject field to the corresponding enterprise node, and perform directional connection and time attachment on the matched enterprise nodes to generate business relationship edges between enterprises; Extract the recommender subject field, the recommended subject field, and the recommend time field from the recommendation event data. Match the recommender subject field and the recommended subject field to the corresponding enterprise node. Generate recommendation behavior edges by performing recommendation connection and time attachment on the matched enterprise nodes. Extract the conversion subject field and conversion time field from the conversion event data, match the conversion subject field to the corresponding enterprise node, and generate conversion event edges by attaching conversion events to the matched enterprise nodes. The basic graph of the industry chain recommendation is generated by writing the subject correspondence and time sequence between enterprise nodes, inter-enterprise business relationship edges, recommendation behavior edges, and conversion event edges into the graph structure.

3. The recommended link splitting tracking method according to claim 1, characterized in that, The candidate recommendation link records formed based on recommendation event data include: Perform event integrity verification on the recommendation event data, and extract the recommender entity, the recommended enterprise entity, the recommendation entry identifier, and the recommendation initiation time to generate recommendation events to be processed; Match the recommending entity and the recommended enterprise entity in the pending recommendation event to the enterprise nodes in the basic graph of the industry chain recommendation to generate corresponding records of the recommendation nodes; Organize the recommendation direction of the records corresponding to the recommendation nodes, take the enterprise node corresponding to the recommender as the starting point of the link, and the enterprise node corresponding to the recommended enterprise as the ending point of the link, and generate a recommendation link direction record; An initial link status record is established based on the recommended link direction record, the recommended entry identifier, and the recommended initiation time. The initial link status record is marked as recommended. The recommended node corresponding record, recommended link direction record, and link state initial record are encapsulated to generate candidate recommended link records.

4. The recommended link splitting tracking method according to claim 3, characterized in that, Candidate recommendation link records carry the parent link identifier. Non-first-level recommendations inherit the identifiers of confirmed recommendation links from the previous level, including: Based on the recommender entity in the candidate recommendation link record, retrieve the confirmed recommendation link record to generate the recommender link source record; The confirmation status and time sequence of the referrer's link source record are verified, and the confirmed referral link record with the confirmation time earlier than the current referral initiation time is retained; If no confirmed recommended link record is found that has passed the verification of confirmation status and time sequence, the candidate recommended link record is marked as a first-level recommended record and the parent link identifier is set to empty; When a confirmed recommended link record that has passed the confirmation status verification and time sequence verification is retrieved, the corresponding confirmed recommended link identifier is written into the parent link identifier field of the candidate recommended link record to generate a non-first-level candidate recommended link record. When a parent link identifier cannot form a single correspondence, the candidate recommended link record is marked as a parent pending verification status.

5. The recommended link splitting tracking method according to claim 1, characterized in that, Retrieve the business connection path corresponding to the candidate recommendation link record in the basic graph of the industry chain recommendation, verify the validity and directional continuity of the business connection path at the time of recommendation initiation, and generate the recommendation link connection degree, including: Locate the recommending entity and the recommended enterprise entity in the candidate recommendation link record to the corresponding enterprise node in the basic graph of the industry chain recommendation, and generate the path retrieval start point and path retrieval end point; Starting from the path retrieval starting point and ending from the path retrieval ending point, the path is extended along the business relationship edge between enterprises in the basic graph of the industry chain recommendation. The enterprise nodes and business relationship edges between enterprises are recorded in sequence to generate candidate business undertaking paths. Perform time verification on the inter-enterprise business relationship edges in the candidate business acceptance path, retain the inter-enterprise business relationship edges that are in effect at the time of recommendation initiation, and generate time-verification paths; Perform directional verification on the business relationship edges between enterprises in the timeliness verification path, and generate a directional verification path by continuously matching the directional order of the business relationship edges with the link direction from the recommender to the recommended enterprise. Perform path-level verification on the direction verification path, determine the direction verification path that meets the fission level limit as the valid business acceptance path, and mark the candidate business acceptance path that does not meet the time verification, direction verification or path-level verification as the acceptance abnormal path. Based on the valid business acceptance paths and the abnormal acceptance paths, acceptance path verification records are generated. The acceptance level is mapped to the acceptance path verification records to generate the acceptance degree of the recommended link corresponding to the candidate recommended link record.

6. The recommended link splitting tracking method according to claim 1, characterized in that, The candidate recommendation link status is updated based on the link event triggered by the recommendation entry point up to the first business transaction, including: Based on the recommendation entry identifier in the candidate recommendation link record, the recommendation entry trigger event is matched with the candidate recommendation link record. The recommended enterprise entity is matched and the time sequence is verified for the recommendation entry trigger event after the entry is matched to generate the link response record. Based on the recommended enterprise entity and the trigger time of the recommendation entry in the link response record, the account opening and registration event is processed with the candidate recommendation link record for account opening acceptance. The account opening and registration event is verified for entity consistency, account opening order, and account opening status acceptance to generate the link account opening record. Based on the recommended enterprise entity and account opening registration time in the link account opening record, the first business event is converted and connected with the candidate recommended link record. The first business event is verified for entity consistency, business occurrence sequence and conversion status connection to generate the link conversion record. Following the generation order of link response records, link account opening records, and link conversion records, the link status in the candidate recommended link records is progressively updated to generate link status change records.

7. The recommended link splitting tracking method according to claim 1, characterized in that, Conversion events from the same enterprise that meet the status and time continuity criteria are backfilled into the candidate recommendation link record, generating conversion backfill matching scores including: Based on the recommended enterprise entity in the link status change record, conversion events with the same entity in the conversion event data are grouped into the candidate recommended link record to generate a set of conversion events with the same entity; Based on the link status in the link status change record, the same subject conversion event set is filtered for status succession, and conversion events that meet the progressive relationship of being responded to to being opened and being opened to being converted are identified as conversion events to be backfilled. Based on the recommendation initiation time, recommendation entry trigger time, account registration time, and conversion event time to be filled in the link status change record, perform time continuity verification on the conversion event to be filled in to generate a conversion time continuity record; The conversion events to be backfilled that have passed the subject attribution verification, status acceptance filtering, and time acceptance verification will be written into the candidate recommendation link record to generate conversion event backfilling records; The verification items of the subject attribution verification results, status inheritance screening results, and time inheritance verification results in the conversion event backfill record are merged, integrity verified, and conflict verified to generate backfill availability record; Based on the backfill availability record, the candidate recommendation link record is marked with a matching level to generate the conversion backfill matching degree corresponding to the candidate recommendation link record.

8. The recommended link splitting tracking method according to claim 1, characterized in that, When the same recommended enterprise corresponds to more than two candidate recommendation link records, the fission attribution lock value is generated based on the recommendation link continuity and conversion feedback matching degree, including: For candidate recommendation link records corresponding to the same recommended enterprise, generate a set of conflicting links by grouping them together under the same subject. Based on the acceptance degree of the recommended link record corresponding to the candidate recommended link record in the set of conflicting links, the acceptance qualification of the candidate recommended link record is screened to generate acceptance qualification record; Based on the matching degree of the acceptance qualification record and the conversion backfill, the candidate recommendation link record that has passed the acceptance qualification screening is used to generate backfill qualification record; Based on the parent link identifier in the backfill qualification record and the candidate recommendation link record, perform parent continuity verification on the candidate recommendation link record that has passed the backfill qualification verification to generate a parent continuity record; The acceptance qualification record, backfill qualification record, and parent continuity record are merged according to the candidate recommendation link record to generate a locking condition combination record; Perform condition integrity verification on the locked condition combination record, write the candidate recommendation link record that meets the acceptance qualification, backfill qualification and parent continuity into the locked candidate record, and write the candidate recommendation link record with the condition not met into the excluded candidate record. Based on the locked candidate records and excluded candidate records, the fission ownership lock value is generated by assigning ownership status values ​​to the candidate recommended link records in the ownership conflict link set.

9. The recommended link splitting tracking method according to claim 1, characterized in that, Candidate recommended links whose fission attribution lock values ​​satisfy the unique locking condition are identified as valid attribution links; When no unique locking condition is formed, the generated link status to be verified includes: Based on the fission attribution lock value, candidate recommended link records with lockable attribution status are filtered to generate a set of lockable links; Perform quantity verification on the set of lockable links to generate a lock quantity verification record; When there is only one candidate recommended link record in the locked quantity verification record, the candidate recommended link record is determined as a valid belonging link; When there is no candidate recommended link record in the locked quantity verification record, the link status to be verified is generated according to the invalid conditions in the excluded candidate record. When there are more than two candidate recommended link records in the locked quantity verification record, the set of lockable links is marked with ownership conflict to generate the status of the link to be verified. Write the status of the valid home link or the link to be verified into the corresponding candidate recommended link record.

10. The recommended link splitting tracking method according to claim 1, characterized in that, The fission level is determined by tracing back level by level according to the parent link identifier of the valid home link. The valid home link, fission level, backfill conversion event, and link status are written into the recommended link fission tracking record, including: Using the valid home link as the starting link for backtracking, hierarchical pointing matching is performed on the parent link identifier in the valid home link to generate a parent pointing record; Perform link identifier mapping between the parent-level pointing record and the confirmed recommendation link record, determine the upper-level recommendation link corresponding to the current level, and generate the upper-level link corresponding record. The corresponding records of the upper-level links are confirmed for status verification and time sequence verification. The upper-level recommended links that pass the verification are connected to the backtracking link sequence to generate hierarchical backtracking records. Repeat the process of matching parent link identifiers, processing corresponding link identifiers, and accessing hierarchical backtracking records until the parent link identifier is empty or a parent pending verification status appears, generating a fission hierarchical path. The fission hierarchy path is sorted hierarchically, the location of the effective belonging link is determined as the last level link, and the link with an empty parent link is determined as the starting link, and a fission hierarchy record is generated. The effective attribution link, fission level record, conversion event backfill record and link status change record are processed to generate a tracking field combination record; The combined tracking field records are encapsulated with link identifiers and status information and written into the recommended link splitting tracking records.

Images