Business data analysis method and system based on multi-platform data fusion

Abstract

The application provides a business data analysis method and system based on multi-platform data fusion. The method comprises the following steps: obtaining original business records of multiple platforms, and constructing a multi-platform candidate event segment set; combining a pre-configured business process constraint table, and constructing object evidence, sequence evidence, time evidence and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time and event content summary to generate a candidate business association relationship set; concatenating directed connections in the candidate business association relationship set into a fusion business event chain to generate a fusion business event chain set; and calculating a time-effective trust value corresponding to the fusion business event chain, and outputting to an enterprise-level data asset center. The application enables scattered records in a transaction system, an online platform, a member management system and a supply chain system to form analyzable data assets layer by layer according to unified business logic.

Description

Technical Field

[0001] This invention belongs to the field of business data analysis, and in particular relates to a business data analysis method and system based on multi-platform data fusion. Background Technology

[0002] As enterprises increasingly adopt digital operations and refined management, transaction systems, online business platforms, membership management systems, and supply chain systems each assume data processing responsibilities for different business segments, such as order transactions, user behavior, membership benefits, and fulfillment and delivery. Enterprises typically use data platforms, data warehouses, ETL tools, or interface integration platforms to access, clean, and integrate business data from these systems, then create wide tables, thematic tables, or indicator tables for business analysis, precision marketing, membership operations, and supply chain decision-making. Existing, relatively similar technical solutions generally involve first configuring data interfaces for each platform, then standardizing fields such as order number, user number, member number, product number, and logistics number according to field mapping rules, and forming a unified dataset through primary key association, time sorting, field concatenation, and indicator processing. While this approach is effective in routine report statistics and field standardization, it still has significant shortcomings in practical engineering applications. Because transaction systems focus more on order and payment status, online platforms focus more on browsing, searching, clicking, and adding-to-cart activity logs, membership management systems focus more on the flow of benefits such as coupons, points, and levels, and supply chain systems focus more on fulfillment nodes such as inventory locking, outbound delivery, distribution, and receipt, the same business process is often broken down into multiple event fragments and recorded separately on different platforms. There is often a lack of unified business event numbers across platforms. Furthermore, the identification systems between platforms are not entirely consistent. Online platforms may use device accounts or login accounts, transaction systems may use order accounts or order association numbers, membership systems may use member accounts, and supply chain systems may only store logistics association numbers or fulfillment batch numbers. Relying solely on a single primary key field for association can easily lead to missed associations, incorrect associations, or cross-order chaining. In addition, the time fields on different platforms also have different definitions. Online platforms record the time of user behavior, transaction systems record the time of order status changes, membership systems record the time of benefit changes, and supply chain systems record the time of fulfillment node scanning. If only time proximity is used for concatenation, it is easy to mix multiple products, multiple orders, or multiple fulfillment batches from the same user within a short period into the same analysis object. Existing wide-table fusion results can usually only indicate that several fields are concatenated into the same row, but it is difficult to express whether these fields actually belong to the same business process, whether the business stage is complete, whether the link order is reasonable, whether the summary information is conflicting, and whether the fusion result is suitable for direct entry into the front-end analysis system.

[0003] Therefore, although existing technologies can complete multi-platform data access and basic field integration, they still have shortcomings in the event-based expression of multi-platform business data, candidate association determination, business chain reconstruction, and reliable output of fusion results. They are difficult to provide stable, continuous, and directly reusable business process-level data objects for enterprise-level data asset centers.

[0004] The technical essence of the above-mentioned shortcomings lies in the inconsistency of field structure, object identification, event granularity, time caliber, and summary content of multi-platform interface data. This results in the lack of executable data lineage, correlation evidence, conflict handling, and trusted state control mechanisms when the data platform constructs unified data objects. Therefore, it is necessary to form a traceable data processing link between interface access, field mapping, event fragment caching, candidate association, chain merging, and standardized output, rather than simply providing business analysis conclusions at the business level. Summary of the Invention

[0005] The purpose of this invention is to propose a business data analysis method and system based on multi-platform data fusion to solve the above-mentioned problems.

[0006] To achieve the above objectives, a business data analysis method based on multi-platform data fusion is provided in a first aspect of the present invention, the method comprising the following steps: Obtain original business records from multiple platforms and construct a multi-platform candidate event fragment set; each candidate event fragment in the multi-platform candidate event fragment set comes from an original business record and includes a de-identified business object identifier, event type, event occurrence time, event content summary, and source platform identifier; Based on the multi-platform candidate event fragment set and combined with the pre-configured business process constraint table, object evidence, sequence evidence, time evidence and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time and event content summary are constructed to generate a candidate business association set. Each candidate business association indicates that there is a usable candidate business association between two candidate event fragments. The directed connections in the candidate business association set are concatenated into a fused business event chain, and the chain validity value of the corresponding fused business event chain is calculated to generate a fused business event chain set. Calculate the timeliness reliability value corresponding to the converged business event chain, convert the converged business event chain into a business converged data unit based on the timeliness reliability value, and output it to the enterprise-level data asset center.

[0007] Furthermore, the multi-platform includes a transaction system, an online platform, a membership management system, and a supply chain system; The de-identified business object identifier is obtained by converting the original account, member number, device number, or order association identifier through a unified identity mapping interface or account mapping table; the event type is determined by the event mapping rule table based on the original action field or status field; the event occurrence time adopts the business action time; the event content summary includes necessary fields from the product summary, order summary, rights summary, or performance summary; the source platform identifier is used to distinguish the transaction system, online platform, member management system, or supply chain system.

[0008] Furthermore, a pre-configured business process constraint table is used to determine the allowed sequence and allowed connection types between different event types, derived from the enterprise's existing business processes, interface specifications, and order fulfillment rules.

[0009] Furthermore, the object evidence is determined by whether the de-identified business object identifiers are consistent and whether the order summary, product summary, rights summary, or performance summary in the event content summary are consistent; The sequence evidence is determined by the order of the two event types in the business process constraint table; The time evidence is determined by whether the times of the two events fall within the allowed business span of the event type pair; The evidence of conflict is determined by whether there is a summary conflict, order conflict, or stage conflict within the same cache area.

[0010] Furthermore, the conditions for generating the candidate business association relationship are as follows: The object evidence level meets the threshold required by the event type, the sequential evidence is valid, the temporal evidence is valid, and the conflicting evidence is invalid. Each candidate business relationship record includes the starting segment of the relationship, the ending segment of the relationship, the relationship type, and the key basis for the relationship.

[0011] Furthermore, the step of connecting the directed connections in the candidate service association set into a fused service event chain specifically involves: The integrated business event chain is composed of candidate event fragments from the multi-platform candidate event fragment set arranged in a directed connection order. Each edge comes from the candidate business association relationship, and the time order constraint ensures that the events in the chain are arranged along the business process direction. If adjacent segments have the same time, their order is determined according to the stage order in the business process constraint table; if adjacent segments have reversed time and cannot be explained by the interface delay rules, then the path is not output as a normal integrated business event chain. The starting point of the integrated business event chain is determined by the incoming edge information of the candidate business association relationship and the event type. Starting from the starting point of the chain, the subsequent candidate business association relationship is read, and candidate event fragments that meet the requirements of adjacent business stages, sequential event time, and continuous content summary are added to the current chain. If a candidate event fragment has multiple successor fragments, multiple candidate chain paths are retained simultaneously, and the chain validity determination stage is used to filter them based on stage coverage and conflict status.

