A data asset cost allocation apparatus and method

Abstract

The application discloses a data asset cost allocation device and method, and belongs to the technical field of data processing. The allocation device is empowered by a blockchain, which is divided into three stages: off-chain, pre-chain and on-chain. The off-chain and pre-chain are used to perform corresponding preparations before on-chain operation on programs outside the blockchain, and the on-chain is run on the blockchain. The off-chain stage includes a cost collection module and a use tracking module. The pre-chain stage includes a three-dimensional weighting module. The on-chain stage includes a cost allocation module and a result on-chain module. The three-dimensional weighting module is introduced into the allocation device and method, and the allocation weight is dynamically adjusted through a quantitative factor. A time decay factor strengthens the cost weight of near-time effective data. A business contribution factor allocates the cost according to the actual value of data, avoiding the mismatch of 'high-value departments bearing low costs'. A data quality factor scores according to the integrity and accuracy dimensions, and encourages departments to use high-quality data. After normalization, the three factors generate a comprehensive weight.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and in particular relates to a data asset cost allocation device and method. Background Technology

[0002] As the value of data assets in enterprise operations becomes increasingly prominent, traditional data cost allocation methods are no longer sufficient to meet the needs of refined management. Traditional data cost allocation methods have the following drawbacks:

[0003] Cost collection is untimely and inaccurate: Currently, most organizations use static accounting methods for the costs of data collection, storage, and governance, which cannot reflect the costs generated at each stage in real time and dynamically, nor can they track the entire lifecycle expenses of data assets.

[0004] The cost-sharing method lacks flexibility and fairness: Data is often reused across multiple departments, such as risk control, marketing, and operations, which may all access the same batch of customer data. However, the existing mechanism cannot fairly allocate costs based on dynamic indicators such as data usage time, frequency, and value density, which can easily lead to resource misallocation and incentive imbalance.

[0005] Lack of automated value perception and adjustment mechanisms: The business value of different data varies greatly. For example, high-quality real-time data is more sensitive to certain scenarios, but existing systems generally lack dynamic weighting mechanisms based on dimensions such as data quality, timeliness, and business contribution, resulting in a disconnect between cost estimation and actual use value.

[0006] The lack of a reliable and traceable cost-sharing system: data value assessment and cost allocation among multiple departments are prone to disputes, traditional manual methods are inefficient and lack consistent standards; and existing systems have also failed to effectively introduce reliable execution and recording mechanisms, failing to meet the needs for transparent, automatic, and fair cost-sharing under multi-party collaboration.

[0007] Therefore, there is an urgent need for a data cost allocation method that supports multi-dimensional dynamic factors and has real-time collection and intelligent execution capabilities.

[0008] It should be noted that the above content falls within the inventor's technical knowledge and does not necessarily constitute prior art. Summary of the Invention

[0009] To address the aforementioned issues, the present invention aims to provide a data asset cost allocation device and method. It innovatively introduces a three-dimensional weighted module (time decay / business contribution / data quality), dynamically adjusting allocation weights through quantitative factors: the time decay factor strengthens the cost weight of near-real-time data (e.g., the allocation ratio of real-time marketing data is higher than that of historical data); the business contribution factor allocates costs based on the actual value generated by the data (e.g., the reduction in bad debt rates by risk control models), avoiding the mismatch of "high-value departments bearing low costs"; the data quality factor scores based on dimensions such as completeness and accuracy, incentivizing departments to use high-quality data. After normalization of these three factors, a comprehensive weight is generated, ensuring a strong correlation between cost allocation and data value density.

[0010] To achieve the above objectives, this invention proposes a data asset cost sharing device. The sharing device is enabled by blockchain, which is divided into three stages: off-chain, front-chain, and on-chain. Off-chain and front-chain involve performing preparatory work on a program outside the blockchain, while on-chain involves running the program on the blockchain.

[0011] The off-chain phase includes a cost collection module and a usage tracking module.

[0012] The pre-chain stage includes a three-dimensional weighted module.

