A customer feedback multi-source data cleaning and KPI pre-calculation system

Abstract

The application relates to the field of data processing and discloses a customer feedback multi-source data cleaning and KPI pre-calculation system; the system comprises a display terminal and a platform server. The platform server generates an import batch number for customer feedback data from at least two types of data sources, completes mapping from source fields to uniform fields, and performs format normalization, missing treatment, logical consistency verification and deduplication and disambiguation on a uniform record set to obtain a cleaned record set; the hierarchical attribution is determined based on the hierarchical relationship of dealers; pre-calculation is performed according to KPI caliber configuration, and the pre-calculation result is stored according to time partitioning and dimension keys, and meanwhile, the import batch number and an index version identifier are bound to generate a caliber identifier; and the matched KPI result is returned in response to a query request to be displayed on the display terminal.

Description

Technical Field

[0001] This invention relates to the field of data processing, specifically to a system for cleaning and pre-calculating KPIs from multi-source customer feedback data. Background Technology

[0002] Customer feedback data comes from a wide range of channels, including after-sales work orders, call centers, online reviews, questionnaires, and reports from dealers. The data includes structured records, semi-structured data, and text-based information. Enterprises typically need to centrally aggregate this data to generate KPIs such as customer satisfaction, response timeliness, and problem closure rate, which can be used for business management. These KPIs can then be queried and compared across different timeframes, regional levels, and dealer dimensions to support operational improvement and performance management.

[0003] Existing customer feedback data platforms typically use batch import or API retrieval methods to access data, then use scripts or ETL processes to complete field alignment and initial cleaning before performing statistical calculations and displaying the data in a data warehouse or reporting system according to indicator definitions. Some solutions establish dimension tables to maintain dealer hierarchical relationships, or temporarily aggregate indicator results based on filtering conditions during the query phase to meet the needs of multi-condition analysis by time and dimension.

[0004] The aforementioned solutions still suffer from a core problem in practical applications: the differences in field meanings, value specifications, and record granularity among multi-source data, coupled with the time-sensitive changes in dealer organizational relationships, make it difficult to maintain consistency in cleaning and merging at the hierarchical level. This leads to inconsistencies between KPI calculation methods and historical results, often resulting in shifts in results under the same query conditions due to data batches or adjustments in methods, heavy recalculation burdens during the query phase, and difficulty in tracing back by method version. To address this, we propose a customer-feedback-based multi-source data cleaning and KPI pre-calculation system. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a system for cleaning and pre-calculating KPIs from multiple sources of customer feedback data. This system solves the technical problems existing in the prior art, such as inconsistencies in field meanings and value standards, difficulty in uniformly cleaning and merging duplicate and abnormal records, difficulty in reproducing stable attribution and KPI standards due to the time-sensitive changes in dealer hierarchy relationships, and difficulty in balancing result consistency and response efficiency due to the need for repeated calculations during the query phase.

[0006] The above-mentioned technical objective of the present invention is achieved through the following technical solution:

[0007] A customer feedback multi-source data cleaning and KPI pre-calculation system includes:

[0008] The display terminal and the platform server are communicatively connected;

[0009] The platform server includes:

[0010] The multi-source access module is used to receive customer feedback data from at least two types of data sources and generate an import batch number for each access.

[0011] The field mapping module is used to convert the source fields of the customer feedback data into unified fields and generate a unified record set;

[0012] The data cleaning module is used to perform cleaning processing on the unified record set. The cleaning processing includes at least format normalization, missing data handling, logical consistency verification, and deduplication and disambiguation to obtain a cleaned record set.

[0013] The distributor hierarchy attribution module is used to determine the hierarchy attribution of the cleaned record set based on the distributor hierarchy relationship.

[0014] The KPI pre-calculation module is used to pre-calculate the cleaned record set based on the KPI caliber configuration, generate a pre-calculation result set, and store the pre-calculation result set according to the time partition corresponding to the time condition and the dimension key corresponding to at least one dimension condition.

[0015] The caliber identifier generation module is used to bind the imported batch number with the indicator version identifier corresponding to the KPI caliber configuration to generate a caliber identifier;

[0016] The results service module is used to receive query requests from the display terminal and return KPI results that match the query conditions based on the caliber identifier and the pre-calculated result set.

[0017] The display terminal is used to send a query request containing at least one dimension condition and a time condition to the platform server, and to receive and display the KPI results.

[0018] Preferably, the multi-source access module includes a file access unit, an interface access unit, and a batch registration unit;

[0019] The file access unit receives customer feedback data files uploaded by the display terminal and parses them to obtain a source field set and a record set.

[0020] The interface access unit obtains customer feedback data from another data source that is different from the data source corresponding to the customer feedback data file through a preset data interface, and parses it to obtain a source field set and a record set.

[0021] The batch registration unit generates the import batch number for the same access and stores the import batch number along with the data source identifier, access time, data start time, data end time, file identifier field, and interface identifier field in the batch registration table; the file access unit writes the file identifier field when accessing the system, and the interface access unit writes the interface identifier field when accessing the system.

[0022] Preferably, the field mapping module includes a field dictionary unit, a mapping relationship storage unit, and a mapping execution unit;

[0023] The field dictionary unit stores a unified field dictionary, which defines a field identifier, data type, value range, and enumeration value set for each unified field.

[0024] The mapping relationship storage unit stores a mapping relationship table from source fields to unified fields. The mapping relationship table includes at least the data source identifier, source field name, unified field identifier, conversion rule identifier, and mapping version number.

[0025] The mapping execution unit reads the mapping relationship table that matches the data source identifier based on the data source identifier corresponding to the import batch number, performs type conversion and enumeration value mapping on the source field set field by field, generates a unified record set containing the unified field identifier, and establishes a correspondence between the import batch number and the mapping version number.

[0026] Preferably, the data cleaning module includes a format normalization unit, a missing data handling unit, a logical consistency verification unit, and a deduplication and disambiguation unit;

[0027] The format normalization unit performs format conversion on the target fields in the unified record set based on a preset format rule table. The format rule table defines a character set, length constraint, and regular expression constraint for each target field.

[0028] The missing data processing unit processes the uniform fields with empty values ​​in the uniform record set based on the missing data processing rule table. The missing data processing rule table defines a missing flag field and a default value field for each uniform field. The missing data processing unit writes the default value recorded in the default value field into the uniform field with empty values ​​and sets the missing flag field to the missing flag value.