[0012] Furthermore, the chain validity value is generated based on the intersection size of the actual set of business stages covered within the chain and the target set of business stages, the size of the target set of business stages, the chain summary collision count, and the number of adjacent connections within the chain. The summary conflicts include product summary conflicts, order summary conflicts, and fulfillment summary conflicts; Among them, while connecting the directed connections of the candidate business association set into a fusion business event chain, the chain expansion is gradually promoted according to the three conditions of stage continuity, platform completion and low conflict. Phase continuity is used to ensure that events extend along the business process direction; platform completion is used to prioritize the retention of business chains that cover multiple platforms; low conflict is used to prioritize the retention of chains with consistent product summary, order summary and fulfillment summary when multiple candidate chains are generated at the same chain starting point. Finally, when writing the fused service event chain set, each fused service event chain saves the chain identifier, the order of candidate event segments within the chain, the candidate service association relationship between adjacent segments, the chain start segment, the chain end segment, the actual covered service stage set, the target service stage set, the conflict count, and the chain validity value.

[0013] Furthermore, the timeliness reliability value is based on the chain validity value of the corresponding fused service event chain, the time break count, the number of adjacent connections within the chain, and The actual number of platforms covered and the target number of platforms are calculated and generated. The time break count is the number of times when the occurrence time of adjacent events within the chain exceeds the allowed business span configured in the business process constraint table.

[0014] Furthermore, the business fusion data unit also stores the original fragment list, the candidate association list, the fusion business event chain identifier, the calculation version number, the trust status, and the reason for pending verification; The trusted status includes high trust, low trust, and pending verification.

[0015] A second aspect of the present invention provides a business data analysis system based on multi-platform data fusion, the system comprising: The candidate event fragment generation module is used to obtain original business records from multiple platforms and construct a multi-platform candidate event fragment set. Each candidate event fragment in the multi-platform candidate event fragment set comes from an original business record and includes a de-identified business object identifier, event type, event occurrence time, event content summary, and source platform identifier. The candidate association generation module is used to construct object evidence, sequence evidence, time evidence, and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time, and event content summary based on the multi-platform candidate event fragment set and combined with the pre-configured business process constraint table, so as to generate a candidate business association set. Each candidate business association indicates that there is a usable candidate business association between two candidate event fragments. The fusion event chain generation module is used to connect the directed connections in the candidate service association set into a fusion service event chain, calculate the chain validity value of the corresponding fusion service event chain, and generate a fusion service event chain set. The business integration data output module is used to calculate the timeliness reliability value corresponding to the integrated business event chain, convert the integrated business event chain into a business integration data unit based on the timeliness reliability value, and output it to the enterprise-level data asset center.

[0016] The beneficial technical effects of the present invention are at least as follows: This invention addresses the inconsistencies in field structures, event granularity, and identification systems across platforms in existing technologies. First, it converts original business records from different sources into candidate event fragments containing de-identified business object identifiers, event types, event occurrence times, event content summaries, and source platform identifiers, according to unified data standards and interface specifications. This eliminates the direct reliance on the original table structures of each platform for subsequent processing. Second, it addresses the lack of unified business event numbers and the susceptibility to misassociations based solely on primary keys or similar times in existing technologies. This invention establishes object evidence, sequence evidence, time evidence, and conflict evidence between candidate event fragments, combining this with a business process constraint table to generate candidate business relationships, ensuring that each association has a clear business connection basis. Third, it addresses the issue of inconsistencies in existing technologies in terms of... To address the issue that partial associations cannot reconstruct a complete business process, this invention further connects candidate business relationships into a fused business event chain according to directed business paths. It then uses business stage coverage and summary conflict constraints to determine the validity of the chain, enabling online behavior, membership benefits, transaction payments, and supply chain fulfillment to be organized as a continuous business process. To resolve the lack of usability status in existing fusion results and the need for repeated cleaning and parsing by the front-end system, this invention further aggregates the fused business event chain into time-sensitive and reliable business fusion data. This forms a standardized data object containing a business stage summary, stage time series, source platform set, chain validity value, and time-sensitive reliability value, which is then written into an enterprise-level data asset center for use by business analysis, precision marketing, membership operations, and supply chain decision-making systems. Through this design, this invention can reconstruct scattered business records into business fusion data with process continuity, stage integrity, and reliability status while preserving the differences in data sources from multiple platforms. This overcomes the problems of inaccurate associations, discontinuous chains, unstable analysis criteria, and insufficient reusability of fusion results in existing field-concatenated data fusion methods. During the above processing, the system saves the interface batch number, field mapping version number, identity mapping version number, candidate event fragment number, candidate association basis, chain validity value, timeliness reliability value, and output data version number, so that each output data can be traced back to the original interface record and intermediate processing results. When the original record is missing necessary fields, identity mapping fails, business constraint table is missing, or chain validity value is lower than the threshold, the system does not output the record as a high-reliability fusion result, but writes it to the pending verification or low-reliability data area. Attached Figure Description

[0017] The present invention will be further described with reference to the accompanying drawings, but the embodiments in the drawings do not constitute any limitation on the present invention. For those skilled in the art, other drawings can be obtained based on the following drawings without creative effort.

[0018] Figure 1 This is a flowchart of the business data analysis method based on multi-platform data fusion according to the present invention. Detailed Implementation

[0019] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0020] like Figure 1 As shown in the embodiment of the present invention, a business data analysis method based on multi-platform data fusion is provided, the method comprising: S101. Obtain original business records from multiple platforms and construct a multi-platform candidate event fragment set; each candidate event fragment in the multi-platform candidate event fragment set comes from an original business record and includes a de-identified business object identifier, event type, event occurrence time, event content summary, and source platform identifier; S102. Based on the multi-platform candidate event fragment set and combined with the pre-configured business process constraint table, construct object evidence, sequence evidence, time evidence and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time and event content summary to generate a candidate business association set. Each candidate business association indicates that there is a usable candidate business association between two candidate event fragments. S103. Connect the directed connections in the candidate service association set into a fused service event chain, calculate the chain validity value of the corresponding fused service event chain, and generate a fused service event chain set. S104. Calculate the timeliness reliability value corresponding to the converged business event chain, convert the converged business event chain into a business converged data unit based on the timeliness reliability value, and output it to the enterprise-level data asset center.

[0021] Through the above steps, at least one of the multi-platform business data integration objects disclosed in this paper has been upgraded from traditional platform fields and wide table records to event fragments, candidate relationships, integrated business event chains, and time-sensitive and reliable business integration data organized around business processes. This enables the scattered records in transaction systems, online platforms, membership management systems, and supply chain systems to form analyzable data assets layer by layer according to a unified business logic.

[0022] In step S101, the original business records of multiple platforms are obtained, and a set of candidate event fragments for multiple platforms is constructed. Each candidate event fragment in the set of candidate event fragments for multiple platforms comes from an original business record and includes a de-identified business object identifier, event type, event occurrence time, event content summary and source platform identifier.

[0023] This step takes necessary original business records from the transaction system, online platform, membership management system, and supply chain system as input. Following pre-configured unified data standards and interface specifications, it converts these original records from different platforms into a unified set of multi-platform candidate event fragments. The system reads the necessary business records through the existing data interfaces of each platform. Specifically, data from the transaction system comes from the order status table, payment transaction interface, or order status message queue, reading records such as order creation, payment completion, refund initiation, and refund completion. Data from the online platform comes from event tracking logs, page behavior logs, or business gateway logs, reading records such as browsing, searching, clicking, adding to cart, and order submission. Data from the membership management system comes from the membership benefits transaction table or membership service interface, reading records such as changes in membership level, points changes, coupon redemption, and coupon redemption. Data from the supply chain system comes from the warehouse management system, logistics node interface, or fulfillment status table, reading records such as inventory locking, outbound delivery, distribution, and receipt. The system extracts data according to the fields required for business event fusion, retaining the business object field, action field, time field, summary field, and source field, while excluding information unrelated to business event fusion, such as ID card number, biometric information, health information, and precise address, from the collected fields.

