Private domain traffic competition relation quantitative generation method

Abstract

The invention discloses a private domain traffic competition relationship quantitative generation method, belongs to the technical field of business intelligent analysis, and aims to solve the problem that the competition relationship in a private domain scene is difficult to accurately quantify. Through an intelligent contract deployed in a block chain, user operation behaviors of each private domain scene are monitored in real time, and standardized tuple data and an operation data set are constructed. When new data is accessed, operation type codes are analyzed, key operations are identified, associated behaviors are retrieved by using a time window, and a causal association map of the key operations is constructed in combination with service priorities and time decay factors. And extracting map feature vectors, marking scene codes, dividing clustering categories, and triggering an updating mechanism to obtain a feature causal association map. And constructing a standardized behavior matrix based on the updated graph, quantifying the behavior mode similarity between scenes through a graph editing distance algorithm, generating a keyword vector in combination with semantic classification mapping, forming a private domain traffic competition relationship quantitative report, and providing data support for enterprise operation decision making.

Description

Technical Field

[0001] This invention relates to the field of business intelligence analysis technology, and more specifically to a method for quantifying and generating competitive relationships in private domain traffic. Background Technology

[0002] In the fields of digital marketing and private domain traffic operation, enterprises typically build private domain scenarios through diverse channels such as mini-programs, social groups, and membership apps. However, current technologies have significant shortcomings. User behavior data from various private domain scenarios are scattered across different systems, lacking a unified data model and quantitative standards across scenarios. This results in severe data silos, making it difficult to achieve systematic comparisons of behavioral patterns. Traditional competitive analysis often relies on manual experience or simple statistical methods, failing to accurately measure the similarity and differences in user operation sequences across different scenarios, especially struggling to dynamically capture changes in the topological structure of behavioral paths. The semantic parsing of user operations lacks industry-standardized classifications, making it difficult to effectively identify core conversion paths and scenario-specific characteristics, leading to a blurred competitive advantage positioning. Simultaneously, the lack of data traceability mechanisms and credible evidence storage systems results in insufficient traceability of analysis results and insufficient credibility for decision support. These technical issues lead to multiple challenges for enterprises in private domain operations, including cross-scenario data integration, competitive relationship quantification, advantage feature identification, and strategy optimization attribution. Therefore, to overcome these limitations, this invention proposes a method for quantifying and generating private domain traffic competitive relationships. Summary of the Invention

[0003] To address the shortcomings of existing technologies, the present invention aims to provide a method for quantifying and generating competitive relationships in private domain traffic, thereby solving the technical problems of scattered user behavior data, difficulty in quantifying competitive relationships, and lack of data support for operational strategies in private domain traffic scenarios.

[0004] To achieve the above objectives, the present invention provides the following technical solution:

[0005] The method for quantifying competition relationships in private domain traffic includes the following steps:

[0006] Deploy smart contracts to monitor user operation behavior in various private domain scenarios, collect user operations under operational operations in each private domain scenario, form tuple data, and then build an operation dataset;

[0007] By parsing the user operation type code, it is determined whether it belongs to a critical operation. If so, a causal relationship dataset of critical operations is constructed by retrieving data through a time window. Based on the user's business priority, the user operations in the causal relationship dataset are assigned basic weights, and the basic weights are corrected by a time decay factor to construct a causal relationship graph of critical operations.

[0008] Extract the feature vectors of the causal association graph, label them with private domain scene codes, divide the causal association graphs under the private domain scene codes into cluster categories, and obtain the feature causal association graphs of each cluster.

[0009] Clustering categories are updated by triggering, and when the update conditions are met, a standardized behavior matrix is ​​constructed according to the private domain scenario encoding and cluster category dimension. The structured similarity matrix is ​​used to quantify the relationship of behavior patterns between private domain scenarios, and keyword vectors of private domain scenarios are generated through semantic classification mapping to generate a quantitative report on the competition relationship of private domain traffic.

[0010] Specifically, the steps for triggering an update of cluster categories include:

[0011] When generating the causal relationship graph of key operations, the nodes and edge weights of the causal relationship graph are mapped to graph feature vectors.

[0012] Calculate the similarity distance between the feature vector of the current causal association graph and the feature causal association graph of the historical cluster category. If the similarity distance is greater than the preset distance threshold, the current causal association graph is assigned to the candidate group to be clustered; otherwise, the current causal association graph is assigned to the cluster category to which the corresponding feature causal association graph belongs.

[0013] The number of causal association graphs to be clustered in the candidate groups to be clustered is counted, and the time interval since the last causal association graph clustering update is obtained. If the number of causal association graphs to be clustered is greater than a preset number threshold or the time interval is greater than a preset update time threshold, the causal association graph clustering update is triggered.

[0014] Specifically, the steps for obtaining the feature causal relationship map of each cluster include:

[0015] When the causal relationship graph clustering update is triggered, the smart contract reads the configuration parameters for the re-evaluation of historical clustering categories, including cluster compactness and member stability.

[0016] If the cluster compactness of a historical cluster category is less than a preset compactness threshold, or the member stability of a historical cluster category is less than a preset stability threshold, then the historical cluster category is marked as needing to be re-clustered in order to construct a re-clustering group.

[0017] Extract the spectral feature vectors of the causal relationship graphs of the candidate groups to be clustered and the groups to be re-clustered, construct a feature vector set, and standardize the spectral feature vectors of the feature vector set.

[0018] Set the neighborhood radius and minimum number of samples for the clustering algorithm, and then cluster the feature vector set using the clustering algorithm;

[0019] For the causal association graph in each cluster category, extract the node sequence with a frequency greater than a preset frequency threshold, construct the core behavioral path, and use it as the feature causal association graph of that cluster category;

[0020] The edge weights of the feature causal relationship graph are generated by weighted aggregation based on the edge weights between nodes within the cluster category.

[0021] Specifically, the steps for generating a quantitative report on private domain traffic competition include:

[0022] The smart contract extracts the feature causal relationship graphs of all cluster categories under each private domain scenario, analyzes the node sequence and edge weight in the feature causal relationship graphs, and constructs a standardized behavior matrix according to the private domain scenario encoding and cluster category dimension.

[0023] The graph editing distance algorithm is used to calculate the structural differences of standardized behavior matrices in different private domain scenarios. The similarity of the minimum cost matrix required for node addition, deletion and edge weight adjustment operations is quantified.