[0029] The logical consistency verification unit performs consistency verification on the unified record set based on the logical constraint table. The logical constraint table defines the value relationship constraints and value range constraints between fields. The logical consistency verification unit generates an exception flag for records that violate the logical constraint table and writes it into the exception record set.

[0030] Preferably, the deduplication and disambiguation unit generates a deduplication key for the unified record set based on the deduplication key generation rule. The deduplication key is obtained by concatenating the customer identifier field, the distributor identifier field, and the time field. The deduplication and disambiguation unit determines the records to be retained and removes the remaining records according to the retention rules for duplicate records with the same deduplication key. The retention rules are as follows: first, retain the record with the largest time field value; if the time field values ​​are the same, first, retain the record with the most non-empty fields; if there are still multiple candidate records to retain, first, retain the record with the smallest record order corresponding to the import batch number.

[0031] The data cleaning module outputs a cleaned record set based on the processing results of the format normalization unit, the missing data handling unit, the logical consistency verification unit, and the deduplication and disambiguation unit. The cleaned record set does not include records from the abnormal record set or records removed by the deduplication and disambiguation unit.

[0032] Preferably, the dealer hierarchy attribution module includes a hierarchy relationship maintenance unit, an attribution matching unit, and an attribution writing unit;

[0033] The hierarchical relationship maintenance unit stores a dealer hierarchical relationship table, which includes at least a dealer identifier, a parent identifier, a hierarchical type, an effective start time, and an effective end time; the hierarchical type includes national level, regional level, group level, and dealer level;

[0034] The attribution matching unit matches the dealer identifier field of each record in the cleaned record set and the time field in the cleaned record set with the dealer hierarchy table to determine the hierarchy path corresponding to the dealer identifier field and whose time field falls between the effective start time and the effective end time; the hierarchy path is a node sequence formed by tracing the dealer hierarchy node corresponding to the dealer identifier field upwards to the national hierarchy node;

[0035] The attribution writing unit writes the identifiers of each level node in the hierarchical path into the hierarchical attribution field of the cleaned record set, thereby obtaining a cleaned record set with a hierarchical attribution field. The hierarchical attribution field includes at least a national identifier field, a regional identifier field, a group identifier field, and a distributor identifier field.

[0036] Preferably, the KPI pre-calculation module includes a caliber configuration parsing unit, a pre-calculation execution unit, and a partitioned materialized storage unit;

[0037] The KPI caliber configuration parsing unit stores a KPI caliber configuration table, which includes at least an indicator identifier, indicator name, calculation expression, aggregation function identifier, a set of unified field identifiers for the calculation, a time granularity identifier, and a set of dimension field identifiers; the aggregation function identifiers include summation, counting, and average.

[0038] The pre-computation execution unit partitions the cleaned record set according to the time granularity identifier, and performs aggregation operations on the dimension keys corresponding to the dimension field identifier set in each time partition based on the calculation expression and the aggregation function identifier, generating a pre-computation result set; the dimension keys are obtained by concatenating the field values ​​corresponding to the dimension field identifier set.

[0039] The partitioned materialized storage unit writes the pre-calculated result set into a pre-calculated result table, which includes at least a time partition identifier, a dimension key, an indicator identifier, and an indicator value.

[0040] Preferably, the caliber identification generation module includes a version maintenance unit, a binding unit, and a caliber identification generation unit;

[0041] The version maintenance unit is used to store the indicator version table, which includes at least the indicator version identifier, the corresponding indicator identifier, the effective start time, the effective end time, and the configuration hash value of the KPI caliber configuration table.

[0042] The binding unit is used to match the access time corresponding to the import batch number with the indicator version table, determine the indicator version identifier whose access time falls between the effective start time and the effective end time, and establish a binding record between the import batch number and the indicator version identifier.

[0043] The caliber identifier generation unit is used to generate the caliber identifier based on the imported batch number and the indicator version identifier, and to set the caliber identifier field for the caliber identifier in the pre-calculation result table.

[0044] Preferably, the result service module includes a query parsing unit, a result locating unit, and a result returning unit;

[0045] The query parsing unit is used to parse the query request sent by the display terminal to obtain time conditions, dimension conditions, and caliber identifiers; the dimension conditions include at least one dimension field identifier and its corresponding field value;

[0046] The result positioning unit is used to filter records that match the caliber identifier field in the pre-calculated result table based on the caliber identifier, and to filter target records based on the time partition identifier corresponding to the time condition and the dimension key corresponding to the dimension condition.

[0047] The result return unit is used to read the indicator identifier and indicator value from the target record, generate KPI results, and return them to the display terminal.

[0048] Preferably, the display terminal includes a query request generation unit and a result display unit;

[0049] The query request generation unit is used to generate the query request, which includes at least a caliber identifier field, a time condition field, and a dimension condition field; the time condition field is used to represent a time partition identifier or a time granularity identifier, and the dimension condition field is used to represent a dimension field identifier and its corresponding field value.

[0050] The result display unit is used to receive the KPI results returned by the platform server, and generate and output display data based on the indicator identifiers and indicator values ​​in the KPI results.

[0051] In summary, the present invention has the following main beneficial effects:

[0052] By setting up a multi-source access module, a field mapping module, and a data cleaning module on the platform server side, customer feedback data from at least two types of data sources are uniformly accessed, uniformly merged, and cleaned according to import batches. Through format normalization, missing data handling, logical consistency verification, and deduplication and disambiguation, a cleaned record set is formed. This ensures that even when there are inconsistencies in the data structure, value specifications, and duplicate records from multiple sources, the system can still output record data with a unified structure that can be used for calculation. This reduces the risk of deviation in subsequent statistical calculations due to differences in source data and improves the consistency and usability of indicator calculation inputs.

[0053] By setting up a dealer tier attribution module and introducing a dealer tier relationship table with an effective time window, the tier path is determined based on the dealer attribution information and time information in the cleaned record set. The attribution information of the national tier, regional tier, group tier, and dealer tier is written into the cleaned record set. This ensures that even if there are adjustments to the dealer organizational relationship or changes in the effective period, the same customer feedback record can still be given a tier attribution result consistent with its occurrence time. This avoids the problem of inconsistent cross-tier aggregation caused by attribution drift and improves the stability and traceability of the tiered statistical results.

[0054] This invention sets up a KPI pre-calculation module, a caliber identifier generation module, and a result service module. It binds the imported batch number and indicator version identifier to generate a caliber identifier, and performs pre-calculation on the cleaned record set based on the KPI caliber configuration. The pre-calculation results are materialized and stored according to time partitions and dimension keys, and returned during querying based on the caliber identifier, time conditions, and dimension conditions. This achieves the goal of moving the calculation from the query stage to the batch processing stage and realizing result management differentiated by caliber version. In multi-condition query scenarios on the display terminal, it reduces the risk of duplicate calculation and mixed calibers, and improves the consistency and reproducibility of query response. Attached Figure Description