[0024] In addition, when the system reads interface data, it synchronously records the interface name, interface batch number, data table version, message queue offset or interface return sequence number, and verifies whether the original record is missing necessary fields, whether it is reported repeatedly, whether the time field is empty, and whether the action field falls into the event mapping rule table. If the original record is missing necessary fields or the interface batch is abnormal, the record enters the interface abnormal record area and does not participate in the generation of normal candidate event fragments.

[0025] Furthermore, after reading the original business records, the system determines the position of each field in the candidate event fragment according to a unified field mapping rule. The business object field is used to form a de-identified business object identifier, the action field is used to determine the event type, the time field is used to determine the event occurrence time, the summary field is used to form an event content summary, and the source field is used to determine the source platform identifier. For example, in online platform logs, the device account or login account is used as the business object field, `add_cart` as the action field, `click_time` as the time field, the product number and page number as the summary field, and the online platform interface number as the source field; in the transaction system, the order account or order association number is used as the business object field, `paid` as the action field, `pay_time` as the time field, the order number and product summary as the summary field, and the transaction system interface number as the source field. For business object fields, the system converts them into de-identified business object identifiers through an internal unified identity mapping interface or account mapping table. The same original object generates a stable de-identified business object identifier within the same enterprise data domain, while different original objects generate different identifiers. If the identity mapping interface returns multiple candidate objects, the system marks the record as having uncertain object mapping and retains the candidate object set and mapping basis, but does not directly use it as a stable object identifier record. If identity mapping fails but the record contains an order summary, product summary, logistics association number, or fulfillment batch number, the system still generates a weakly identified candidate event fragment and saves a summary field in the event content summary that can be used for subsequent supplementary associations. For supply chain records containing only a logistics association number or fulfillment batch number, the system writes this field as a business association clue into the event content summary, enabling the record to participate in the subsequent judgment of candidate business association relationships. For action fields, the system converts them into a unified event type according to a pre-configured event mapping rule table. For example, in the online platform logs, view_goods is mapped to a browsing event, add_cart is mapped to a shopping cart event, create_order in the transaction system is mapped to an order placement event, paid is mapped to a payment event, coupon_write_off in the membership system is mapped to a coupon usage event, warehouse_out in the supply chain system is mapped to an outbound event, and delivery_signed is mapped to a delivery confirmation event. This converts technical fields from different platforms into a unified business semantics. If an action field does not match the event mapping rule table, the system writes the original record to the unmapped action record area and retains the original action field and the source platform identifier.

[0026] After completing the field mapping, the system converts each original business record into a candidate event fragment. The data structure of the candidate event fragment is represented as follows: ; in, Indicates the first Each candidate event fragment is generated by the event conversion module based on an original business record; This indicates the de-identified business object identifier, obtained by converting the original account, member number, device number, and order association identifier using the unified identity mapping interface or account mapping table. It is used when identity mapping fails but the summary field is available. It can be empty and by To handle weakly related clues; Indicates the event type, which is determined by the event mapping rule table based on the original action field or status field; This indicates the time when the event occurred, derived from the business action time field in the original business record. If the same record contains both the business action time and the system write time and the interface push time, the business action time will be used. This represents a summary of the event content, consisting of necessary fields from product summary, order summary, rights summary, or fulfillment summary. This indicates the source platform identifier, written by the data access interface when reading records, used to distinguish between transaction systems, online platforms, membership management systems, or supply chain systems. The system also stores the original record index, interface batch number, field mapping version number, identity mapping version number, time source marker, and data validity marker in the extended fields of the candidate event fragment, enabling... The five core fields in the system allow for tracing back to the original business records. For example, when an online platform generates an add-to-cart log, the original record includes the device account, product number, action name "add_cart," and action time. The system then converts the device account into... Map add_cart to Write the action time Write the product number and page summary. Write the online platform identifier into This forms a candidate event fragment; the transaction system generates a payment completion record, the original record including order account, order number, payment status (paid), and payment completion time. The system converts the order account into... Map the paid date to a payment event and write the payment completion time to it. Write the order number and product summary. Write the transaction system identifier to This forms another candidate event fragment.

[0027] For the time field, the system adopts a unified time selection rule, enabling candidate event fragments generated by different platforms to enter subsequent processing under the same time caliber. Online platforms use the user behavior occurrence time, transaction systems use the order status change time, membership systems use the equity change time, and supply chain systems use the fulfillment node scan time. When a platform only provides the system write time, the system will write that system write time. and in The system retains a time source description. If the time field is empty, the format cannot be parsed, or it is earlier than the minimum business time allowed by the system, the system will not output the record as a normal candidate event segment, but will write it to the time anomaly record area. If there are differences in time zones or time units between different platforms, the system will first convert it to a unified time base according to the time zone, millisecond / second unit, and time correction rules in the interface configuration, and then write it to the time source area. .

[0028] Understandably, taking a typical business process as an example, a de-identified business object generates an add-to-cart event on the online platform at 09:02, a coupon redemption event on the membership system at 09:03, a payment event on the transaction system at 09:05, and a delivery event on the supply chain system at 10:20. The system generates four candidate event fragments, and retains the same or related de-identified business object identifier in each fragment. Corresponding Each necessary and corresponding These candidate event fragments are written to the unified event buffer and, based on... ,,and Establish a basic search index; for de-identified business object identifiers Empty but The system creates a summary retrieval index for weakly identified fragments containing order summaries, product summaries, or fulfillment summaries, enabling the next processing step to quickly retrieve potentially relevant candidate event fragments based on business object, event type, time range, summary field, and source platform.

[0029] The output of this step is a multi-platform candidate event fragment set. Each candidate event fragment in this set comes from an original business record and has a unified data structure, including a de-identified business object identifier, event type, event occurrence time, event content summary, and source platform identifier. This output serves as input for the next step of generating a candidate business relationship set, used to further determine whether different candidate event fragments may belong to the same business process. The system also outputs unmapped action records, object mapping uncertain records, time anomaly records, and interface anomaly records.

[0030] In step S102, based on the multi-platform candidate event fragment set and combined with the pre-configured business process constraint table, object evidence, sequence evidence, time evidence and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time and event content summary are constructed to generate a candidate business association set. Each candidate business association indicates that there is a usable candidate business association between two candidate event fragments.

[0031] Specifically, the multi-platform candidate event fragment set output in step S101 is used as input, and the candidate event fragments are used directly. De-identification of business object identifiers in Event Type Time of the incident Summary of Event Content and source platform identifier This step establishes candidate business relationships between candidate event fragments, forming a set of candidate business relationship relationships. These relationships indicate whether two candidate event fragments are qualified to enter the same business process. For example, an online platform's add-to-cart fragment can form a "behavior-to-transaction" relationship with a transaction system's payment fragment, and the transaction system's payment fragment can form a "transaction-to-fulfillment" relationship with a supply chain system's outbound fragment. This step follows the unified event representation already completed in step S101, enabling discrete fragments generated by different platforms to be judged pairwise under a unified structure, providing clear association edges for the next step of generating a fused business event chain.

[0032] If a candidate event fragment is marked as an interface anomaly, time anomaly, or unmapped action record in step S101, it will not be included in the normal candidate business association calculation; if the candidate event fragment is only a weak identifier fragment, it can only participate in the candidate judgment through summary supplementation, and the source of the weak identifier will be saved in the association record.

[0033] The system first reads candidate event fragments from the multi-platform candidate event fragment set, and then, based on... Establish a temporary associated cache area. This cache should contain business objects with the same de-identified identifier. Candidate event fragments are placed in the same cache; for de-identified business object identifiers Empty but event summary The system reads event content summaries of other candidate event fragments within adjacent business time ranges, including candidate event summaries, product summaries, rights summaries, or fulfillment summaries. And perform a summary consistency comparison. For example, an outbound segment in a supply chain system may only have a logistics association number or fulfillment batch number, but its event content summary... If a transaction fragment contains both a product summary and an order summary, and the payment fragment in the transaction system also contains the same product summary and order summary, then that outbound fragment is included in the same candidate judgment range as the payment fragment. This cache is used to narrow down the judgment range and avoid establishing irrelevant comparisons between all event fragments.