[0024] Based on the matrix similarity of standardized behavior matrices for different private domain scenarios, a structured similarity matrix is ​​constructed. In the structured similarity matrix, the rows and columns correspond to the private domain scenario codes, and the matrix similarity is stored in the intersecting cells.

[0025] The node sequence of the feature causal association graph is mapped to a natural language description, and the semantic classification of the nodes is associated through a semantic classification mapping table.

[0026] Calculate the TF-IDF value of semantic classification in each private domain scenario and generate keyword vectors specific to the private domain scenario;

[0027] Based on the structured similarity matrix and keyword vectors between different private domain scenarios, a hierarchical clustering algorithm combined with TF-IDF weight threshold filtering is used to identify the associated scenario groups and their characteristic operations in private domain scenarios, and a quantitative report on the competitive relationship of private domain traffic is generated.

[0028] Specifically, the steps for constructing a causal relationship graph of key operations include:

[0029] A predefined business rule base is used to classify user operations into critical operations and ordinary operations.

[0030] Based on a predefined business rule base, smart contracts parse the user operation type encoding in tuple data and determine whether the user operation type is a critical operation.

[0031] If so, the time window configuration parameters are retrieved, the tuple data within the time window is located, and a causal relationship dataset of key operations is constructed. The time window configuration parameters are used to constrain the time range for tracing.

[0032] The tuple data in the causal association dataset is processed hierarchically according to the user operation type, and sorted based on the operation timestamp and business priority matrix to construct historical key operation sequences and historical ordinary operation sequences.

[0033] Based on the business priority of the current user operation, the basic weight sequence of historical key operation sequence and historical ordinary operation sequence are assigned respectively by the difference of business priority;

[0034] Specifically, obtaining the basic weight sequence includes:

[0035] Obtain the business priority sequence of historical key operations, execute progressive weight determination logic, and determine whether the business priority of the historical key operation is less than the business priority of the current key operation. If not, set the base weight of the historical key operation to 0.

[0036] If so, the base weight of historical critical operations will be set to the reciprocal of the difference between the business priority of the current critical operation and the historical critical operation.

[0037] Obtain the business priority sequence of historical ordinary operations, and set the base weight of the historical ordinary operations to the reciprocal of the difference between the business priority of the current critical operation and the historical ordinary operations.

[0038] Specifically, the steps for constructing a causal relationship graph of key operations also include:

[0039] Based on the time interval between the operation timestamps of historical user operations and the current critical operation in the historical critical operation sequence and the historical ordinary operation sequence, a time decay factor is calculated according to a preset decay coefficient. The basic weight sequence is then weighted and corrected based on the time decay factor to form the weight sequence.

[0040] Configure a weight threshold to remove historical user operations whose weights are less than the weight threshold from the weighted sequences of historical critical operation sequences and historical ordinary operation sequences;

[0041] Based on the weighted sequence, construct a causal relationship graph between the current key operation and historical key operation sequences, as well as historical ordinary operation sequences, that is:

[0042] Using the current critical operation as the core node, historical critical operations are arranged in descending order of weight as first-level child nodes, and historical ordinary operations are arranged in descending order of weight as second-level child nodes. Each node is connected by a weighted directed edge, and the time interval and priority difference are marked.

[0043] Specifically, the steps for constructing the operational dataset include:

[0044] During the smart contract deployment phase, a pre-set data collection template is used to standardize the scope and format of operational data collection.

[0045] By scanning each private domain scenario through distributed nodes, authorization verification is performed when a user visits a private domain scenario for the first time. If the verification is successful, the event monitoring of the smart contract is triggered, and operation behavior monitoring is started; if the verification fails, the silent exit logic is executed.

[0046] When a user's actions are detected in an authorized private domain scenario, the smart contract triggers data collection, starts a minimal collection process based on the data collection template, extracts the user operation type code, operation timestamp, operation operation code and private domain scenario code, and constructs tuple data consisting of user operations.

[0047] User operation type code is used to represent the code assigned after classifying user operation behavior; operation timestamp is used to record the time mark when the user operation occurs; operation operation code is used to represent the code of operation operation initiated in private domain scenario, and to locate the operation operation in which the user operation occurs; private domain scenario code is used to represent the code of private domain scenario carrier, and to locate the private domain scenario in which the user operation occurs.

[0048] Specifically, the steps for constructing the operational dataset also include:

[0049] Once the tuple data is constructed, the smart contract stores it in the operation dataset according to a three-level indexing system;

[0050] The three-level index system creates a B+ tree index based on the operation timestamp and stores it in shards according to the time window of the operation timestamp; it adopts an inverted index structure, using the private domain scenario code as the first-level key and the user operation type code as the second-level key to store user operation records in the private domain scenario; and it builds an adjacency table centered on the operation operation code to store user operations that participated in the operation operation.

[0051] Specifically, cluster compactness is used to evaluate the tightness of the causal association graphs within a cluster, and is obtained by calculating the mean cosine similarity of the graph feature vectors of the causal association graphs within the cluster and the feature causal association graphs; member stability is used to evaluate the degree of structural change of the clusters over time, and is obtained by comparing the overlap rate of the causal association graphs in the current cluster category with the causal association graphs at the time of the last cluster update.

[0052] The beneficial effects of this invention are:

[0053] This invention achieves standardized collection and trusted storage of user behavior data across multiple private domain scenarios through blockchain smart contracts. It utilizes a graph edit distance algorithm to quantify the similarity of cross-scenario behavior matrices and combines TF-IDF to extract scenario-specific labels, solving the problems of traditional data silos and ambiguous competitive quantification. By dynamically adjusting weights through a time decay factor, it ensures that the causal relationship graph reflects the temporal logic of behavior, and its hierarchical structure enables hierarchical modeling of behavioral paths, presenting differences in operational causal levels. Graph embedding and density clustering are used to achieve graph dimensionality reduction and high-frequency pattern extraction. The generated structured similarity matrix and keyword vectors can be fused to analyze scenario group characteristics. The cross-scenario competitive analysis mechanism, by quantifying the similarity of behavior matrices and extracting scenario-specific vectors, helps enterprises identify differences in conversion paths and competitive advantages, providing data support for resource allocation and strategy optimization.