[0055] Figure 1 This is an overall system diagram of the present invention;

[0056] Figure 2 This is a flowchart of the multi-source data access and batch registration process of the present invention. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] Example 1

[0059] refer to Figure 1-2 A customer feedback multi-source data cleaning and KPI pre-calculation system, comprising:

[0060] It includes a display terminal and a platform server, with the display terminal communicating with the platform server.

[0061] The display terminal is a terminal device with network communication capabilities. The display terminal includes at least a processor, memory and communication interface, which is used to initiate data upload requests or query requests to the platform server, and to receive the processing results or KPI results returned by the platform server for display.

[0062] The platform server is a server device or server cluster that provides data access and processing capabilities. A platform server includes at least a processor, memory, and communication interfaces. Communication between the platform server and the display terminal is via HTTP or HTTPS protocols. Data files are uploaded in segments or all at once, and interface data access is achieved through the platform server actively pulling data from the interface.

[0063] To ensure that subsequent modules such as field mapping, data cleaning, dealer level attribution, and KPI pre-calculation can consistently identify the same data access, the platform server generates an import batch number for each access and uses the import batch number as a cross-module association key for continuous recording.

[0064] The platform server includes a multi-source access module, which is used to receive customer feedback data from at least two types of data sources and generate an import batch number for each access.

[0065] Data sources are divided into file data sources and API data sources:

[0066] File data source: The data source corresponding to the customer feedback data file uploaded by the display terminal;

[0067] Interface data source: The data source corresponding to the customer feedback data obtained by the platform server through a preset data interface;

[0068] The interface data source and the file data source have different data generation systems and different data source identifiers.

[0069] The multi-source access module includes a file access unit, an interface access unit, and a batch registration unit.

[0070] The file access unit receives customer feedback data files uploaded by the display terminal and parses them to obtain a source field set and a record set.

[0071] Customer feedback data files are CSV or XLSX files, with table headers indicating the source field names. Assume the table header contains... If there are multiple source fields, then the set of source fields is denoted as: ;in, This indicates the first in the table header. A string representing a source field name. .

[0072] Suppose the file contains a total of tables excluding the header. If there are 100 records, then the set of records is denoted as: ;in, Indicates the first The field value vector of each record is represented as: ;in, Representing records In the source field The value of , and , .

[0073] To ensure consistency of uploaded files, the file access unit analyzes the binary byte sequence of the uploaded files. Calculate the hash digest as the value of the file identifier field. The hash digest is denoted as: ;in, This indicates a hash function with an output length of 256 bits. This represents the binary byte sequence of the uploaded file.

[0074] The file access unit will The uploaded file name and file size will be written as additional fields to the extended fields of the batch registration table, serving as the values ​​to be written to the file identifier field.

[0075] The interface access unit obtains customer feedback data from another data source that is different from the data source corresponding to the customer feedback data file through a preset data interface, and parses it to obtain the source field set and record set.

[0076] The preset data interface includes at least an interface address, authentication parameters, a set of request parameters, and definitions of return fields. The interface address is an HTTP or HTTPS address; the authentication parameters are used to generate the token field or signature field in the request header; the set of request parameters includes at least the data start time and the data end time.

[0077] The interface access unit retrieves data according to a time window, which is determined by the data start time and the data end time, denoted as: ;in, Indicates the start time of the data. This indicates the end time of the data, and the time window is a left-closed, right-open interval.

[0078] When the interface returns a result containing a pagination identifier, the interface access unit retrieves the results page by page according to the page number parameter or cursor parameter until an end identifier is returned.

[0079] The API returns data in JSON or a table structure object. The API access unit extracts the source field set based on the returned field definitions. And convert each returned record into a vector of field values. Thus, a record set is obtained. .

[0080] After completing this interface pull, the interface access unit generates interface identification information to ensure consistency between the source and request of this interface pull.

[0081] Let the interface identifier of the preset data interface be... The request identifier generated by this fetch request is The interface identifier information is recorded as: ;in This represents a string concatenation function.

[0082] The request identifier Generated by a combination of a millisecond timestamp and an incrementing sequence number, denoted as: ;in, This represents a timestamp in milliseconds indicating the moment the request identifier was generated. Represents an incrementing sequence number under the same millisecond timestamp; when When a change occurs, the incrementing sequence number Reset to the preset initial value.

[0083] The batch registration unit generates an import batch number for the same access and generates a batch registration record corresponding to the import batch number; the batch registration record includes at least the following information items: data source identifier, access time, data start time, data end time, and identifier information used to distinguish between file access and interface access.

[0084] To avoid ambiguity arising from a single access operation, a single access operation is limited to: one data source identifier and one time window. This triggers an access processing step. File access and interface access each generate their own import batch number. When the business needs to jointly process data from different access methods within the same time window, association information can be added to the batch registration record to represent the correspondence between batches, but this does not change the rule of generating an independent import batch number for each access.

[0085] When generating the import batch number, the batch registration unit combines the data source identifier, access time, time window, and identifier information, and calculates a summary to obtain the import batch number. Let the data source identifier be... Access time is The time window is The identification information is The incrementing sequence number within the same millisecond is The batch number for import is defined as follows:

[0086] ;

[0087] in, This represents a hash function with an output length of 256 bits. This function converts a digest to a hexadecimal string. Represents a string concatenation function; identification information Retrieve file identification information during file access. When accessing an interface, retrieve the interface identifier information. .

[0088] The batch registration unit uses the imported batch number. The batch registration records are stored as an index; when an index conflict is detected, the batch registration unit increments the sequence number. Increment by 1 and regenerate the import batch number until the batch registration record corresponding to the generated import batch number is stored.

[0089] When access is made through the file access unit, the batch registration unit writes the file identification information into the batch registration record. The interface identifier information is then set to empty; when access is made through the interface access unit, the batch registration unit writes the interface identifier information into the batch registration record. The file identifier information is then set to empty. In the batch registration record, the file identifier information and interface identifier information are allowed to be empty, but at least one of them must be non-empty in the same batch registration record.

[0090] The batch registration unit stores the number of source fields and the number of records obtained from this access parsing as statistical information and associates them with the import batch number, so that subsequent modules can identify the scale of accessed data according to the import batch number.