[0034] The adjacent business time range is configured by event type in the business process constraint table; if this range is not configured, the system uses the platform's default candidate range and saves the default range marker in the associated record; if the business object identifier is removed... If both the key summary and the candidate event fragment are empty, the fragment is saved as an isolated fragment and no candidate business relationship is established with other fragments.

[0035] Furthermore, the system then reads a pre-configured business process constraint table to determine the allowed sequence relationships and allowed connection types between different event types. This constraint table is derived from the enterprise's existing business processes, interface specifications, and order fulfillment rules. For example, a browsing event can be connected to an add-to-cart event, an add-to-cart event can be connected to an order placement event or a payment event, a coupon usage event can be connected to a payment event, a payment event can be connected to a shipment event, and a shipment event can be connected to a receipt event. The system will then select any two candidate event fragments... and As the object to be judged, candidate business relationships are generated based on object evidence, sequence evidence, time evidence, and conflict evidence. A gating judgment method is used here, rather than simply adding multiple ratio values; its basis lies in set judgment and logical conjunction rules in mathematics, that is, elements in the target set are generated only when multiple necessary conditions are simultaneously met. This application further specifies the necessary conditions as object consistency, process reachability, time reachability, and conflict resolution in multi-platform business event fusion scenarios, thus giving each candidate relationship a clear engineering meaning. If the business process constraint table is missing... and For the corresponding connection type, the system will not generate candidate business associations for that event type pair and will record the reason for the missing constraints to avoid unconstrained connections leading to incorrect cross-process associations.

[0036] Candidate event fragments and Whether the conditions for forming a candidate business relationship exist between them is determined according to the following formula: ; in, Representing candidate event fragments With candidate event fragments The correlation determination results between them This indicates that a candidate business relationship record is generated between the two. This indicates that no candidate business relationship record will be generated between the two. The level of evidence for an object is indicated by... and Whether they are consistent and and The consistency of the order summary, product summary, rights summary, or fulfillment summary is determined. For example, if the de-identified business objects are consistent and the product summaries are consistent, the higher level is taken; if the de-identified business objects are missing but the order summaries are consistent, the middle level is taken; and if the object identifier and the summary cannot correspond, the lower level is taken. This indicates the threshold of required object evidence for the current event type, determined by... and The corresponding business connection type is determined. For example, "payment to outbound" requires the order summary or fulfillment summary to reach a high threshold, while "browse to add to cart" mainly requires the same de-identified business object to reach a threshold. Indicating the order of evidence, by and The sequential relationship in the business process constraint table is determined, allowing the direction to be true and disallowing the direction to be false; Indicating time evidence, by and Whether the event falls within the allowed business span of this event type is determined; if it falls within the allowed business span, the event is valid; otherwise, it is invalid. The evidence of a conflict is determined by whether there is a summary conflict, order conflict, or stage conflict within the same cache area. A conflict is established if a conflict exists, and not if no conflict exists. All terms in this formula are directly determined by the candidate event fragment's own fields and the preset business rule table. Used only as a binary determination result. If Not configured or Missing or If it fails to map to the business process constraint table, the system will directly... And save the reason for the lack of association; , , , and The value and its source are written into the candidate decision log.

[0037] It should be noted that the system calculation First compare and Compare again and Key summary in the text. For the online platform add-to-cart segment and the transaction system payment segment, if both... If the evidence is consistent and the product summary is consistent, then the level of evidence for the object reaches the threshold for the "behavior to transaction" connection; for the payment segment of the transaction system and the outbound segment of the supply chain system, even if the supply chain segment lacks a stable... As long as the fulfillment summary matches the payment segment order summary, it can also meet the threshold for the "transaction to fulfillment" connection. (System calculation) At that time, read and The allowed directions in the business process constraint table include, for example, adding to purchase before payment, payment before shipment, and signing for receipt before payment. The system calculates... At that time, the system reads the corresponding business scope based on the event type. For example, browsing to adding to cart applies to the behavior decision scope, adding to cart to payment applies to the transaction decision scope, payment to shipment applies to the fulfillment processing scope, and shipment to receipt applies to the delivery scope. The system calculates... At that time, the system checks whether there are competing segments within the same cache area. For example, if the same de-identified business object has two payment segments with different product summaries within a similar business time, and the current add-to-cart segment only matches one of the product summaries, then there is conflict evidence between the payment segments that do not match the other product summary. If there are multiple candidate connections of the same level in the same cache area and they cannot be distinguished by summary, time, or stage order, the system does not arbitrarily select a unique connection among these candidates. Instead, it saves the multiple candidate conflict states and submits them to the chain validity and conflict count in step S103 for further filtering.

[0038] For example, in a typical e-commerce business process, a de-identified business object generates an "add to cart" event on the online platform at 09:02, a coupon usage event in the membership management system at 09:03, a payment event in the transaction system at 09:05, and a shipment event in the supply chain system at 10:20. Regarding the "add to cart" event... Payment events ,both Consistent and The product descriptions are consistent. Reaching the threshold for connecting "behavior to transaction" ; For the add-on purchase event, This is a payment event, and it falls under the allowed direction in the business process constraint table. ; and Within the permitted business scope from adding to cart to payment, No competing payment fragments corresponding to this product summary were found within the same cache area. Substituting into the decision equation, The system generates a candidate business association linking the add-to-cart event to the payment event. If another payment event exists for the same de-identified business object within an adjacent time period, but its product summary is inconsistent with the add-to-cart event, then that fragment pair... Unable to meet the corresponding threshold, or Because the competing payment segment was established, This is incorrect, thus avoiding the mistaken connection of different products or different orders.

[0039] Furthermore, when generating candidate business relationships, the system executes the process in the following order: priority for similar objects, summary supplementation, stage constraints, and conflict resolution. The system first prioritizes similar objects... The candidate event fragments are evaluated to prioritize event fragments under stable business objects for candidate connections; subsequently, the process is repeated. Missing but The system supplements fragments containing order summaries, product summaries, or fulfillment summaries to enable weakly identifying data such as supply chain fulfillment records and logistics node records to participate in business integration; then, based on... and The corresponding business stage restricts the connection direction, causing events such as browsing, adding to cart, using benefits, payment, shipment, and receipt to form candidate connections according to the enterprise's business processes; finally, through... Handling competitive relationships arising from multiple orders, multiple products, and multiple fulfillment batches. Whenever... At that time, the system writes a record into the candidate business relationship set by point to The system identifies candidate business relationships and saves the starting and ending segments of the relationships, the relationship type, and key relationship criteria. The relationship type is determined by... and The corresponding business stages are defined, such as "from action to transaction," "from rights to transaction," "from transaction to performance," and "from performance to receipt." Key correlation evidence comes from... , , , and The specific values ​​include, for example, the same de-identified business object, consistent product summary, adding to cart before payment, payment to shipment within the allowed span, and the connection between the online platform and the transaction system formation stage. The system also saves the judgment batch, constraint table version, weak identifier flag, multiple candidate conflict flag, and non-association reason in the candidate business relationship record, so that the candidate association generation process can be traced by subsequent chain merging and manual verification.

[0040] The output of this step is a set of candidate business relationships. Each candidate business relationship in this set is formed from the candidate event fragments output in step S101, and carries the relationship start fragment, relationship end fragment, relationship type, and key relationship basis. This output serves as the input for the next step to generate a set of fused business event chains, enabling the next step to perform chain merging based on the completed candidate relationship screening, forming a fused business event chain that can represent the complete business process. Isolated fragments, weakly identified fragments, and multi-candidate conflict fragments that have not formed candidate business relationships are also retained in the candidate decision log, but are not directly output as high-reliability links.