[0054] Compared to existing technologies, this invention combines blockchain distributed governance with a hierarchical weight design of causal relationship graphs. It achieves accurate measurement of behavioral correlations through dynamic coupling of business priority matrix and time decay factor, breaking through the limitations of traditional static analysis. By integrating structured similarity matrix and semantic classification mapping, it constructs a complete quantitative link from behavioral data to competitive strategies, forming a systematic innovation for private domain traffic competition. It provides enterprises with quantitative reports containing scenario correlation and core operational differences, improving the scientific nature of decision-making and operational efficiency. Attached Figure Description

[0055] Figure 1 This is a flowchart of the method for quantifying and generating private domain traffic competition relationships according to the present invention;

[0056] Figure 2 A flowchart illustrating the specific steps involved in constructing the dataset according to this invention;

[0057] Figure 3 A flowchart outlining the specific steps involved in constructing a causal relationship graph of key operations for this invention;

[0058] Figure 4 This is a flowchart illustrating the specific steps involved in triggering updates to clustering categories according to the present invention.

[0059] Figure 5 This is a flowchart illustrating the specific steps involved in obtaining the feature causal relationship map for each cluster according to the present invention. Detailed Implementation

[0060] Example 1

[0061] Please see Figure 1 This embodiment introduces a method for quantifying and generating private domain traffic competition relationships, including the following steps:

[0062] Step S1: Smart contracts deployed on the blockchain continuously monitor user actions in various private domain scenarios. When a user completes active authorization confirmation and triggers a user action event, a minimal data collection process is automatically initiated to collect user actions under operational operations in each private domain scenario. This ensures that any record is indistinguishable under a combination of quasi-identifiers, ultimately constructing an operation dataset that conforms to the principle of minimum necessity. The smart contracts deployed on the blockchain are used to implement a distributed decision-making mechanism involving multiple stakeholders, and to collaboratively govern major matters such as system parameters and rule updates through consensus algorithms.

[0063] In this embodiment, smart contracts are deployed on the blockchain to monitor user operation behaviors in various private domain scenarios. After user authorization, tuple data such as operation type codes and timestamps are collected according to the principle of minimum necessity to form an operation dataset. The operation dataset is stored through a three-level indexing system. User operation types are analyzed to identify key operations, and a causal relationship graph is constructed by combining time windows, business priority matrices, and time decay factors. A graph embedding model is called to extract graph feature vectors, and a feature causal relationship graph is generated through similarity calculation and clustering algorithms. A standardized behavior matrix is ​​constructed based on the feature graph, and a structured similarity matrix and keyword vectors are generated using graph edit distance algorithms and TF-IDF technology. Finally, a quantitative report on the competition relationship of private domain traffic is generated by merging these components. At the same time, the data collection rules are stored on the blockchain, multi-entity collaborative governance is achieved, and the report hash value is stored on the blockchain.

[0064] Deployed on the blockchain, smart contracts continuously monitor user activity events in private domain scenarios such as brand mini-programs, WeChat groups, and member apps through distributed nodes. When a user enters the mini-program for the first time, the client triggers a user data authorization pop-up based on the smart contract. This pop-up is designed and configured according to current laws and regulations on personal information protection or data compliance requirements, clearly stating the scope of data collection and its purpose. After the user clicks the "agree" button, the smart contract generates an authorization hash value and stores it on the blockchain for evidence. Subsequently, when the user performs actions such as adding items to their cart or sending messages to a group, the contract triggers a minimal data collection process: extracting only necessary fields such as operation type, timestamp, and scenario ID, and ensuring that sensitive information such as names and phone numbers are not included in the data records. The processed data is verified for compliance by the smart contract, stored in the blockchain distributed ledger according to scenario categories, and the collection rules, authorization records, and processing logs are also uploaded to the blockchain as smart contract events, achieving traceability of the data source and auditability of the collection process.

[0065] Please see Figure 2 Preferably, the specific steps for constructing the dataset include:

[0066] During the smart contract deployment phase, a multi-signature governance mechanism is used to pre-define data collection templates. These templates standardize the scope and format of data collection, providing a standardized basis for subsequent data collection operations. The multi-signature governance mechanism requires multiple authorized entities to jointly sign and confirm before it takes effect. By distributing decision-making authority, it ensures the security and consensus of the data collection rule pre-setting process. The data collection templates use standardized formats to define the permitted operation types, authorized scenario scope, data retention period, and de-identification requirements. The data collection templates are stored on the blockchain to ensure the transparency and traceability of the collection rules; any changes must be made through the on-chain governance process.

[0067] The smart contract scans each private domain scenario in real time through distributed nodes. When a user accesses a private domain scenario for the first time, authorization verification is performed. If the verification is successful, the smart contract's event monitoring is triggered, and operation behavior monitoring is started. If the verification fails, the silent exit logic is executed. The smart contract's fallback function returns an authorization missing prompt to the user and records the unauthorized access attempt to the blockchain log, which is used for subsequent compliance audits.

[0068] When a user's actions are detected in an authorized private domain scenario, the smart contract triggers data collection through an event tracing mechanism. Based on the data collection template, a minimal collection process is initiated to extract the user action type code, action timestamp, operational action code, and private domain scenario code, constructing tuple data of the user action. The event tracing mechanism refers to the mechanism of locating the trigger source and data flow of user behavior by tracking the hash of the operation event on the blockchain and the log records. This is used to ensure that the triggering process of data collection is traceable, avoid unauthorized collection behavior, and provide event chain evidence for subsequent causal correlation analysis.

[0069] Among them, the user operation type code refers to a unique code assigned after classifying user operation behaviors according to industry standards or enterprise-defined specifications. It is used to quickly identify the type of user operation behavior, such as 0x01 representing adding products to the cart and 0x02 representing sharing content, providing behavioral feature labels for subsequent quantitative analysis of competitive relationships; the operation timestamp refers to a time mark that records the moment when a user operation occurs. It is used to determine the order of user operation behaviors, calculate the duration of behavior intervals, and analyze the timeliness of the impact of operational operations on user behavior in combination with the time decay function; the operational operation code refers to the unique code of the operational operation initiated in the private domain scenario within the system. It is used to associate user operations with enterprise operational behaviors and analyze the driving effect of specific operational activities on user behavior, such as determining whether a coupon issuance promotes user purchases; the private domain scenario code is a unique code used to distinguish different private domain carriers such as mini-programs, communities, and membership platforms. It is used to locate the scenario in which user behavior occurs and to compare and analyze user behavior preferences and switching tendencies in different scenarios.