[0091] To avoid generating duplicate import batch numbers for repeated accesses to the same file or the same interface, the batch registration unit performs a reuse determination before generating the import batch number:

[0092] When the access method is file access, if there are batch registration records that meet the requirements of the same data source identifier, the same file identifier information, the same data start time and the same data end time, then the import batch number corresponding to the batch registration record will be reused.

[0093] When the access method is interface access, if there are batch registration records that meet the requirements of having the same data source identifier and the same interface identifier information, then the import batch number corresponding to that batch registration record will be reused.

[0094] After completing multi-source access and generating an import batch number, the platform server submits the corresponding source field set and record set to the field mapping module. The field mapping module converts the source fields of customer feedback data into unified fields, generating a unified record set. This provides consistent data objects for subsequent data cleaning, dealer level attribution, and KPI pre-calculation. The field mapping module includes a field dictionary unit, a mapping relationship storage unit, and a mapping execution unit.

[0095] The field dictionary unit stores the unified field dictionary. The unified field dictionary is used to define executable constraints for each unified field, including the unified field identifier, data type, value range, and enumerated value set; for each unified field... Define the following attribute: Uniform field identifier It is a unique identifier;

[0096] Data types ;

[0097] Range of values ,when When it is a numeric type ,when When it is a date and time type ;

[0098] Set of enumerated values: Set when the unified field is an enumerated field; otherwise, use the value for a non-enumerated field. ;

[0099] The field dictionary unit also maintains missing flag rules and validity verification rules for each uniform field. These rules are called by the mapping execution unit for type conversion and enumeration normalization.

[0100] The mapping relationship storage unit stores a mapping relationship table from source fields to unified fields, used to describe the field mapping and transformation rules of different data sources under different versions. The mapping relationship table is abstracted into a set of mapping entries. Each mapping entry is denoted as: ;in, Identify the data source; The source field name; To standardize field identifiers; For conversion rule identification; This is for mapping version numbers.

[0101] The mapping relationship storage unit also stores the transformation rule base. Transformation rule identifier Mapped to executable rule object An executable rule object must include at least: type conversion rules, enumeration value mapping rules, and format normalization rules.

[0102] To enhance the traceability of mapping rules, for each mapping version number Computational Configuration Summary And record the version effective time window. Mapping version number and read the set of mapping entries. .

[0103] The mapping execution unit generates a record corresponding to the batch and the mapping version, and matches the import batch number with the mapping version number. Associated storage. This corresponding record is used by subsequent modules to reuse the same mapping version when backtracking or recalculation occurs, avoiding mapping drift caused by the same batch being run repeatedly at different times.

[0104] Suppose the set of source fields obtained from parsing this batch is: ;Mapping execution unit in The source field name in the filter belongs to The mapping entries are obtained, and the applicable mapping set for this batch is obtained: ;in, Represents mapping entries The source field name.

[0105] Mapping execution unit according to The unified field identifier set in the middle is used to obtain the unified field set for this batch: ,in Represents mapping entries The corresponding unified field identifier.

[0106] Missed in source field set The source fields do not participate in the generation of the unified recordset; unified field set Each uniform field in the dictionary generates a value or missing flag according to the type and constraints defined in the field dictionary unit.

[0107] Let the set of records for this batch be: , ;in, For record In the source field The value that can be taken on.

[0108] For any record With any mapping entry The mapping execution unit first locates the source field. exist The corresponding index Then retrieve the source value. .

[0109] Mapping execution unit on source value Execute transformation rule object The candidate unified values ​​are obtained as follows: ;in, Representing records In the unified field identifier Candidate values ​​on the unified field.

[0110] The mapping execution unit is based on the type constraints and enumeration constraints provided by the field dictionary unit. Perform a validity check:

[0111] Type validation: ;

[0112] Range check: when Time requirements ;

[0113] Enumeration check: When Time requirements .

[0114] When a candidate uniform value does not meet any of the above constraints, the mapping execution unit does not directly discard the entire record, but instead writes a missing flag value for the uniform field and writes the corresponding transformation exception information into the exception record set; the exception record set is used for logical consistency verification and audit backtracking in the subsequent cleaning phase.

[0115] The mapping execution unit performs a mapping on each record. Output a unified record , Indicates by the first The first record obtained by field mapping of the source record A unified record; a unified record consists of a unified set of fields. The vector of values ​​on: ;in, Indicates the first The record is identified in the unified field as The value to be taken on the unified field; when the conversion of this field fails or is missing. Retrieve missing marker values; , For a unified field set Arranged in a fixed order; Represents a unified set of fields The number of elements. This leads to the unified record set: ;in, This shows the unified recordset generated by this import batch, containing Each record in the unified record set contains a value or missing flag corresponding to a unified field identifier, and the unified record set for this batch is stored in a one-to-one association with the import batch number for subsequent data cleaning module reading and processing.

[0116] After the field mapping module outputs a unified record set, the platform server submits the unified record set corresponding to the imported batch to the data cleaning module. The data cleaning module performs cleaning processing on the unified record set, which includes at least format normalization, missing data handling, logical consistency verification, and deduplication and disambiguation, resulting in a cleaned record set, which serves as input for dealer level attribution and KPI pre-calculation.

[0117] The data cleaning module includes a format normalization unit, a missing data handling unit, a logical consistency verification unit, and a deduplication and disambiguation unit. Let the unified record set be... The format normalization unit performs format conversion on target fields in a unified record set based on a preset format rule table. The format rule table defines a character set, length constraint, and regular expression constraint for each target field to ensure a consistent representation of the same semantic field across different data sources. Let the set of target fields be... For any The formatting rules table defines the triples for it: ;in, Indicates the allowed character set; Indicates a length-constrained interval; This represents a regular expression constraint.

[0118] For any record and any The format normalization unit will take the original value Convert to: ;in, Indicates basis The format normalization function to be executed must include at least:

[0119] Convert the input value to Allowed character set; if the length exceeds If the preset truncation or filling rules are not met, the length will be adjusted accordingly; otherwise... Then set the field as a missing candidate and output a record with an abnormal format.

[0120] The format normalization unit outputs the first intermediate record set: ;in, The field value is .

[0121] The missing data processing unit processes uniform fields with empty values ​​in the uniform record set based on the missing data processing rule table. For each uniform field... A missing tag rule and a default value function are preset. The missing tag is not used as a business field in subsequent KPI calculations, but is used as status information in the cleaning process for filtering or auditing.

