A distributor level customer satisfaction drill-down analysis and report generation system

Abstract

The application relates to the field of data processing and information display, and discloses a dealer level customer satisfaction drilling analysis and report generation system, which comprises a display terminal and a platform server. The display terminal collects interaction events and renders a chart; the platform server maintains nationwide, regional, group and dealer level relationships, generates a filtering condition set identifier; generates a data request based on a drilling event and generates a view snapshot identifier to restore a view state; establishes a component dependency relationship and determines a target component set identifier to realize linkage refreshing; performs permission verification on drilling, sharing and exporting and generates a query signature to implement cache management; assembles a report data table according to a report template, writes into metadata to generate a report file, and provides the display terminal with download output.

Description

Technical Field

[0001] This invention relates to the field of data processing and information display, specifically to a system for drill-down analysis and report generation of customer satisfaction at the dealer level. Background Technology

[0002] In enterprise channel management and customer operations scenarios, customer satisfaction data is often organized at levels such as national, regional, group, and distributor, and cross-linked with filtering dimensions such as brand, region, and time. Business personnel typically need to perform drill-down analysis of satisfaction indicators in a visual dashboard, while exporting the data results corresponding to the current view into a shareable report file to support business diagnosis, channel assessment, and improvement loop.

[0003] Existing customer satisfaction dashboards and report export solutions mostly employ a method where interactive events are triggered by the display terminal, and the platform server responds to query requests to achieve drill-down and refresh. Inter-component interaction typically relies on front-end configuration or back-end rule tables, with filter conditions and drill-down contexts maintained separately in different modules or interfaces. To improve response speed, some solutions introduce caching, but cache key generation is often only related to query parameters, failing to establish consistent constraints with user permission ranges, chart configuration versions, and data versions. Regarding report export, data tables are often assembled and files generated using template mapping, but the association between the export process and the interface state is inconsistent.

[0004] The above solution is prone to issues such as difficulty in accurately restoring the view state, difficulty in precisely limiting the scope of linked refreshes, and inconsistencies between the exported results and the interface display when performing continuous operations of drilling down, returning to the previous level, sharing access, and exporting reports. At the same time, when the user permission scope changes or the data version and chart configuration version are updated, the caching and export tasks lack unified version boundary control, which poses a risk of accidentally hitting old caches or reusing data across permissions, thereby affecting the stability and traceability of the analysis results. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a dealer-level customer satisfaction drill-down analysis and report generation system. This system solves the technical problem in existing technologies where it is difficult to maintain consistency in filtering conditions, view states, and the linked refresh of multiple chart components during multi-level drill-down analysis of dealer-level customer satisfaction, resulting in inconsistencies between the dashboard display results and the exported report results.

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

[0007] A system for drill-down analysis and report generation of customer satisfaction at the dealer level, comprising:

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

[0009] The display terminal includes an interactive event acquisition module and a visualization rendering module;

[0010] The platform server includes:

[0011] The hierarchy and filtering management module is used to maintain the hierarchical relationship, which includes at least the national level, regional level, group level and distributor level, and to assign node identifiers to the hierarchical nodes. It receives brand conditions, time conditions and regional conditions to form a set of filtering conditions, and generates a filtering condition set identifier corresponding to the set of filtering conditions.

[0012] The drill-up and view state management module is used to receive drill-up events carrying the current level node identifier, the target level node identifier, the dimension identifier, and the member identifier; generate a data request based on the filter condition record corresponding to the filter condition set identifier; generate a view snapshot identifier for the view state corresponding to the drill-up process and store it; and restore the view state and trigger a data request based on the view snapshot identifier when returning to the previous level instruction or sharing access request.

[0013] The linkage refresh module is used to establish component dependencies for multiple chart components in the dashboard interface and determine the set of affected target components, trigger data requests for the set of target components and drive the visualization rendering module to refresh the display.

[0014] The permissions and query caching module is used to verify permissions for drill-up events, share access requests, and export requests, and to generate query signatures for data requests based on the user's permission scope and perform cache management.

[0015] The report generation and output module is used to generate report files based on the data request results corresponding to the target component set according to the report template, and provide download output to the display terminal.

[0016] Preferably, the interactive event acquisition module includes an event listening unit and an event message generation unit;

[0017] The event listening unit is set in the chart component interaction layer of the dashboard interface. When it detects that the user performs a click operation, filter condition change operation, drill-down operation, return to the previous level operation, export operation, or share operation on the chart component, it collects the component identifier and operation parameters corresponding to the operation.

[0018] The event message generation unit encapsulates the component identifier and the operation parameters into an event message and sends it to the platform server. The event message includes a user identifier, event type, timestamp, current level node identifier, target level node identifier, dimension identifier, member identifier, filter condition set identifier, and chart configuration version identifier.

[0019] When the event type is a drill-down operation, the target level node identifier, the dimension identifier, and the member identifier are taken from the operation parameters;

[0020] When the event type is a filter condition change operation, the filter condition set identifier is taken from the operation parameter.

[0021] Preferably, the visualization rendering module includes a data binding unit and a rendering and presentation unit;

[0022] The data binding unit receives the data response message returned by the platform server, and parses it to obtain the dataset identifier, component identifier and chart configuration version identifier that correspond one-to-one with the chart component. Based on the component identifier, the data dataset and the chart component are bound together.

[0023] After the binding relationship is established, the rendering unit generates a graphic object according to the chart configuration parameters corresponding to the chart configuration version identifier and presents it in the component display area of ​​the dashboard interface.

[0024] When the platform server carries a target component set identifier in the data response message, the rendering unit only performs the rendering on the chart component corresponding to the target component set identifier.

[0025] Preferably, the hierarchy and filtering management module includes a hierarchy relationship maintenance unit, a node identifier generation unit, and a filtering condition normalization unit;

[0026] The hierarchical relationship maintenance unit is used to store the hierarchical object table and the hierarchical relationship table. The hierarchical object table includes at least a hierarchical type field, a hierarchical object name field, and a hierarchical object code field. The hierarchical relationship table includes at least a parent node identifier field and a child node identifier field. The hierarchical type field is used to identify one of the following: national level, regional level, group level, and distributor level.

[0027] The node identifier generation unit is used to generate a hierarchical node identifier based on the hierarchical type field and the hierarchical object encoding field, and write the hierarchical node identifier into the hierarchical object table;

[0028] The filter condition normalization unit is used to receive brand conditions, time conditions, and regional conditions, respectively convert the brand conditions into a list of brand identifiers, the time conditions into a start date and an end date, and the regional conditions into a list of regional identifiers, and generate a filter condition set identifier according to a preset field order;

[0029] The filter condition set identifier is stored in a filter condition table in a one-to-one correspondence with the brand identifier list, the start date and the end date, and the region identifier list. The filter condition table includes a filter condition set identifier field, a brand identifier list field, a start date field, an end date field, and a region identifier list field.

[0030] Preferably, the drill and view state management module includes a drill event parsing unit, a data request generation unit, a view snapshot generation unit, a view state storage unit, and a view state playback unit;

[0031] The drill-up event parsing unit is used to receive the drill-up event and parse it to obtain the user identifier, the current level node identifier, the target level node identifier, the dimension identifier, and the member identifier.

[0032] The data request generation unit is used to generate a data request message based on the filter condition record corresponding to the filter condition set identifier, combined with the target level node identifier, the dimension identifier, and the member identifier. The data request message includes a level node identifier field, a dimension identifier field, a member identifier field, and a filter condition set identifier field.

[0033] The view snapshot generation unit is used to generate a view snapshot identifier. The view snapshot identifier is obtained by concatenating the current level node identifier, the target level node identifier, the dimension identifier, the member identifier, the filter condition set identifier, and the chart configuration version identifier in a preset field order and then performing a hash operation.

[0034] The view state storage unit is used to store view state records with the view snapshot identifier as an index. The view state record includes at least the current level node identifier field, the target level node identifier field, the dimension identifier field, the member identifier field, the filter condition set identifier field, and the chart configuration version identifier field.