[0070] Once the tuple data is constructed, the smart contract automatically stores it in the operation dataset according to a three-level index system to support efficient querying and correlation analysis: a B+ tree index is created based on the operation timestamp, and the data is stored in shards according to the time window of the operation timestamp, which supports quick retrieval of user behavior sequences within a specific time period; for example, when analyzing a user's operation behavior within a certain hour, the data in the corresponding time window can be quickly located through this index, greatly improving query efficiency.

[0071] It adopts an inverted index structure, with the private domain scenario code as the first-level key and the user operation type code as the second-level key, to store user operation records of all operation types in the private domain scenario, and supports cross-scenario behavior comparison and analysis; for example, if an enterprise wants to compare the differences in user sharing behavior in mini-programs and social groups, it can quickly obtain the operation record data of sharing behavior in the two scenarios through this index.

[0072] An adjacency list is constructed around the operational operation code to store all user actions involved in the operation, supporting the analysis of user response effects for specific operational strategies. For example, when evaluating the impact of a limited-time discount event on user purchasing behavior, user action data participating in the event can be obtained through this adjacency list.

[0073] During the tuple data writing process, the tuple data is deduplicated and validated to ensure the accuracy and uniqueness of the data, ultimately constructing a well-structured and easily analyzable operational dataset.

[0074] Step S2: When new tuple data is received in the operation dataset, the user operation type code is first parsed to determine whether it is a critical operation or a normal operation. If it is a critical operation, other operation records of the same user within the preset time window are retrieved. Based on the time decay algorithm, the association weight is dynamically adjusted according to the interval between the operation time and the critical operation, so that the association between the critical operation and the historical operation becomes more accurate with the distance over time, and a causal association graph of the critical operations in the operation dataset is constructed.

[0075] In this embodiment, when the operation dataset receives new tuple data, the smart contract first parses the user operation type code. Based on the built-in operation type definition rules, it determines whether the operation is a critical operation directly impacting business conversion, such as completing a purchase or registering a membership, or a general interactive behavior, such as browsing products or liking content. If determined to be a critical operation, the smart contract automatically activates a preset time window tracing mechanism. According to industry characteristics and business needs, it quickly retrieves all operation records of the same user within that time window using an index. Then, based on a time decay mechanism, it dynamically adjusts the correlation weight between ordinary and critical operations based on the time interval between them. Ordinary operations closer to the critical operation's time are assigned a higher correlation weight, and vice versa. Operations exceeding the time window or whose weight decays to a certain extent are automatically de-associated. This mechanism can accurately identify the correlation strength between key user behaviors and historical operational operations. In practical applications, it can effectively improve the accuracy of enterprises' analysis of operational strategy effectiveness, clearly present the causal relationship between user behavior trajectories and enterprise operational actions, and provide data support for subsequent quantitative analysis of competitive relationships.

[0076] Please see Figure 3 Preferably, the specific steps for constructing a causal relationship graph of key operations include:

[0077] Smart contracts parse the user operation type encoding in newly received tuple data based on a predefined business rule base. The business rule base includes industry-standard rules and enterprise-defined rules, which are used to distinguish between critical operations and ordinary operations in user operations.

[0078] If the current user operation is determined to be a critical operation, the smart contract immediately retrieves the time window configuration parameters and quickly locates all tuple data generated by the same user within the time window using a B+ tree index. This constructs a causal relationship dataset for the critical operation. The time window configuration parameters are dynamically set by the on-chain governance contract through a multi-signature mechanism and are used to constrain the traceability time range according to business characteristics.

[0079] The tuple data in the causal association dataset is stratified according to user operation type. Historical key operations within a time window are filtered and sorted based on operation timestamps and a business priority matrix to form a historical key operation sequence. The business priority matrix is ​​a structured matrix that assigns relative priorities to different types of user operations based on business objectives and the contribution of user operations to conversion. It is constructed through training on operation conversion efficiency in historical user operation data and is used to quantitatively evaluate the importance hierarchy and logical order of user operations in causal associations. For example, in e-commerce scenarios, first-time purchases and current repeat purchases constitute a key sequence; in education scenarios, course trials and formal registration form a logical chain. Historical ordinary operations within the time window are also extracted and sorted based on operation timestamps and the business priority matrix to form a historical ordinary operation sequence.

[0080] Extract the business priority sequences of historical critical operation sequences and historical ordinary operation sequences respectively. Based on the business priority of the current user operation, assign basic weight sequences to the historical critical operation sequences and historical ordinary operation sequences respectively through the difference in business priorities, that is:

[0081] Obtain the business priority sequence of historical key operations, execute progressive weight determination logic to determine whether the business priority of the historical key operation is lower than that of the current key operation. If not, it indicates that the historical key operation is a more core or earlier high-value action in the business conversion link and does not provide direct causal support for the current key operation. In this case, the basic weight of the historical key operation is set to 0. If yes, it indicates that the historical operation may be a preparatory behavior for the current key action. In this case, the basic weight of the historical key operation is set to the reciprocal of the difference between the business priority of the current key operation and the historical key operation, quantifying the supporting value of the low-priority operation for the high-priority conversion.

[0082] For the business priority sequence of historical ordinary operation sequences, the base weight of historical ordinary operations is set as the reciprocal of the difference between the business priority of the current critical operation and the historical ordinary operation; this ensures that all ordinary operations obtain differentiated base weight allocation based on the priority difference with the current critical operation.

[0083] After the basic weight sequence is constructed, the time decay factor is calculated according to the time interval between the operation timestamps of historical user operations and the current key operation, based on the preset decay coefficient. The basic weight sequences of historical key operation sequences and historical ordinary operation sequences are weighted and corrected according to the time decay factor, and used as the weight sequences of historical key operation sequences and historical ordinary operation sequences.

[0084] Configure weight thresholds to remove historical user operations with weights less than the weight threshold from historical key operation sequences and historical ordinary operation sequences. This filters out invalid associations with weak impact on the current key operation, ensuring that causal association analysis focuses on high-value behavioral links. Based on the weight sequence, establish a causal association graph between the current key operation and historical key operation sequences and historical ordinary operation sequences, i.e.:

[0085] Using the current critical operation as the core node, historical critical operations are arranged in descending order of weight as first-level child nodes, and historical ordinary operations are arranged in descending order of weight as second-level child nodes. Each node is connected by weighted directed edges, labeled with parameters such as time intervals and priority differences. The causal relationship graph automatically generates the optimal causal path from historical user operations to the current critical operation, and uses blockchain hash storage to ensure data immutability. Ultimately, this forms a causal relationship graph that integrates time dimensions and business logic, providing visualized end-to-end data support for quantifying the competitive relationships in private domain traffic.

[0086] Step S3: Based on the constructed key operation causal relationship graph, to solve the problem of quantification workload caused by the large operation dataset, the smart contract calls the pre-trained graph embedding model to first extract user operation nodes and edge weights from the causal relationship graph to form graph feature vectors, and marks the private domain scene encoding of each graph feature vector. Set clustering update conditions such as time period, the number of newly added graphs exceeding a threshold, or manual triggering by the business. If not triggered, the newly added graphs are classified into existing clusters or new separate groups are created according to feature distance. When the number of separate groups reaches the set value, they are marked as candidate groups to be clustered. When clustering is triggered, the causal relationship graph is clustered to generate feature causal relationship graphs for each private domain scene.

[0087] In this embodiment, for massive causal relationship graphs of key operations, operation nodes and edge weights are automatically extracted and transformed into graph feature vectors. Structured data representation improves the computability and comparability of causal relationship graph features, laying a standardized foundation for subsequent clustering analysis. Clustering update conditions are set based on fixed time periods, thresholds for the number of newly added causal relationship graphs, or on-chain multi-signature governance. A multi-dimensional triggering mechanism balances computational resource consumption with data timeliness requirements, avoiding excessive system load caused by frequent clustering while ensuring that clustering results reflect business changes promptly. During non-trigger periods, the feature distance between newly added causal relationship graphs and existing clusters is calculated using a similarity algorithm. Efficient classification of causal relationship graphs is achieved based on distance metrics, reducing manual intervention costs. High-matching graphs are classified; otherwise, a new group is created. When the number of groups reaches a set scale, they are marked as candidate groups. This progressive grouping strategy ensures the stability of the clustering system while reserving capacity for new patterns, preventing rare but important causal relationship graphs from being mistakenly removed. When clustering is triggered, a density clustering algorithm is used to select core causal relationship graphs, and a density threshold is used to filter noisy data to ensure the representativeness of the feature causal relationship graphs. A feature causal relationship graph containing typical operation paths, weighted association edges, and scene distribution is generated. By aggregating high-frequency behavior patterns, the core logical chain of user operations is extracted, so that the complex causal relationship graph system can be presented hierarchically. Invalid causal relationship graphs with sparse nodes or weak associations are removed simultaneously, effectively compressing the amount of causal relationship graph data, significantly improving the efficiency of subsequent analysis, and optimizing the response speed of querying, comparing, and visualizing large-scale causal relationship graphs by orders of magnitude, providing technical support for real-time competitive analysis.

[0088] Preferably, the specific steps for generating the feature causal relationship map for each private domain scene include:

[0089] Please see Figure 4 When generating a causal relationship graph of key operations, the smart contract calls a pre-trained graph embedding model to map the nodes and edge weights in the causal relationship graph into feature points in a high-dimensional vector space, forming graph feature vectors. Each graph feature vector is then labeled with its private domain scene encoding. The graph embedding model is obtained through continuous pre-training on a heterogeneous knowledge graph constructed from user operation tuple data, combining self-supervised contrastive learning and on-chain domain knowledge distillation. This model is used to capture potential patterns and causal relationships in the behavioral sequences of the user's causal relationship graph. For example, adding a product to the cart is mapped to a vector representation of a specific dimension, edge weights are transformed into distance metrics between vectors, and scene labels are added as an additional dimension to the vectors, forming standardized graph feature vectors to ensure the comparability of graphs from different sources.

[0090] Under each private domain scenario encoding, smart contracts deployed on the blockchain are used to cluster the causal relationship graph of the current key operation based on the feature causal relationship graph of historical cluster categories. Specifically, the similarity distance between the feature vector of the current causal relationship graph and the historical cluster centers is calculated using the cosine similarity algorithm. The historical cluster centers are the feature vectors of the feature causal relationship graphs. If the similarity distance is greater than a distance threshold, the current causal relationship graph is assigned to the candidate group to be clustered; otherwise, the current causal relationship graph is assigned to the cluster category to which the corresponding feature causal relationship graph belongs.

[0091] The distance threshold is used as a criterion to determine whether the current causal relationship graph belongs to a known behavior pattern category, ensuring high cohesion of graphs of the same type and low coupling of graphs of different types. It is obtained through statistical analysis of historical clustering results by on-chain governance contracts.

[0092] The number of causal association graphs to be clustered in the candidate groups to be clustered is counted, and the time interval since the last causal association graph clustering update is obtained. If the number of causal association graphs to be clustered is greater than a preset number threshold or the time interval is greater than a preset update time threshold, the causal association graph clustering update is triggered.

[0093] Please see Figure 5 When a causal relationship graph clustering update is triggered, the smart contract reads the configuration parameters for re-evaluating historical cluster categories, including cluster compactness and member stability, to determine whether historical clusters should be re-clustered. If the cluster compactness of a historical cluster category is less than a preset compactness threshold, or the member stability of a historical cluster category is less than a preset stability threshold, then the historical cluster is marked as needing to be re-clustered to construct a re-clustering group. Cluster compactness is used to evaluate the tightness of the causal relationship graph within a cluster, measuring the aggregation quality of similar graph features, and is obtained by calculating the mean cosine similarity of the graph feature vectors of the causal relationship graph within the cluster and the feature causal relationship graph. Member stability is used to evaluate the degree of structural change of the cluster over time, reflecting the persistence of user behavior patterns, and is obtained by comparing the overlap rate of the causal relationship graph in the current cluster category with the causal relationship graph at the time of the last clustering update. The compactness threshold and stability threshold are dynamically set through the multi-signature consensus mechanism of the on-chain governance contract.