[0013] The on-chain phase includes a cost-sharing module and a result-on-chain module.

[0014] The cost aggregation module is responsible for summarizing all costs related to data assets in real time to form a dynamically updatable cost pool.

[0015] The cost aggregation module categorizes costs according to data asset type or business activity type, and periodically outputs the total cost to the on-chain cost allocation module.

[0016] The tracking module is used to track and record the usage behavior of data assets by various business departments.

[0017] The three-dimensional weighting module is used to provide weighting basis for the calculation of the on-chain cost allocation module. The three-dimensional weighting module includes time decay factor, business contribution factor and data quality factor.

[0018] The time decay factor embodies the concept of "the closer, the greater," meaning that the closer the contact is to the conversion point, the greater its influence.

[0019] The business contribution factor is used to reflect the actual business value generated by data usage.

[0020] Data quality factors are used to weight and evaluate the accuracy, completeness, uniqueness, and timeliness of the data used by various departments.

[0021] Furthermore, the on-chain stage function is blockchain-enabled, using smart contracts to distribute computational costs. The logic executed by the smart contracts mainly involves weight verification, which verifies whether the sum of the comprehensive weight values ​​of all departments meets expectations.

[0022] Furthermore, the costs associated with data assets include hardware costs, storage costs, and human resource management costs.

[0023] Furthermore, the usage tracking module can be connected to a log system or audit system to capture access frequency, usage duration, and data processing volume. The usage tracking module is responsible for outputting the collected usage information as quantifiable business metrics.

[0024] A data asset cost allocation method, applied to the aforementioned allocation device, includes the following steps:

[0025] S1: Dynamic aggregation of cost pool;

[0026] S2: Data Usage Tracking

[0027] S3: Calculate the time decay factor;

[0028] This indicates whether a department's use of data has "real-time" or "timely" value;

[0029] S4: Calculate the business contribution factor;

[0030] Used to reflect the actual business value generated by data usage;

[0031] S5: Calculate the data quality adjustment factor;

[0032] Used to weight and evaluate the quality dimensions of data used by various departments, such as completeness, accuracy, timeliness, and reliability;

[0033] S6: Comprehensive factor normalization;

[0034] S7: Smart contract execution and on-chain processing;

[0035] This includes weight verification, cost allocation calculation, structured ledger generation, and on-chain evidence storage.

[0036] Furthermore, S1 specifically includes the following:

[0037] Cost data of departmental data assets is collected. Departmental data comes from data centers, cloud platforms, database systems, and analysis platforms.

[0038] Periodic costs are amortized over time, and usage-based costs are measured in real time. A unified list of cost pool entries is then compiled and output. Each record in the cost pool entry list includes the cost type, amount, time of occurrence, and related attribution dimension. Finally, all costs are aggregated by time period to form a cost pool.

[0039] Cost data includes storage resource fees, computing resource fees, network traffic fees, maintenance personnel costs, and software license fees.

[0040] Furthermore, S2 specifically includes the following:

[0041] By integrating monitoring components into the data warehouse, data lake, or API gateway layer, the usage behavior of various business systems or users can be tracked in real time, including query requests, data writing, and data extraction.

[0042] User behavior can be mapped to corresponding business scenarios through tags or metadata. Methods for mapping user behavior to corresponding business scenarios include financial statement analysis and marketing data mining.

[0043] Dimensional structure: Organize tracking data according to business units, users, data assets, or projects.

[0044] Typical dimensions include dataset identifier, data user ID, access timestamp, usage type, and usage volume. Usage type includes read, write, and process, while usage volume includes the number of records and the amount of data.

[0045] Analysis metrics: The collected raw usage logs are aggregated and statistically analyzed to form key metrics, which include usage frequency, duration of use, amount of computing resources consumed, and value generated.

[0046] Normalize or score key indicators to calculate the relative contribution of each entity or data asset to platform resources.