[0035] The view state playback unit is used to read the view state record corresponding to the view snapshot identifier when it receives a command to return to the previous level or a share access request, and replace the target level node identifier with the current level node identifier to generate a playback data request message and send it to the platform server.

[0036] Preferably, the linkage refresh module includes a dependency relationship establishment unit, a trigger component determination unit, an affected component set determination unit, and a linkage request issuance unit;

[0037] The dependency relationship establishment unit is used to establish a component dependency relationship table for multiple chart components in the Kanban interface. The component dependency relationship table includes a source component identifier field, a target component identifier field, and a dependency type field. The dependency type field is used to identify one of the filter condition propagation dependency and the hierarchical node propagation dependency.

[0038] The triggering component determining unit is used to determine the triggering component identifier based on the component identifier in the event message when the event message is received;

[0039] The influencing component set determination unit is used to start from the triggering component identifier, traverse the source component identifier field and the target component identifier field in the component dependency table, generate a target component set identifier, and write the target component set identifier into the linkage control record;

[0040] The linkage request sending unit is used to read the target component set identifier in the linkage control record and send a data request message containing the target component set identifier to the platform server.

[0041] The data request message also includes a view snapshot identifier and a filter condition set identifier. The platform server carries a component identifier and a dataset identifier that correspond one-to-one with the target component set identifier in the returned data response message, so that the visualization rendering module can perform a refresh display based on the target component set identifier.

[0042] Preferably, the permission and query caching module includes a permission rule storage unit, a permission verification unit, a query signature generation unit, a cache read / write unit, and a cache invalidation control unit;

[0043] The permission rule storage unit is used to store user permission records. The user permission record includes a user identifier field, a user permission scope identifier field, and an available function set field. The available function set field includes at least one of drill-down, share access, and export.

[0044] The permission verification unit is used to read the user permission record when it receives a drill-down event, share access request or export request, verify whether the event type or request type of the request is included in the available function set field, and verify whether the hierarchical node identifier carried in the request belongs to the hierarchical node set corresponding to the user permission scope identifier.

[0045] The query signature generation unit is used to generate a query signature for a data request. The query signature is obtained by concatenating the user permission scope identifier, hierarchical node identifier, filter condition set identifier, dimension identifier, member identifier, indicator set identifier, chart configuration version identifier, and data version identifier in a preset field order and then performing a hash operation.

[0046] The cache read / write unit is used to perform a cache hit query with the query signature as the cache key, output the cached dataset when the cache key is hit, and write the data request result to the cache when the cache key is not hit.

[0047] The cache invalidation control unit is used to delete the cache key corresponding to the data version identifier or the chart configuration version identifier when the data version identifier or the chart configuration version identifier changes.

[0048] Preferably, the platform server includes an indicator set configuration storage unit and a data version storage unit;

[0049] The indicator set configuration storage unit is used to store the indicator set configuration table, which includes an indicator set identifier field and an indicator identifier list field. The indicator set identifier in the query signature is taken from the indicator set identifier field of the indicator set configuration table.

[0050] The data version storage unit is used to store a data version table, which includes a data version identifier field, an update batch identifier field, and an update time field. The data version identifier in the query signature is taken from the data version identifier field of the data version table, and the data version identifier is updated after each data access batch is completed.

[0051] Preferably, the report generation and output module includes a template management unit, a report content assembly unit, a metadata writing unit, a file generation unit, and a download and output unit;

[0052] The template management unit is used to store report templates. The report template includes component layout definitions, field mapping rules, and file format identifiers. The file format identifiers are used to identify one of CSV files, spreadsheet files, and PDF files.

[0053] The report content assembly unit is used to receive the data request result corresponding to the target component set, and convert the data request result into a report data table according to the field mapping rule. The report data table includes at least a component identifier field, an indicator field, a dimension field, a member field, a numerical field, and a time field.

[0054] Preferably, the metadata writing unit is used to generate report metadata records and write them to the metadata area of ​​the report data table or report file. The report metadata records include view snapshot identifier, filter condition set identifier, target component set identifier, chart configuration version identifier, data version identifier, and generation timestamp.

[0055] The file generation unit is used to generate a report file by combining the report data table and the report metadata record according to the component layout definition.

[0056] The download output unit is used to return an export response message containing the download address of the report file to the display terminal when it receives an export request and passes the permission verification unit.

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

[0058] This invention achieves structured constraints on the drill-down analysis process of the dealer-level customer satisfaction dashboard by setting up modules such as hierarchical and filtering management, drill-down and view state management, linked refresh, and permission and query caching on the platform server side. By establishing a correspondence between hierarchical node identifiers, filtering condition set identifiers, and view snapshot identifiers, and restoring the view state based on the view snapshot identifier when returning to the previous level or sharing access, the invention maintains consistency of the analysis context in scenarios of multiple drill-downs, rollbacks, and cross-terminal access, thereby reducing the risk of repeated operations and result deviations caused by interface state loss and inconsistent filtering conditions.

[0059] This invention achieves precise limitation of the scope of linked refreshes by establishing component dependencies for multiple chart components within a dashboard and generating a target component set identifier. After receiving an event message, the triggering component is determined, and the target component set is obtained by traversing dependencies. Refreshing is only performed on the data request results corresponding to the target component set, reducing full refreshes and redundant queries. This lowers the query load on the platform server and improves the responsiveness and smoothness of the display terminal.

[0060] This invention incorporates user permission scope identifiers, data version identifiers, and chart configuration version identifiers into query signatures and implements cache hit and invalidation control, achieving the goal of reusing data request results within permission and version boundaries. By performing functional and scope checks on drill-down, share access, and export requests, and deleting the corresponding cache key when the data version or chart configuration version changes, it avoids data misuse across permission scopes and prevents cache pollution from old versions, thereby improving data access security and the traceability and consistency of report export results. Attached Figure Description

[0061] Figure 1This is a system block diagram of the platform server of this invention;

[0062] Figure 2 This is a block diagram of the terminal system of this invention. Detailed Implementation

[0063] 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.

[0064] Example 1

[0065] refer to Figure 1-2 A drill-down analysis and report generation system for customer satisfaction at the dealer level includes a display terminal and a platform server, wherein the display terminal is communicatively connected to the platform server;

[0066] The display terminal includes an interactive event acquisition module and a visualization rendering module;

[0067] The platform server includes:

[0068] The hierarchy and filtering management module is used to maintain the hierarchical relationship, which includes at least the national level, regional level, group level and distributor level, and to assign node identifiers to the hierarchical nodes. It receives brand conditions, time conditions and regional conditions to form a set of filtering conditions, and generates a filtering condition set identifier corresponding to the set of filtering conditions.

[0069] The drill-up and view state management module is used to receive drill-up events carrying the current level node identifier, the target level node identifier, the dimension identifier, and the member identifier; generate a data request based on the filter condition record corresponding to the filter condition set identifier; generate a view snapshot identifier for the view state corresponding to the drill-up process and store it; and restore the view state and trigger a data request based on the view snapshot identifier when returning to the previous level instruction or sharing access request.

[0070] The linkage refresh module is used to establish component dependencies for multiple chart components in the dashboard interface and determine the set of affected target components, trigger data requests for the set of target components and drive the visualization rendering module to refresh the display.

[0071] The permissions and query caching module is used to verify permissions for drill-up events, share access requests, and export requests, and to generate query signatures for data requests based on the user's permission scope and perform cache management.

[0072] The report generation and output module is used to generate report files based on the data request results corresponding to the target component set according to the report template, and provide download output to the display terminal.

[0073] In this embodiment, a communication connection between the terminal and the platform server is demonstrated. The communication connection can be an HTTPS-based request-response connection or a WebSocket persistent connection, demonstrating that the terminal and the platform server use a unified interface address and message format for data interaction.

[0074] The display terminal is used to present the dashboard interface. The dashboard interface includes multiple chart components and a filter control area. The chart components are used to display the visualization results of customer satisfaction-related indicators, and the filter control area is used to configure brand, time, and region criteria.