[0094] The causal relationship graphs of candidate groups to be clustered and groups to be re-clustered are extracted to construct a feature vector set. The spectral feature vectors in the feature vector set are standardized, and the missing dimensions of the spectral feature vectors are filled in using a pre-configured filling strategy in the on-chain governance contract, such as the class mean, default values ​​of business rules, or neighbor vector interpolation. The smart contract calls the on-chain reinforcement learning model to set the neighborhood radius and minimum number of samples for the clustering algorithm based on the number of spectral feature vectors in the feature vector set. The feature vector set is then clustered using the DBSCAN clustering algorithm, which is a density-based clustering algorithm.

[0095] For the causal relationship graph in each cluster category, the node sequences with a frequency greater than a preset frequency threshold are extracted to construct the core behavioral path, which serves as the feature causal relationship graph of that cluster. The edge weights of the feature causal relationship graph are weighted and aggregated based on the edge weights between nodes within the cluster: the edge weights of the same node pairs in the causal relationship graph of the cluster are statistically analyzed, and different weight coefficients are assigned by arithmetic average or according to the credibility of the causal relationship graph to generate the edge weight values ​​between feature path nodes. This ensures that the weights not only retain the processing results of business logic and time dimension in the original data, but also reflect the correlation strength of the node pair in the group behavior through cluster aggregation.

[0096] Step S4: When the clustered categories of private domain scene codes are updated, the smart contract synchronously triggers the quantification operation of private domain scene competition relationships: extract the feature causal relationship graph of each clustered category of each private domain scene to construct a scene behavior matrix; then calculate the similarity of the behavior matrices between different private domain scenes using the graph edit distance algorithm, and combine it with the competition intensity coefficient configured in the on-chain governance contract to generate a scene competition relationship heatmap; at the same time, perform semantic parsing on the high-frequency operation sequences in the feature causal relationship graph to identify the differences in the core conversion paths of each private domain scene, extract scene-specific behavior labels using the TF-IDF algorithm to form a competitive advantage feature vector; finally, encapsulate the scene competition relationship heatmap, advantage feature vector, and cluster update log into a competition analysis report, push it to the authorized entity through a smart contract event, and simultaneously store the report hash value on the chain to provide data support for enterprises to adjust their private domain operation strategies.

[0097] In this embodiment, when the clustering category of the private domain scene encoding is updated, the smart contract constructs a scene behavior matrix based on the feature causal relationship graph. It uses the graph editing distance algorithm to quantify the similarity of user behavior patterns between different scenes, and generates a heat map by combining the competitive intensity coefficient configured on the chain, which intuitively presents the differences in scene operation. The TF-IDF algorithm is used to extract scene-specific tags from high-frequency operation sequences to form competitive advantage feature vectors, which clarify the core competitiveness of each scene. After the final encapsulated competitive analysis report is stored on the chain, enterprises can quickly locate scene operation problems based on the heat map and advantage feature vectors. By tracing the causal chain of strategy adjustment through clustering update logs, enterprises can achieve dynamic perception and strategy iteration of the competitive situation of private domain traffic. For example, if an enterprise discovers through this mechanism that the weight of the core conversion path in a certain private domain scene has decreased, it can trace the source back to the timely optimization after the operation strategy is adjusted, thereby promoting the improvement of cross-scene operation efficiency.

[0098] Preferably, the specific steps for quantifying competitive relationships in private domain scenarios include:

[0099] When the operation of quantifying the competitive relationship in the private domain scenario is triggered, the smart contract extracts the feature causal relationship graph of all cluster categories under each private domain scenario, analyzes the node sequence and edge weight in the feature causal relationship graph, and constructs a standardized behavior matrix according to the private domain scenario encoding and cluster category dimension. The rows and columns of this standardized behavior matrix are the operation nodes and related edges, and the values ​​are the edge weights, ensuring that the behavior patterns of different scenarios are numerically comparable.

[0100] The graph editing distance algorithm is used to calculate the structural differences of standardized behavior matrices in different private domain scenarios. The matrix similarity of standardized behavior matrices in different private domain scenarios is quantified by quantifying the minimum cost required for operations such as adding and deleting nodes and adjusting edge weights. The cost of adding and deleting nodes is set based on the business importance coefficient pre-configured in the on-chain governance contract, and the cost of adjusting edge weights is dynamically calculated based on the product of the edge weight difference and the business priority matrix. This ensures that the algorithm can capture the topological differences of the behavior matrix and reflect the sensitivity of the business logic to changes in the strength of operational associations. Finally, the similarity is transformed into a matrix similarity in the [0,1] interval through normalization.

[0101] A structured similarity matrix is ​​used to present the behavioral pattern relationships between different private domain scenarios. The rows and columns of the matrix correspond to different private domain scenario codes, and the cross cells store the standardized matrix similarity. For example, the similarity between scenario A and scenario B is 0.73, while the similarity between scenario C and scenario A is 0.41. It also includes difference analysis data on the core behavioral paths of each scenario, such as path overlap rate and key edge weight difference, forming a CSV report that can be imported into data analysis tools. This report supports sorting by similarity value and filtering highly correlated scenario combinations, providing the operations team with precise quantitative data support for scenario behavioral relationships.

[0102] The node sequences of the feature causal association graphs of clustering categories under different private domain scenarios are mapped to natural language descriptions based on the business dictionary contract deployed on the chain. The nodes of the feature causal association graphs are then associated with predefined semantic categories through a semantic classification mapping table. The semantic categories include conversion categories such as product purchase and member registration, interaction categories such as content likes, comments and sharing, information acquisition categories such as search queries and details browsing, social dissemination categories such as inviting friends and sharing in communities, and retention categories such as check-in and points redemption.

[0103] The TF-IDF value of semantic categories in each private domain scenario is calculated to generate a unique keyword vector. Specifically, all node sequences in each private domain scenario are treated as a document, and all private domain scenarios constitute a document set. The frequency of operations of each semantic category in a specific private domain scenario is counted and divided by the total number of operations in that scenario to obtain the word frequency. The logarithm of the number of private domain scenarios containing a specific semantic category is counted to obtain the inverse document frequency to reflect the specificity of the category. The TF-IDF values ​​of each semantic category are combined into a vector. The high-value category represents the characteristic operation of the private domain scenario. For example, when the TF-IDF value of social communication in a certain private domain scenario is significantly higher than that of other scenarios, it indicates that users in that scenario are more active in sharing behavior.