[0047] Based on the data quality assessment indicators, adjustment coefficients are calculated. In-depth analysis is conducted on the collected log data, key indicator data, and usage behavior data for different data assets or the same data in different usage scenarios, and the data completeness, accuracy, timeliness, and reliability are scored.

[0048] Data usage tracking technologies include log collection, streaming monitoring systems, and monitoring interfaces.

[0049] The tracking module is used to periodically output comprehensive usage metrics for each user entity.

[0050] Data quality assessment indicators include data completeness, accuracy, timeliness, and reliability.

[0051] Furthermore, the time decay factor in S3 is defined as follows:

[0052]

[0053] in: It is a department Use the data after the time since it was generated.

[0054] λ is the time decay coefficient, which reflects the sensitivity of data timeliness.

[0055] The closer it is to 0, the larger the function value of the time decay factor, and the higher the cost that the corresponding department should bear.

[0056] The business contribution factor in S4 is defined as follows:

[0057]

[0058] in: It is a department The business value contribution, i.e. the relative contribution calculated in S2.

[0059] This indicates that, relative to the proportion of business value, the corresponding department should bear more costs.

[0060] The data quality adjustment factor in S5 is defined as follows:

[0061]

[0062] in: It is a department The data used in the first The scores for each quality dimension, namely the scores for data completeness, accuracy, timeliness, and reliability in S2.

[0063] It is the weight of each dimension, satisfying .

[0064] Higher quality indicates a more critical reliance on data resources, and the relevant departments should bear more costs.

[0065] Furthermore, the comprehensive factor in S6 is determined by... , and Dimensional composition.

[0066] It is exponential, and the range varies.

[0067] It is a ratio, ranging from 0 to 1.

[0068] It is a quantitative scoring system with varying ranges.

[0069] To perform normalization, firstly, calculate the original weighted score for each department, defined as follows:

[0070]

[0071] Then, standardization is performed to obtain the overall weight:

[0072]

[0073] At this point, the following condition is met:

[0074] .

[0075] Furthermore, the weight verification in S7 is to verify whether the sum of the comprehensive weight values ​​of all departments meets the expectations.

[0076] Cost allocation calculations are based on the comprehensive weighting of S6, which dynamically and proportionally distributes the total cost among departments. For the first... The costs to be borne by each department are:

[0077]

[0078] Wherein, C is the total cost pool amount S1, which is the final cost pool obtained; For the department The overall allocation weight.

[0079] Structured ledger generation involves packaging the allocation results in a structured manner. The allocation results include allocation time, department IDs, allocation amounts, and weight values.

[0080] On-chain evidence storage records the allocation results in the blockchain ledger, forming an immutable timestamp certificate.

[0081] The data asset cost allocation device and method proposed in this invention can bring the following beneficial effects:

[0082] 1. The cost allocation device and method of this invention innovatively introduces a three-dimensional weighted module (time decay / business contribution / data quality), which dynamically adjusts the allocation weight through quantitative factors: the time decay factor strengthens the cost weight of near-time data (e.g., the allocation ratio of real-time marketing data is higher than that of historical data); the business contribution factor allocates costs according to the actual value generated by the data (e.g., the bad debt rate reduced by the risk control model), avoiding the mismatch of "high-value departments bearing low costs"; the data quality factor scores according to dimensions such as completeness and accuracy, incentivizing departments to use high-quality data. After normalization of the three factors, a comprehensive weight is generated to ensure that cost allocation is strongly correlated with data value density.

[0083] 2. The cost allocation device and method of the present invention summarizes the costs of hardware, storage, manpower and other dimensions in real time through the off-chain cost collection module to form a dynamically updated cost pool. It also supports collection by business scenario classification. Combined with the use of the tracking module, it monitors data access frequency, processing volume and value conversion in real time, which completely solves the cost lag and collection blind spots caused by traditional static accounting, and realizes accurate capture of data life cycle costs.