[0122] For any uniform field identifier Definition of missing handling rules table: ;in, Missing marker; This is a default value function or default value constant used to generate complete values ​​when a field is missing.

[0123] The missing condition is defined as a predicate function. A value is considered missing if it meets any of the following conditions: it is empty, contains only whitespace characters, or is marked as a missing candidate during the format normalization stage.

[0124] For any record and any uniform field ,like If =1, then: , =1; otherwise: , =0, where, To retrieve values ​​for fields after missing information processing, Mark the missing field for this record.

[0125] The missing record processing unit outputs a second intermediate record set: Output the missing marker matrix: ;in, It is the number of records; It is a missing marker; the missing marker matrix is ​​stored in association with the imported batch for subsequent logical consistency verification and KPI filtering.

[0126] The logical consistency verification unit performs consistency checks on the second intermediate record set based on the logical constraint table. The logical constraint table defines the constraints on the value relationships and ranges between fields. The logical consistency verification unit generates anomaly flags for records that violate the logical constraint table and writes them to the abnormal record set. The logical constraint table consists of two types of constraints:

[0127] Range constraint set For any uniform field Define the legal range Require: ;

[0128] Relational constraint set Each relation constraint is a predicate function. To apply logical relationships to multiple fields in the same record, for example: =1; where To make constraints enforceable, each constraint is provided with: a set of participating field identifiers, a predicate expression, and an exception type code for violation.

[0129] For any record The logical consistency verification unit calculates the anomaly indicator variable:

[0130] ;

[0131] in, This is the exception indicator variable for this record. =1 indicates that the record is an abnormal record.

[0132] The logical consistency verification unit will include all The record index with value 1 was written to the exception record set. And for each abnormal record, write: import batch identifier, record sequence number. The violated constraint identifier and exception type code. The exception record set is used for subsequent output filtering and audit backtracking.

[0133] The logical consistency verification unit outputs a third intermediate record set: ; =0 indicates that the validation passed.

[0134] The deduplication and disambiguation unit generates deduplication keys for the third intermediate record set based on the deduplication key generation rules. For duplicate records with the same deduplication key, the unit determines the records to be retained and removes the remaining records according to the retention rules.

[0135] To avoid directly referencing field name strings, the deduplication key is defined as being obtained by concatenating the values ​​of three unified fields: a customer entity identifier field, a dealer affiliation identifier field, and a time field. Let the corresponding unified field identifiers be respectively... , , ;in, This field identifier represents a unified field for customer entity identification, used to uniquely identify the customer entity; This field identifier represents the unified field of the dealer attribution identifier class, used to identify the dealer entity to which this record belongs; The field identifier for a time-based unified field is used to represent the time value corresponding to the record. , , All fields are identified by a unified field set and are selected from a unified field set and remain unchanged after system deployment.

[0136] For any unified record The deduplication and disambiguation unit first retrieves the values ​​of the record in the three unified fields mentioned above, which are respectively , , To avoid boundary ambiguity when concatenating values ​​from different fields, the deduplication and disambiguation unit performs delimitation encoding on each field value. The delimitation encoding function is denoted as... , The output is a reversible string representation.

[0137] After completing the encoding, define the deduplication key generation function. ,in Indicates unified record Deduplication keys. Deduplication keys are generated as follows:

[0138] ;

[0139] in, To remove duplicate keys; This is a string concatenation function; This is a delimiting encoding function used to escape or prefix field values, ensuring that concatenated field values ​​can still be uniquely decomposed into three encoded segments.

[0140] When two consistent records and satisfy When the two are identified as duplicate candidate records under the same deduplication key, the deduplication and disambiguation unit determines them and groups them into the same group to enter the disambiguation process of the subsequent retention rules.

[0141] The deduplication and disambiguation unit groups the unified records in the third intermediate record set according to the deduplication key, and selects a unique record to retain within each group. Let's assume that for any unified record... The deduplication key is Define the set of values ​​for the deduplication key: ;in, This represents the set of all deduplicated key values ​​that appear in the third intermediate record set; This represents the third intermediate record set output after logical consistency verification.

[0142] For any deduplication key, take the value Define its corresponding record group:

[0143] ;

[0144] in, Indicates the deduplication key is A unified set of records; This indicates the number of records in the set. When = 1, the deduplication and disambiguation unit directly retains this unique record; when When the value is greater than 1, the deduplication and disambiguation unit performs the disambiguation selection in the following order.

[0145] Define time comparison function ,in Indicates unified record In time-class unified fields The values ​​that can be taken on are: ;in, To provide a unified field identifier for time-related fields, To record in a uniform field identifier The function that retrieves values ​​on.

[0146] In groups Select the candidate set with the largest time value:

[0147] ;

[0148] in, This represents the candidate set that satisfies rule one; This represents any candidate record within the same group. When = 1, the unique element is a reserved record; when If the value is greater than 1, proceed to rule two.

[0149] Rule 2: Prioritize the number of non-missing fields.

[0150] Define a function to count non-missing fields. ,in Indicates unified record In a unified field set Number of non-missing fields:

[0151] ;

[0152] in, For a unified set of fields; This is a predicate for determining missing values; This is an indicator function; it returns 1 if the condition is true, and 0 otherwise. (In the candidate set) Select the secondary candidate set with the largest number of non-missing fields:

[0153] ;

[0154] in, Let this represent the candidate set that satisfies rule two. When When = 1, the unique element is a reserved record; when If the value is greater than 1, proceed to rule three.

[0155] Rule 3: Recording order as a safety net:

[0156] Define record order function ,in Indicates unified record The record sequence number when it enters the data cleaning module in this import batch, and it is unique for each record within the same import batch.

[0157] In the candidate set The record with the smallest sequence number is selected as the final retained record, denoted as . :

[0158] ;

[0159] in, Indicates the deduplication key is The grouping is ultimately recorded; This represents the independent variable that minimizes the objective function. The deduplication and disambiguation unit groups... Except Records other than those listed are marked as duplicate records to be removed, and a set of duplicate records to be removed is formed:

[0160] ;

[0161] in, This represents the set of records to be removed due to duplicates. This represents the set difference operation.

[0162] The deduplication and disambiguation unit selects a unique record to retain for each deduplication key group and outputs the deduplicated record set: ;in, This represents the set of records after deduplication and disambiguation. For deduplication keys The grouping is ultimately recorded; This is the set of values ​​for the deduplication key.

[0163] The data cleaning module will remove duplicate records from the collection. As the output of the cleaned record set, it is denoted as: ;in, This represents the cleaned record set; the cleaned record set contains records that have passed the logical consistency check and have been retained after deduplication and disambiguation.