[0104] This approach integrates structured similarity matrices and keyword vectors across different private domain scenarios for analysis. Hierarchical clustering algorithms combined with TF-IDF weighted threshold filtering identify related scenario groups and their characteristic operational differences. Specifically, a tree-like clustering graph is constructed using the structured similarity matrix as a distance metric. Thresholds are set to divide the scenarios into groups. Principal component analysis is performed on the keyword vectors within each group to reduce dimensionality, extracting feature dimensions with high explained variance. By comparing the TF-IDF values ​​of these feature dimensions between groups, the core operational features of each private domain scenario group are identified, resulting in a correlation analysis between related scenario groups and characteristic operation labels. For example, if private domain scenario A and private domain scenario B have high similarity, but private domain scenario A's social propagation TF-IDF value is significantly higher than that of private domain scenario B, it can be inferred that private domain scenario A has a stronger user growth capability. Finally, a quantitative report on domain traffic competition relationships, including related scenario groups and characteristic operations, is generated. This report is pushed to the authorized entity via smart contract events, and the report's hash value is stored on the blockchain for evidence.

[0105] Working principle and its effects:

[0106] By deploying smart contracts on the blockchain, user operation data from multiple private domain scenarios is collected according to the principle of minimum necessity. This data is then used to construct tuple data containing fields such as operation type codes and timestamps. A standardized operation dataset is formed through three-level indexing and storage, ensuring traceability of the data source, auditability of the collection process, and comparability across scenarios. This fundamentally solves the problem of data silos that are difficult to integrate in traditional solutions, enabling enterprises to achieve unified quantitative management of user behavior across multiple channels. When new data is received, the smart contract parses the operation type based on the business rule base, retrieves related records for key operations by time window, and dynamically calculates weights using a business priority matrix and time decay factor. This constructs a weighted directed edge causal relationship graph, accurately presenting the temporal causal logic of user behavior and operational actions. The optimal path is generated to intuitively display the conversion chain, changing the inefficient traditional model of manually sorting out paths.

[0107] Furthermore, a pre-trained graph embedding model is used to transform the graph into high-dimensional feature vectors. Multi-dimensional triggering conditions are set, and density clustering algorithms are used to automatically filter noisy data and generate feature causal relationship graphs, achieving effective compression of massive graph data. Simultaneously, high-frequency behavior patterns are extracted, providing technical support for real-time competitive analysis. Finally, a standardized behavior matrix is ​​constructed based on the feature graph, and a graph edit distance algorithm is used to quantify scene similarity. TF-IDF is combined to extract specific labels, and hierarchical clustering and principal component analysis are used to generate a quantitative report containing a scene correlation heatmap and feature operation comparisons. The data is stored on the blockchain to ensure its immutability.

[0108] This solution ensures transparent and trustworthy data collection rules through a blockchain-based distributed governance mechanism. It leverages semantic classification mapping and graph algorithms to achieve standardized analysis of behavioral characteristics, enabling enterprises to quickly identify their core competitive advantages across different scenarios and improve the efficiency of cross-scenario operational strategy optimization. In practical applications, enterprises can use this solution to discover behavioral similarities and characteristic path differences across various private domain scenarios, adjusting resource allocation accordingly to improve cross-scenario user conversion rates. This fully validates the solution's value in dynamically perceiving and accurately deciding on the competitive landscape of private domain traffic.

[0109] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for quantifying and generating private domain traffic competition relationships, characterized in that, Includes the following steps: Deploy smart contracts to monitor user operation behavior in various private domain scenarios, collect user operations under operational operations in each private domain scenario, form tuple data, and then build an operation dataset; By parsing the user operation type code, it is determined whether it belongs to a critical operation. If so, a causal relationship dataset of the critical operation is constructed by retrieving the time window. Based on the user business priority, the user operation in the causal relationship dataset is assigned a basic weight, and the basic weight is corrected by the time decay factor to construct a causal relationship graph of the critical operation. Extract the feature vector of the causal association graph and label it with the private domain scene code. Determine the cluster category of the causal association graph under the private domain scene code by triggering an update, and obtain the feature causal association graph of each cluster. When the conditions for triggering the update are met, a standardized behavior matrix is ​​constructed according to the private domain scenario encoding and cluster category dimensions. The relationship between behavior patterns between private domain scenarios is quantified by the structured similarity matrix, and keyword vectors of private domain scenarios are generated through semantic classification mapping to generate a quantitative report on the competition relationship of private domain traffic.

2. The method for quantifying and generating private domain traffic competition relationships as described in claim 1, characterized in that, The specific steps for triggering the update determination include: When generating the causal relationship graph of key operations, the nodes and edge weights of the causal relationship graph are mapped to graph feature vectors. Calculate the similarity distance between the feature vector of the current causal association graph and the feature causal association graph of the historical cluster category. If the similarity distance is greater than the preset distance threshold, the current causal association graph is assigned to the cluster category to which the corresponding feature causal association graph belongs; otherwise, the current causal association graph is assigned to the candidate group to be clustered. The number of causal association graphs to be clustered in the candidate groups to be clustered is counted, and the time interval since the last causal association graph clustering update is obtained. If the number of causal association graphs to be clustered is greater than a preset number threshold or the time interval is greater than a preset update time threshold, the causal association graph clustering update is triggered.

3. The method for quantifying and generating private domain traffic competition relationships as described in claim 2, characterized in that, The specific steps for obtaining the feature causal correlation map of each cluster include: When the causal relationship graph clustering update is triggered, the smart contract reads the configuration parameters for the re-evaluation of historical clustering categories, including cluster compactness and member stability. If the cluster compactness of a historical cluster category is less than a preset compactness threshold, or the member stability of a historical cluster category is less than a preset stability threshold, then the historical cluster category is marked as needing to be re-clustered in order to construct a re-clustering group. Extract the spectral feature vectors of the causal relationship graphs of the candidate groups to be clustered and the groups to be re-clustered, construct a feature vector set, and standardize the spectral feature vectors of the feature vector set. Set the neighborhood radius and minimum number of samples for the clustering algorithm, and then cluster the feature vector set using the clustering algorithm; For the causal association graph in each cluster category, extract the node sequence with a frequency greater than a preset frequency threshold, construct the core behavioral path, and use it as the feature causal association graph of that cluster category; The edge weights of the feature causal relationship graph are generated by weighted aggregation based on the edge weights between nodes within the cluster category.