[0075] The display terminal includes an interactive event acquisition module and a visualization rendering module. The interactive event acquisition module is located in the chart component interaction layer of the dashboard interface. The chart component interaction layer is situated above the display layer of the chart components and is used to capture user interactions on the chart components and filter control. The chart component interaction layer maintains a component identifier for each chart component, which is a unique and reusable identifier on the terminal side.

[0076] To avoid inconsistencies in interactive behavior due to different terminal versions, the chart configuration settings of the dashboard interface include a chart configuration version identifier. This identifier is obtained by the terminal when loading the dashboard interface and carried in subsequent interactive events.

[0077] The interactive event acquisition module includes an event listening unit and an event message generation unit.

[0078] The event listening unit is set in the chart component interaction layer of the dashboard interface. When it detects that a user performs a click operation, filter condition change operation, drill-down operation, return to the previous level operation, export operation, or share operation on the chart component, the event listening unit collects the component identifier and operation parameters corresponding to the operation, and transmits the component identifier and the operation parameters to the event message generation unit.

[0079] To ensure the determinism of operation parameters, the operation parameters collected by the event listening unit for different event types must meet the following constraints.

[0080] (1) Click operation, the operation parameters of the click operation include at least the dimension identifier and member identifier of the clicked data point; when the chart component is a trend chart or a comparison chart, the dimension identifier is the identifier of the horizontal axis dimension or the grouping dimension, and the member identifier is the member value identifier of the dimension at the data point.

[0081] (2) Filter condition change operation: The operation parameters for the filter condition change operation must include at least the filter condition set identifier. The filter condition set identifier is a unique identifier for the current filter condition combination on the terminal side. After the filter conditions are changed, the terminal side generates a new filter condition set identifier and uses this identifier as part of the operation parameters.

[0082] (3) Drill-down operation. The operation parameters of the drill-down operation include at least the target level node identifier, dimension identifier, and member identifier. The target level node identifier is used to indicate the display level after drill-down, and the dimension identifier and member identifier are used to indicate the dimension member that triggered the drill-down.

[0083] (4) Return to the previous level operation. The operation parameters for returning to the previous level operation must include at least the current level node identifier and the target level node identifier. The target level node identifier is the previous level node identifier after returning. If the terminal side maintains a view snapshot identifier, the return to the previous level operation can also carry the view snapshot identifier for playback, without being strictly limited to it.

[0084] (5) Export operation. The export operation parameters include at least the export range identifier and the export format identifier. The export range identifier is used to indicate whether the export object is the current chart component or the target set of components, and the export format identifier is used to indicate whether it is a CSV file, a spreadsheet file, or a PDF file.

[0085] (6) Sharing operation. The operation parameters of the sharing operation include at least the sharing scope identifier and the access method identifier. The sharing scope identifier is used to indicate whether the sharing object is the current state of the dashboard interface or the state of a specific chart component, and the access method identifier is used to indicate whether to access via a link or a password.

[0086] The event message generation unit encapsulates the component identifier and operation parameters into an event message and sends it to the platform server. The event message includes at least the user identifier, event type, timestamp, current level node identifier, target level node identifier, dimension identifier, member identifier, filter condition set identifier, and chart configuration version identifier.

[0087] When the event type is a drill-down operation, the target level node identifier, dimension identifier, and member identifier are taken from the operation parameters. When the event type is a filter condition change operation, the filter condition set identifier is taken from the operation parameters. For click, export, and share operations, the event message generation unit fills in the fields related to the event type in the dimension identifier, member identifier, target level node identifier, or filter condition set identifier according to the operation parameters corresponding to the event type. Unrelated fields are filled with a null value identifier, which is a preset constant.

[0088] To avoid ambiguity in field interpretation, the key fields of the event message are defined as follows:

[0089] The user identifier is a unique identifier assigned to a logged-in user by the platform server. The terminal caches the user identifier after successful login and writes it into the user identifier field when generating an event message.

[0090] Event type: The event type is an enumerated set of values, including at least click, filter change, drill-down, return to previous level, export, and share. The event message generation unit determines the event type based on the operation category provided by the event listening unit.

[0091] A timestamp, a millisecond-level time identifier based on UTC time, is used to characterize the moment an event occurs. The demonstration shows that when the terminal generates an event message, it obtains the current UTC time and writes the millisecond-level time value corresponding to that UTC time into the timestamp field of the event message.

[0092] The current level node identifier and the target level node identifier are used. The current level node identifier is the node at which the terminal is located when the event occurs. The target level node identifier is the node to which the terminal should switch after the event is completed. For drill-down operations, the target level node identifier is given by the operation parameters. For operations that return to the previous level, the target level node identifier is determined by the terminal based on the hierarchical relationship. For event types that do not change the level, the target level node identifier is the same as the current level node identifier.

[0093] Dimension identifiers and member identifiers: Dimension identifiers identify the data dimension that triggers the event, such as one of the following: region, group, distributor, time, or brand. Member identifiers identify the specific member value under the stated dimension. For filter condition change operations, both dimension identifiers and member identifiers are nullable.

[0094] The filter condition set identifier is generated on the terminal side for the current combination of filter conditions. To ensure that the same combination of filter conditions generates the same identifier on different terminals, the filter condition set identifier is generated by calculating the summary value after normalization serialization. The normalized serialization field order is: brand identifier list, start date, end date, and region identifier list. The brand identifier list and region identifier list are arranged in ascending order according to the lexicographical order of the identifiers, concatenated, and the four field segments are connected by a preset delimiter to form a normalized serialized string. The filter criteria set identifier is defined as follows: ;in, Indicates the set identifier of the filtering criteria. This represents a normalized serialized string. This represents the Chinese cryptographic digest algorithm, and the output is a digest value represented as a hexadecimal string.

[0095] The chart configuration version identifier identifies the chart configuration version currently used by the terminal. When loading the dashboard interface, the terminal obtains the chart configuration version identifier from the platform server and carries this identifier in subsequent event messages, so that the platform server interprets the component identifier and field mapping rules according to the same configuration version.

[0096] Within an interactive processing cycle, the event listening unit triggers the event message generation unit to generate and send event messages according to the order in which events occur. To ensure that the server can reconstruct the state in the order of events, the terminal appends an incrementing local sequence number to event messages sent by the same user within the same dashboard interface. This local sequence number starts from 1 and increments. The local sequence number serves as an extended field of the event message and does not affect the set of essential fields for the event message. The platform server can determine the event order based on the timestamp and the local sequence number.

[0097] For drill-down operations, the terminal reads the current level node identifier and the current filter condition set identifier before generating an event message, and obtains the target level node identifier, dimension identifier, and member identifier from the operation parameters before writing them into the event message. For filter condition change operations, the terminal generates a new filter condition set identifier and writes it into the event message, then triggers a data refresh request to ensure that the terminal interface matches the server's query conditions.

[0098] The display terminal includes a visualization rendering module, which comprises a data binding unit and a rendering unit. The platform server returns a data response message to the display terminal. This data response message includes at least a chart configuration version identifier, a target component set identifier, and a component data list. The component data list includes multiple list items, each of which includes at least a component identifier, a dataset identifier, and a data payload. The component identifier uniquely identifies a chart component in the dashboard interface, and the dataset identifier uniquely identifies the dataset corresponding to the chart component.

[0099] After receiving the data response message, the data binding unit reads the chart configuration version identifier and performs a consistency check with the chart configuration version identifier corresponding to the currently loaded dashboard configuration on the display terminal. If the versions match, the data binding unit parses the component data list to obtain the component identifier and dataset identifier corresponding to each chart component, and establishes a one-to-one binding relationship between the component identifier and the dataset identifier. To ensure that the binding relationship can be directly determined, the display terminal maintains a binding table. The binding table uses the component identifier as the index key and records the dataset identifier and the corresponding chart configuration version identifier corresponding to the component identifier. When the dataset identifier corresponding to the same component identifier is updated in the data response message, the data binding unit updates the record corresponding to the component identifier in the binding table with the new dataset identifier.