[0164] The data cleaning module separates the abnormal record set (output by the logical consistency verification unit) from the duplicate record set. The data is stored in association with the imported batch number to support subsequent audit backtracking and recalculation; the exception record set is used to identify entries that failed to enter due to violations of logical constraint tables. The set of records to be removed for duplicates. Used to identify those not selected within the same deduplication key group. The record.

[0165] After the data cleaning module outputs the cleaned record set, the platform server submits the cleaned record set corresponding to the imported batch to the dealer level attribution module. The dealer level attribution module is used to determine the level attribution of the cleaned record set based on the dealer level relationship, thereby providing a consistent attribution path for subsequent KPI pre-calculation aggregation by national level, regional level, group level, and dealer level.

[0166] The dealer hierarchy attribution module includes a hierarchy relationship maintenance unit, an attribution matching unit, and an attribution writing unit.

[0167] For ease of explanation, let the cleaned record set be... For any record Its dealer attribution identifier value is ; Its time class value is ,in A unified field identifier for dealer attribution. Used as a unified field identifier for time-related fields.

[0168] The hierarchical relationship maintenance unit stores the dealer hierarchical relationship table. To make the meanings of dealer identifier, parent identifier, hierarchical type, effective start time, and effective end time executable, the hierarchical relationship table is abstracted into a set of relationship entries, each denoted as: ;in, For dealer node identification; Used as the identifier for the parent node; Used as a hierarchy type identifier; The effective start time; This is the effective end time.

[0169] Hierarchical type identifier The set of possible values ​​is defined as: ;in, Indicates the national level; Indicates the regional level; Indicates the group level; This indicates the distributor level. To avoid ambiguity regarding time boundaries, the effective time window is specified as a left-closed, right-open interval: ;in This is to record the corresponding time-related values.

[0170] The attribution matching unit is used to determine the hierarchical path corresponding to a record in the hierarchical relationship table based on the record's dealer attribution identifier class value and time class value.

[0171] To achieve deterministic matching when hierarchical relationships may change over time, for any given point in time... Define parent mapping function Identify any node Its parent mapping is defined as: If and only if exists and ;in, Represents a node At time The corresponding parent node identifier; Retrieve the time value of the record If in If there are no entries that meet the conditions, then It is considered undefined.

[0172] To ensure the uniqueness of the matching results, for the same With the same In cases where there is no overlap, a non-overlapping effective window constraint is used; when multiple entries simultaneously meet the conditions due to configuration reasons, the attribution matching unit selects a unique entry according to the following deterministic rule: select the effective start time. The parent identifier corresponding to the largest entry is used as .

[0173] For any record definition: , ;in, This indicates the dealer level node identifier corresponding to this record; This indicates the time value corresponding to the record.

[0174] The attribution matching unit starts from the dealer level node. Starting from the parent level, trace upwards level by level according to the parent mapping function to obtain the hierarchical path vector: ;in, Representing records Hierarchical path; These represent node identifiers at the national, regional, group, and distributor levels, respectively.

[0175] To obtain the above path vector, a step-by-step tracing definition method is adopted: , , ;in This is a parent mapping function that is valid at any point in time; if any level is traced back... If not defined, the record is marked as an affiliation anomaly record and written to the affiliation anomaly record set. This record will not be included in the subsequent cleaned record set with hierarchical affiliation fields.

[0176] To prevent loops from causing the tracing process to continue indefinitely, a set of accesses is maintained during the tracing process. When the tracing process occurs If the hierarchical relationship loop is determined to be abnormal, the record will be written to the affiliation abnormal record set.

[0177] The attribution writing unit is used to write the hierarchical path into the hierarchical attribution information of the record, resulting in a cleaned record set with hierarchical attribution information.

[0178] To avoid using field name strings, the hierarchy attribution field is represented as a set of unified hierarchy attribution field identifiers, denoted as: ;in, A unified field identifier indicating the national hierarchical affiliation; A unified field identifier indicating the hierarchical affiliation of a major region; A unified field identifier indicating the group's hierarchical affiliation; A unified field identifier indicating the distributor's tier affiliation.

[0179] For any record that satisfies the requirement of successful traceability Its hierarchical path is The attribution writing unit writes the path vector into the corresponding hierarchical attribution unified field. The writing rule is defined as follows:

[0180] ;

[0181] in, This indicates an assignment operation to the record field; For record In the unified field identifier The position of the value on the field.

[0182] To facilitate differentiation from common matching schemes that rely solely on static hierarchical tables, the following optional implementations are provided:

[0183] 1) Batch freeze hierarchical version: When the attribution matching unit starts processing the imported batch, it generates a configuration summary of the set of hierarchical relationship entries involved in the batch and binds it to the imported batch number; the same hierarchical version is reused for the playback or recalculation of the same imported batch to avoid the historical batch attribution drift caused by the adjustment of the hierarchical table.

[0184] 2) Path caching: For the same path Combined cache path This reduces redundant tracing; cache hits do not change the determinism of rules one through three, and the output is reproducible.

[0185] 3) Anomaly Classification Records: The anomaly record set is classified and recorded according to parent missing, time window not hit, loop anomaly, and inconsistent hierarchy type, which facilitates subsequent investigation of hierarchical relationship maintenance issues.

[0186] After the dealer hierarchy attribution module outputs a cleaned record set with hierarchy attribution information, the platform server uses this record set as pre-calculation input and submits it to the KPI pre-calculation module. The KPI pre-calculation module performs pre-calculation on the cleaned record set according to the KPI caliber configuration, generating a pre-calculation result set and storing it in partitioned materialized form. The caliber identifier generation module binds the imported batch number with the corresponding indicator version identifier and generates a caliber identifier to ensure a one-to-one correspondence between the pre-calculation results and the imported batch and caliber version. Upon receiving a query request from the display terminal, the result service module locates and matches records based on the caliber identifier and the pre-calculation result set, returns the KPI results, and the display terminal receives and displays the KPI results.

[0187] The KPI caliber configuration parsing unit stores the KPI caliber configuration table. Each configuration record in the KPI caliber configuration table includes at least the indicator identifier, indicator name, calculation expression, aggregation function identifier, unified field identifier set involved in the calculation, time granularity identifier, and dimension field identifier set.