[0041] In step S103, the directed connections in the candidate service association set are concatenated into a fused service event chain, and the chain validity value of the corresponding fused service event chain is calculated to generate a fused service event chain set.

[0042] Specifically, using the candidate business association set output in step S102 as input, the candidate business associations are further concatenated into a fused business event chain set. The candidate business association set stores information from... The generated candidate business relationship records each include a starting fragment, an ending fragment, a relationship type, and key relationship criteria. Therefore, this step uses these candidate business relationship records as the basis for chain-like merging. The system will then merge the candidate event fragments... Treat them as event nodes in the business process, The corresponding candidate business relationship records are regarded as available directed connections between event nodes, and the partial relationships in the online platform, member management system, transaction system and supply chain system are organized into a complete or near-complete business process chain according to the business process constraint table pre-configured by the enterprise.

[0043] For example, step S102 has already generated candidate business relationship records such as "browsing event to add-to-cart event", "add-to-cart event to coupon usage event", "coupon usage event to payment event", "payment event to outbound event", and "outbound event to receipt event". This step generates a fusion business event chain that represents the user's journey from online behavior, benefit usage, transaction completion to supply chain fulfillment along these directed connections. If the candidate business relationship set is empty, the system does not generate a normal fusion business event chain, but instead saves the candidate event fragments from step S101 as isolated fragments.

[0044] Furthermore, the system first reads the candidate service association set and establishes a directional connection structure. Each node in the directional connection structure corresponds to a candidate event fragment. Each directed connection corresponds to a link formed by... The system generates candidate business relationship records. Based on the starting and ending segments of these records, the system establishes connection directions and determines the corresponding business stage transition based on the relationship type, such as "behavior to transaction," "rights to transaction," "transaction to fulfillment," and "fulfillment to receipt." In the directional connection structure, the system retains the possibility of the same candidate event segment connecting to multiple subsequent segments. For example, the same add-to-cart event may connect to both coupon usage and payment events, and the same payment event may connect to outbound or refund events. This approach is suitable for real-world enterprise business scenarios because a single transaction may have different subsequent branches such as rights usage, payment, fulfillment, and refund. The system selects the more suitable path to enter the fused business event chain set by determining the validity of subsequent chains. When establishing the directional connection structure, the system checks for loops, duplicate edges, or reverse connections. If the same segment returns to itself via multiple connections, the system truncates the loop path and saves a loop anomaly marker to prevent infinite chain expansion through merging.

[0045] Furthermore, the integrated business event chain is generated using a directed path, based on the definition of a directed path in graph theory, where all adjacent nodes in the path are connected by directed edges. This application defines this directed path as a business process path, ensuring that each node in the path originates from a candidate event fragment generated in step S101, each edge originates from a candidate business association record generated in step S102, and the path direction conforms to the stage order in the business process constraint table. Integrated Business Event Chain Represented as: ; in, Indicates the first A chain of integrated business events is generated by the system along directed connections in the set of candidate business relationships; Indicates the first The first in the integrated business event chain The candidate event fragments are derived from the multi-platform candidate event fragment set output in step S101; Indicates the first The number of candidate event segments contained in a chain of integrated business events is determined by the number of candidate event segments actually connected in the chain merging process; Indicates adjacent segments within the chain and There are candidate business association records generated in step S102, among which and ; express The event occurrence time in the data is derived from the candidate event fragments. The fusion business event chain in this expression The data structure is a chain, with the right side showing the ordered arrangement of candidate event fragments and the adjacent connection constraints. The adjacent connection constraints ensure that adjacent events within the chain are supported by the candidate business association records of step S102, and the time order constraints ensure that events within the chain are arranged along the business process direction.

[0046] If adjacent segments have the same time, the system further determines the order based on the stage order in the business process constraint table; if adjacent segments have reversed time and cannot be explained by the interface delay rules, then the path is not output as a normal integrated business event chain.

[0047] Furthermore, the system is generated starting from the chain's origin. The starting point of a chain is determined by the incoming edges of candidate business relationships and the event type: when a candidate event fragment has no preceding candidate business relationship and its event type belongs to a stage in which a business process can begin, such as browsing, searching, adding to cart, or placing an order, the system uses it as the starting point of the chain; when a payment event in the transaction system has a subsequent relationship of outbound or receipt, and lacks a valid preceding behavior fragment, the system can also use the payment event as the starting point of a transaction fulfillment chain. Starting from the chain starting point, the system reads its subsequent candidate business relationships and adds candidate event fragments that satisfy the requirements of adjacent business stages, sequential event time, and continuous content summaries to the current chain. If a candidate event fragment has multiple subsequent fragments, the system retains multiple candidate chain paths simultaneously and filters them based on stage coverage and conflict conditions during the chain validity determination stage.

[0048] For example, after the same payment event, there may be both a warehouse release event and a refund event. The system will form a transaction fulfillment chain and a transaction refund chain respectively, and the type of chain to be retained will be determined by the target business stage configuration. The system also sets the maximum number of nodes and the maximum business span of a single chain. If the candidate path exceeds this range, it will stop further expansion and save the reason for truncation to avoid abnormal associations causing the chain to become too long.

[0049] In addition, during the chain expansion process, the system performs stage coverage and summary conflict determination for each candidate chain. This determination is based on the mathematical concept of set coverage, where the degree of coverage is represented by the proportion of the intersection between the target set and the actual set. This application defines the target set as the set of business stages that a certain type of business process should cover, and the actual set as the set of business stages already covered by the current integrated business event chain. Furthermore, a summary conflict deduction item is added to the coverage level to handle the common issues of multiple orders, multiple products, and multiple fulfillment batches in multi-platform business integration. The effective value of the integrated business event chain is calculated as follows: ; in, Indicates the first The valid value of each chain in the converged business event chain is used to determine whether the chain is written into the converged business event chain set; Indicates the first The integrated business event chain actually covers a set of business stages, consisting of the event types of each candidate event segment within the chain. The mapping results in events such as browsing and adding to cart being mapped to the behavior stage, coupon usage being mapped to the benefit stage, payment being mapped to the transaction stage, and outbound and receipt being mapped to the fulfillment stage. This indicates the set of target business stages that the current business type requires to be covered. It is pre-configured by the business process constraint table. For example, the ordinary transaction fulfillment process corresponds to the behavior stage, transaction stage, and fulfillment stage, while the membership marketing conversion process corresponds to the behavior stage, benefit stage, and transaction stage. Indicates the first The conflict count in a chain of integrated business events is obtained by summing the number of product summary conflicts, order summary conflicts, and fulfillment summary conflicts within the chain. Indicates the first The number of candidate event fragments contained in a chain of integrated business events. The first term of the formula represents the coverage of the target business stage, and the second term represents the degree to which in-chain summary conflicts weaken the stability of the chain. Both are proportional results and can be directly subtracted. The number of adjacent connections within the chain corresponds to the conflict deduction, ensuring it aligns with the chain's connection size. For records containing only one candidate event segment, the system saves them as isolated segments and excludes them from the valid value calculation process. If not configured or empty, the system will not perform normal calculations. Instead, it marks the candidate chain as missing in the target stage; if the calculated If the value is below 0, the system processes it as a low-trust chain and retains the original calculated value and the low-trust tag.

[0050] Furthermore, the system calculates the set of business stages. At that time, based on each candidate event fragment Event types in Read the business phase mapping table. For example, browsing events and add-to-cart events on the online platform are mapped to the behavior phase, coupon usage events in the membership system are mapped to the benefit phase, payment events in the transaction system are mapped to the transaction phase, and outbound events and receipt events in the supply chain system are mapped to the fulfillment phase.

[0051] The system calculates the set of target business stages that the current business type requires to be covered. At that time, the target stage set is read according to the main business type of the current chain. For example, for a transaction fulfillment chain with payment events and outbound events as the core, the target stages are behavior stage, transaction stage and fulfillment stage; for a member conversion chain with coupon usage events and payment events as the core, the target stages are behavior stage, rights stage and transaction stage.