[0100] After establishing the binding relationship, the rendering unit determines the chart configuration parameters based on the chart configuration version identifier, retrieves the dataset corresponding to each chart component according to the binding table, parses the dataset, generates a graphical object, and displays it in the component display area of ​​the dashboard interface. The chart configuration parameters include at least the chart type, dimension field, indicator field, sorting rule, indicator axis range, and component display area parameters. The component display area parameters represent the top-left corner position, width, and height of the component display area, and the indicator axis range includes the minimum and maximum values ​​of the indicator axis. After parsing the dataset, the rendering unit obtains the dimension sequence and indicator value sequence. Then, based on the sorting rule, it obtains ordered data pairs for rendering, maps these ordered data pairs to a set of pixel coordinates, generates a graphical object, and outputs it to the component display area.

[0101] To ensure that the coordinate mapping rules can be directly determined, the two-dimensional coordinate mapping uses the following formula:

[0102] ;

[0103] ;

[0104] in, Indicates the data point index, with values ​​ranging from 1 to... , Indicates the number of data points; Indicates the first The pixel coordinates of each data point within the component's display area; , This indicates the pixel coordinates of the top-left corner of the component's display area; Indicates the width of the component's display area; Indicates the height of the component's display area; Indicates the first The indicator value corresponding to each data point , These represent the minimum and maximum values ​​of the indicator axis, respectively, and are taken from the range of the indicator axis. A preset positive constant, used in = Avoid division by zero in certain situations; This represents the function that takes the maximum value. Used in When the value is 1, avoid the denominator being 0. Used to avoid a denominator of 0 when the span of the indicator axis is 0.

[0105] When generating a graphical object, if the chart type is a line chart, the rendering unit connects the pixel coordinate points in sequence according to the data point numbers to form a line segment and draws it; if the chart type is a bar .... Determine the horizontal position of the column, and with + and The pixel difference between the columns determines the column height; when the chart type is a table, the rendering unit generates table rows based on the dimension field and indicator field, and then presents them.

[0106] When the platform server carries a target component set identifier in the data response message, the rendering unit only renders the chart component corresponding to the target component set identifier. To ensure clear correspondence, the display terminal maintains a target component set table, which records the correspondence between target component set identifiers and a list of component identifiers. The rendering unit reads the list of component identifiers corresponding to the target component set identifiers and only performs the aforementioned data parsing, coordinate mapping, and graphic object output process on each component identifier in the list. Chart components not included in the list of component identifiers retain their existing graphic objects.

[0107] The platform server includes a hierarchy and filtering management module, which comprises a hierarchy relationship maintenance unit, a node identifier generation unit, and a filtering condition normalization unit. The hierarchy and filtering management module provides unified hierarchy node identifiers and filtering condition set identifiers for the drill-down and filtering links in the dashboard interface, ensuring consistent input identifiers during data request generation, view snapshot generation, and query signature generation.

[0108] Hierarchical Object Table: The hierarchical relationship maintenance unit is used to store the hierarchical object table. The hierarchical object table must include at least the following fields:

[0109] The hierarchy type field is used to identify one of the following: national hierarchy, regional hierarchy, group hierarchy, and distributor hierarchy;

[0110] The hierarchy object name field is used to store the object name corresponding to the hierarchy type;

[0111] The hierarchical object encoding field is used to store the object encoding that corresponds one-to-one with the object;

[0112] The hierarchical object encoding field is unique within the same hierarchical type. To avoid identification conflicts caused by name ambiguity, the hierarchical object encoding field is used as an input field for node identifier generation, while the hierarchical object name field is used as a display field in terminal rendering but is not used in node identifier calculation.

[0113] Hierarchical Relationship Table: The hierarchical relationship maintenance unit is used to store the hierarchical relationship table. The hierarchical relationship table must include at least the following fields:

[0114] Parent node identifier field; Child node identifier field;

[0115] The hierarchy table is used to describe the relationships between nodes at different levels. To ensure that the relationships can be directly determined, the records composed of the parent node identifier field and the child node identifier field are constrained to be unique in the hierarchy table, and the same child node identifier field is constrained to correspond to only one parent node identifier field in the same level type switching direction.

[0116] To ensure the node identifier generation rules are directly determinable, a hierarchical type code is established for the hierarchical type field. The correspondence between the hierarchical type code and the hierarchical type is fixed as follows: 00 for national level, 01 for regional level, 02 for group level, and 03 for distributor level. The hierarchical type code participates in node identifier generation and maintains a fixed meaning in the specification.

[0117] The node identifier generation unit generates hierarchical node identifiers based on the hierarchical type field and the hierarchical object code field, and writes the hierarchical node identifiers into the hierarchical object table. To avoid conflicts caused by the same object code under different hierarchical types, the combination of the hierarchical type code and the hierarchical object code is used as the input for node identifier generation, and a normalized concatenation and digest calculation method is adopted to generate hierarchical node identifiers.

[0118] The node identifier generation unit extracts the hierarchical type code from the hierarchical type field, denoted as the type code; and extracts the encoding value from the hierarchical object encoding field, denoted as the object encoding. The node identifier generation unit generates a standardized concatenated string according to a fixed field order, where the type code comes first, followed by the object encoding, separated by a preset delimiter; the standardized concatenated string is obtained by sequentially concatenating the type code, delimiter, and object encoding.

[0119] The formula for generating hierarchical node identifiers is denoted as follows: A digest algorithm is used to normalize the concatenated string. The calculation yielded: ,in, This represents the Chinese cryptographic digest algorithm, with a string as input. The output is a digest value represented as a hexadecimal string; It is written as a hierarchical node identifier into the hierarchical object table and referenced by the hierarchical relationship table as the source of values ​​for the parent node identifier field and the child node identifier field.

[0120] When a new record is added to the hierarchical object table or the hierarchical object encoding field changes, the node identifier generation unit regenerates the hierarchical node identifier for that record and writes it into the hierarchical object table; the hierarchical relationship maintenance unit synchronously updates the parent-child relationship records involving that node identifier in the hierarchical relationship table to ensure consistent references between the hierarchical object table and the hierarchical relationship table.

[0121] The filter condition normalization unit receives brand conditions, time conditions, and region conditions, converts brand conditions into a list of brand identifiers, time conditions into start and end dates, and region conditions into a list of region identifiers, and generates a set of filter condition identifiers according to the preset field order.

[0122] Upon receiving brand criteria, the filter condition normalization unit converts the criteria into a list of brand identifiers. This list consists of one or more brand identifiers. Each brand identifier is a unique identifier pre-defined in the platform server's brand master data table. The filter condition normalization unit then performs deduplication and lexicographical ascending sorting on the brand identifier list to obtain a standardized list of brand identifiers, which is used to subsequently generate the filter condition set identifiers.

[0123] When a time condition is received, the filter condition normalization unit converts the time condition into a start date and an end date. The start date and end date are date strings in YYYY-MM-DD format, and represent closed intervals, meaning that the data request includes the start date and end date when generating the query conditions. If the terminal inputs a time condition in the form of a month or quarter, the filter condition normalization unit converts it into the corresponding calendar day start date and end date and writes it.

[0124] When a region condition is received, the filter condition normalization unit converts the region condition into a list of region identifiers. Each region identifier is a unique identifier in the region master data table. The filter condition normalization unit then performs deduplication and lexicographical ascending sorting on the region identifier list to obtain a normalized list of region identifiers.

[0125] To ensure that the same filter combination generates the same filter condition set identifier on different terminals, a fixed field order is used for serialization. The default field order is: Brand Identifier List, Start Date, End Date, Region Identifier List.

[0126] To ensure that the same combination of filter criteria generates the same filter criterion set identifier on different terminals, the filter criterion normalization unit performs deduplication on the brand identifier list and the region identifier list and sorts them in ascending lexicographical order, converting time criteria into start and end dates. Then, the above content is concatenated according to a fixed field order to generate a normalized serialized string. The fixed field order is: brand identifier list, start date, end date, and region identifier list; the fields are separated by a preset delimiter.