[0084] 3. The cost allocation device and method of the present invention automatically verify and calculate through smart contracts. At the on-chain stage, the compliance of the weight (such as Σ weight = 1) is automatically verified through smart contracts, and the cost allocation formula is executed. This eliminates the efficiency bottleneck and subjective bias caused by human intervention. The results are stored on the chain to generate a structured ledger and written into the blockchain, providing an immutable and traceable allocation certificate, which effectively solves the dispute problem in multi-department collaboration.

[0085] 4. The cost-sharing device and method of the present invention positively correlates the cost borne by a department with the timeliness, value output, and quality dependence of its data usage, thereby prompting business departments to prioritize the use of high-timeliness and high-quality data resources, reduce redundant requests for low-value data, and proactively improve data governance (high-quality data can reduce its own sharing coefficient), forming a resource optimization closed loop that links "cost and value" and suppressing resource waste from the source.

[0086] 5. The cost sharing device and method of the present invention, through log integration and metadata mapping capabilities, are compatible with multi-source systems such as data centers, cloud platforms, and API gateways, and realize accurate tracking and weight quantification of cross-departmental reused data (such as customer data shared by risk control, marketing, and operations), providing large organizations with cross-business unit data cost settlement infrastructure. Attached Figure Description

[0087] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0088] Figure 1 This is a system architecture diagram of a data asset cost sharing device according to the present invention.

[0089] Figure 2 This is a flowchart of a data asset cost allocation method according to the present invention. Detailed Implementation

[0090] To more clearly illustrate the overall concept of the present invention, a detailed description will be provided below with reference to the accompanying drawings and examples.

[0091] The embodiments of the present invention propose a data asset cost sharing device. The sharing device is enabled by blockchain, which is divided into three stages: off-chain, front-chain, and on-chain. Off-chain and front-chain do not run on the blockchain, but perform the corresponding preparatory matters for running on the blockchain in a program outside the blockchain. On-chain runs entirely on the blockchain.

[0092] The off-chain phase includes a cost collection module and a usage tracking module.

[0093] The pre-chain stage includes a three-dimensional weighted module.

[0094] The on-chain phase includes a cost-sharing module and a result-on-chain module.

[0095] The cost aggregation module is responsible for summarizing all costs related to data assets in real time to form a dynamically updatable cost pool. Costs related to data assets include hardware costs, storage costs, human resource management costs, etc.

[0096] The cost aggregation module categorizes costs according to data asset type or business activity type, and periodically outputs the total cost to the on-chain cost allocation module.

[0097] The tracking module is responsible for tracking and recording the usage behavior of data assets in various business departments. It can be connected to the log system or audit system to capture indicators such as access frequency, usage duration, and data volume processed. The tracking module is responsible for outputting the collected usage information into quantifiable business indicators, namely business contribution indicators.

[0098] The three-dimensional weighting module is used to provide weighting basis for the calculation of the on-chain cost allocation module. The three-dimensional weighting module includes time decay factor, business contribution factor and data quality factor.

[0099] The time decay factor embodies the concept of "the closer, the heavier," meaning that the most recent use receives greater weight. Just as the time decay attribution model in marketing shows, the touchpoints closer to the conversion point have the greatest influence.

[0100] The business contribution factor is used to reflect the actual business value generated by data usage. The higher the proportion of actual business value to total business value, the more the department benefits from the data, and the corresponding department should bear more costs.

[0101] The data quality factor is used to weight and evaluate the accuracy, completeness, uniqueness, and timeliness of the data used by each department. The higher the data quality factor, the more critical the department's reliance on data resources, and the higher the responsibility should be. Finally, the time decay factor, business contribution factor and data quality factor are integrated to calculate the original weight of the department and then standardized.

[0102] The on-chain stage features blockchain-enabled computing and uses smart contracts to distribute computational costs. The logic of smart contract execution mainly includes weight verification, which verifies whether the sum of the comprehensive weight values ​​of all departments meets expectations (the sum of the comprehensive weight values ​​is close to 1), thus avoiding cost imbalances caused by data anomalies.

[0103] A data asset cost allocation method, applied to the aforementioned allocation device, includes the following steps:

[0104] S1: Dynamic aggregation of cost pool;

[0105] Cost data is collected from all data assets across departments, including data centers, cloud platforms, database systems, and analytics platforms.

[0106] Cost data includes storage resource fees, computing resource fees, network traffic fees, maintenance personnel costs, software license fees, etc.

[0107] Periodic costs (such as bandwidth costs) are amortized over time, while usage-based costs (such as computing resources measured hourly) are measured in real time. This process then generates a unified list of cost pool entries. Each record in the cost pool list includes the cost type, amount, time of occurrence, and relevant attribution dimension. Finally, all costs are aggregated by time period to form a cost pool, providing a data foundation for subsequent amortization calculations. The relevant attribution dimension can be business line, system type, etc.

[0108] S2: Data Usage Tracking;

[0109] By integrating monitoring components into data warehouses, data lakes, or API gateway layers, real-time tracking of query requests, data writing, data extraction, and other usage behaviors of various business systems or users can be achieved.

[0110] Common technologies for tracking data usage include log collection, streaming monitoring systems (such as Kafka and Flume), and monitoring interfaces. The monitoring interface is a built-in feature of the data platform with auditing functionality enabled.

[0111] Dimensional structure: Organize tracking data according to business units, users, data assets, or projects.

[0112] Typical dimensions include dataset identifier, data user ID, access timestamp, usage type, and usage volume. Usage type includes read, write, and process, while usage volume includes the number of records and the amount of data.

[0113] User behavior is mapped to corresponding business scenarios through tags or metadata. Methods for mapping user behavior to corresponding business scenarios include financial statement analysis and marketing data mining.

[0114] Analysis metrics: The collected raw usage logs are aggregated and statistically analyzed to form key metrics, including usage frequency, duration of use, amount of computing resources consumed, and value generated.

[0115] Normalize or score key indicators to calculate the relative contribution of each entity or data asset to platform resources.

[0116] The tracking module periodically outputs a comprehensive usage metric for each user entity, which is used for subsequent weight calculations.

[0117] Based on the data quality assessment indicators, adjustment coefficients are calculated. In-depth analysis is conducted on the collected log data, key indicator data, and usage behavior data for different data assets or the same data in different usage scenarios. The data completeness, accuracy, timeliness, and reliability are scored. The data quality assessment indicators include data completeness, accuracy, timeliness, and reliability.

[0118] S3: Calculate the time decay factor;

[0119] The time decay factor, used to indicate whether a department's use of data has "real-time" or "high timeliness" value, is defined as follows:

[0120]

[0121] in: It is a department The time elapsed since the data was generated when using the data, i.e., the access time and duration of S2, and other time-related dimensions.

[0122] λ is the time decay coefficient, which reflects the sensitivity of data timeliness;

[0123] The closer to real-time use, that is The closer the value is to 0, the larger the function value of the time decay factor, indicating that the department used higher-value data, and the corresponding department should bear higher costs.

[0124] S4: Calculate the business contribution factor;

[0125] To reflect the actual business value generated by data usage, such as how much customer conversion rate has increased or how much risk exposure has been reduced, the business contribution factor is defined as follows:

[0126]

[0127] in: It is a department The business value contribution, i.e. the relative contribution calculated in S2;

[0128] This indicates the relative value of the data to the business; a higher percentage means the department benefits more from the data, and the corresponding department should bear more costs.

[0129] S5: Calculate the data quality adjustment factor, which is used to weight and evaluate the data used by each department in terms of quality dimensions such as completeness, accuracy, timeliness, and reliability. The definition of the data quality adjustment factor is as follows:

[0130]

[0131] in: It is a department The data used in the first The scores for each quality dimension, namely the scores for data completeness, accuracy, timeliness, and reliability in S2;

[0132] It is the weight of each dimension, satisfying ;

[0133] Higher quality indicates a more critical reliance on data resources, and the relevant departments should bear more costs.

[0134] S6: Comprehensive factor normalization;