4. The method for quantifying and generating private domain traffic competition relationships as described in claim 1, characterized in that, The specific steps for generating a quantitative report on private domain traffic competition relationships include: The smart contract extracts the feature causal relationship graphs of all cluster categories under each private domain scenario, analyzes the node sequence and edge weight in the feature causal relationship graphs, and constructs a standardized behavior matrix according to the private domain scenario encoding and cluster category dimension. The graph editing distance algorithm is used to calculate the structural differences of standardized behavior matrices in different private domain scenarios. The similarity of the minimum cost matrix required for node addition, deletion and edge weight adjustment operations is quantified. Based on the matrix similarity of standardized behavior matrices for different private domain scenarios, a structured similarity matrix is ​​constructed. In the structured similarity matrix, the rows and columns correspond to the private domain scenario codes, and the cross cells store the matrix similarity. The node sequence of the feature causal association graph is mapped to a natural language description, and the semantic classification of the nodes is associated through a semantic classification mapping table. Calculate the TF-IDF value of semantic classification in each private domain scenario and generate keyword vectors specific to the private domain scenario; Based on the structured similarity matrix and keyword vectors between different private domain scenarios, a hierarchical clustering algorithm combined with TF-IDF weight threshold filtering is used to identify the associated scenario groups and their characteristic operations in private domain scenarios, and a quantitative report on the competitive relationship of private domain traffic is generated.

5. The method for quantifying and generating private domain traffic competition relationships as described in claim 1, characterized in that, The specific steps for constructing the causal relationship graph of key operations include: A predefined business rule base is used to classify user operations into critical operations and ordinary operations. Based on a predefined business rule base, smart contracts parse the user operation type encoding in tuple data and determine whether the user operation type is a critical operation. If so, the time window configuration parameters are retrieved, the tuple data within the time window is located, and a causal relationship dataset of key operations is constructed. The time window configuration parameters are used to constrain the traceability time range. The tuple data in the causal association dataset is processed hierarchically according to the user operation type, and sorted based on the operation timestamp and business priority matrix to construct historical key operation sequences and historical ordinary operation sequences. Based on the business priority of the current user operation, the basic weight sequence of historical key operation sequence and historical ordinary operation sequence are assigned respectively by the difference of business priority.

6. The method for quantifying and generating private domain traffic competition relationships as described in claim 5, characterized in that, The acquisition of the basic weight sequence includes: Obtain the business priority sequence of historical key operations, execute progressive weight determination logic, and determine whether the business priority of the historical key operation is less than the business priority of the current key operation. If not, set the base weight of the historical key operation to 0. If so, the base weight of historical critical operations will be set to the reciprocal of the difference between the business priority of the current critical operation and the historical critical operation. Obtain the business priority sequence of historical ordinary operations, and set the base weight of the historical ordinary operations to the reciprocal of the difference between the business priority of the current critical operation and the historical ordinary operations.

7. The method for quantifying and generating private domain traffic competition relationships as described in claim 5, characterized in that, The specific steps for constructing the causal relationship graph of key operations also include: Based on the time interval between the operation timestamps of historical user operations and the current critical operation in the historical critical operation sequence and the historical ordinary operation sequence, a time decay factor is calculated according to a preset decay coefficient. The basic weight sequence is then weighted and corrected based on the time decay factor to form the weight sequence. Configure a weight threshold to remove historical user operations whose weights are less than the weight threshold from the weighted sequences of historical critical operation sequences and historical ordinary operation sequences; Based on the weighted sequence, construct a causal relationship graph between the current key operation and historical key operation sequences, as well as historical ordinary operation sequences, that is: Using the current critical operation as the core node, historical critical operations are arranged in descending order of weight as first-level child nodes, and historical ordinary operations are arranged in descending order of weight as second-level child nodes. Each node is connected by a weighted directed edge, and the time interval and priority difference are marked.

8. The method for quantifying and generating private domain traffic competition relationships as described in claim 1, characterized in that, The specific steps for constructing the operational dataset include: During the smart contract deployment phase, a pre-set data collection template is used to standardize the scope and format of operational data collection. By scanning each private domain scenario through distributed nodes, authorization verification is performed when a user visits a private domain scenario for the first time. If the verification is successful, the event monitoring of the smart contract is triggered, and operation behavior monitoring is started; if the verification fails, the silent exit logic is executed. When a user's actions are detected in an authorized private domain scenario, the smart contract triggers data collection, starts a minimal collection process based on the data collection template, extracts the user operation type code, operation timestamp, operation operation code and private domain scenario code, and constructs tuple data consisting of user operations. The user operation type code is used to represent the code assigned after classifying user operation behavior; the operation timestamp is used to record the time mark when the user operation occurs; the operation operation code is used to represent the code of the operation operation initiated in the private domain scenario, and to locate the operation operation in which the user operation occurs; the private domain scenario code is used to represent the code of the private domain scenario carrier, and to locate the private domain scenario in which the user operation occurs.

9. The method for quantifying and generating private domain traffic competition relationships as described in claim 2, characterized in that, The specific steps for constructing the operational dataset also include: After the tuple data is constructed, the smart contract stores it in the operation dataset according to the three-level indexing system. The three-level index system creates a B+ tree index based on the operation timestamp and stores it in shards according to the time window of the operation timestamp; it adopts an inverted index structure, using the private domain scenario code as the first-level key and the user operation type code as the second-level key to store user operation records under the private domain scenario; and it constructs an adjacency table centered on the operation operation code to store user operations that participate in the operation operation.

10. The method for quantifying and generating private domain traffic competition relationships as described in claim 3, characterized in that, The cluster compactness is used to evaluate the tightness of the causal association graphs within a cluster, and is obtained by calculating the average cosine similarity of the graph feature vectors of the causal association graphs within the cluster and the feature causal association graphs. The member stability is used to evaluate the degree of structural change of the cluster over time, and is obtained by comparing the overlap rate of the causal association graph in the current cluster category with the causal association graph at the time of the last cluster update.

Images