[0127] The filter criteria set identifier is denoted as For normalized serialized strings The calculation yielded: ;in, This is a Chinese cryptographic digest algorithm; the input is a normalized serialized string. The output is a summary value represented as a hexadecimal string. Filter criteria set identifier. One of the input fields used for generating event messages, data request messages, view snapshot identifiers, and query signatures.

[0128] The filter condition set identifier is stored in a filter condition table, corresponding one-to-one with the brand identifier list, start date, end date, and region identifier list. The filter condition table must include at least the following fields: filter condition set identifier field, brand identifier list field, start date field, end date field, and region identifier list field; the filter condition set identifier field is either a primary key field or a unique index field. When the platform server generates a data request message, it uses the filter condition set identifier field as an index to read the corresponding brand identifier list, start date, end date, and region identifier list, converts them into query conditions, and participates in data aggregation calculations. This constraint ensures that the filter condition set identifier is not only an identifier but also has a storage basis that can be traced back to the content that determined the filter conditions, facilitating subsequent view snapshot playback and query cache consistency management.

[0129] The platform server includes a drill-down and view state management module, which comprises a drill-down event parsing unit, a data request generation unit, a view snapshot generation unit, a view state storage unit, and a view state playback unit. When a user triggers a drill-down operation, returns to the previous level operation, or performs a share operation, the display terminal sends an event message to the platform server. The platform server processes the event message to generate a data request message and drives the terminal to restore or switch view states.

[0130] The drill-up event parsing unit receives drill-up events sent by the display terminal and parses them to obtain the user identifier, current level node identifier, target level node identifier, dimension identifier, and member identifier. To avoid ambiguity in the meaning of these fields, the following constraints are applied to their meanings:

[0131] The user identifier is a unique identifier assigned by the platform server to the logged-in user, which is used in conjunction with modules such as permission verification and query caching.

[0132] The current level node identifier is the node identifier of the level at which the terminal interface is located when the drill-down is triggered;

[0133] The target level node identifier is the node identifier to which you need to switch after drilling down;

[0134] The dimension identifier is the identifier of the dimension field that triggers drill-down, and the member identifier is the identifier of the specific member value under the dimension. The dimension identifier and the member identifier together define the data slice position of the drill-down entry point.

[0135] The data request generation unit generates a data request message based on the filter condition record corresponding to the filter condition set identifier, combined with the target level node identifier, dimension identifier, and member identifier. The data request message includes at least a level node identifier field, a dimension identifier field, a member identifier field, and a filter condition set identifier field, wherein:

[0136] The hierarchy node identifier field is filled with the target hierarchy node identifier, which is used to indicate the data aggregation hierarchy returned in this request;

[0137] The dimension identifier field and the member identifier field are used to indicate the dimension member conditions at the drill-down entry point;

[0138] The filter condition set identifier field is used to index the list of brand identifiers, start date, end date, and region identifiers that correspond one-to-one with the filter condition table, thereby forming a specific set of query conditions.

[0139] To ensure reproducibility of requests, the rule for determining the value of the filter set identifier when generating constraint data requests is as follows: the filter set identifier is directly read from the event message, and the filter record is read using the identifier as an index. The identifier for brand, time, and region conditions is not recalculated within this unit.

[0140] The view snapshot generation unit is used to generate view snapshot identifiers. The view snapshot identifier is obtained by concatenating the current level node identifier, target level node identifier, dimension identifier, member identifier, filter condition set identifier, and chart configuration version identifier in a preset field order, followed by a hash operation. To ensure consistent results across different terminals and request paths, a standardized concatenated string is generated using a fixed field order and a fixed delimiter, and its summary value is calculated as the view snapshot identifier.

[0141] Generating a normalized concatenated string:

[0142] The default field order is: current level node identifier, target level node identifier, dimension identifier, member identifier, filter condition set identifier, and chart configuration version identifier; adjacent fields are separated by the default separator "|", generating a standardized concatenated string. The view snapshot identifier is denoted as For standardized string concatenation The calculation yielded: ;in, Indicates the view snapshot identifier; This represents a normalized string obtained by concatenating fields in a preset order. It is a national cryptographic digest algorithm;

[0143] The chart configuration version identifier is used to distinguish the differences in component layout and field mapping rules under different chart configuration versions, so that the snapshot identifier can uniquely correspond to the set of states of the same view state under the same configuration version.

[0144] The view state storage unit is used to store view state records using the view snapshot identifier as an index. To ensure that the index relationship can be directly determined, the view state storage unit maintains a view state table, which includes at least the following fields: view snapshot identifier field, current level node identifier field, target level node identifier field, dimension identifier field, member identifier field, filter condition set identifier field, and chart configuration version identifier field.

[0145] The view snapshot identifier field is either a primary key field or a unique index field; the remaining fields serve as the source fields for the data reconstruction request message and the terminal view state during playback.

[0146] When storing view state records, the view state storage unit writes the view snapshot identifier and the above fields into the same record, ensuring that a single record can restore the corresponding drill-down context without relying on additional implicit state.

[0147] The view state playback unit is used to read the view state record corresponding to the view snapshot identifier when it receives a command to return to the previous level or a share access request, and replace the target level node identifier with the current level node identifier to generate a playback data request message and send it to the platform server.

[0148] When a command to return to the previous level is received, the view state playback unit reads the view state record corresponding to the view snapshot identifier, replaces the target level node identifier field with the current level node identifier field to obtain the playback level node identifier, and generates a playback data request message with the playback level node identifier, filter condition set identifier, dimension identifier, and member identifier. The playback data request message is used to request to return to the data set under the level before drill-up, so as to drive the display terminal to restore the level view before drill-up.

[0149] When a share access request is received, it carries a view snapshot identifier. The view state replay unit reads the view state record using this view snapshot identifier and generates a data request message based on the current level node identifier, target level node identifier, dimension identifier, member identifier, filter condition set identifier, and chart configuration version identifier in the record. This allows the shared party to restore its view state to the same state as the sharing party under the same chart configuration version. The share access request and user permission verification are handled collaboratively by the permission and query caching module; this unit only provides view state record reading and replay request generation.

[0150] The platform server includes a linkage refresh module, which comprises a dependency establishment unit, a trigger component determination unit, an affected component set determination unit, and a linkage request issuance unit. When a user performs actions on the dashboard interface such as clicking, changing filter conditions, drilling down, returning to the previous level, exporting, or sharing, the display terminal sends an event message to the platform server. After receiving the event message, the platform server uses the linkage refresh module to determine the target chart component set that needs to be refreshed and organizes a data response message to return to the display terminal, so that the visualization rendering module can perform a refresh display based on the target component set identifier.

[0151] The dependency establishment unit is used to create a component dependency table for multiple chart components in the Kanban interface. The component dependency table includes at least a source component identifier, a target component identifier, and a dependency type field, where the dependency type field is used to identify either filter condition propagation dependency or hierarchical node propagation dependency.

[0152] To ensure that dependencies can be directly determined, the following constraints are applied to the component dependency table:

[0153] Both the source component identifier and the target component identifier are chart component identifiers within the Kanban interface; the source component identifier refers to the component that triggered the change, and the target component identifier refers to the component that needs to be refreshed due to the change.

[0154] The component dependency table is a directed table, where the source component identifier points to the target component identifier;

[0155] When the dependency type is a filter condition propagation dependency, it means that changes in the filter conditions of the source component need to be propagated to the target component; when the dependency type is a hierarchical node propagation dependency, it means that changes in the hierarchical nodes of the source component need to be propagated to the target component.

[0156] To avoid duplicate entries for the same dependency, each record in the component dependency table is uniquely identified by the source component identifier, the target component identifier, and the dependency type.