[0135] The comprehensive factor is composed of , and Dimensional composition.

[0136] It is exponential, and the range varies.

[0137] It is a ratio, ranging from 0 to 1.

[0138] It is a quantitative scoring system with varying ranges.

[0139] , and The magnitude, unit, and distribution range of these factors are all different. If they are directly weighted or combined, the problem of "a certain factor dominating the result due to its large scale" will occur, leading to valuation bias.

[0140] Therefore, normalization is required. First, calculate the original weight score for each department, defined as follows:

[0141]

[0142] Then, a standardized process is performed to obtain a comprehensive weight that can be directly used for subsequent smart contract cost allocation:

[0143]

[0144] At this point, the following condition is met:

[0145] ;

[0146] S7: Smart contract execution and on-chain processing;

[0147] Weight verification: Verify whether the sum of the overall weight values ​​of all departments meets the expectation (close to 1) to avoid cost imbalance due to data anomalies.

[0148] Cost allocation calculation: Based on the comprehensive weights of S6, the total cost is dynamically and proportionally allocated among the departments. For the first... The costs to be borne by each department are:

[0149]

[0150] Wherein, C is the total cost pool amount S1, which is the final cost pool obtained; For the department The overall allocation weight.

[0151] Structured ledger generation: The allocation results are packaged in a structured manner, including allocation time, department ID, allocation amount and weight value.

[0152] On-chain evidence storage: The allocation results are recorded in the blockchain ledger, forming an immutable timestamp certificate for subsequent auditing, accountability and automated settlement.

[0153] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0154] The above description is merely an embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.

Claims

1. A data asset cost allocation device, characterized in that, The sharing device is powered by blockchain, which is divided into three stages: off-chain, front-chain, and on-chain. Off-chain and front-chain involve executing the corresponding preparatory work before running on the blockchain on a program outside the blockchain, while on-chain involves running on the blockchain. The off-chain phase includes a cost collection module and a usage tracking module; The pre-chain stage includes a three-dimensional weighted module; The on-chain phase includes a cost-sharing module and a result-on-chain module; The cost aggregation module is responsible for summarizing all costs related to data assets in real time to form a dynamically updatable cost pool; The costs associated with data assets include hardware costs, storage costs, and human resource management costs; The cost collection module categorizes costs according to data asset type or business activity type, and periodically outputs the total cost to the on-chain cost allocation module. The tracking module is used to track and record the usage behavior of data assets by each business department; The three-dimensional weighting module is used to provide weighting basis for the calculation of the on-chain cost allocation module. The three-dimensional weighting module includes time decay factor, business contribution factor and data quality factor. The time decay factor embodies the concept that the closer the point, the greater the impact; the closer the contact is to the conversion point, the greater its influence. The business contribution factor is used to reflect the actual business value generated by data usage. Data quality factors are used to weight and evaluate the accuracy, completeness, uniqueness, and timeliness of the data used by each department. It also includes a data asset cost allocation method applied to the allocation device, the allocation method comprising the following steps: S1: Dynamic aggregation of cost pool; S2: Data Usage Tracking S3: Calculate the time decay factor; This indicates whether a department's use of data is timely or has high timeliness value; S4: Calculate the business contribution factor; Used to reflect the actual business value generated by data usage; S5: Calculate the data quality adjustment factor; Used to weight and evaluate the data used by each department in terms of completeness, accuracy, timeliness, and reliability. S6: Comprehensive factor normalization; S7: Smart contract execution and on-chain processing; This includes weight verification, cost allocation calculation, structured ledger generation, and on-chain evidence storage.

2. The data asset cost allocation device according to claim 1, characterized in that, The on-chain phase features blockchain-enabled functionality, using smart contracts to distribute computational costs. The logic of smart contract execution mainly includes: Weight verification verifies whether the sum of the overall weight values ​​of all departments meets expectations.