[0052] The system calculates the first Conflict Counting in a Converged Business Event Chain At that time, examine each candidate event segment in the chain. If two inconsistent product summaries appear within the same chain and both participate in the transaction phase, it is recorded as a product summary conflict; if multiple inconsistent order summaries appear within the same chain and are all connected to the same fulfillment summary, it is recorded as an order summary conflict; if the same order summary is connected to multiple inconsistent fulfillment summaries, it is recorded as a fulfillment summary conflict. For Missing but For stable and consistent segments, the system does not directly identify them as summary conflicts, but instead writes a summary missing marker; for Missing and The missing segment will not enter the normal integrated business event chain.

[0053] Taking an online transaction fulfillment process as an example, the candidate business relationships consist of five consecutive relationships: a browsing event points to an add-to-cart event, the add-to-cart event points to a coupon usage event, the coupon usage event points to a payment event, the payment event points to a shipment event, and the shipment event points to a receipt event. The system generates a fused business event chain along these candidate business relationships. The chain contains 6 candidate event fragments, namely The set of actual business stages corresponding to the in-chain event types. The target business stages are categorized into action stage, rights stage, transaction stage, and performance stage; if the current business type is a typical transaction performance process, the target business stages are set as follows: If the stages are divided into the behavioral stage, the transaction stage, and the performance stage, then... , If the product summary, order summary, and fulfillment summary within the chain are consistent, conflict counts will be recorded. Substituting into the formula, we get The system writes this chain into the integrated business event chain set. If a payment event for another product is incorrectly accessed in the same chain, resulting in a product summary conflict, then... ,exist hour, When the chain validity threshold configured by the enterprise is 0.85, the chain is not written to the converged business event chain set, and the system retains business chains with consistent summaries and complete stage coverage. In this example... The effective threshold of the chain is determined by both stage coverage and conflict count, and is configured by the system parameter area and saved with the chain record.

[0054] The system advances step-by-step during chain expansion according to three conditions: stage continuity, platform complementarity, and low conflict. Stage continuity ensures that events expand along the business process direction; for example, a behavior stage connects to the rights or transaction stage, a transaction stage connects to the fulfillment stage, and the fulfillment stage connects to the receipt or after-sales stage. Platform complementarity prioritizes business chains covering multiple platforms; for example, chains containing event fragments from online platforms, membership management systems, transaction systems, and supply chain systems are more suitable as multi-platform integration results than chains containing only internal state changes within the transaction system. Low conflict prioritizes chains with consistent product summaries, order summaries, and fulfillment summaries when multiple candidate chains are generated from the same starting point. In cases where the same candidate event fragment is shared by multiple candidate chains, the system compares the performance of each chain. Chains with higher effective values ​​and more complete coverage of the target stage are prioritized for retention. The usage evidence for shared fragments is stored in the chain record for use in the next step of generating timely and reliable business fusion data. If multiple candidate chains... Similarly, the system prioritizes retaining chains with more complete source platform coverage, fewer weak identifier fragments, and fewer time breaks; unselected chains are saved as candidate chains and do not enter the high-reliability fusion business event chain set.

[0055] When the system writes the converged service event chain set, it saves the chain identifier, the order of candidate event segments within the chain, the candidate service association relationship between adjacent segments, the chain start segment, the chain end segment, the actual covered service stage set, the target service stage set, the conflict count, and the chain validity value for each converged service event chain.

[0056] The chain identifier is generated by combining the business object, the chain's starting event time, and a summary of the main transactions; the order of candidate event fragments within the chain comes from... In to The candidate service association relationships corresponding to adjacent segments are derived from the output of step S102. The actual set of covered business stages is obtained by mapping within-chain event types; the target set of business stages is determined by the business process constraint table; the conflict count comes from the consistency check of the event content summary within the chain; the chain validity value is jointly determined by the stage coverage ratio and conflict deduction. The system also saves the chain generation batch, chain validity threshold, business process constraint table version, loop truncation marker, alternative chain marker, and isolated fragment list, enabling the generation process of the fused business event chain to be traced and verified.

[0057] The output of this step is a set of fused business event chains. Each fused business event chain in this set is formed by concatenating the candidate business relationships output in step S102, and retains the order of event fragments within the chain, adjacent relationships, business stage coverage, conflict count, and chain validity value. This output serves as the input for the next step to generate timely and reliable business fusion data, enabling the next step to form business fusion data units that can be written to the enterprise-level data asset center based on the complete business chain. Candidate chains that do not reach the chain validity threshold and isolated fragments are not output as high-reliability chains, but their original fragments and reasons for not being included in the chain are still stored in the chain merging log.

[0058] In step S104, the timeliness reliability value corresponding to the converged business event chain is calculated, and the converged business event chain is converted into a business converged data unit based on the timeliness reliability value and output to the enterprise-level data asset center.

[0059] Specifically, using the fused service event chain set output in step S103 as input, timely and reliable service fused data is generated and output. Each fused service event chain in the fused service event chain set... The order of candidate event fragments within the chain, the relationship between adjacent candidate businesses, and the set of actual covered business stages have been saved. Target business stage set Conflict count Chain valid value Therefore, the system directly reads these chain-level results and combines them with candidate event fragments within the chain. De-identification of business object identifiers in Event Type Time of the incident Summary of Event Content and source platform identifier This step transforms the process chain into business-integrated data units that can be written into an enterprise-level data asset center. This transformation addresses the actual analytical needs of enterprises: business analysis systems need to know if a business process is complete, precision marketing systems need to know if the use of benefits is indeed linked to the transaction result, supply chain decision-making systems need to know if payment and fulfillment are continuous, and membership operation systems need to know if membership benefits participated in the conversion process. Therefore, this step further condenses the chain process results formed in step S103 into standardized business data with stage summaries, time series, source platform sets, and timeliness reliability status. The data objects output by this step are standardized machine-readable data units in the enterprise-level data asset center. Their core function is to reduce the repetitive cleaning, repetitive association, and repetitive judgment of link reliability in front-end systems, rather than directly replacing manual business decisions.

[0060] Furthermore, the system first reads each integrated business event chain. According to event type The system aggregates candidate event fragments within the chain according to the corresponding business stages. Browsing events, search events, and add-to-cart events on the online platform are categorized into the behavior stage; coupon redemption, coupon usage, and points changes in the membership management system are categorized into the benefits stage; order placement, payment, and refunds in the transaction system are categorized into the transaction stage; and inventory locking, outbound delivery, distribution, and receipt in the supply chain system are categorized into the fulfillment stage. Within each stage, the system categorizes events according to their occurrence time. Arrange candidate event fragments and extract event content summaries. The system extracts business summaries corresponding to each stage. For example, the behavior stage retains product and page summaries, the benefits stage retains coupon or points summaries, the transaction stage retains order and payment status summaries, and the fulfillment stage retains outbound and receipt summaries. If multiple candidate event segments exist in the same stage, the system forms an event sequence within the stage according to time order and retains the source platform identifier of each segment. This allows business data to be used directly for analysis and also traced back to its original business stage when needed. If a summary for a certain stage is missing but the chain's valid value reaches a threshold, the system writes a summary missing flag for that stage, instead of automatically replacing it with a summary from another stage.