[0188] To ensure executable semantics and avoid ambiguity, the computational expression is represented using a restricted expression structure. This restricted expression structure is formed by combining values ​​of uniform field identifiers with preset operators, and is parsed into an executable expression structure (e.g., an expression tree or an equivalent executable structure) by the caliber configuration parsing unit. During the parsing process, the caliber configuration parsing unit simultaneously verifies that all uniform field identifiers referenced in the computational expression are included in the set of uniform field identifiers participating in the calculation, and records the concatenation order of the dimension field identifier set for this configuration, thereby ensuring the determinism of subsequent dimension key generation.

[0189] The values ​​of the aggregation function identifier include summation, counting, and average. The caliber configuration parsing unit maps the aggregation function identifier to the corresponding aggregation operator for use by the pre-computation execution unit.

[0190] The caliber identifier generation module includes a version maintenance unit, a binding unit, and a caliber identifier generation unit. The version maintenance unit stores an indicator version table, which includes at least the indicator version identifier, the corresponding indicator identifier, the effective start time, the effective end time, and the configuration hash value of the KPI caliber configuration table.

[0191] The binding unit is used to bind the import batch number with the indicator version identifier. Specifically, the binding unit obtains the access time corresponding to the import batch number and searches the indicator version table for the indicator version identifier whose access time falls between the effective start time and effective end time. If multiple version records meet the condition, the one with the largest effective start time is selected as the unique matching version to ensure that the binding result is unique and reproducible. The binding unit establishes a binding record between the import batch number and the indicator version identifier.

[0192] The caliber identifier generation unit generates a caliber identifier based on the imported batch number and the bound indicator version information, and sets the caliber identifier field in the pre-calculation result table. The caliber identifier is used to limit the caliber range of the pre-calculation results during the query phase, thereby avoiding the drift of query results for historical batches due to changes in caliber configuration.

[0193] The pre-computation execution unit partitions the cleaned record set according to a time granularity identifier. The time granularity identifier is used to map the time value of the record to a time partition identifier, which serves as the basis for partitioning the pre-computation result table.

[0194] Within each time partition, the pre-computation execution unit generates dimension keys based on the dimension field identifier set. The dimension keys are obtained by concatenating the field values ​​corresponding to the dimension field identifier set in a fixed order, and the values ​​are delimited using a unified encoding rule to avoid concatenation ambiguity. The dimension keys are used as grouping keys for pre-computation aggregations.

[0195] The pre-computation execution unit first obtains a record-level calculated value for each record based on the calculation expression, and then performs aggregation operations on the record set under the same time partition and the same dimension key according to the aggregation function identifier to form an index value. The aggregation operations include: summing the record-level calculated values, counting the number of records, and averaging the record-level calculated values. For the average value operation, when the number of records participating in the aggregation is zero, no corresponding pre-computation result record is generated to avoid undefined situations.

[0196] The pre-computation execution unit outputs a pre-computation result set. Each result record in the pre-computation result set includes at least a time partition identifier, a dimension key, an indicator identifier, and an indicator value, and is associated with a caliber identifier.

[0197] The partitioned materialized storage unit writes the pre-calculated result set into a pre-calculated result table. The pre-calculated result table includes at least a caliber identifier field, a time partition identifier field, a dimension key field, an indicator identifier field, and an indicator value field, and establishes uniqueness constraints to ensure that the same caliber identifier, the same time partition identifier, the same dimension key, and the same indicator identifier correspond to a unique pre-calculated result record. The partitioned materialized storage unit stores data in partitions based on time partition identifiers and creates indexes within each partition based on the dimension key to support rapid location by the result service module.

[0198] The display terminal is used to generate query requests and send them to the platform server. The query request includes at least a caliber identifier, time conditions, and dimension conditions. The results service module includes a query parsing unit, a result location unit, and a result return unit.

[0199] The query parsing unit parses the query request to obtain the caliber identifier, time condition, and dimension condition. For the time condition, the query parsing unit converts it into one or more time partition identifiers; for the dimension condition, the query parsing unit generates the target dimension key or target dimension key set according to the dimension field order and encoding rules consistent with the pre-computation stage to ensure consistency between the query side and the pre-computation side.

[0200] The result location unit filters matching records in the pre-calculated result table based on the caliber identifier, and further filters target records based on the time partition identifier and dimension key; when the query request contains indicator identifier constraints, the result location unit further filters target records based on the indicator identifier. The result return unit reads the indicator identifier and indicator value from the target record, generates KPI results, and returns them to the display terminal. The display terminal receives the KPI results and displays them.

[0201] At the start of batch import processing, the caliber identifier and indicator version information are frozen, and the frozen caliber is used uniformly in subsequent pre-calculation and query. At the same time, the same time partition mapping rule and dimension key encoding rule are reused for both pre-calculation and query parsing, thereby ensuring that the result positioning under the same caliber, the same time condition and the same dimension condition is deterministic and reproducible.

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

Claims

1. A system for cleaning and pre-calculating KPIs from multi-source customer feedback data, characterized in that, include: The display terminal and the platform server are communicatively connected; The platform server includes: The multi-source access module is used to receive customer feedback data from at least two types of data sources and generate an import batch number for each access. The field mapping module is used to convert the source fields of customer feedback data into unified fields to generate a unified record set. The data cleaning module is used to perform cleaning processing on a unified record set. The cleaning process includes at least format normalization, missing data handling, logical consistency verification, and deduplication and disambiguation to obtain a cleaned record set. The distributor hierarchy assignment module is used to determine the hierarchy assignment of the cleaned record set based on the distributor hierarchy relationship. The KPI pre-calculation module is used to pre-calculate the cleaned record set based on the KPI caliber configuration, generate a pre-calculation result set, and store the pre-calculation result set according to the time partition corresponding to the time condition and the dimension key corresponding to at least one dimension condition. The caliber identifier generation module is used to bind the imported batch number with the indicator version identifier corresponding to the KPI caliber configuration to generate the caliber identifier. The results service module is used to receive query requests from the display terminal and return KPI results that match the query conditions based on the caliber identifier and the pre-calculated result set. The display terminal is used to send a query request containing at least one dimension condition and a time condition to the platform server, and to receive and display the KPI results; The dealer hierarchy attribution module includes a hierarchy relationship maintenance unit, an attribution matching unit, and an attribution writing unit; The hierarchical relationship maintenance unit stores a dealer hierarchical relationship table, which includes at least a dealer identifier, a parent identifier, a hierarchical type, an effective start time, and an effective end time; the hierarchical types include national level, regional level, group level, and dealer level; The attribution matching unit matches the dealer identifier field of each record in the cleaned record set with the time field in the cleaned record set and the dealer hierarchy relationship table to determine the hierarchy path corresponding to the dealer identifier field and whose time field falls between the effective start time and the effective end time; the hierarchy path is a node sequence formed by tracing the dealer hierarchy node corresponding to the dealer identifier field upwards to the national hierarchy node; The attribution writing unit writes the identifiers of each level node in the hierarchical path into the hierarchical attribution field of the cleaned record set, resulting in a cleaned record set with hierarchical attribution fields. The hierarchical attribution fields include at least the national identifier field, the regional identifier field, the group identifier field, and the distributor identifier field.