3. The data asset cost allocation device according to claim 2, characterized in that, The usage tracking module can be connected to a log system or audit system to capture access frequency, usage duration and data volume. The usage tracking module is responsible for outputting the collected usage information into quantifiable business indicators.

4. A data asset cost allocation device according to claim 3, characterized in that, S1 specifically includes the following: Cost data of departmental data assets is collected. Departmental data comes from data centers, cloud platforms, database systems, and analysis platforms. Periodic costs are amortized over time, and usage-based costs are measured in real time. A unified list of cost pool entries is then compiled and output. Each record in the cost pool entry list includes the cost type, amount, time of occurrence, and related attribution dimension. Finally, all costs are summarized by time period to form a cost pool. Cost data includes storage resource fees, computing resource fees, network traffic fees, maintenance personnel costs, and software license fees.

5. A data asset cost allocation device according to claim 4, characterized in that, S2 specifically includes the following: By integrating monitoring components into the data warehouse, data lake, or API gateway layer, the usage behavior of various business systems or users can be tracked in real time, including query requests, data writing, and data extraction. Using tags or metadata to map usage behavior to corresponding business scenarios, methods for mapping usage behavior to corresponding business scenarios include financial statement analysis and marketing data mining; Dimensional Structure: Organize tracking data according to business units, users, data assets, or projects. Typical dimensions include dataset identifier, data user ID, access timestamp, usage type, and usage volume. Usage type includes read, write, and process, while usage volume includes the number of records and the amount of data. Analysis metrics: The collected raw usage logs are aggregated and statistically analyzed to form key metrics, which include usage frequency, duration of use, amount of computing resources consumed, and value generated. Normalize or score key indicators to calculate the relative contribution of each entity or data asset to platform resources; Based on data quality assessment indicators, adjustment coefficients are calculated. For different data assets or the same data in different usage scenarios, in-depth analysis is conducted on the collected log data, key indicator data, and usage behavior data to score the data completeness, accuracy, timeliness, and reliability. Data usage tracking technologies include log collection, streaming monitoring systems, and monitoring interfaces; The tracking module outputs a comprehensive usage metric for each user entity. Data quality assessment indicators include data completeness, accuracy, timeliness, and reliability.

6. A data asset cost allocation device according to claim 5, characterized in that, The time decay factor in S3 is defined as follows: in: It is a department The time elapsed since the data was generated when using the data; λ is the time decay coefficient, which reflects the sensitivity of data timeliness; The closer it is to 0, the larger the function value of the time decay factor, and the higher the cost that the corresponding department should bear; The business contribution factor in S4 is defined as follows: in: It is a department The business value contribution, i.e. the relative contribution calculated in S2; This indicates that, relative to the proportion of business value, the corresponding department should bear more costs. The data quality adjustment factor in S5 is defined as follows: in: It is a department The data used in the first The scores for each quality dimension, namely the scores for data completeness, accuracy, timeliness, and reliability in S2; It is the weight of each dimension, satisfying ; Higher quality indicates a more critical reliance on data resources, and the relevant departments should bear more costs.

7. A data asset cost allocation device according to claim 6, characterized in that, The comprehensive factor in S6 is determined by... , and Dimensional composition; It is exponential; It is a ratio, ranging from 0 to 1; It is a quantitative scoring; To perform normalization, firstly, calculate the original weighted score for each department, defined as follows: Then, standardization is performed to obtain the overall weight: At this point, the following condition is met: 。 8. A data asset cost allocation device according to claim 7, characterized in that, The weight verification in S7 is to verify whether the sum of the comprehensive weight values ​​of all departments meets the expectations; Cost allocation calculations are based on the comprehensive weighting of S6, which dynamically and proportionally distributes the total cost among departments. For the first... The costs to be borne by each department are: Where C is the cost pool finally obtained from S1; For the department The overall allocation weight; Structured ledger generation involves packaging the allocation results in a structured manner. The allocation results include allocation time, department IDs, allocation amounts, and weight values. On-chain evidence storage records the allocation results in the blockchain ledger, forming an immutable timestamp certificate.

Images