[0061] The system then generates a timeliness reliability value based on the chain validity value, time continuity, and platform coverage. This calculation is based on the reliability concepts of serial systems and set coverage in reliability engineering: any anomaly in a serial system reduces overall reliability, and the proportion of the target set actually covered in set coverage represents the degree of target achievement. This application applies these two concepts to a multi-platform business data fusion scenario, using the chain validity value obtained in step S103... As the foundation of the business chain structure, time breaks between adjacent business stages are treated as connection anomalies in the serialization process, and source platform coverage is used as a constraint on the sufficiency of multi-platform integration. The final result indicates whether a fused business event chain can be used as stable business analysis data. The timeliness reliability value is calculated as follows: ; in, Indicates the first The timeliness reliability value corresponding to each integrated business event chain is calculated by the system based on the chain structure, time continuity and platform coverage. The valid chain value generated in step S103 is derived from the target business stage coverage and the internal summary conflict of the chain. Indicates the first The time break count in the integrated business event chain is obtained by the system checking the time span between adjacent candidate event segments one by one. For example, when the time span from the payment event to the outbound event exceeds the fulfillment processing span configured in the business process constraint table, it is counted as a time break. Indicates the first The number of candidate event fragments contained in a single integrated business event chain comes from... The number of event fragments in the data; Indicates the first The number of platforms actually covered by the integrated business event chain is determined by the source platform identifier of the candidate event fragments within the chain. The results were obtained through deduplication statistics; This indicates the number of target platforms required to be covered for the current business type. This number is configured in the business process constraint table based on the business type. For example, a typical transaction fulfillment process usually requires coverage of online platforms, transaction systems, and supply chain systems, while a membership marketing conversion process typically requires coverage of online platforms, membership management systems, and transaction systems. The formula... Used to support the chain structure mass in step S103 Used to represent the proportion of adjacent connections within a chain that have not experienced time breaks. Used to represent the actual platform coverage; all three are proportional results, and the product still represents the proportionalized reliability state. If Less than 2 If not configured or zero, the system does not perform normal calculation of the expression, but instead writes the chain to a state where the trusted value is not computable; if Exceed The system processes data based on complete coverage of the target platform, ensuring that all platform coverage items are represented and avoiding the loss of business meaning from additional platform records. If the calculated... If the value is below 0 or above 1, the system will limit the output according to the range of 0 to 1 and retain the original calculated value before limiting.

[0062] System calculates reliable timeliness value At that time, read adjacent candidate event fragments in the chain one by one. and The event type and occurrence time are determined, and the allowed business span for that event type pair is read from the business process constraint table. For example, the transaction decision span corresponds to adding to cart to payment, the fulfillment processing span corresponds to payment to shipment, and the delivery span corresponds to shipment to receipt. and If the interval between adjacent points is within the corresponding span, the adjacent connection remains continuous; if it exceeds the corresponding range, a time break is formed. System calculation. At that time, the source platform identifier for all candidate event fragments within the chain. Perform deduplication statistics.

[0063] For example, if a chain contains event fragments from online platforms, membership management systems, transaction systems, and supply chain systems, then the actual platform covered includes four types; if a chain only contains order placement, payment, and refund statuses from the transaction system, then the actual platform covered is only the transaction system.

[0064] System Calculation At that time, the system reads the target platform configuration based on the main business type of the chain. For example, transaction fulfillment-related businesses require data integration covering at least the online platform, transaction system, and supply chain system; membership conversion-related businesses require data integration covering at least the online platform, membership management system, and transaction system. Through this processing, the timeliness reliability value preserves the quality of the business chain structure while reflecting the temporal continuity of events within the chain and the degree of multi-platform integration. The system also saves the adjacent segment numbers, event type pairs, and allowed business spans corresponding to each time break, enabling... The source can be traced.

[0065] Taking a transaction fulfillment-related integrated business event chain as an example, the chain includes an online platform browsing event at 09:00, a shopping cart addition event at 09:02, a coupon usage event in the membership management system at 09:03, a payment event in the transaction system at 09:05, a delivery event in the supply chain system at 10:20, and a receipt event at 09:00 the next day. Step S103 calculates the chain based on stage coverage and digest conflict. The chain contains 6 candidate event fragments, therefore The system checks the business span of adjacent event segments. Browsing to adding to cart, adding to cart to coupon usage, coupon usage to payment, payment to shipment, and shipment to receipt all fall within the corresponding business span. Therefore... The chain actually covers online platforms, membership management systems, transaction systems, and supply chain systems, namely... Current transaction fulfillment businesses require coverage of online platforms, transaction systems, and supply chain systems, namely... Since the target platform has already been covered, the platform coverage value is taken as the maximum value. Substituting into the formula, we get... The system marks the business integration data corresponding to that chain as a high-timeliness and trustworthy state. If another chain also covers the behavior stage, transaction stage, and fulfillment stage, but the payment event and the outbound event exceed the fulfillment processing span, forming a time gap, and the chain only covers two platforms: the transaction system and the supply chain system, then... , , , , In the case of continuous time term, The platform covers the following items: Thus we obtain The system can write the preceding chain into direct analysis data and the following chain into data in a pending verification or low-trust state, based on the enterprise's configured trust threshold. This avoids chains with time gaps or insufficient platform coverage being directly used for core business analysis. (Example above) The calculation results and the output of step S103 The number of chain nodes, the time break count, and the coverage of the source platform are all matched one by one, without introducing any new external variables.

[0066] The system receives Subsequently, the integrated business event chain is converted into business integration data units. Each business integration data unit uses a de-identified business object identifier as the business object entry point and a chain identifier as the process entry point, and includes a summary of the behavior stage, a summary of the rights stage, a summary of the transaction stage, a summary of the performance stage, a stage time series, a set of source platforms, and a chain validity value. and timeliness reliability value The business object entry point comes from the candidate event fragment within the chain. The stage summary is derived from the aggregated data of each stage within the chain. The phase time series is derived from fragments of candidate events within the chain. Results arranged by business stage; source platform collection from candidate event fragments within the chain. Deduplication results; chain validity value From step S103; Timeliness confidence value This step calculates the results based on the chain validity value, time break count, and platform coverage. For transaction fulfillment-related business data, the system primarily retains the behavioral, transaction, and fulfillment stages; for membership conversion-related business data, it primarily retains the behavioral, benefit, and transaction stages; and for supply chain collaboration-related business data, it primarily retains the transaction and fulfillment stages, and also retains the time series from payment to outbound and from outbound to receipt. The system also saves a list of original fragments, a list of candidate associations, a merged business event chain identifier, a calculation version number, a trusted status, and a reason for pending verification for each business data unit, enabling the front-end system to directly read standardized objects and trace back to the original interface data when necessary.

[0067] The system writes timely and reliable business integration data into the enterprise-level data asset center according to a unified interface specification and outputs it to the front-end business systems. The business analysis system can analyze the conversion process from online behavior to transaction fulfillment based on business stage summaries and stage time series; the precision marketing system can determine whether a certain type of preferential benefit has achieved effective conversion based on behavior stage, benefit stage, and transaction stage; the membership operation system can identify the participation of member benefits in transactions based on benefit usage summaries and payment summaries; and the supply chain decision-making system can identify the stability of the order fulfillment process based on transaction stage, fulfillment stage, and time break count. When outputting data, the system retains the timely and reliable status, enabling the front-end system to distinguish between high-reliability business integration data, low-reliability business integration data, and business integration data awaiting verification, and select the corresponding data usage scope according to the business scenario. High-reliability data is written to the formal analysis data area, low-reliability data to the low-reliability data area, and data awaiting verification to the verification task queue. If subsequent manual or system verification confirms the correct correlation of low-reliability data, the system can update the reliability status based on the verification results and save the verification version, avoiding overwriting the original calculation records.

[0068] The output of this step is timely and reliable business fusion data. This data is generated from the fusion business event chain set output in step S103, and includes business object entry, business stage summary, stage time series, source platform set, chain validity value, and timely reliability value. It is provided as a standardized business analysis object in the enterprise-level data asset center for business analysis, precision marketing, membership operation, and supply chain decision-making systems to use.