2. The customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 1, characterized in that, The multi-source access module includes a file access unit, an interface access unit, and a batch registration unit; The file access unit receives customer feedback data files uploaded by the display terminal and parses them to obtain a source field set and a record set. The interface access unit obtains customer feedback data from another data source that is different from the data source corresponding to the customer feedback data file through a preset data interface, and parses it to obtain the source field set and record set. The batch registration unit generates an import batch number for the same access and stores the import batch number, data source identifier, access time, data start time, data end time, file identifier field, and interface identifier field in the batch registration table; the file access unit writes the file identifier field when accessing, and the interface access unit writes the interface identifier field when accessing.

3. The customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 2, characterized in that, The field mapping module includes a field dictionary unit, a mapping relationship storage unit, and a mapping execution unit; The field dictionary unit stores a unified field dictionary, which defines a field identifier, data type, value range, and enumeration value set for each unified field. The mapping relationship storage unit stores a mapping relationship table from the source field to the unified field. The mapping relationship table includes at least the data source identifier, the source field name, the unified field identifier, the conversion rule identifier, and the mapping version number. The mapping execution unit reads the mapping relationship table that matches the data source identifier based on the data source identifier corresponding to the import batch number, performs type conversion and enumeration value mapping on the source field set field by field, generates a unified record set containing unified field identifiers, and establishes a correspondence between the import batch number and the mapping version number.

4. The customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 3, characterized in that, The data cleaning module includes a format normalization unit, a missing data handling unit, a logical consistency verification unit, and a deduplication and disambiguation unit. The format normalization unit performs format conversion on the target fields in the unified record set based on a preset format rule table. The format rule table defines the character set, length constraint, and regular expression constraint for each target field. The missing data processing unit processes the uniform fields with empty values ​​in the uniform record set based on the missing data processing rule table. The missing data processing rule table defines a missing flag field and a default value field for each uniform field. The missing data processing unit writes the default value recorded in the default value field into the uniform field with an empty value and sets the missing flag field to the missing flag value. The logical consistency verification unit performs consistency verification on the unified record set based on the logical constraint table. The logical constraint table defines the value relationship constraints and value range constraints between fields. The logical consistency verification unit generates an exception flag for records that violate the logical constraint table and writes it into the exception record set.

5. The customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 4, characterized in that, The deduplication and disambiguation unit generates deduplication keys for the unified record set based on the deduplication key generation rules. The deduplication key is obtained by concatenating the customer identifier field, the distributor identifier field, and the time field. The deduplication and disambiguation unit determines the records to be retained and removes the remaining records according to the retention rules for duplicate records with the same deduplication key. The retention rules are as follows: the record with the largest time field value is retained first; when the time field values ​​are the same, the record with the most non-empty fields is retained first; when there are still multiple candidate records to be retained, the record with the smallest record order corresponding to the import batch number is retained first. The data cleaning module outputs a cleaned record set based on the processing results of the format normalization unit, the missing data handling unit, the logical consistency verification unit, and the deduplication and disambiguation unit. The cleaned record set does not contain records from the abnormal record set or records removed by the deduplication and disambiguation unit.

6. The customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 5, characterized in that, The KPI pre-calculation module includes a caliber configuration parsing unit, a pre-calculation execution unit, and a partitioned materialized storage unit. The KPI caliber configuration parsing unit stores a KPI caliber configuration table, which includes at least an indicator identifier, indicator name, calculation expression, aggregation function identifier, a set of unified field identifiers for the calculation, a time granularity identifier, and a set of dimension field identifiers; the aggregation function identifiers include summation, counting, and average. The pre-computation execution unit partitions the cleaned record set according to the time granularity identifier, and performs aggregation operations on the dimension keys corresponding to the dimension field identifier set in each time partition based on the calculation expression and aggregation function identifier, to generate a pre-computation result set; Dimension keys are obtained by concatenating the values ​​of the fields corresponding to the dimension field identifier set; The partitioned materialized storage unit writes the pre-calculated result set into the pre-calculated result table, which includes at least the time partition identifier, dimension key, indicator identifier, and indicator value.

7. The customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 6, characterized in that, The caliber identification generation module includes a version maintenance unit, a binding unit, and a caliber identification generation unit; The version maintenance unit is used to store the indicator version table. The indicator version table includes at least the indicator version identifier, the corresponding indicator identifier, the effective start time, the effective end time, and the configuration hash value of the KPI caliber configuration table. The binding unit is used to match the access time corresponding to the import batch number with the indicator version table, determine the indicator version identifier that falls between the effective start time and the effective end time, and establish a binding record between the import batch number and the indicator version identifier. The caliber identifier generation unit is used to generate caliber identifiers based on the imported batch number and indicator version identifier, and to set the caliber identifier field for the caliber identifier in the pre-calculation result table.

8. The customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 7, characterized in that, The result service module includes a query parsing unit, a result locating unit, and a result returning unit; The query parsing unit is used to parse the query request sent by the display terminal to obtain time conditions, dimension conditions, and caliber identifiers; the dimension conditions include at least one dimension field identifier and its corresponding field value; The result location unit is used to filter records that match the caliber identifier field in the pre-calculated result table based on the caliber identifier, and to filter target records based on the time partition identifier corresponding to the time condition and the dimension key corresponding to the dimension condition. The result return unit is used to read the indicator identifier and indicator value from the target record, generate KPI results, and return them to the display terminal.

9. A customer feedback multi-source data cleaning and KPI pre-calculation system according to claim 8, characterized in that, The display terminal includes a query request generation unit and a result display unit; The query request generation unit is used to generate a query request, which includes at least a caliber identifier field, a time condition field, and a dimension condition field; the time condition field is used to represent a time partition identifier or a time granularity identifier, and the dimension condition field is used to represent a dimension field identifier and its corresponding field value. The result display unit is used to receive the KPI results returned by the platform server, and generate and output display data based on the indicator identifiers and indicator values ​​in the KPI results.

Images