[0157] The component dependency table can be generated as follows: the platform server generates it based on the Kanban configuration file corresponding to the chart configuration version identifier, and updates it when the Kanban configuration is published; after generation, the dependency establishment unit stores it as a queryable data structure for subsequent traversal.

[0158] The trigger component determination unit is used to determine the trigger component identifier based on the component identifier in the event message when an event message is received. To avoid ambiguity in the trigger source due to the filter control not being a chart component, this embodiment imposes the following constraints: the component identifier in the event message corresponds to the component identifier in the Kanban interface; the filter control participates in the identifier allocation as a component and is written into the component dependency table as the source component identifier; when the event type of the event message is a filter condition change operation, the trigger component identifier is taken from the component identifier of the filter control; when the event type is a drill-down operation or a click operation, the trigger component identifier is taken from the component identifier of the chart component being operated on.

[0159] The influencing component set determination unit is used to traverse the source component identifier and target component identifier in the component dependency table, starting from the trigger component identifier, to generate a target component set identifier, and write the target component set identifier into the linkage control record.

[0160] To ensure that the traversal results are consistent with the event type, select the dependency type according to the event type:

[0161] When the event type is a filter condition change operation, only records that depend on the filter condition are traversed.

[0162] When the event type is a drill-down operation or a return to the previous level operation, only the dependent records are traversed along the hierarchical nodes;

[0163] When the event type affects both the filtering conditions and the hierarchical nodes, the union of the two types of dependencies is taken as the target component set.

[0164] The unit determining the affected component set performs a directed traversal starting from the triggering component identifier to obtain a set of all reachable target component identifiers. To avoid the traversal from failing to terminate due to circular dependencies, a visited set is set. During the traversal, if a component identifier is found to be already in the visited set, the traversal will stop extending from that component identifier as the starting point. The traversal result includes at least the triggering component identifier itself and the target component identifiers reachable from it.

[0165] The component set determination unit performs deduplication on the target component identifier set obtained through traversal, and sorts it in ascending order according to the lexicographical order of the component identifiers to generate a normalized component identifier list; then, the normalized component identifier list is concatenated with the view snapshot identifier and the filter condition set identifier according to the preset field order to form a normalized concatenated string, and the target component set identifier is calculated from it.

[0166] The target component set identifier can be uniquely mapped to the same view snapshot identifier, the same filter condition set identifier, and the same group of target components, so that the chart component corresponding to the target component set identifier can be directly determined within the system.

[0167] The component set determination unit writes the target component set identifier into the linkage control record. The linkage control record includes at least the target component set identifier field, the triggering component identifier field, the view snapshot identifier field, the filter condition set identifier field, and the target component identifier list field. The target component set identifier field serves as an index field, used by the subsequent linkage request issuing unit to read the target component identifier list.

[0168] The linkage request issuing unit is used to read the target component set identifier from the linkage control record and send a data request message containing the target component set identifier to the platform server. To be consistent with the claims, the data request message includes at least: the target component set identifier, the view snapshot identifier, and the filter condition set identifier.

[0169] The processing rules for the linked request issuing unit when generating data request messages are as follows:

[0170] Read the target component set identifier, view snapshot identifier, and filter condition set identifier from the linkage control record, and write them into the data request message;

[0171] The data request processing unit inside the platform server reads the target component identifier list using the target component set identifier as an index, and generates a corresponding data query request for each component identifier in the target component identifier list;

[0172] The data query request generated for each component identifier is constructed based on the hierarchical context corresponding to the view snapshot identifier and the filter condition record corresponding to the filter condition set identifier, so that the same view snapshot identifier and filter condition set identifier can derive a definite query condition set.

[0173] The platform server includes a permission and query caching module, which comprises a permission rule storage unit, a permission verification unit, a query signature generation unit, a cache read / write unit, and a cache invalidation control unit. The platform server also includes an indicator set configuration storage unit and a data version storage unit. When processing drill-down events, share access requests, and export requests, the permission and query caching module first performs permission verification, then generates a query signature based on the permission scope, view context, filter conditions, indicator set, chart configuration version, and data version as the cache key. This enables controllable dataset reuse and performs cache invalidation control when data or configuration changes.

[0174] The permission rule storage unit is used to store user permission records, which include at least: a user identifier field, a user permission scope identifier field, and an available function set field.

[0175] User identifiers are used to uniquely identify users and locate the corresponding user permission records.

[0176] The user permission scope identifier is used to identify the range of hierarchical nodes that the user can access. The platform server maintains the permission scope mapping relationship so that the user permission scope identifier can be mapped to a specific set of hierarchical nodes.

[0177] The available functionality set field includes at least one of drill-down, share access, and export, indicating the type of functionality that the user is authorized to perform.

[0178] The permission verification unit is used to read user permission records and perform function verification and scope verification when a drill-down event, share access request, or export request is received.

[0179] Functionality validation: Verify whether the request type is included in the available functionality set field.

[0180] Scope verification: Verify whether the hierarchical node identifier carried in the request belongs to the set of hierarchical nodes corresponding to the user's permission scope identifier.

[0181] To ensure that the verification result can be directly determined, the permission verification result is represented as a Boolean decision:

[0182] ;

[0183] in, Indicates whether the permission verification has passed; Indicates whether the function verification passed; Indicates whether the range check passed; Representing logic; when When =1, continue executing query signature generation and caching; when When the value is 0, the request will be rejected and an insufficient permissions message or error code will be returned.

[0184] The indicator set configuration storage unit is used to store the indicator set configuration table, which includes at least an indicator set identifier field and an indicator identifier list field.

[0185] To ensure the reproducibility of the correspondence between the indicator set identifiers and the indicator identifier list, the indicator identifier list is deduplicated and sorted in ascending lexicographical order to obtain a normalized indicator list. The indicator set identifiers are then generated using the following formula: ; Identifier for the set of indicators; The concatenated result string will be used as input for subsequent calculations of the indicator set identifier.

[0186] The data version storage unit stores a data version table, which includes at least a data version identifier field, an update batch identifier field, and an update time field. The data version identifier is updated after each data ingestion batch is completed, enabling subsequent query signatures to distinguish data results from different batches. The data version identifier serves as one of the input fields for the query signature, and its value is derived from the data version identifier field in the data version table.

[0187] The query signature generation unit generates a query signature for data requests, which serves as a cache key. To ensure consistency between the cache key and the permission scope, and between the query context and the data version, a standardized concatenated string is generated by concatenating fields in a preset order. Then calculate the query signature. :

[0188] The default field order is: user permission scope identifier, hierarchical node identifier, filter condition set identifier, dimension identifier, member identifier, indicator set identifier, chart configuration version identifier, and data version identifier; adjacent fields are separated by the separator "|"; ,in, To query the signature; A normalized concatenated string generated according to field order and delimiter.

[0189] By incorporating user permission scope identifiers, chart configuration version identifiers, and data version identifiers into the query signature, cache misses across permission scopes, configuration versions, or data versions can be avoided.

[0190] The cache read / write unit is used to query signatures. The cache key is used to perform a cache hit query. To ensure that the hit and origin retrieval logic are directly determinable, the following branching rules are used to represent the dataset output:

[0191] ;

[0192] in, This represents the dataset used for the response; This represents a cached dataset with the query signature as the key. This represents the set of keys that already exist in the cache; This represents the dataset obtained by performing queries and calculations based on the data request;

[0193] when At that time, the cache read / write unit will Write , and output the dataset.

[0194] The cache invalidation control unit is used to delete the corresponding cache key when the data version identifier or chart configuration version identifier changes. To make the triggering condition explicit, a cache invalidation trigger predicate is defined:

[0195] ;

[0196] in, =1 indicates that the data version identifier has been updated; =1 indicates that the chart configuration version identifier has been updated; when When =1, the cache invalidation control unit deletes the cache key associated with the old data version identifier or the old chart configuration version identifier to prevent the old version dataset from being used under the new version conditions.