[0069] Through the above processing, the candidate event fragments formed in step S101, the candidate business associations formed in step S102, the fusion business event chain formed in step S103, and the time-sensitive and reliable business fusion data formed in step S104 are continuously connected, enabling multi-platform interface data to be transformed from original heterogeneous records into standardized data objects with data lineage, link evidence, and reliable status.

[0070] This invention also provides a business data analysis system based on multi-platform data fusion, the system comprising: The candidate event fragment generation module is used to obtain original business records from multiple platforms and construct a multi-platform candidate event fragment set. Each candidate event fragment in the multi-platform candidate event fragment set comes from an original business record and includes a de-identified business object identifier, event type, event occurrence time, event content summary, and source platform identifier. The candidate association generation module is used to construct object evidence, sequence evidence, time evidence, and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time, and event content summary based on the multi-platform candidate event fragment set and combined with the pre-configured business process constraint table, so as to generate a candidate business association set. Each candidate business association indicates that there is a usable candidate business association between two candidate event fragments. The fusion event chain generation module is used to connect the directed connections in the candidate service association set into a fusion service event chain, calculate the chain validity value of the corresponding fusion service event chain, and generate a fusion service event chain set. The business integration data output module is used to calculate the timeliness reliability value corresponding to the integrated business event chain, convert the integrated business event chain into a business integration data unit based on the timeliness reliability value, and output it to the enterprise-level data asset center.

[0071] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0072] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or units may be electrical, mechanical, or other forms.

[0073] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0074] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and variations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A business data analysis method based on multi-platform data fusion, characterized in that, The method includes the following steps: Obtain original business records from multiple platforms and construct a multi-platform candidate event fragment set; each candidate event fragment in the multi-platform candidate event fragment set comes from an original business record and includes a de-identified business object identifier, event type, event occurrence time, event content summary, and source platform identifier; Based on the multi-platform candidate event fragment set and combined with the pre-configured business process constraint table, object evidence, sequence evidence, time evidence and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time and event content summary are constructed to generate a candidate business association set. Each candidate business association indicates that there is a usable candidate business association between two candidate event fragments. The directed connections in the candidate business association set are concatenated into a fused business event chain, and the chain validity value of the corresponding fused business event chain is calculated to generate a fused business event chain set. Calculate the timeliness reliability value corresponding to the converged business event chain, convert the converged business event chain into a business converged data unit based on the timeliness reliability value, and output it to the enterprise-level data asset center.

2. The business data analysis method based on multi-platform data fusion according to claim 1, characterized in that, The multiple platforms include a transaction system, an online platform, a membership management system, and a supply chain system; The de-identified business object identifier is obtained by converting the original account, member number, device number or order association identifier through a unified identity mapping interface or account mapping table; The event type is determined by the event mapping rule table based on the original action field or status field; the event occurrence time is the business action time. The event summary includes the necessary fields from the product summary, order summary, rights summary, or performance summary; the source platform identifier is used to distinguish between the transaction system, online platform, membership management system, or supply chain system.

3. The business data analysis method based on multi-platform data fusion according to claim 1, characterized in that, The pre-configured business process constraint table is used to determine the allowed sequence relationship and allowed connection type between different event types, and comes from the enterprise's existing business processes, interface specifications and order fulfillment rules.

4. The business data analysis method based on multi-platform data fusion according to claim 1, characterized in that, The object evidence is determined by whether the de-identified business object identifier is consistent and whether the order summary, product summary, rights summary or performance summary in the event content summary is consistent. The sequence evidence is determined by the order of the two event types in the business process constraint table; The time evidence is determined by whether the times of the two events fall within the allowed business span of the event type pair; The evidence of conflict is determined by whether there is a summary conflict, order conflict, or stage conflict within the same cache area.

5. The business data analysis method based on multi-platform data fusion according to claim 4, characterized in that, The conditions for generating the candidate business association relationship are as follows: The object evidence level meets the threshold required by the event type, the sequential evidence is valid, the temporal evidence is valid, and the conflicting evidence is invalid. Each candidate business relationship record includes the starting segment of the relationship, the ending segment of the relationship, the relationship type, and the key basis for the relationship.

6. The business data analysis method based on multi-platform data fusion according to claim 1, characterized in that, The step of connecting the directed connections in the candidate service association set into a fused service event chain specifically involves: The integrated business event chain is composed of candidate event fragments from the multi-platform candidate event fragment set arranged in a directed connection order. Each edge comes from the candidate business association relationship, and the time order constraint ensures that the events in the chain are arranged along the business process direction. If adjacent segments have the same time, the order is determined according to the stage order in the business process constraint table; if adjacent segments have reversed time and cannot be explained by the interface delay rules, the current path is not output as a normal integrated business event chain. The starting point of the integrated business event chain is determined by the incoming edge information of the candidate business association relationship and the event type. Starting from the starting point of the chain, the subsequent candidate business association relationship is read, and candidate event fragments that meet the requirements of adjacent business stages, sequential event time, and continuous content summary are added to the current chain. If a candidate event fragment has multiple successor fragments, multiple candidate chain paths are retained simultaneously, and the chain validity determination stage is used to filter them based on stage coverage and conflict status.

7. The business data analysis method based on multi-platform data fusion according to claim 6, characterized in that, The chain validity value is generated based on the intersection size of the actual set of business stages covered in the chain and the target set of business stages, the size of the target set of business stages, the chain summary conflict count, and the number of adjacent connections in the chain. The summary conflicts include product summary conflicts, order summary conflicts, and fulfillment summary conflicts; Among them, while connecting the directed connections of the candidate business association set into a fusion business event chain, the chain expansion is gradually promoted according to the three conditions of stage continuity, platform completion and low conflict. Phase continuity is used to ensure that events extend along the business process direction; platform completion is used to prioritize the retention of business chains that cover multiple platforms; low conflict is used to prioritize the retention of chains with consistent product summary, order summary and fulfillment summary when multiple candidate chains are generated at the same chain starting point. Finally, when writing the fused service event chain set, each fused service event chain saves the chain identifier, the order of candidate event segments within the chain, the candidate service association relationship between adjacent segments, the chain start segment, the chain end segment, the actual covered service stage set, the target service stage set, the conflict count, and the chain validity value.

8. The business data analysis method based on multi-platform data fusion according to claim 1, characterized in that, The reliability value of timeliness is based on the chain validity value of the corresponding integrated business event chain, the time break count, and the number of adjacent connections within the chain. The actual number of platforms covered and the target number of platforms are calculated and generated. The time break count is the number of times when the occurrence time of adjacent events within the chain exceeds the allowed business span configured in the business process constraint table.

9. The business data analysis method based on multi-platform data fusion according to claim 1, characterized in that, The business fusion data unit also stores the original fragment list, candidate association list, fusion business event chain identifier, calculation version number, trust status, and reason for verification; The trusted status includes high trust, low trust, and pending verification.

10. A business data analysis system based on multi-platform data fusion, characterized in that: The system includes: The candidate event fragment generation module is used to obtain original business records from multiple platforms and construct a multi-platform candidate event fragment set. Each candidate event fragment in the multi-platform candidate event fragment set comes from an original business record and includes a de-identified business object identifier, event type, event occurrence time, event content summary, and source platform identifier. The candidate association generation module is used to construct object evidence, sequence evidence, time evidence, and conflict evidence corresponding to the de-identified business object identifier, event type, event occurrence time, and event content summary based on the multi-platform candidate event fragment set and combined with the pre-configured business process constraint table, so as to generate a candidate business association set. Each candidate business association indicates that there is a usable candidate business association between two candidate event fragments. The fusion event chain generation module is used to connect the directed connections in the candidate service association set into a fusion service event chain, calculate the chain validity value of the corresponding fusion service event chain, and generate a fusion service event chain set. The business integration data output module is used to calculate the timeliness reliability value corresponding to the integrated business event chain, convert the integrated business event chain into a business integration data unit based on the timeliness reliability value, and output it to the enterprise-level data asset center.

Images