[0197] The platform server includes a report generation and output module, which comprises a template management unit, a report content assembly unit, a metadata writing unit, a file generation unit, and a download and output unit. Upon receiving an export request and passing the permission verification unit, the report generation and output module generates a report file based on the data request result corresponding to the target component set and the report template, and returns an export response message containing the report file download address to the display terminal.

[0198] The template management unit is used to store report templates. To ensure that component layout definitions, field mapping rules, and file format identifiers have directly achievable meanings, report templates must include at least the following parts:

[0199] The file format identifier is used to identify whether a file is a CSV file, a spreadsheet file, or a PDF file. The platform server selects the appropriate file generator and metadata write location based on this file format identifier.

[0200] The component layout definition describes the presentation structure of each chart component in the report file, and includes at least: component identifier, component display order, component title text, and the page or section identifier to which the component belongs;

[0201] When the file format is identified as a spreadsheet file, the component layout definition also includes the worksheet identifier corresponding to the component and the starting cell position, which are used to determine the area where the component's data table is written.

[0202] When the file format is identified as PDF, the component layout definition also includes page number and layout area identifier, which are used to determine the arrangement order of component content on the page.

[0203] Field mapping rules are used to convert the field structure in the data request result into the field structure of the report data table. A field mapping rule must include at least: source field identifier, target field identifier, field type identifier, and display format identifier.

[0204] The target field identifier must cover at least the component identifier, metric field, dimension field, member field, numeric field, and time field. Field mapping rules are stored in the template as a table structure to ensure consistent field alignment across different export tasks using the same template.

[0205] The report content assembly unit receives the data request results corresponding to the target component set and converts the data request results into a report data table according to the field mapping rules. To avoid ambiguity in the meaning of the data request results, the data request results are the result set obtained by the platform server after processing the data request message containing the target component set identifier, and this result set can be distinguished into each chart component by component identifier.

[0206] When the report content assembly unit receives the data request result, it reads the component identifier and data payload from each result item, and aggregates the data payloads corresponding to the same component identifier into a component dataset for that component. Each component identifier in the target component set corresponds to at least one component dataset.

[0207] The report content assembly unit transforms each component dataset according to field mapping rules to generate a report data table. The report data table includes at least the following fields: component identifier field, indicator field, dimension field, member field, numeric field, and time field.

[0208] The component identifier field is taken from the component identifier to which the component dataset belongs;

[0209] The indicator fields are taken from the fields in the component dataset that represent the meaning of the indicator, or the indicator identifiers specified by the field mapping rules.

[0210] Dimension fields and member fields are taken from the fields in the component dataset that represent dimension names and dimension members; when the component dataset contains multiple dimensions, the report content assembly unit determines the combination of output dimension fields according to the field mapping rules and writes them in a fixed order on the same line;

[0211] Numeric fields are taken from the fields representing indicator values ​​in the component dataset and numeric type conversion is performed according to the field type identifier specified by the field mapping rules;

[0212] The time field is taken from the field representing the time granularity in the component dataset and output according to the time format specified in the template.

[0213] To ensure the output of the same export task is stable and reproducible, a fixed sorting rule is set for the report data table: first sort by the component identifier field, then sort by the time field; when there are duplicate time and member combination records in the component dataset, deduplication is performed according to the deduplication key specified by the field mapping rule. The deduplication key includes at least the component identifier field, indicator field, dimension field, member field, and time field.

[0214] The metadata writing unit is used to generate report metadata records and write them to the metadata area of ​​the report data table or report file. The report metadata records include a view snapshot identifier, a filter condition set identifier, a target component set identifier, a chart configuration version identifier, a data version identifier, and a generation timestamp.

[0215] The metadata writing unit reads the view snapshot identifier, filter condition set identifier, target component set identifier, and chart configuration version identifier from the export request context, reads the data version identifier from the data version storage unit, generates a generation timestamp, and assembles them into a report metadata record.

[0216] When the file format is identified as a CSV file, the metadata writing unit writes the report metadata records into the preset metadata area of ​​the CSV file. The metadata area is located before the report data table and records each metadata field in a fixed field order.

[0217] When the file format is identified as a spreadsheet file, the metadata writing unit writes the report metadata record to a separate metadata worksheet, or to a preset metadata area in the same worksheet, and records the location of that area in the template.

[0218] When the file format is identified as a PDF file, the metadata writing unit writes the report metadata record into the metadata area of ​​the PDF file or into the preset metadata block on the report homepage. The location of the metadata block is determined by the component layout definition.

[0219] The file generation unit is used to generate a report file from the report data table and report metadata records based on the component layout definition. To ensure the generated report file can be directly determined, the generation steps include:

[0220] The file generation unit reads the component layout definition and processes the component identifiers in the target component set sequentially according to the component display order. For each component identifier, the file generation unit filters out the set of records with the same component identifier field from the report data table and writes the set of records to the target location specified in the template.

[0221] The file generation unit formats numeric and time fields according to the display format identifier in the field mapping rules to ensure that the exported format of the same template is consistent.

[0222] To generate a unique identifier for the export task and use it for download address association, a report file identifier is generated, denoted as . First, a standardized concatenated string is generated by concatenating fields in a fixed order. Then, the summary is calculated to obtain the report file identifier. ,in, The string is concatenated according to a preset field order, which includes at least the following: view snapshot identifier, filter condition set identifier, target component set identifier, chart configuration version identifier, data version identifier, and generation timestamp. Adjacent fields are separated by a preset delimiter. Write the report metadata record and include it as part of the report file storage index.

[0223] The download output unit is used to return an export response message containing the download address of the report file to the display terminal when it receives an export request and passes the permission verification unit.

[0224] Before generating the export response message, the download output unit must at least verify that the user identifier corresponding to the export request has been verified by the permission verification unit, and that the target component set identifier carried in the export request is consistent with the report file generated this time.

[0225] The download output unit is based on the report file identifier. Locate the storage location of the report file and generate a download link. The download link must at least contain the report file identifier. This enables the display terminal to request and obtain the corresponding report file through the download address;

[0226] The exported response message should include at least: user identifier and report file identifier. The message includes the file format identifier, the target component set identifier, and the report file download address. After receiving the export response message, the display terminal can initiate a download request to obtain the report file via the provided download address.

[0227] 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 drill-down analysis and report generation of customer satisfaction at the dealer level, characterized in that, include: The display terminal and the platform server are communicatively connected; The display terminal includes an interactive event acquisition module and a visualization rendering module; The platform server includes: The hierarchy and filtering management module is used to maintain the hierarchical relationship, which includes at least the national level, regional level, group level and distributor level, and to assign node identifiers to the hierarchical nodes. It receives brand conditions, time conditions and regional conditions to form a set of filtering conditions, and generates a filtering condition set identifier corresponding to the set of filtering conditions. The drill-up and view state management module is used to receive drill-up events carrying the current level node identifier, the target level node identifier, the dimension identifier, and the member identifier; generate a data request based on the filter condition record corresponding to the filter condition set identifier; generate a view snapshot identifier for the view state corresponding to the drill-up process and store it; and restore the view state and trigger a data request based on the view snapshot identifier when returning to the previous level instruction or sharing access request. The linkage refresh module is used to establish component dependencies for multiple chart components in the dashboard interface and determine the set of affected target components, trigger data requests for the set of target components and drive the visualization rendering module to refresh the display. The permissions and query caching module is used to verify permissions for drill-up events, share access requests, and export requests, and to generate query signatures for data requests based on the user's permission scope and perform cache management. The report generation and output module is used to generate a report file based on the data request results corresponding to the target component set according to the report template, and provide download output to the display terminal. The linkage refresh module includes a dependency relationship establishment unit, a trigger component determination unit, an affected component set determination unit, and a linkage request issuance unit; The dependency relationship establishment unit is used to establish a component dependency relationship table for multiple chart components in the Kanban interface. The component dependency relationship table includes a source component identifier field, a target component identifier field, and a dependency type field. The dependency type field is used to identify one of the filter condition propagation dependency and the hierarchical node propagation dependency. The triggering component determination unit is used to determine the triggering component identifier based on the component identifier in the event message when an event message is received; The influencing component set determination unit is used to start from the triggering component identifier, traverse the source component identifier field and the target component identifier field in the component dependency table, generate a target component set identifier, and write the target component set identifier into the linkage control record; The linkage request sending unit is used to read the target component set identifier in the linkage control record and send a data request message containing the target component set identifier to the platform server. The data request message also includes a view snapshot identifier and a filter condition set identifier. The platform server carries a component identifier and a dataset identifier that correspond one-to-one with the target component set identifier in the returned data response message, so that the visualization rendering module can perform a refresh display based on the target component set identifier.

2. The dealer-level customer satisfaction drill-down analysis and report generation system according to claim 1, characterized in that, The interactive event acquisition module includes an event listening unit and an event message generation unit; The event listening unit is set in the chart component interaction layer of the dashboard interface. When it detects that the user performs a click operation, filter condition change operation, drill-down operation, return to the previous level operation, export operation, or share operation on the chart component, it collects the component identifier and operation parameters corresponding to the operation. The event message generation unit encapsulates the component identifier and the operation parameters into an event message and sends it to the platform server. The event message includes a user identifier, event type, timestamp, current level node identifier, target level node identifier, dimension identifier, member identifier, filter condition set identifier, and chart configuration version identifier. When the event type is a drill-down operation, the target level node identifier, the dimension identifier, and the member identifier are taken from the operation parameters; When the event type is a filter condition change operation, the filter condition set identifier is taken from the operation parameter.

3. The dealer-level customer satisfaction drill-down analysis and report generation system according to claim 2, characterized in that, The visualization rendering module includes a data binding unit and a rendering unit; The data binding unit receives the data response message returned by the platform server, and parses it to obtain the dataset identifier, component identifier and chart configuration version identifier that correspond one-to-one with the chart component. Based on the component identifier, the data dataset and the chart component are bound together. After the binding relationship is established, the rendering unit generates a graphic object according to the chart configuration parameters corresponding to the chart configuration version identifier and presents it in the component display area of ​​the dashboard interface. When the platform server carries a target component set identifier in the data response message, the rendering unit only performs the rendering on the chart component corresponding to the target component set identifier.

4. The dealer-level customer satisfaction drill-down analysis and report generation system according to claim 3, characterized in that, The hierarchy and filtering management module includes a hierarchy relationship maintenance unit, a node identifier generation unit, and a filtering condition normalization unit. The hierarchical relationship maintenance unit is used to store the hierarchical object table and the hierarchical relationship table. The hierarchical object table includes at least a hierarchical type field, a hierarchical object name field, and a hierarchical object code field. The hierarchical relationship table includes at least a parent node identifier field and a child node identifier field. The hierarchical type field is used to identify one of the following: national level, regional level, group level, and distributor level. The node identifier generation unit is used to generate a hierarchical node identifier based on the hierarchical type field and the hierarchical object encoding field, and write the hierarchical node identifier into the hierarchical object table; The filter condition normalization unit is used to receive brand conditions, time conditions, and regional conditions, respectively convert the brand conditions into a list of brand identifiers, the time conditions into a start date and an end date, and the regional conditions into a list of regional identifiers, and generate a filter condition set identifier according to a preset field order; The filter condition set identifier is stored in a filter condition table in a one-to-one correspondence with the brand identifier list, the start date and the end date, and the region identifier list. The filter condition table includes a filter condition set identifier field, a brand identifier list field, a start date field, an end date field, and a region identifier list field.

5. The dealer-level customer satisfaction drill-down analysis and report generation system according to claim 4, characterized in that, The drill-up and view status management module includes a drill-up event parsing unit, a data request generation unit, a view snapshot generation unit, a view status storage unit, and a view status playback unit. The drill-up event parsing unit is used to receive the drill-up event and parse it to obtain the user identifier, the current level node identifier, the target level node identifier, the dimension identifier, and the member identifier. The data request generation unit is used to generate a data request message based on the filter condition record corresponding to the filter condition set identifier, combined with the target level node identifier, the dimension identifier, and the member identifier. The data request message includes a level node identifier field, a dimension identifier field, a member identifier field, and a filter condition set identifier field. The view snapshot generation unit is used to generate a view snapshot identifier. The view snapshot identifier is obtained by concatenating the current level node identifier, the target level node identifier, the dimension identifier, the member identifier, the filter condition set identifier, and the chart configuration version identifier in a preset field order and then performing a hash operation. The view state storage unit is used to store view state records with the view snapshot identifier as an index. The view state record includes at least the current level node identifier field, the target level node identifier field, the dimension identifier field, the member identifier field, the filter condition set identifier field, and the chart configuration version identifier field. The view state playback unit is used to read the view state record corresponding to the view snapshot identifier when it receives a command to return to the previous level or a share access request, and replace the target level node identifier with the current level node identifier to generate a playback data request message and send it to the platform server.

6. The dealer-level customer satisfaction drill-down analysis and report generation system according to claim 5, characterized in that, The permission and query caching module includes a permission rule storage unit, a permission verification unit, a query signature generation unit, a cache read / write unit, and a cache invalidation control unit; The permission rule storage unit is used to store user permission records. The user permission record includes a user identifier field, a user permission scope identifier field, and an available function set field. The available function set field includes at least one of drill-down, share access, and export. The permission verification unit is used to read the user permission record when it receives a drill-down event, share access request or export request, verify whether the event type or request type of the request is included in the available function set field, and verify whether the hierarchical node identifier carried in the request belongs to the hierarchical node set corresponding to the user permission scope identifier. The query signature generation unit is used to generate a query signature for a data request. The query signature is obtained by concatenating the user permission scope identifier, hierarchical node identifier, filter condition set identifier, dimension identifier, member identifier, indicator set identifier, chart configuration version identifier, and data version identifier in a preset field order and then performing a hash operation. The cache read / write unit is used to perform a cache hit query with the query signature as the cache key, output the cached dataset when the cache key is hit, and write the data request result to the cache when the cache key is not hit. The cache invalidation control unit is used to delete the cache key corresponding to the data version identifier or the chart configuration version identifier when the data version identifier or the chart configuration version identifier changes.

7. The dealer-level customer satisfaction drill-down analysis and report generation system according to claim 6, characterized in that, The platform server includes an indicator set configuration storage unit and a data version storage unit; The indicator set configuration storage unit is used to store the indicator set configuration table, which includes an indicator set identifier field and an indicator identifier list field. The indicator set identifier in the query signature is taken from the indicator set identifier field of the indicator set configuration table. The data version storage unit is used to store a data version table, which includes a data version identifier field, an update batch identifier field, and an update time field. The data version identifier in the query signature is taken from the data version identifier field of the data version table, and the data version identifier is updated after each data access batch is completed.

8. The dealer-level customer satisfaction drill-down analysis and report generation system according to claim 7, characterized in that, The report generation and output module includes a template management unit, a report content assembly unit, a metadata writing unit, a file generation unit, and a download and output unit; The template management unit is used to store report templates. The report template includes component layout definitions, field mapping rules, and file format identifiers. The file format identifiers are used to identify one of CSV files, spreadsheet files, and PDF files. The report content assembly unit is used to receive the data request result corresponding to the target component set, and convert the data request result into a report data table according to the field mapping rule. The report data table includes at least a component identifier field, an indicator field, a dimension field, a member field, a numerical field, and a time field.

9. A dealer-level customer satisfaction drill-down analysis and report generation system according to claim 8, characterized in that, The metadata writing unit is used to generate report metadata records and write them to the metadata area of ​​the report data table or report file. The report metadata records include view snapshot identifier, filter condition set identifier, target component set identifier, chart configuration version identifier, data version identifier, and generation timestamp. The file generation unit is used to generate a report file from the report data table and the report metadata record according to the component layout definition. The download output unit is used to return an export response message containing the download address of the report file to the display terminal when it receives an export request and passes the permission verification unit.

Images