Business process visual early warning and strategy response method and device, equipment and medium

Abstract

The invention relates to the technical field of data analysis, can be applied to business scenes of financial science and technology, medical treatment and health and the like, and discloses a business process visualization early warning and strategy response method, which comprises the following steps: setting a physical interrupt node to collect interrupt operation track data, generating multilevel logic interrupt type structured data based on the operation track data, the method comprises the following steps: acquiring a preset business strategy, mapping the preset business strategy into a visual topological graph, identifying a preset business strategy verification failure type, counting interruption frequency, triggering a grading early warning instruction, and generating a page element weight adjustment parameter and a fault-tolerant threshold set. According to the method, the visual topological graph is constructed and the high-frequency interruption behavior is identified, so that real-time identification and graded early warning of business strategy verification failure are realized, and adaptive adjustment of page elements and strategy thresholds is further driven, so that the user insurance conversion rate is effectively improved and the front-end operation loss risk is reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of data analysis, and in particular, to a method, device, equipment and storage medium for visual warning and policy response of business processes. Background Art

[0002] In the field of fintech business, with the rapid expansion of insurance products and the extensive layout of online channels, more and more users conduct self-insurance through the mobile H5 page. However, in this process, a large number of users have entered the insurance process but have not completed the insurance behavior ultimately, forming a relatively high proportion of lost user groups. Such users usually have shown a clear intention to purchase insurance, and the information carried by their behavior paths and interruption nodes has extremely high conversion potential and business value. However, under the existing technology, enterprises generally rely on traditional page embedding means, and can only collect limited user operation data at preset positions, and cannot effectively capture and restore the fine-grained behaviors of the interrupted insurance process. This passive and static data collection method not only makes it difficult to identify user behavior deviation in a timely manner, but also cannot accurately locate and visually model the interruption nodes, resulting in the lack of active response means for enterprises in terms of improving user conversion rate and process optimization.

[0003] In the field of medical and health business, the process of users selecting health insurance products through online platforms is also complex and sensitive, usually involving multiple key nodes such as medical history filling, physical examination information submission, and health notification. The current system usually cannot distinguish whether the user interruption is due to specific factors such as failed health information matching, content understanding deviation, or poor page response experience. The user loss behavior in the medical scenario not only affects the conversion rate, but also may hide potential risk hazards. Due to the diverse causes behind the interruption behavior, relying on fixed-rule embedding is difficult to comprehensively reflect the true intentions of users and the decision-making blocking points, resulting in the lack of support based on behavior logic for product strategies, page interaction optimization, and risk model parameter adjustment.

[0004] In the context of the rapid development of big data and intelligent visual analysis technologies, some enterprises have tried to introduce a method of combining log embedding and manual analysis to restore and analyze the insurance process. However, the current means still highly rely on data developers for temporary data extraction and query operations, lacking a standardized structured behavior modeling and cross-role collaboration mechanism. In addition, the data processing process is lengthy, and the accuracy is easily affected by the subjectivity of the analysis method, and it is also difficult to support the needs of real-time warning and process intervention, especially in complex processes with multiple strategies and multiple page jumps. Therefore, there are still large technical gaps and application blind spots in the existing technology in terms of user behavior path restoration, visual recognition of interruption behaviors, and policy-level response capabilities. Summary of the Invention

[0005] The main object of the present invention is to provide a business process visualization warning and policy response method, device, equipment and storage medium, aiming to solve the technical problems in the prior art that cannot structurally classify, visually model the business process interruption behavior, and achieve hierarchical warning and policy optimization response based on the interruption frequency.

[0006] To achieve the above object, the present invention provides a business process visualization warning and policy response method, including:

[0007] Set a plurality of physical interruption nodes on the front-end interface of the business process;

[0008] Collect the operation track data of the interrupted business process through the physical interruption nodes;

[0009] Classify the operation track data into multi-level logical interruption type structured data according to the business process sequence;

[0010] Map the multi-level logical interruption type structured data into a visual topology graph;

[0011] Screen out the entries with the logical interruption type being the preset business policy verification failure type from the multi-level logical interruption type structured data;

[0012] According to the interruption timestamp field in the screened entries, count the trigger times of the preset business policy verification failure type, and generate interruption frequency data based on the interruption timestamp field, trigger times and preset business policy verification failure type;

[0013] When the interruption frequency data exceeds the baseline number upper limit, trigger a hierarchical warning instruction including the preset business policy version identifier;

[0014] Generate page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding preset business policy version according to the preset business policy verification failure type data associated with the hierarchical warning instruction.

[0015] Further, to achieve the above object, the present invention provides a business process visualization warning and policy response device, including:

[0016] An interruption node configuration module, configured to set a plurality of physical interruption nodes on the front-end interface of the business process;

[0017] An operation track acquisition module, configured to collect the operation track data of the interrupted business process through the physical interruption nodes;

[0018] A logical interruption classification module, configured to classify the operation track data into multi-level logical interruption type structured data according to the business process sequence;

[0019] A topology graph construction module for mapping the multi-level logical interruption type structured data into a visual topology graph;

[0020] An interruption screening module for screening entries with the logical interruption type being the preset business policy verification failure type from the multi-level logical interruption type structured data;

[0021] An interruption frequency statistics module for counting the number of trigger times of the preset business policy verification failure type according to the interruption timestamp field in the screened entries, and generating interruption frequency data based on the interruption timestamp field, the number of trigger times, and the preset business policy verification failure type;

[0022] An early warning trigger module for triggering a hierarchical early warning instruction including a preset business policy version identifier when the interruption frequency data exceeds the baseline number upper limit;

[0023] A policy optimization parameter generation module for generating page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding preset business policy version according to the preset business policy verification failure type data associated with the hierarchical early warning instruction.

[0024] Furthermore, to achieve the above object, the present invention also provides a computer device, which includes a memory, a processor, and a business process visualization early warning and policy response program stored in the memory and executable on the processor. When the business process visualization early warning and policy response program is executed by the processor, the steps of the business process visualization early warning and policy response method as described above are implemented.

[0025] Furthermore, to achieve the above object, the present invention also provides a computer-readable storage medium, on which a business process visualization early warning and policy response program is stored. When the business process visualization early warning and policy response program is executed by a processor, the steps of the business process visualization early warning and policy response method as described above are implemented.

[0026] Beneficial effects: The present invention relates to the technical field of data analysis and can be applied to business scenarios such as fintech and healthcare. A business process visualization warning and policy response method is disclosed, including: setting a physical interruption node to collect interruption operation trajectory data, and classifying the data into multi-level logical interruption type structured data based on the business process sequence; mapping the structured data into a visualization topology graph, screening entries with the logical interruption type being the preset business policy verification failure type, and statistically generating interruption frequency data for the interruption timestamp field; when the frequency exceeds the baseline number upper limit, triggering a hierarchical warning instruction including the preset business policy version identifier, and generating page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding policy version according to the instruction. By constructing a visualization topology graph and identifying high-frequency interruption behaviors, the present invention realizes real-time identification and hierarchical warning of business policy verification failures, further driving the adaptive adjustment of page elements and policy thresholds, thereby effectively improving the user's insurance purchase conversion rate and reducing the risk of front-end operation loss. Brief Description of the Drawings

[0027] The present invention will be further described below in conjunction with the drawings and embodiments. In the drawings:

[0028] Figure 1 is a schematic diagram of an application environment of the business process visualization warning and policy response method in an embodiment of the present invention;

[0029] Figure 2 is a schematic flowchart of an embodiment of the business process visualization warning and policy response method of the present invention;

[0030] Figure 3 is a schematic diagram of the functional modules of a preferred embodiment of the business process visualization warning and policy response device of the present invention;

[0031] Figure 4 is a schematic diagram of the structure of a computer device in an embodiment of the present invention;

[0032] Figure 5 is another schematic diagram of the structure of a computer device in an embodiment of the present invention. Detailed Embodiments

[0033] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0034] The business process visualization warning and policy response method provided by the embodiments of the present invention can be applied in such as Figure 1In the application environment, the client communicates with the server through the network. The server can set the physical interruption node to collect interruption operation trajectory data through the client, and classify the data into multi-level logical interruption type structured data based on the business process sequence; map the structured data into a visual topology graph, screen the entries with the logical interruption type being the preset business policy verification failure type, and count the interruption timestamp field to generate interruption frequency data; when the frequency exceeds the upper limit of the baseline number, trigger a hierarchical warning instruction including the preset business policy version identifier, and generate page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding policy version according to the instruction. The present invention realizes the real-time identification and hierarchical warning of business policy verification failure by constructing a visual topology graph and identifying high-frequency interruption behaviors, further driving the adaptive adjustment of page elements and policy thresholds, thereby effectively improving the user insurance purchase conversion rate and reducing the risk of front-end operation loss. Among them, the client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented by an independent server or a server cluster composed of multiple servers. The present invention will be described in detail below through specific embodiments.

[0035] Please refer to Figure 2 , Figure 2 which is a schematic flowchart of an embodiment of the business process visualization warning and policy response method provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than here.

[0036] As Figure 2 shown, the business process visualization warning and policy response method proposed by the present invention includes the following steps:

[0037] S10, set a plurality of physical interruption nodes on the front-end interface of the business process;

[0038] In this embodiment, the purpose of setting a plurality of physical interruption nodes on the front-end interface of the business process is to analyze the precise position and type of user behavior interruption, so as to provide a structured basis for subsequent interruption attribution and warning. The front-end interface of the business process refers to a set of page elements that can be interacted with by the user, including but not limited to form filling pages, confirmation pages, payment pages, or notification pages. These page structures correspond to specific process steps, and the controls, buttons, input boxes, etc. on each page all constitute key positions that may trigger user interruption behaviors.

[0039] A physical interruption node refers to an explicit interface control or behavior trigger point in the system that can capture the behavior of operation termination. These trigger points do not necessarily represent browser closure or process termination, but include behaviors such as input termination, click to abandon, page exit, etc. that can be perceived by the front end of the system, such as clicking the back button, staying for more than the threshold time without completing input, actively clicking to close the prompt pop-up window, jumping to other links, etc. Setting these physical interruption nodes requires combining the structured identification of page elements, for example, based on the unique identification path of each control element in the DOM (Document Object Model) structure, such as accurately describing the corresponding control through XPath or CSS Selector.

[0040] These nodes are usually accessed through configuration rather than hard-coded. The implementation process can be automatically instrumented through the front-end monitoring SDK, or the interaction event listener can be registered by parsing the configuration file, and the node recognition logic can be injected into the system rendering process. Each node needs to be bound with a unique identifier, which can include information such as control ID, page path, control position sequence, business type code, etc., and establish a mapping relationship with the interruption event collection module in the back-end system.

[0041] During the implementation process, the system also needs to define the behavior trigger rules for each registered physical interruption node, including trigger conditions (such as click, input blur, page exit), data reporting content (such as user identification, device identification, timestamp, control identifier, page context where it is located), and exception judgment logic. The setting of trigger rules can be deduced through front-end behavior modeling rules, or enhanced configuration can be performed after automatically counting abnormal high-frequency nodes in the background.

[0042] In one specific implementation, the JavaScript SDK can be embedded in the front-end page. The SDK scans the node identifiers in the configuration manifest during the page loading phase and binds the listening functions to the corresponding DOM element events, such as click, blur, unload, etc. The configuration manifest can adopt the JSON format and support fields such as control path, trigger event, exception type mark, etc. The system can also integrate the buried point management background, drag and select controls in the page visualization structure, automatically generate the node path and publish the configuration, realizing operation and maintenance level deployment without development.

[0043] Another way is to adopt non-intrusive proxy monitoring technology, combine the browser MutationObserver or IntersectionObserver interface to monitor the change of control state, and then perform real-time analysis based on user behavior and judge whether it constitutes a physical interruption event. This method is more suitable for scenarios where it is difficult to modify the source code of the existing front-end system.

[0044] It is also possible to extend the component encapsulation specification based on standardized front-end frameworks (such as React and Vue), encapsulate the interruption node registration logic in the public component lifecycle function, and ensure the standardization, inheritance, and reusability of the interruption node deployment. For the low-code platform, it is also possible to embed the interruption control library components, and developers can automatically register the interruption identifiers and collection rules when dragging components, further reducing the implementation difficulty.

[0045] In different business environments, such as the medical and health insurance system, it may involve complex health information disclosure processes. At this time, the control interruption nodes include the heart rate, blood pressure, and past medical history filling areas. In the financial risk control decision-making system, they may be key points in processes such as risk assessment questionnaires and identity verification. For the multi-terminal deployment scenario, a unified control identifier naming rule and platform difference adaptation logic can be designed to ensure that both the mobile and desktop terminals can access the same interruption perception system.

[0046] Example illustration: In the insurance application business process, users need to complete multiple steps online to generate an insurance policy. By analyzing the buried point structure of the existing front-end interface, it is found that there are naturally a large number of control nodes and operation behaviors strongly related to interruption behaviors throughout the application path, which can be defined and captured as physical interruption nodes. For example, in "Termination after page opening", the system can embed a physical interruption node in the page loading event. When the user exits the browser without making any valid clicks after the page initialization is completed, this node can be recorded as a non-interactive termination. In the "Termination at the pre-guidance page" section, the user may leave without clicking the "Apply now" button after browsing the marketing page or product introduction page. The system forms a physical node for judging interruption through the exposure and un-triggered state of this button. Further, in steps such as "Termination at the quote filling page" and "Termination at the health declaration page", the page contains multiple high-risk fields and strongly interactive controls, such as controls for age input, disease history selection, BMI filling, etc. After configuring the corresponding physical interruption nodes on these controls, the system can real-time perceive whether the user interrupts the process during the operation of a certain field or gives up submission after verification fails. In addition, behaviors such as uploading ID photos in "Termination at the real-name authentication page", the OCR recognition failure prompt button, and the unactivated payment method selection card in "Termination before payment page" can all be bound to physical interruption nodes through actual control events. Whenever the user has behaviors such as jumping out, closing the page, staying overtime, or quickly swiping at these controls, the system will automatically trigger the collection of interruption events, accompanied by fields such as control identifiers, interruption timestamps, and front and back interaction trajectories. The setting of these physical interruption nodes not only covers the complete path from guidance to payment, but also has the characteristics of being measurable, traceable, and retraceable, providing basic support for subsequent construction of structured data of interruption types and hierarchical early warning. These nodes are all real interactive components in the front-end interface, with clear event listening points, and can achieve interruption perception in a non-intrusive manner, thus supporting the closed-loop implementation of the entire visualization early warning method.

[0047] By deploying physical interruption nodes in the front-end interface of the business process, the system can accurately perceive the interruption behaviors of users at each control and each path in the process, thereby providing a clear-structured and clearly identified original event basis for subsequent data collection, path analysis, and early warning modeling. It improves the accuracy and controllability of interruption positioning, makes the analysis of interruption reasons no longer rely on subjective feedback from users or fuzzy inferences from the back-end, and provides technical support for business process optimization.

[0048] S20. Collect operation trajectory data of the interrupted business process through the physical interruption node;

[0049] In this embodiment, in order to achieve full - process observation and cause identification of interruption behaviors, it is necessary to rely on the deployed physical interruption nodes to perform real - time perception and data collection on unexpected exits, process disconnections, or page jumps and other behaviors that occur during the user's page operation. These physical interruption nodes are usually embedded in key interaction positions in the form of front - end control listeners, page event catchers, or user behavior recording scripts, such as button clicks, field input box out - of - focus, page load failures, window closing, or interception before refreshing and other operation links. By embedding the listening mechanism, the interaction behaviors triggered by the user are captured and linked with the process control state to determine whether it constitutes an interruption event.

[0050] During the collection process, the system will associate and record the interruption event with its occurrence context, including the current page URL, device type, user identification, network status, interruption timestamp, the previous operation node identification, the control element ID that triggers the interruption, operation types (click, jump out, refresh, etc.), browser environment parameters, etc. These data are pushed by the front - end interruption nodes to the server - side data receiving interface through the data - embedding script. The server - side system performs structured encapsulation on the received event information, and uniformly maps the field names, time formats, and event classification criteria according to the configuration rules to ensure the consistency and traceability of multi - terminal data.

[0051] In addition, to enhance the integrity of the operation track and the accuracy of interruption identification, the collection mechanism also introduces a state - keeping logic to record the behavior sequence before the interruption, including access starting points, historical page transition links, filled - in field values, operation delay behaviors, focus stay durations, and other information. These additional contents will be part of the track sequence to support subsequent behavior chain modeling and precise location analysis of the process interruption position.

[0052] The whole process of data collection needs to have low latency and high robustness, ensuring that the data is completely delivered without affecting the user operation experience. Therefore, the front - end script design needs to adopt an asynchronous non - blocking communication mode, and combine a cache queue and a re - sending mechanism to handle weak - network scenarios, ensuring that interruption events at key nodes are not missed. The collection module is usually decoupled from the front - end page rendering service for easy unified access and policy update. At the same time, it supports remotely controlling the collection granularity and enabling status through the configuration center to meet the dynamic adjustment requirements of collection accuracy for different - stage services.

[0053] In actual deployment, the operation trajectory data collection function is automatically loaded and event registered by the front-end buried point SDK. The development team will identify all key physical interruption nodes based on the page prototype diagram and business path definition, and insert unified data binding instructions in the front-end template. For example, configure the attribute data-interrupt-node-id for each control to mark its node ID. After the SDK is started, it will scan all the bound interruption nodes and register corresponding listening functions based on the preset event types. For example, register the "click" event for button controls, register the "blur" and "change" events for input controls, and register the "beforeunload" event for the entire page to sense forced exit.

[0054] When an event is detected, the SDK will read fields such as control identification, event type, occurrence time, page URL, user SessionID, etc., and at the same time append the summary of all form fields that have been filled in on the current page to form a raw trajectory event object. The event object will be sent to the back-end interruption trajectory collection service, and the collection service will determine whether it belongs to an interruption event and write it into the trajectory analysis database.

[0055] For the adaptation of different devices and business terminals, an end-to-end data collection channel can also be introduced. For example, when using RN or Flutter in a mobile APP, relevant components can perform interruption monitoring in the form of native bridging; the WeChat mini-program terminal can use onUnload in combination with route monitoring; the PC browser can use visibilitychange in combination with performance detection to judge leaving.

[0056] By accurately binding the perception entry of interruption behavior to specific physical interruption nodes and combining event listening and context information extension, high-precision and high-coverage collection of interruption operations is achieved, avoiding the problem of fuzzy path recognition based on traditional back-end log speculation. It not only realizes the real-time reporting of interruption behavior, but also provides a structurally complete and granularly clear basic data source for subsequent data classification, frequency statistics, and interruption visualization.

[0057] S30, classify the operation trajectory data into multi-level logical interruption type structured data according to the business process sequence;

[0058] In this embodiment, operation trajectory data refers to a set of operation events generated by users through front-end pages or controls in the business process, usually including event types such as page stay, control click, content input, and request submission, and is accompanied by field information such as event trigger time, interruption timestamp, control identifier, and business process node number. The core of classifying operation trajectory data according to the order of business processes is to construct a logical execution path with time consistency and node sequence consistency, so as to trace the link where the interruption occurred and the motivation of the user's interruption behavior. The determination of the business process sequence can be based on a preset process definition file, which expresses the logical order of each stage of the business in the form of a graph structure, a process linked list or a node tree, and assigns a unique identifier to each process node.

[0059] When classifying the operation trajectory data, it is necessary to first extract the last valid node operation and locate it in combination with the corresponding interruption timestamp field. The positioning operation is used to determine the process node where the user stayed before leaving or terminating the process. According to the context position of the node in the process definition file, the stage of occurrence of the interruption and its possible causes can be further deduced. When the interruption corresponds to a failure in the server-side policy judgment, such as health notification data not meeting the conditions, insufficient risk control model score, system interface verification failure, etc., it can be classified as a preset business policy verification failure type; and when the interruption cause is a behavior-triggered event such as user page closing, clicking back, or not responding within the specified time, it is classified as a user-initiated termination type.

[0060] After classification is complete, the results must be presented in a structured format. The structured fields should include, but are not limited to, business process stage fields (e.g., information entry, health notification, payment confirmation, etc.), interruption type fields (e.g., policy verification failure, active termination), control identification fields, interruption timestamp fields, and associated policy version fields. This structured result will serve as the basis for subsequent mapping to a visual topology diagram, frequency statistics, and the generation of early warning instructions.

[0061] In the actual system, the event tracking middleware can be used in conjunction with the browser-side tracking SDK to collect operation trajectories, and transmit them to the back-end analysis module in real time through the message queue. The back-end analysis module uses the process definition metadata and the interruption classification rule engine to aggregate the operation trajectories within the same user's single insurance process into an event chain, determine the last valid operation node, and extract relevant fields. For interruption events that are determined to have failed policy verification, the policy verification module can be used to backtrack the hit policy items and judgment results; for active termination events, the user behavior event feature library (such as page pop-ups, window closings, etc.) is combined to determine the behavioral intention. Different systems can expand and refine structured fields based on their own process depth, control complexity, and policy rule granularity.

[0062] Example description: In the healthcare scenario, a user purchases a critical illness insurance product through the self-operated H5 page. The purchase process includes multiple front-end page nodes such as home page display, policyholder information filling, insured person information filling, health declaration, confirmation of coverage responsibilities, and payment submission. The user entered a height of 160 cm and a weight of 95 kg on the health declaration page. The system determined that their BMI index exceeded the upper limit configured for the current underwriting version and did not meet the requirements of the health declaration. When the user clicked the "Next" button to submit the information, it triggered the server-side policy judgment module to return a failure prompt, and a pop-up window showing "Temporary non-support for purchase" was displayed on the page. The user then closed the page and exited the process. During this process, the operation track collection module recorded the user's click behavior, interruption timestamp, control identifier "#btn_submit_ghg3.1", and the returned policy hit item "BMI exceeded the limit" on the health declaration page, and also recorded the policy version "Health Declaration Policy V3.1" used for this event. The back-end system parsed this operation track chain, confirmed that the user interrupted at the health declaration node, and this interruption met the "preset business policy verification failure type" defined by the system. The system further extracted the control identifier, policy version identifier, node name, trigger timestamp, etc. in the event to generate the following structured data fields:

[0063] Business process stage: Health declaration; Interruption type: Policy verification failure; Control identifier: #btn_submit_ghg3.1; Interruption timestamp: 2025-03-29T14:23:11Z; Policy version identifier: Health Declaration Policy V3.1; Policy hit type: BMI exceeded the limit.

[0064] In the fintech business, another user tried to apply for a small accidental injury insurance through the H5 terminal. They stayed on the contact information filling page for more than 10 minutes without any operation and then directly closed the page. In the collected operation track, the last event was the input box focus timestamp "2025-03-29T10:45:02Z", the page closing timestamp "2025-03-29T10:56:11Z", and the control identifier was "#input_contact_name". After parsing, the back-end determined that this behavior was a typical user-initiated termination behavior, mapped to an interruption in the "information filling process" stage and the type of "user-initiated termination", and generated the following structured data:

[0065] Business process stage: Filling contact information; Interruption type: User-initiated termination; Control identifier: #input_contact_name; Interruption timestamp: 2025-03-29T10:56:11Z; Policy version identifier: null; Policy hit type: null.

[0066] Through these structured expressions, different types of process interruptions can be accurately captured and classified, providing a clear starting point and logical source for subsequent data analysis, frequency statistics, early warning identification, etc., and offering visual support and a basis for strategy updates for process optimization. This structured expression also supports expansion and reuse under different business lines and different control structures, with good engineering adaptability and product practical value.

[0067] By classifying user operation trajectory data in the order of the business process and generating structured interruption type data, the interruption behaviors in the insurance application process can be effectively mapped to logical node types that can be quantitatively analyzed, and further reveal process bottlenecks and strategy blocking positions, enabling more context-aware behavior attribution and cause derivation.

[0068] S40, map the structured data of the multi-level logical interruption type to a visual topology graph;

[0069] In this embodiment, after generating the structured data of the multi-level logical interruption type, in order to achieve visual tracking and multi-dimensional data display of the interruption type, the structured data needs to be topologically mapped. During the mapping process, the core classification fields in the structured data need to be identified first, namely the first-level logical interruption type and the second-level logical interruption subclass fields, and these two fields constitute the backbone structure of data aggregation. In the topological structure, the first-level logical interruption type field is used to generate the topological main node, which is an attribution node for macro business process interruptions, such as "failed health declaration", "payment abandonment", "information missing", etc.; while the second-level logical interruption subclass field is used to generate subordinate child nodes mounted under the main node to express more specific cause classifications, such as "BMI exceeding the limit", "bank card not verified", "contact person's mobile phone number missing", etc.

[0070] After the nodes are generated, in order to encode the interruption activity in different time dimensions, the time series field in the structured data needs to be extracted, and combined with the current time and the interruption timestamp, calculate the heat value of each interruption event, and this heat value is used to represent the "freshness" or "urgency" of the event. A common calculation method is to divide the difference between the "current time" and the "interruption timestamp" by a preset time window (such as 24 hours) and perform a normalized inversion process. The higher the heat value, the closer the interruption time is to the current time. Then generate a hue gradient value according to the calculated heat value, and establish a mapping model between the heat value and the color. For example, use red to represent a high heat value and blue to represent a low heat value.

[0071] Furthermore, the business policy version identification field contained in the structured data must be displayed in the diagram using icons and labels. This policy version information not only helps locate the source of the interruption policy but also serves as an auxiliary clue for subsequent policy evaluation and policy rollover management. Finally, connecting edges are constructed based on the logical subordinate relationships between the first-level and second-level nodes. The line width of the connecting edge can be positively correlated with the interruption frequency corresponding to the first-level logical interruption type, and the color of the edge should be consistent with the hue gradient of the primary node to enhance visual alignment and hierarchical perception.

[0072] This mapping process not only constructs a structural node graph, but also encodes the subordination, frequency and thermal data between nodes into the graph, realizing the fusion expression of interruption data in the graph space.

[0073] During implementation, a front-end visualization engine (such as D3.js or ECharts) can be used to dynamically generate topology diagrams. The system backend first establishes a data model based on the structured interruption data, using the first-level logical interruption type as the main node of the diagram. This is rendered as a circular node on the front-end canvas, with the node size linked to the cumulative interruption frequency. Each main node then has its corresponding sub-nodes, generated using the second-level logical interruption sub-type field in the structured data and similarly displayed as circles or rectangles.

[0074] To express temporal thermal energy, the server pre-calculates thermal values during data processing and converts them into HSV or RGB color values for dynamic rendering by the front-end engine. Policy version identifiers are attached to nodes as visual labels, distinguished by different colors or border styles and interruption frequency information. All node and edge data structures are organized into a standard graph data format (such as the nodes and links fields in JSON) to enable efficient interaction between the front-end and back-end.

[0075] In terms of graph layout algorithms, force-directed layout can be used to allow nodes to expand naturally, or layered layout can be chosen to ensure that the main node is always on the main axis of the graph for easy focus. Edge rendering logic should dynamically adjust line width parameters based on the main node frequency, while allowing users to click on nodes to view specific strategy hit information or jump to the strategy tuning portal.

[0076] Example description: In the medical and health insurance business, a health insurance platform has configured a health disclosure verification strategy covering multiple products and populations. As the business develops, the number of users who are unable to complete insurance due to the health disclosure link has increased significantly in a certain quarter. The backend system topologically maps the structured interruption data of all users who have failed to be insured recently to generate a visual topology diagram. In the diagram, "health disclosure failure" is a first-level node, which gathers multiple child nodes, such as "BMI exceeds the limit", "high blood pressure is not reported", "physical examination report is missing", etc. The node color is distributed from blue to red, and the red node is significantly focused on "BMI exceeds the limit", and the policy version V3.2 corresponding to this node is marked as a policy label in the diagram. The edge connections are dense, the line width is thick, and the frequency is high, indicating that the interruption has concentrated in the recent period.

[0077] In a financial insurance scenario, during the application process for a small personal accident insurance product, the operations team observed a significant increase in the frequency of "Incomplete Payment" as the primary node through a topology diagram. Further tracking of the subnodes revealed that "Credit Card Verification Failure" was the most significant interruption. This subnode, with a red hue and high heat value, and the version label "Payment Strategy V1.4," indicated a surge in interruption events within a week of the launch of this policy version. Based on this information, the team promptly adjusted the policy parameters and optimized the front-end payment verification logic, effectively reducing the subsequent trigger rate of this node.

[0078] By mapping structured outage data into a visual topology, we achieve the goal of visualizing and structured presentation of abstract outage categories and policy events. This process integrates information from multiple dimensions, including business classification, time-based trends, policy versions, and data frequency, enabling business operations personnel to quickly identify outage hotspots, changing trends, and policy triggering structures through a visual interface. Compared to traditional log screening or table analysis, topology maps significantly improve decision-making efficiency and policy response speed.

[0079] S50, filtering entries whose logical interruption type is a preset service policy verification failure type from the multi-level logical interruption type structured data;

[0080] In this embodiment, in the completed multi-level logical interruption type structured data, the logical interruption type field usually exists in the form of enumeration or multi-level classification, indicating the cause of the business process interruption. This type of structured data not only contains the context information of each interruption event (such as control identifier, timestamp, policy version identifier), but also records the logical interruption type corresponding to the event in the form of a field. In order to further focus on the monitoring and analysis of the execution link of the preset business policy, it is necessary to filter these structured data entries and extract the record set whose logical interruption type is equal to the preset business policy verification failure type.

[0081] This operation relies on a predefined enumeration set of business policy verification failure types, which is dynamically maintained by the policy management service or configuration system according to the online policy list. It contains all verification classifications with business policy trigger logic, such as "health declaration verification failed", "payment logic verification failed", "user qualification verification failed", etc. The screening process needs to be based on the first-level logic interruption type field in the structured data to match whether the field value belongs to the set of predefined business policy verification failure types.

[0082] When performing the screening action, to ensure the accuracy and timeliness of the results, filtering conditions such as dynamic enumeration pulling, version matching verification, and data time range limitation can be supported to ensure that the screening results can accurately reflect the true impact range of the current version policy on interruptions. The finally screened set of entries will be used as the core input data set for subsequent statistics, analysis, and early warning, ensuring that the data processing logic has target focus and policy traceability.

[0083] Example illustration: In a medical and health insurance platform, a health declaration policy V3.2 was launched in a certain quarter. This policy contains multiple parameter thresholds and control verification logics. After a user completes filling in health information, if it fails due to rules such as BMI, pre-existing medical conditions, and age not meeting the requirements, it is recorded as "health declaration verification failed". After the platform has accumulated interruption data for a period of time, the system performs a screening operation to filter out all entries with the first-level logic interruption type of "health declaration verification failed" from the complete structured data set of logic interruption types, and filters out irrelevant records such as "payment not completed" and "user actively exits". The screening results contain the true trigger data of this policy under the specified time window, including specific control identifiers, failure timestamps, and user source channels, providing a solid data foundation for subsequent generation of frequency data, hierarchical early warning, and policy optimization.

[0084] In the financial and insurance business scenario, an accident insurance product platform launched a payment verification optimization policy V1.8 in the fourth quarter of 2023. Through the screening function of the interruption structured data, the platform extracted all entries with the logic interruption type of "payment verification failed" and confirmed that they were all triggered by the policy rule verification logic rather than user manual cancellation. This screening action ensures that subsequent frequency statistics are not interfered by non-policy interruption factors, making the hierarchical early warning mechanism more accurate and reliable.

[0085] By accurately screening out the entries corresponding to the preset business policy verification failure types from the multi-level logical interruption type structured data, uncontrollable or non-policy-related interruption factors such as user-initiated termination and page stay timeout are effectively isolated, making the subsequent statistical and early warning analysis more focused on the real business disruptions caused by policy execution. This screening operation not only improves the target consistency of interruption data analysis but also constructs a causal data path bound to the policy version, providing a data basis for policy effect evaluation and anomaly monitoring.

[0086] S60, according to the interruption timestamp field in the screened entries, count the number of trigger times of the preset business policy verification failure type, and generate interruption frequency data based on the interruption timestamp field, the number of trigger times, and the preset business policy verification failure type;

[0087] In this embodiment, the interruption timestamp field is usually a basic field recorded in each structured interruption entry in a standard time format, and its function is to identify the exact time point when a specific interruption event occurs in the business process. After completing the screening of the entries of the policy verification failure type, this field can be used as a key statistical benchmark to perform time-dimensional analysis of the policy trigger frequency.

[0088] To achieve frequency statistics, a reasonable time aggregation granularity needs to be defined first. This granularity usually manifests as a preset time window, which can include hours, days, weeks, natural months, or business quarters, etc. For example, when dividing by day as the time window, the system needs to determine which natural day the timestamp of each interruption event belongs to and classify it into the counting bucket under that date. The system groups and statistically analyzes all the screened interruption events according to the time window, and the number of policy verification failures within each time window can be obtained, thereby generating interruption frequency data with a time series structure.

[0089] The structure of the interruption frequency data generally includes three basic fields: time window, policy verification failure type, and number of trigger times. This structure can be used to support subsequent operations such as baseline model calculation, trend analysis, and month-on-month change rate calculation, and has high scalability and model compatibility. Parallel statistics for multiple policy types should also be supported during the statistical process to adapt to the actual application scenarios of concurrent operation of multiple business lines and multiple policy versions.

[0090] Through aggregate statistics based on the interruption timestamp field, not only the trigger frequency modeling of the policy verification failure type in each time window is realized, but also a quantifiable index basis is provided for subsequent fluctuation detection, anomaly warning, and dynamic fault tolerance adjustment.

[0091] S70, when the interruption frequency data exceeds the baseline number upper limit, trigger a hierarchical warning instruction including the preset business policy version identifier;

[0092] In this embodiment, interruption frequency data is a record of the number of policy verification failures triggered within a time window, calculated based on historical trajectory information. The baseline upper limit is the normal fluctuation range of this type of policy interruption during similar historical periods, used to define the abnormal boundary. When the interruption frequency data reaches or exceeds this baseline limit, immediate classification judgment and warning triggering are required.

[0093] First, the system reads the trigger count field and its corresponding policy version identifier field in the interruption frequency data object within the current time window to locate the currently active policy version and its performance fluctuation indicator. The system then calls the historical interruption frequency data cache or analysis results, matches the trigger record set for the same period in the current time window according to the periodic attributes (e.g., quarterly Q1, Q2, etc.), and extracts the trigger count sequence, such as the frequency values for the same quarter over the past three years.

[0094] The system then uses this historical sequence to calculate the upper limit of the strategy's baseline number of times during that time window. This upper limit is typically calculated using statistical interval methods, such as the mean plus three standard deviations (μ+3σ) or the upper bound of a 95% confidence interval, to ensure that it covers abnormal growth outside the normal fluctuation range. This baseline value can be dynamically updated by the strategy analysis module, and an upper threshold can be set in the configuration system to limit its growth range.

[0095] After comparing the upper and lower limits, if the current trigger count field exceeds the baseline upper limit, the system enters the alert generation process. At this point, the system first calculates the over-limit value (i.e., the current trigger count minus the baseline upper limit) and matches this value to the corresponding graded alert rule table based on the interval level. This rule table defines the mapping between over-limit ranges and alert levels. For example, an over-limit of 0–10 times corresponds to a level 1 alert; an over-limit of 11–30 times corresponds to a level 2 alert; and an over-limit of 30 times or more corresponds to a level 3 alert.

[0096] After a successful match, the system generates a hierarchical warning instruction. This instruction is a structured object containing fields such as the current time window identifier, the actual number of triggers, the upper limit of the baseline number, the extent of the overrun, the warning level of the matching result, the policy version identifier, and the current policy type field. This instruction can be used as a trigger action push notification or as a decision parameter for subsequent policy weight adjustment modules.

[0097] Generated, graded warning instructions can be pushed to designated warning channels, such as email servers, SMS gateways, instant messaging systems, and operational dashboards. These instructions support JSON, XML, or internally pre-defined protocol structures, ensuring high compatibility and lightweight transmission. In some systems, these warning instructions can also serve as pre-trigger conditions for automatic policy adjustments, leveraging policy fault tolerance settings or front-end saliency optimization components.

[0098] By comparing the numerical relationship between the interruption frequency data and the baseline upper limit, it is possible to promptly identify scenarios where the failure frequency of business strategy verification abnormally increases, and trigger a hierarchical warning instruction containing the preset business strategy version identifier, enabling the system to quickly locate the potentially abnormal strategy versions and business controls, and then driving subsequent page adjustments and strategy corrections, thereby enhancing the stability of the business process and the response efficiency of strategy operation and maintenance.

[0099] S80, generate page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding preset business strategy version according to the preset business strategy verification failure type data associated with the hierarchical warning instruction.

[0100] In this embodiment, after the system receives the hierarchical warning instruction, it structurally analyzes the preset business strategy verification failure type data contained therein, and extracts two core fields: the unique identifier of the page control and the corresponding business strategy version identifier. The unique identifier of the page control usually points to a business interaction node bound in the front-end page, such as a form input box, a drop-down selector, or a confirmation button. This identifier can be generated and cached by the rendering engine when loading the page, or preset as a component parameter by the developer. The business strategy version identifier serves as an index key for the server-side strategy verification module, used to accurately point to the currently running set of strategy logics. Different versions may trigger different business interruption behaviors due to rule differences.

[0101] Using the control identifier as an index, the system searches for interruption frequency data related to the historical trigger behavior of the control. The data sources include local log files, real-time monitoring streams, or backend interruption record tables. After being standardized, the interruption frequency value is mapped to a priority coefficient, which is used to regulate the salience degree during page rendering. The priority coefficient can be linearly positively correlated with the frequency, or can be dynamically adjusted through piecewise functions, exponential functions, or weight models. For example, when the frequency is greater than the preset threshold, the priority coefficient will rapidly increase to ensure that key page controls can be noticed by users and input behaviors can be corrected in a short time.

[0102] Meanwhile, the system extracts the historical fault tolerance configuration record in the strategy management database based on the strategy version identifier, and locates the fault tolerance trigger times field of the target version. This field represents the upper limit of the tolerance for verification failures of a certain strategy version in the business process, such as the maximum allowed number of failures, the error submission threshold, or the number of times to wait for retry. The system updates the fault tolerance threshold according to the current trigger level. The updated value can be set statically, adopt a year-on-year growth strategy, or be adjusted according to the event response level (for example, when the warning level is level one, the fault tolerance threshold is adjusted to 150% of the default value). The update action should retain the historical threshold records to support retrospective analysis.

[0103] After completing the two subtasks, the system merges the page element weight adjustment parameters generated with the fault tolerance threshold set to construct a set of policy optimization configuration data for two-way linkage between the front end and the back end. This configuration data is represented in a structured form, including control identifiers, priority coefficients, policy version identifiers, and maximum fault tolerance trigger times fields, which can be used as the data basis for cross-module calls to drive dynamic style adjustment of the front end and update the tolerance of the back-end policy engine.

[0104] In specific implementation, a data-aware service based on event-driven can be constructed to receive hierarchical warning instructions, and the preset business policy verification failure type data fields carried therein, including two core fields of control identifier and policy version identifier, can be parsed through the JSON format. The control identifier is predefined by the DOM attributes of the front-end control during the data point embedding, and the policy version identifier is written into the operation track data by the policy service each time a verification failure event occurs to ensure consistency.

[0105] The interruption frequency of the control identifier can be obtained by regularly scanning the data point data log, Kafka stream log, or historical behavior table in the database. Frequency statistics support aggregation analysis using a sliding window, such as calculating the cumulative number within the sliding window in units of hours, days, or weeks. In actual deployment, the calculation of the priority coefficient can use the method based on min-max normalization to map the frequency to a fixed interval, such as [1.0, 3.0], or it can be calculated based on Z-score to ensure that controls with three standard deviations above the average have significant visual weights.

[0106] The fault tolerance trigger times associated with the policy version identifier are generally stored in the sub-version table of the policy configuration center, and each version contains a set of rules and corresponding threshold items. The system can request this fault tolerance value through MySQL, Redis, or the policy service API interface. The update methods for the maximum fault tolerance trigger times support strategies such as static replacement, interval adjustment, and dynamic setting through historical comparison to ensure matching with the warning level. For example, when reaching the first-level warning level, the maximum fault tolerance value can be increased from 50 to 75; for the second-level warning, it can be moderately increased to 60. All updated thresholds need to be synchronized to the policy engine configuration center and trigger the cache refresh mechanism of the policy service.

[0107] The optimized policy configuration data is finally written into the policy release queue or the configuration distribution middleware for subscription and use by the front-end page rendering system and the back-end verification engine. The front end injects the priority coefficient into the CSS style according to the control identifier, and realizes visual enhancement by adjusting the control border thickness, color saturation, or flashing animation; the back end adjusts the policy verification logic accordingly to improve the system's fault tolerance elasticity.

[0108] By parsing the page control identifier and policy version identifier in the hierarchical warning instruction, the system can achieve two-way linkage adjustment of the page guidance focus and policy tolerance threshold. On the one hand, it improves the pertinence and intervention ability of page interaction, reducing the psychological burden of users repeatedly failing on key controls; on the other hand, it enhances the adaptability of the backend policy to high-frequency verification failure scenarios, avoiding false killing or experience degradation caused by overly tight fault tolerance policy settings. In this way, the system realizes dynamic policy optimization and user behavior guidance without interrupting the business process, overall improving the conversion efficiency and user satisfaction.

[0109] The present invention relates to the technical field of data analysis and can be applied to business scenarios such as fintech and healthcare. It discloses a method for visual warning and policy response of business processes, including: setting a physical interruption node to collect interruption operation trajectory data, and classifying the data into multi-level logical interruption type structured data based on the business process sequence; mapping the structured data into a visual topology graph, screening entries with the logical interruption type being the preset business policy verification failure type, and statistically generating interruption frequency data for the interruption timestamp field; when the frequency exceeds the baseline upper limit, triggering a hierarchical warning instruction containing the preset business policy version identifier, and generating page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding policy version according to this instruction. The present invention realizes real-time identification and hierarchical warning of business policy verification failures by constructing a visual topology graph and identifying high-frequency interruption behaviors, further driving the adaptive adjustment of page elements and policy thresholds, thereby effectively improving the user insurance purchase conversion rate and reducing the risk of front-end operation loss.

[0110] In one embodiment, the above step S30 includes:

[0111] S301, parsing the last operation node identifier and the interruption timestamp field in the operation trajectory data;

[0112] S302, matching the verification failure code corresponding to the last operation node identifier in the preset business policy library;

[0113] S303, associating the currently effective business policy version identifier with the verification failure code;

[0114] S304, generating a first-level logical interruption type and a second-level logical interruption subclass according to the business process sequence, where the first-level logical interruption type corresponds to the business process stage classification, and the second-level logical interruption subclass corresponds to the verification failure scenarios defined in the preset policy library;

[0115] S305, converting the interruption timestamp into a time series field in the preset time zone format;

[0116] S306. Combine the verification failure code, the currently effective business policy version identifier, the primary logic interruption type, the secondary logic interruption subclass, and the time series field to generate the structured data of the multi-level logic interruption type.

[0117] In this embodiment, the operation trace data in the business process usually includes the behavior information generated during the interaction between the user and the front-end interface. The core fields include the last page operation point before termination and the corresponding timestamp information. Parsing the "last operation node identifier" in the operation trace data is to extract the number of the last control or component where the current interruption operation occurs from the original data, such as the control ID of a button click event or a form submission action, for subsequent traceability. At the same time, parsing the "interruption timestamp field" means extracting the time point when the interruption behavior occurs, for subsequent time classification, heat map analysis, etc.

[0118] By comparing with the preset business policy library, the system can locate the business verification process corresponding to the control identifier. For example, if the policy verification fails after a certain control is triggered, the "verification failure code" corresponding to the control can be found in the policy library. This step needs to ensure that there is a bidirectional mapping relationship. Based on this mapping relationship, further associate the "currently effective business policy version identifier". The policy version identifier can be obtained by querying the entries with the status of "effective" in the policy library to avoid confusing historical versions and rules to be deprecated.

[0119] Based on the business process sequence information, map the policy failure behavior to two dimensions: "primary logic interruption type" and "secondary logic interruption subclass". Among them, the primary logic interruption type usually corresponds to the high-level business stages in the process, such as user authentication, health information verification, compliance confirmation, etc.; the secondary logic interruption subclass is refined into specific trigger scenarios, such as invalid ID number, BMI exceeding the limit, disease history conflict, etc. For the convenience of subsequent time series analysis and visual display, the system needs to uniformly format the timestamp field into a time series in the "preset time zone format", for example, uniformly converted to the YYYY-MM-DD HH:mm:ss form in the East Eighth Time Zone.

[0120] Finally, by combining the verification failure code, the policy version identifier, the logic interruption level information, and the time series field, convert the user behavior interruption event into a structured interruption entry. This structured entry has a unified field expression and classification identifier, and can be directly called by visual components, warning models, or rule engines.

[0121] In actual deployment, the system first receives the interruption behavior logs reported by the business front-end data collection system. The logs contain fields such as control numbers, page paths, and operation times in JSON format. The parsing module on the server side uses regular expressions or preset field extractors to extract the "last operation node identifier" and "interruption timestamp field". Thereafter, through the relational database maintained in the policy engine module, the system matches the verification failure code based on the control identifier and generates a version identifier in combination with the effective policy version marked by the current system. The mapping of the logical type hierarchy can be deduced through the process structure definition configured in the metadata warehouse. For example, the page path information can correspond to the first-level stage, and the suffix of the failure type identification code can be mapped to the second-level subcategory. The standardization of the time field depends on the unified time service module, which is converted to the standard time zone format by calling the service API. The generation method of the final output structured data can adopt multi-field splicing to form the following structure:

[0122] {"Verification failure code": "S101", "Policy version": "V3.2", "First-level logical interruption type": "Health check", "Second-level subcategory": "BMI exceeding limit", "Time series": "2025-03-30 15:45:22"}

[0123] This data will be pushed to the downstream Kafka message queue for real-time consumption by the topology graph drawing service and the anomaly analysis engine.

[0124] In this embodiment, by introducing a mechanism for layer-by-layer parsing and structured processing of operation trajectory data, the ability to accurately extract the root cause of interruptions, hierarchical classification, and policy traceability from the original behavior data is realized. It has higher logical restoration ability and stronger process context awareness ability, making the interruption behavior interpretable and controllable in subsequent analysis, and improving the system's recognition accuracy and optimization guidance ability for high-intent interruption users.

[0125] In one embodiment, the above step S40 includes:

[0126] S401, extracting the first-level logical interruption type field and the second-level logical interruption subclass field from the multi-level logical interruption type structured data;

[0127] S402, mapping the first-level logical interruption type to the main node of the topology graph and mapping the second-level logical interruption subclass to the subordinate sub-node of the main node according to the preset visualization coding strategy;

[0128] S403, extracting the time series field from the multi-level logical interruption type structured data and converting the time series field into a time series heat value;

[0129] S404, generating a node hue gradient according to the time series heat value

[0130] S405, generate a policy version label based on the service policy version identification field in the multi-level logic interruption type structured data, and bind the policy version label to the corresponding master node and slave child nodes;

[0131] S406, generate connection edges of the topology graph based on the hierarchical relationship between the master node and the slave child nodes, and apply the node hue gradient to the filling attributes of the corresponding nodes to form a visual topology graph.

[0132] In this embodiment, in the process of converting the structured multi-level logic interruption type data into a visual topology graph, it is first necessary to complete the preprocessing operation of the field structure. This structured data comes from the interruption event classification process, and its core fields include the first-level logic interruption type field, the second-level logic interruption sub-type field, the time series field, and the service policy version identification field. Before mapping, each field needs to pass data consistency verification and semantic matching. For example, it is necessary to ensure that there is a preset hierarchical relationship between the second-level sub-type field and the first-level type field to avoid abnormal mounting or unexpected hierarchical drift.

[0133] The first-level logic interruption type field is used as the basic identification basis for the master node and is usually displayed in the center or upper layout during graph composition to emphasize its aggregation. Inside the system, this field will be converted into a graph node type label to drive the topology graph generator to recognize it as the "main type". The second-level logic interruption sub-type field is then mounted below or around the main type node as the "sub-type" and is organized through a logical tree relationship or a polar coordinate layout. This organization method not only improves the information density but also reduces cross edges and redundant connections, improving the readability of the topology.

[0134] The processing of the time series field is not only for heat value calculation. Its conversion process involves time zone standardization, time precision clipping (such as unifying to minute granularity or hour granularity), and event occurrence density aggregation. The system can configure different time window policies, such as a short window for real-time heat perception and a long window for policy backtracking visual analysis. After conversion, each event node has a standardized timestamp, which participates in hue mapping as a dynamic input in the heat value function to ensure that the time evolution directly affects the color of the graph.

[0135] In the graph composition rule, the connection edge between the master node and the slave node not only expresses the structural hierarchy but also serves as an information transmission channel driven by data. Attributes such as the width, transparency, and animation flow direction of the connection edge can be bound to the trigger frequency, time intensity, or version label of the interruption event. For example, between nodes with extremely high interruption frequencies, animated flashing edges can be used to enhance the visual focus effect. At the same time, the color of the connection edge can also be set to be consistent with the source node color to reduce color fragmentation.

[0136] The binding policy of the policy version identification field supports a two-way mapping mechanism, that is, it can not only trace the source of the policy version from the node structure, but also activate the visible node group under a specific version in the version filtering panel. The version label is not limited to the text annotation form, but can also be embedded in graphic elements (such as upper right corner marks, icon overlays), and is linked with the event tracking system. After clicking, it jumps to the policy configuration background to form a cross-system interaction closed loop.

[0137] During the generation process of the entire visualization topology graph, a rule-based graphic template engine can be used. For example, bind a specific graphic (circle, rectangle, hexagon, etc.) to each first-level logic type to assist users in identifying different types of abnormal patterns. In addition, the generation of the topology graph should support capabilities such as dynamic redrawing, filtering, and zooming to ensure that key data can be efficiently obtained under different screen sizes and business personnel roles.

[0138] In addition, the system can support multi-level nesting of interruption types. For example, add a third-level logic subclass and display it in the form of an aggregation circle or a collapsible node in the graph. This mechanism is particularly important in complex process interruption scenarios (such as medical information filling), which can effectively reduce graph congestion and maintain interaction efficiency. The update mechanism of the graph can also be based on a timing task or a trigger mechanism to dynamically refresh the node status to reflect the real-time interruption situation.

[0139] In this embodiment, by converting the structured interruption type data into a visualization topology graph, it can not only intuitively present the hierarchical structure and specific distribution of interruption events, but also express the time dimension characteristics of interruptions through the node hue, and assist in realizing policy attribution and version tracing with the help of the policy version identification. By integrating the originally scattered and invisible business interruption information into an interactive map, it provides an efficient means of problem identification and decision support for product operation personnel and policy formulation teams.

[0140] In one embodiment, after the above step S40, it further includes:

[0141] S407, obtaining the time interval parameter and product classification code configured through the interaction interface;

[0142] S408, extracting a subset of logical interruption types from the visualization topology graph that can match the time interval parameter and can match the product classification code;

[0143] S409, performing a visualization hiding operation on the logical interruption types that do not match the time interval parameter or product classification code;

[0144] S410, based on historical business cycle data, determining the month-on-month change rate of each node within the subset of logical interruption types;

[0145] S411. Mark the logical interruption types with a year-on-year change rate exceeding the preset change rate threshold as high - concern logical interruption types, and mark the physical interruption nodes belonging to the high - concern logical interruption types with pulse special effects in the visual topology map;

[0146] S412. Generate an abnormal category optimization list based on the commodity classification code corresponding to the high - concern logical interruption type.

[0147] In this embodiment, after the topology map is generated, a targeted focus analysis can be further performed on the logical interruption types presented therein to improve the relevance between data readability and business optimization. First, it is necessary to obtain the time - interval parameter and the commodity classification code in the analysis dimension. Both of these parameters are provided by the interactive interface configuration module, and the user can input them through the time selector and the commodity category filtering component. The time - interval parameter usually includes the start and end timestamps or the natural - cycle range (such as quarters, months), and the commodity classification code is the identifier of the commodity category defined in the preset business system, such as health insurance, critical illness insurance, travel insurance, etc.

[0148] The system will filter the interruption nodes in the visual topology map based on the time - interval parameter. Each node contains a time - series field and a commodity - classification field internally. The former is used to match the time dimension, and the latter is used to match the business dimension. The nodes that meet the matching of both dimensions will be extracted to form a subset of logical interruption types, and this subset is the object of subsequent high - frequency focus and fluctuation analysis. For the nodes that do not meet any dimension - matching conditions, the system will trigger a graphic - hiding operation, that is, achieve visual elimination by reducing transparency, canceling edge connections, removing labels, etc., to avoid visual interference.

[0149] After extracting the subset of logical interruption types, the system will perform a year - on - year calculation on each node based on the historical business - cycle data. The interruption frequency of the node comes from the interruption - frequency data generated in the previous step. The system aggregates by the dual dimensions of commodity classification and node identifier to obtain the frequency values of the current period and the previous period. The previous period is defined as the previous unit time period in the same cycle as the current time interval. For example, if the current is 2024 - Q1, then the previous period is 2023 - Q4. The calculation formula for the year - on - year change rate can be:

[0150] Year - on - year change rate=(Current - period interruption frequency - Previous - period interruption frequency) / Previous - period interruption frequency×100%.

[0151] This calculation method is used to measure the trend fluctuation of each logical interruption type in the time dimension. When the year - on - year change rate of a certain node exceeds the change rate threshold set by the system (such as + 50%), it is regarded as a high - concern logical interruption type. The system will mark such nodes and give them visual enhancement effects, such as setting a continuously pulsating pulse halo, color flashing, edge diffusion and other dynamic special effects around the node to attract the attention of analysts.

[0152] After completing the visual marking, the system will also summarize and form an optimized list of abnormal categories according to the product classification codes corresponding to the marked nodes. This list is sorted and output according to dimensions such as the rising amplitude of the interruption frequency, the number of nodes, and the involved controls, and is used by the business department to identify the insurance categories that need to be optimized with key emphasis currently. This list can be directly used for tasks such as optimizing downstream product operation strategies, reconstructing user processes, and adjusting front-end interactions.

[0153] In the specific implementation process, analysts can select the time interval and product classification code through the parameter configuration component on the front-end interface. The selected time interval parameter supports natural language parsing (such as "this quarter", "last month"), and also supports the input of a time stamp range accurate to the day. The product classification code can be obtained by docking with the insurance product information system, constructing a drop-down selection list and supporting multiple selection operations.

[0154] After the back-end processing module receives the filtering conditions, it will perform a dual filtering operation on the generated visual topology graph data. The filtering logic first looks for nodes that match the product classification code in the first-level logic interruption type and second-level logic interruption sub-category fields, and then compares whether it is within the current time interval in the time series field within each node. If both match, the node and its associated structure are retained; otherwise, the node will be marked as inactive, and the front-end will set its transparency to 0.2 during rendering and cancel its connection edge with the main node.

[0155] To calculate the month-on-month change rate, the system will query the interruption frequency data of the previous time window corresponding to the same node identifier and product classification code stored in the historical database. If the current time interval is the first quarter of 2024, the system will automatically extract the first quarter of 2023 or the previous quarter (depending on the business definition) as the reference period. After the difference between the current frequency data and the historical frequency is normalized, the change rate of each node is obtained. The system can set a global default threshold (such as 50%) or set it separately for different product classifications.

[0156] Once a node is identified as a high-concern type, the system will attach an animation style of "jumping" to its topological graph representation. For example, it uses WebGL or Canvas rendering methods to achieve a periodic radiation effect on the edge color of the node, and adds a "high-concern type" identifier in the legend for easy understanding.

[0157] Finally, the optimized list of abnormal categories will be generated in a structured JSON format at the back-end, including fields such as product classification code, number of trigger nodes, average change rate, and main control identifier. The list is pushed to the operation system or decision support platform through the message queue for subsequent automated policy adjustment or manual intervention review.

[0158] In this embodiment, by introducing a dual-dimension screening mechanism of time interval parameters and commodity classification codes, the display results of logic interruption types are made more business-targeted and time-sensitive, avoiding information redundancy and interference caused by full-volume visualization. Further, the month-on-month change rate is calculated based on historical business cycle data, and the interruption nodes with prominent change trends are dynamically marked in a visual form, enabling effective discovery of potential abnormal links in the business process. The automatic generation mechanism of the abnormal category optimization list constructs a technical closed-loop from interruption identification to operation intervention, significantly improving the efficiency of product optimization and strategy response.

[0159] In one embodiment, the above step S60 includes:

[0160] S601, based on the interruption timestamp field in the selected entries, classify each entry into a corresponding preset time window, where the preset time window is a predefined statistical cycle interval;

[0161] S602, based on the preset business policy verification failure type, group and aggregate the entries classified into the same preset time window to generate a set of policy verification failure type entries arranged in the order of time windows;

[0162] S603, count the number of interruption event triggers in the set of policy verification failure type entries for each preset time window, where the trigger count is the cumulative number of all entries in the corresponding time window, and each entry corresponds to one interruption event of preset business policy verification failure;

[0163] S604, combine the preset time window, the interruption event trigger count, and the preset business policy verification failure type to generate the interruption frequency data.

[0164] In this embodiment, when processing the entries of the preset business policy verification failure type selected from the structured data, in order to analyze the concentration, time distribution, and policy problem density of the interruption events, it is necessary to construct a time aggregation model of the interruption events based on the timestamp field. This model first requires standardizing the interruption timestamp field in each piece of data, that is, converting it into a time format under a unified time zone, such as the ISO 8601 time standard, to ensure that subsequent clustering operations do not cause distribution deviations due to time zone differences in data sources.

[0165] The time window is the core analysis unit of this model. It is not just a simple time period division but also needs to support flexible definition driven by business. For example, the peak period of insurance application may be concentrated from 19:00 to 23:00 on weekdays in the evening. Therefore, non-uniform time windows can be constructed, such as "weekday evening window" and "window around holidays". These time windows can be based not only on fixed time lengths but also dynamically generated by business rules, with higher interpretability and pertinence in statistical logic.

[0166] After each interruption entry is classified into its corresponding time window, it needs to be logically clustered in combination with the policy verification failure type. The clustering is not only based on the policy identification field, but can also be further extended to multi-level fields such as policy category, applicable products, and policy effective time period to construct a multi-dimensional cross-statistical model. For example, the same policy identification may trigger completely different interruption frequencies in different products. Therefore, the aggregation logic should support grouping by multiple keys combined and provide the ability to adjust weights at the field level.

[0167] The frequency statistics itself should not be just a process of summarizing single counts. To ensure the ability to identify continuously triggered events, a rolling time window mechanism can be introduced. That is, for each policy failure event, while accumulating it in its corresponding time window, its impact is propagated forward and backward within a certain time range. For example, when multiple users continuously interrupt at the same policy point within 5 minutes in a day, the statistical system should identify it as "local high-frequency anomaly" instead of just counting it as independent events.

[0168] The finally generated interruption frequency data should not only include basic fields: time window, policy type, and number of interruption events, but can also be extended to generate analysis index fields such as trend vectors, anomaly indices, or volatility coefficients. These fields will serve as the input for subsequent hierarchical warning mechanisms and policy optimization calculation models, providing a data basis for refined control.

[0169] The key to this statistical process lies not in the static summarization of data, but in the cross-mapping and aggregation integration between the time dimension and policy logic. The system should support a high-frequency refresh mechanism and the ability to schedule asynchronous statistical tasks, enabling the frequency data to have real-time feedback capabilities in key scenarios such as policy changes, promotional activities, and holidays.

[0170] Example illustration: In the self-operated H5 insurance application process provided by an insurance platform for the medical and health scenario, users need to complete interactive inputs for multiple control fields such as filling in basic information, selecting health questions and answers, confirming occupation classification, and setting payment methods in sequence. The system performs real-time verification on each input content through preset policies, and only when all verifications pass can the user enter the formal insurance application link. Recently, the platform monitoring team observed during the peak hours at night that a large number of users significantly extended their stay time in the health information filling stage and the insurance application completion rate decreased significantly. They suspected that there was an abnormal situation in the frequency of policy verification triggers.

[0171] To this end, the system processes all interaction records that have not successfully completed the insurance application process in the past 7 days, extracts structured entries whose logic interruption type is "preset business policy verification failure type", and focuses on failure records with a policy version identifier of HEALTH-GUOCHENG-3.2. This policy is mainly used to restrict the integrity and compliance of users' answers in the health Q&A session. Once there are behaviors such as missing required fields, answers not conforming to the rules, or missing additional materials, it is determined that the policy verification has failed.

[0172] First, the system extracts the interruption timestamp fields in these entries and uniformly converts all time information into the Beijing time (time zone of East 8) format for subsequent construction of the time window. Taking a record at 21:30 on May 12, 2024 as an example, the system classifies it into the statistical window of "2024-05-12 21:00–22:00" and aggregates all records that belong to the same window and are attributed to the HEALTH-GUOCHENG-3.2 policy version.

[0173] The system counts the number of times this policy is triggered in each window according to the predefined time window granularity (in hours). During the above time period, this policy was triggered 58 times in total, while it was only triggered 23 times in the same period of the previous day, showing an obvious fluctuating trend. The system automatically writes this aggregation result into the structured output, including the preset time window field (such as "2024-05-12 21:00–22:00"), the policy version identifier field (HEALTH-GUOCHENG-3.2), and the interruption event trigger count field (58), constituting the interruption frequency data for the current cycle.

[0174] The above analysis process ensures the accuracy and comparability of the trigger count calculation process through automated classification and per-window statistics, provides a quantitative basis for subsequent trigger warning rules, and at the same time supports the data infrastructure construction for optimizing the front-end interaction logic and adjusting the policy fault tolerance configuration. The system avoids the previous lag mechanism that relied on manual judgment and offline data extraction, and realizes the proactive discovery and high-frequency response to policy-level interruption risks.

[0175] In this embodiment, by mapping the interruption timestamp to the preset time window and combining the policy type for frequency statistics, it is possible to obtain a data analysis basis with a structured time dimension without interrupting the business process. It can help the platform timely discover the trend of a sharp increase in interruptions of a certain policy type in a short period of time, and at the same time facilitate horizontal comparison of the stability between different time periods or different policy types. By constructing such a frequency data structure in advance, it provides an efficient and unified underlying support for subsequent trend identification, warning trigger, and policy optimization operations.

[0176] In one embodiment, the above step S70 includes:

[0177] S701, based on the trigger count field and the historical time window field in the historical interruption frequency data, determine the upper limit of the baseline count for each preset time window;

[0178] S702, configuring a graded warning strategy to define warning levels corresponding to different excess ranges of the trigger times exceeding the upper limit of the baseline times;

[0179] S703, when the number of interrupt event triggering in the interrupt frequency data exceeds the upper limit of the baseline number in the current preset time window, matching the graded warning strategy according to the excess range, and generating a graded warning instruction corresponding to the warning level;

[0180] S704: Send a graded warning instruction to the configured warning notification receiving terminal through a preset notification channel.

[0181] In this embodiment, in order to respond promptly to abnormal fluctuations in the frequency of policy verification interruptions, it is necessary to automatically generate a hierarchical warning instruction containing a business policy version identifier based on the degree of deviation between the interruption frequency data and the historical level. In this processing process, first, it is determined whether the number of interruptions in each statistical period reaches the threshold for triggering an early warning, using the time window as a unit. To this end, it is necessary to establish a historical statistical baseline with time comparability. The historical same period time window field provides a reference for the time dimension of this type of baseline. This field represents a historical time period that is the same as the current preset time window period classification. For example, when "the working day lunch period of the second week of Q3 2024" is used as the current window, its historical same period may include "the working day lunch period of the second week of Q3 2023". By traversing the time periods belonging to the historical same period classification in the historical interruption frequency data, the corresponding trigger number field is extracted to form a sample set that can be used for statistics.

[0182] After acquiring sample data, the system calculates the baseline upper limit for the preset time window using various methods, including mean, standard deviation, range, and quantiles. The most common method is to set a dynamic upper limit by weighting the mean and standard deviation. For example, baseline = μ + 2σ, where μ is the historical average number of outages over the same period and σ is the standard deviation. This approach can adapt to baseline shifts caused by changes in business volume and effectively control the risk of false alarms.

[0183] Tiered alert policies are used to set different alert response levels based on the extent of violations. These policies can be configured based on a combination of policy type, business priority, and risk level. For example, if a policy exceeds the baseline limit by more than 20%, a Level 1 alert is issued; if it exceeds 50%, the alert is raised to Level 2. These policies can be dynamically adjusted through the rule configuration service and support automatic binding to risk grading standards based on the policy version identifier.

[0184] After completing the warning level matching, the system generates a hierarchical warning instruction, which includes the current preset time window, the calculated overrun amplitude, and the business policy version identification field recorded in the interruption frequency data. This identification ensures the accurate binding of the instruction content to the specific policy configuration, facilitating subsequent personalized responses for policy fault tolerance parameters, control significance weights, or notification frequencies.

[0185] Finally, the system pushes the hierarchical warning instruction to the warning notification receiver through the configured notification channel, which can be an email service, a text message service, an internal message system, an exception handling console, etc. The pushing process can configure the notification priority, notification interval time, and repeated sending rules to meet the different requirements for warning response efficiency in different industry fields.

[0186] In this embodiment, by dynamically comparing the interruption frequency data with the upper limit of the baseline number statistically obtained based on the same historical period and introducing a hierarchical warning mechanism driven by the overrun amplitude, it is possible to achieve automatic perception and response to abnormal fluctuations in policy verification. It not only gets rid of the dependence on fixed thresholds or manual subjective judgments, significantly improves the monitoring sensitivity to the risk of business process interruption, but also can adaptively configure the warning level and notification method according to the business importance and risk level of different policies, enhancing the controllability and accuracy of the warning system.

[0187] In one embodiment, after the above step S80, the following steps are further included:

[0188] S901, parsing the control identifier and priority coefficient in the page element weight adjustment parameter;

[0189] S902, matching the control identifier with the document object model node in the interface rendering service component;

[0190] S903, adjusting the page element weight value of the matched document object model node according to the priority coefficient;

[0191] S904, injecting the adjusted page element weight value into the browser rendering pipeline to enhance the visual significance of the control corresponding to the preset business policy verification failure type;

[0192] S905, parsing the policy version identifier and the maximum fault tolerance trigger times in the fault tolerance threshold set;

[0193] S906, performing version matching on the policy version identifier and the effective policy entry in the policy verification service database;

[0194] S907, updating the maximum fault tolerance trigger times field in the matched effective policy entry according to the maximum fault tolerance trigger times;

[0195] S908: Synchronize the updated effective policy entry to the business process execution service component to adjust the triggering condition of the preset business policy verification failure type.

[0196] In this embodiment, after the system completes the generation of the page element weight adjustment parameters and the corresponding fault tolerance threshold set of the preset business policy version, the processing logic will be divided into two directions: one is to apply the page-level parameters to the front-end visual presentation, and the other is to feed back the policy-level parameters to the policy verification service system, thereby realizing two-way dynamic adjustment of user interaction experience and policy tolerance.

[0197] First, the system parses the control identifier and priority coefficient within the page element weight adjustment parameters. The control identifier uniquely identifies the interactive control that failed policy validation, while the priority coefficient is a dynamic indicator calculated based on the interruption frequency corresponding to the control, reflecting its attention weight within the current business process. In practice, the control identifier can be expressed using the DOM node ID, CSS selector, or unique path of the H5 page component, while the priority coefficient can be output as a floating-point value using a standardized weight model to maintain consistency across different devices and resolutions.

[0198] The system then matches the control identifier with the Document Object Model node in the UI rendering service component. In modern browsers, this is typically done through JavaScript runtime access to the page's DOM structure, matching the target node using selectors or path rules. This matching process not only requires field consistency but also considers scenarios like deferred rendering of dynamically generated components, nested structures, and component reuse. Therefore, the system can incorporate node tree traversal, deferred binding, or MutationObserver monitoring mechanisms to enhance matching robustness.

[0199] Once a match is made, the system adjusts the weight of the page element that matched the node based on the priority coefficient. This weight controls the visual prominence of the node in the page display, such as font size, border highlighting, background color enhancement, animation frequency, etc. The weight adjustment can be used with CSS variables, style attributes, or the responsive binding mechanism of the front-end framework to enhance the interactive guidance effect without affecting the user's operation logic. For example, controls with higher priority coefficients will be given a higher visual hierarchy, making them easier for users to perceive and operate.

[0200] After completing the visual enhancement parameter settings, the system injects the adjusted page element weights into the browser rendering pipeline. This operation relies on the staged rendering mechanism of DOM→Style→Layout→Paint→Composite in the modern web rendering architecture. The parameter injection point is located in the Style or Layout stage. The rendering task is pushed through the front-end main thread or Web Worker to ensure that the control is redrawn according to the adjusted weights within the next frame refresh cycle, thus achieving rapid effect without affecting the performance of the main business process.

[0201] At the same time, the system parses the policy version identifier and maximum fault tolerance trigger count in the fault tolerance threshold set and performs a version match with the effective policy entries in the policy validation service database. The policy version identifier is typically marked with the policy type + version number (e.g., HEALTH-GUOCHENG-3.2) and is used to accurately locate the currently executing policy logic. The matching process must ensure consistent version granularity to avoid historical errors caused by policy adjustments.

[0202] Once a corresponding policy entry is found, the system updates the maximum fault tolerance trigger count field in the entry based on the maximum fault tolerance trigger count, thereby dynamically adjusting the tolerance of the policy validation logic. For example, after a recent large-scale outage, the mandatory field restrictions, retry counts, or tolerance limits for some fields can be temporarily relaxed to enhance the system's adaptability to complex user input behaviors.

[0203] Finally, the updated policy entries are synchronized to the business process execution service component. This synchronization can be achieved through mechanisms such as database write monitoring, cache update push, or configuration center distribution. This ensures that the business system immediately adopts the updated parameters during the next policy verification, forming a rapid closed loop of early warning drive → parameter adjustment → business response.

[0204] Example: In an insurance company's proprietary H5 application process for medical and health insurance, users must complete multiple front-end forms and verify business rules before a formal insurance order can be generated. Recently, the operations team, through data analysis, discovered a significant increase in bounce rates on the health disclosure page, particularly during peak nighttime hours. Conversion rates also fluctuated significantly, suggesting potential policy blocking or an abnormal page experience. To address this, the system implemented a comprehensive process based on visual early warning of business process interruptions.

[0205] First, physical interrupt nodes are deployed at every key page in the insurance application process, including front-end components such as health information disclosure, career selection, policyholder information entry, and payment method selection. These physical interrupt nodes use embedded monitoring scripts to collect user behavior trajectory data during page operations, recording raw behavior logs including user input fields, button clicks, bounce actions, dwell time, device environment, and network status.

[0206] When the user interrupts an operation or repeatedly fails to submit on a certain page, the system parses and classifies this operation track data according to the sequential logic preset in the business process, generating multi-level logical interruption type data with a structured expression. For example, if errors such as "fields not filled in completely" or "selecting a health condition that does not meet the standard" repeatedly appear on the health declaration page, this behavior is classified as the "preset business policy verification failure type"; if the user actively closes the page before seeing the "Next" button, it is classified as the "user actively terminates type". Each record is assigned a first-level logical interruption type (such as the "health declaration stage") and a second-level logical interruption sub-type (such as "missing declaration fields"), and the interruption timestamp is recorded.

[0207] The system maps the above structured data into a visual topology diagram, with the health declaration stage as the main node and different second-level interruption types as its subordinate child nodes. The color of the node is determined by the time heat value of the interruption event, with recently occurred events shown in red and historical events shown in blue. For example, if "health questions not fully selected" appears frequently as a child node within the last hour, the corresponding node is shown in dark red. Each node is also bound to the policy version number (such as "HEALTH-GUOCHENG-3.2") and the failed control ID (such as "health_input_001") referenced by this event.

[0208] The system further filters out the entries with the logical interruption type of "preset business policy verification failure type" and extracts the interruption timestamp field among them. Classification is carried out according to the set hourly statistical window (such as divided every 1 hour), and the number of interruption events triggered by each policy type within each time window is counted. For example, within the time period of "2024-05-12 21:00–22:00", the "HEALTH-GUOCHENG-3.2" policy has been interrupted 58 times in total, showing a significant increase compared to 23 times in the same time period of the previous day.

[0209] The system calculates the upper limit of the baseline number for the current time window based on the historical frequency data of the same time period in the past three days (such as 42 times after adding three times the standard deviation to the historical mean). Since the current trigger count of 58 exceeds the upper limit of the baseline, the system triggers a hierarchical warning mechanism. According to the configured hierarchical strategy, if it exceeds 25% of the upper limit, a first-level warning is triggered, and the system immediately generates a first-level warning instruction containing the current time window, the overrun amplitude, and the policy version identifier.

[0210] The warning instruction is pushed to the preset notification channels, including the email end and the system message end, and is received and processed by the operation system and the policy reviewer. Meanwhile, the system parses the policy failure data bound to the warning instruction, obtains the control identifier (such as health_input_001) and the policy version (HEALTH-GUOCHENG-3.2) therefrom, and generates a priority coefficient (such as 1.6) based on the interruption frequency of the control in the past three days, and generates a page element weight adjustment parameter.

[0211] After receiving this parameter, the page front-end engine adjusts the visual salience of the control in real time, such as bolding the font, highlighting with a red frame, increasing the frequency of guiding prompts, etc., so that users can more easily identify and complete the required items when re-visiting the page. Meanwhile, the back-end policy service queries the HEALTH-GUOCHENG-3.2 entries marked as effective in the policy database and temporarily adjusts the maximum fault tolerance trigger times field to a higher threshold (such as increasing from 50 to 80), reducing the possibility of false interception caused by short-term behavior fluctuations.

[0212] After the policy adjustment is synchronized to the business execution service, the new fault tolerance configuration is automatically enabled in subsequent user accesses, allowing users to have more room for interaction attempts during the operation process and avoiding a further increase in the interruption frequency.

[0213] Through the above process, the system not only captures the risk of policy interruption fluctuations in the first time, but also automatically completes the front-end interaction optimization and the back-end policy flexible adjustment, maximizing the guarantee of business continuity and user conversion rate, and at the same time building an insurance application process monitoring and response system with real-time warning ability and closed-loop adaptive ability.

[0214] In this embodiment, by finely parsing the data fields associated with the warning instruction, the risk of abnormal user behavior is transformed into executable visual guidance and policy tolerance control actions, thereby realizing the linkage optimization between the page end and the policy end. The injection of the page element weight adjustment parameter enhances the salience of high-risk controls and increases the probability of users completing key operations; at the same time, the dynamic adjustment of the policy fault tolerance threshold improves the fault tolerance ability of the system and reduces the loss risk caused by misjudgment without sacrificing compliance. Finally, the system can actively adjust the interface interaction and policy rules based on real behavior data, realizing fast response, continuous optimization and risk control closed-loop in the case of business interruption, and greatly improving the user insurance application conversion rate and the overall experience consistency.

[0215] In one embodiment, a business process visualization warning and policy response device is provided, and the business process visualization warning and policy response device corresponds one-to-one to the business process visualization warning and policy response method in the above embodiment. Refer to Figure 3 , Figure 3This is a schematic diagram of the functional modules of a preferred embodiment of the business process visualization warning and strategy response device of the present invention. An interruption node configuration module 10, an operation trajectory collection module 20, a logical interruption classification module 30, a topology map construction module 40, an interruption screening module 50, an interruption frequency statistics module 60, a warning trigger module 70, and a policy optimization parameter generation module 80. The detailed description of each functional module is as follows:

[0216] The interruption node configuration module 10 is used to set a plurality of physical interruption nodes on the front-end interface of the business process;

[0217] The operation trajectory collection module 20 is used to collect operation trajectory data of the interrupted business process through the physical interruption nodes;

[0218] The logical interruption classification module 30 is used to classify the operation trajectory data into multi-level logical interruption type structured data according to the business process sequence;

[0219] The topology map construction module 40 is used to map the multi-level logical interruption type structured data into a visual topology map;

[0220] The interruption screening module 50 is used to screen entries whose logical interruption type is a preset business policy verification failure type from the multi-level logical interruption type structured data;

[0221] The interruption frequency statistics module 60 is used to count the number of triggers of the preset business policy verification failure type according to the interruption timestamp field in the screened entries, and generate interruption frequency data according to the interruption timestamp field, the number of triggers, and the preset business policy verification failure type;

[0222] The warning trigger module 70 is used to trigger a hierarchical warning instruction including a preset business policy version identifier when the interruption frequency data exceeds the baseline number upper limit;

[0223] The policy optimization parameter generation module 80 is used to generate page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding preset business policy version according to the preset business policy verification failure type data associated with the hierarchical warning instruction.

[0224] In one embodiment, the logical interruption classification module 30 is specifically used for:

[0225] Parse the last operation node identifier and the interruption timestamp field in the operation trajectory data;

[0226] Match the verification failure code corresponding to the last operation node identifier in the preset business policy library;

[0227] Associate the currently effective business policy version identifier with the verification failure code;

[0228] Generate a first-level logical interruption type and a second-level logical interruption subclass according to the business process sequence. The first-level logical interruption type corresponds to the business process stage classification, and the second-level logical interruption subclass corresponds to the verification failure scenarios defined in the preset policy library;

[0229] Convert the interruption timestamp into a time series field in the preset time zone format;

[0230] Combine the verification failure code, the currently effective business policy version identifier, the first-level logical interruption type, the second-level logical interruption subclass, and the time series field to generate the structured data of the multi-level logical interruption type.

[0231] In one embodiment, the topology graph construction module 40 is specifically configured to:

[0232] Extract the first-level logical interruption type field and the second-level logical interruption subclass field from the structured data of the multi-level logical interruption type;

[0233] According to the preset visualization coding strategy, map the first-level logical interruption type to the main nodes of the topology graph, and map the second-level logical interruption subclass to the subordinate child nodes of the main nodes;

[0234] Extract the time series field from the structured data of the multi-level logical interruption type, and convert the time series field into a time series heat value;

[0235] Generate a node hue gradient according to the time series heat value;

[0236] Generate a policy version label based on the business policy version identifier field in the structured data of the multi-level logical interruption type, and bind the policy version label to the corresponding main nodes and subordinate child nodes;

[0237] Generate the connection edges of the topology graph based on the hierarchical relationship between the main nodes and the subordinate child nodes, and apply the node hue gradient to the filling attributes of the corresponding nodes to form a visualized topology graph.

[0238] In one embodiment, the topology graph construction module 40 is specifically configured to:

[0239] Obtain the time interval parameter and the commodity classification code configured through the interaction interface;

[0240] Extract a subset of logical interruption types from the visualized topology graph that can match the time interval parameter and can match the commodity classification code;

[0241] Perform a visualization hiding operation on the logical interruption types that do not match the time interval parameter or the commodity classification code;

[0242] Based on historical business cycle data, determine the month-on-month change rate of each node within the subset of logic interruption types;

[0243] Mark the logic interruption types with a month-on-month change rate exceeding the preset change rate threshold as high-concern logic interruption types, and annotate the physical interruption nodes belonging to the high-concern logic interruption types with pulse special effects in the visualization topology map;

[0244] Generate an abnormal category optimization list based on the commodity classification code corresponding to the high-concern logic interruption type.

[0245] In one embodiment, the interruption frequency statistics module 60 is specifically configured to:

[0246] Based on the interruption timestamp field in the selected entries, classify each entry into the corresponding preset time window, where the preset time window is a predefined statistical period interval;

[0247] Based on the preset business policy verification failure type, group and aggregate the entries classified into the same preset time window to generate a set of policy verification failure type entries arranged in the order of time windows;

[0248] Count the number of trigger times of interruption events in the set of policy verification failure type entries for each preset time window, where the trigger times are the cumulative quantity of all entries within the corresponding time window, and each entry corresponds to an interruption event of a preset business policy verification failure;

[0249] Combine the preset time window, the number of trigger times of interruption events, and the preset business policy verification failure type to generate the interruption frequency data.

[0250] In one embodiment, the early warning trigger module 70 is specifically configured to:

[0251] Based on the trigger times field and the historical same-period time window field in the historical interruption frequency data, determine the upper limit of the baseline times for each preset time window;

[0252] Configure a hierarchical early warning policy to define the early warning levels corresponding to different overrun amplitudes where the trigger times exceed the upper limit of the baseline times;

[0253] When the number of trigger times of interruption events in the interruption frequency data exceeds the upper limit of the baseline times for the current preset time window, match the hierarchical early warning policy according to the overrun amplitude to generate a hierarchical early warning instruction corresponding to the early warning level;

[0254] Send the hierarchical early warning instruction to the configured early warning notification receiver through a preset notification channel.

[0255] In one embodiment, the policy optimization parameter generation module 80 is specifically configured to:

[0256] Parse the control identifier and priority coefficient in the page element weight adjustment parameter;

[0257] Match the control identifier with the document object model node in the interface rendering service component;

[0258] Adjust the page element weight value of the matched document object model node according to the priority coefficient;

[0259] Inject the adjusted page element weight value into the browser rendering pipeline to enhance the visual salience of the control corresponding to the preset business policy verification failure type;

[0260] Parse the policy version identifier and maximum fault tolerance trigger count in the fault tolerance threshold set;

[0261] Match the policy version identifier with the effective policy entry in the policy verification service database;

[0262] Update the maximum fault tolerance trigger count field in the matched effective policy entry according to the maximum fault tolerance trigger count;

[0263] Synchronize the updated effective policy entry to the business process execution service component to adjust the trigger condition of the preset business policy verification failure type.

[0264] In one embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as shown in Figure 4 shown. The computer device includes a processor, a memory, a network interface, and a database connected by a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client through a network connection. When the computer program is executed by the processor, it realizes the functions or steps of the server side of a business process visualization warning and policy response method.

[0265] In one embodiment, a computer device is provided. The computer device can be a client, and its internal structure diagram can be as shown in Figure 5As shown in the figure. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the user side of a business process visualization warning and policy response method

[0266] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are realized:

[0267] Set multiple physical interruption nodes on the front-end interface of the business process;

[0268] Collect operation track data of the interrupted business process through the physical interruption nodes;

[0269] Classify the operation track data into multi-level logical interruption type structured data according to the business process sequence;

[0270] Map the multi-level logical interruption type structured data into a visualization topology graph;

[0271] Screen entries with the logical interruption type being the preset business policy verification failure type from the multi-level logical interruption type structured data;

[0272] According to the interruption timestamp field in the screened entries, count the triggering times of the preset business policy verification failure type, and generate interruption frequency data based on the interruption timestamp field, triggering times, and preset business policy verification failure type;

[0273] When the interruption frequency data exceeds the baseline number upper limit, trigger a hierarchical warning instruction including a preset business policy version identifier;

[0274] Generate page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding preset business policy version according to the preset business policy verification failure type data associated with the hierarchical warning instruction.

[0275] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by the processor, the following steps are realized:

[0276] Set multiple physical interruption nodes on the front-end interface of the business process;

[0277] Collect the operation track data of the interruption service process through the physical interruption node;

[0278] Classify the operation track data into multi-level logical interruption type structured data according to the service process sequence;

[0279] Map the multi-level logical interruption type structured data into a visual topology diagram;

[0280] Screen out the entries whose logical interruption type is the preset service policy verification failure type from the multi-level logical interruption type structured data;

[0281] According to the interruption timestamp field in the screened-out entries, count the trigger times of the preset service policy verification failure type, and generate interruption frequency data based on the interruption timestamp field, trigger times and preset service policy verification failure type;

[0282] When the interruption frequency data exceeds the baseline number upper limit, trigger a hierarchical warning instruction containing the preset service policy version identifier;

[0283] Generate page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding preset service policy version according to the preset service policy verification failure type data associated with the hierarchical warning instruction.

[0284] It should be noted that the functions or steps that can be realized by the above computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0285] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided in the present application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

[0286] Those skilled in the art can clearly understand that for the convenience and brevity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules as needed, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above.

[0287] It should be noted that if non-company software tools or components appear in the embodiments of the present application, they are only used for illustrative introduction and do not represent actual use. The above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features. These modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A business process visualization warning and strategy response method, characterized in that It includes the following steps: Set multiple physical interruption nodes on the front-end interface of the business process; Collect the operation track data of the interrupted business process through the physical interruption nodes; Classify the operation track data into multi-level logical interruption type structured data according to the business process sequence; Map the multi-level logical interruption type structured data into a visual topology diagram; Filter out the entries whose logical interruption type is the preset business policy verification failure type from the multi-level logical interruption type structured data; According to the interruption timestamp field in the filtered entries, count the trigger times of the preset business policy verification failure type, and generate interruption frequency data based on the interruption timestamp field, trigger times and preset business policy verification failure type; When the interruption frequency data exceeds the baseline number upper limit, trigger a hierarchical warning instruction including the preset business policy version identifier; Generate page element weight adjustment parameters and a set of fault tolerance thresholds for the corresponding preset business policy version according to the preset business policy verification failure type data associated with the hierarchical warning instruction.

2. The business process visualization warning and strategy response method according to claim 1, wherein, Classify the operation track data into multi-level logical interruption type structured data according to the business process sequence, including: Analyze the last operation node identifier and interruption timestamp field in the operation track data; Match the verification failure code corresponding to the last operation node identifier in the preset business policy library; Associate the currently effective business policy version identifier with the verification failure code; Generate a first-level logical interruption type and a second-level logical interruption subclass according to the business process sequence, where the first-level logical interruption type corresponds to the business process stage classification, and the second-level logical interruption subclass corresponds to the verification failure scenarios defined in the preset policy library; Convert the interruption timestamp into a time series field in the preset time zone format; Combine the verification failure code, the currently effective business policy version identifier, the first-level logical interruption type, the second-level logical interruption subclass and the time series field to generate the multi-level logical interruption type structured data.

3. The business process visualization warning and strategy response method according to claim 1, characterized in that Map the multi-level logical interruption type structured data into a visual topology diagram, including: Extract the first-level logical interruption type field and the second-level logical interruption subclass field from the multi-level logical interruption type structured data; According to the preset visual encoding strategy, map the first-level logical interruption type to the main node of the topology diagram, and map the second-level logical interruption subclass to the subordinate sub-nodes of the main node; Extract the time series field from the multi-level logical interruption type structured data, and convert the time series field into a time series heat value; Generate a node hue gradient according to the time series heat value; Generate a policy version label based on the business policy version identifier field in the multi-level logical interruption type structured data, and bind the policy version label to the corresponding main node and subordinate sub-nodes; Generate the connection edges of the topology diagram based on the hierarchical relationship between the main node and the subordinate sub-nodes, and apply the node hue gradient to the filling attribute of the corresponding node to form a visual topology diagram.

4. The business process visualization warning and strategy response method according to claim 1, characterized in that, After mapping the multi-level logical interruption type structured data into a visual topology diagram, it further includes: Get the time interval parameters and product category codes configured through the interactive interface; Extracting a subset of logical interruption types that match the time interval parameter and the commodity classification code from the visual topology map; Performing a visual hiding operation on the logical interrupt type that does not match the time interval parameter or the commodity classification code; Determining, based on historical service cycle data, a month-on-month change rate of each node in the logical interruption type subset; Marking the logical interruption type whose month-on-month change rate exceeds the preset change rate threshold as a high-concern logical interruption type, and marking the physical interruption nodes belonging to the high-concern logical interruption type with a pulse effect in the visual topology diagram; Based on the commodity classification codes corresponding to the high-attention logical interruption types, an optimized list of abnormal categories is generated.

5. The business process visualization warning and strategy response method according to claim 1, characterized in that According to the interruption timestamp field in the filtered entries, the number of times the preset business policy verification failure type is triggered is counted, and interruption frequency data is generated according to the interruption timestamp field, the number of triggers, and the preset business policy verification failure type, including: Based on the interruption timestamp field in the filtered entries, each entry is classified into a corresponding preset time window, where the preset time window is a predefined statistical period interval; Based on the preset business policy verification failure type, grouping and aggregating entries classified into the same preset time window to generate a set of policy verification failure type entries arranged in order of the time window; Count the number of interruption event triggers for the policy verification failure type entry set within each preset time window. The triggering number is the cumulative number of all entries in the corresponding time window, and each entry corresponds to an interruption event of a preset service policy verification failure. The interruption frequency data is generated by combining the preset time window, the number of interruption event triggering times and the preset service policy verification failure type.

6. The business process visualization warning and strategy response method according to claim 1, characterized in that When the interruption frequency data exceeds the upper limit of the baseline number, a hierarchical warning instruction containing a preset business policy version identifier is triggered, including: Based on the trigger count field and the historical time window field in the historical interruption frequency data, determine the upper limit of the baseline count for each preset time window; Configure a hierarchical warning strategy to define the warning levels corresponding to different excess limits when the number of triggers exceeds the upper limit of the baseline number; When the number of interrupt event triggers in the interrupt frequency data exceeds the upper limit of the baseline number in the current preset time window, the graded warning strategy is matched according to the excess range to generate a graded warning instruction corresponding to the warning level; Send graded warning instructions to the configured warning notification receiver through the preset notification channel.

7. The business process visualization warning and strategy response method according to claim 1, characterized in that, After generating page element weight adjustment parameters and a set of fault tolerance thresholds corresponding to the preset business policy version according to the preset business policy verification failure type data associated with the hierarchical warning instruction, the method further includes: Parsing the control identifier and priority coefficient in the page element weight adjustment parameter; Matching the control identifier with a document object model node in the interface rendering service component; Adjusting the page element weight value of the matched document object model node according to the priority coefficient; Inject the adjusted page element weight value into the browser rendering pipeline to enhance the visual salience of the controls corresponding to the preset business policy verification failure types; Parse the policy version identifier and the maximum fault tolerance trigger times in the fault tolerance threshold set; Perform version matching between the policy version identifier and the effective policy entries in the policy verification service database; Update the maximum fault tolerance trigger times field in the matched effective policy entries according to the maximum fault tolerance trigger times; Synchronize the updated effective policy entries to the business process execution service component to adjust the trigger conditions for the preset business policy verification failure types.

8. A business process visualization warning and strategy response device, characterized in that, The business process visualization warning and policy response device includes: An interruption node configuration module for setting multiple physical interruption nodes on the front-end interface of the business process; An operation trajectory collection module for collecting operation trajectory data for interrupting the business process through the physical interruption nodes; A logical interruption classification module for classifying the operation trajectory data into multi-level logical interruption type structured data according to the business process sequence; A topology graph construction module for mapping the multi-level logical interruption type structured data into a visual topology graph; An interruption screening module for screening entries with the logical interruption type being the preset business policy verification failure type from the multi-level logical interruption type structured data; An interruption frequency statistics module for counting the trigger times of the preset business policy verification failure type according to the interruption timestamp field in the screened entries, and generating interruption frequency data based on the interruption timestamp field, the trigger times, and the preset business policy verification failure type; A warning trigger module for triggering a hierarchical warning instruction including the preset business policy version identifier when the interruption frequency data exceeds the baseline number upper limit; A policy optimization parameter generation module for generating page element weight adjustment parameters and a fault tolerance threshold set corresponding to the preset business policy version according to the preset business policy verification failure type data associated with the hierarchical warning instruction.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a business process visualization warning and policy response program stored on the memory and executable on the processor. When the business process visualization warning and policy response program is executed by the processor, the steps of the business process visualization warning and policy response method according to any one of claims 1-7 are implemented.

10. A computer-readable storage medium, characterized in that, A business process visualization warning and policy response program is stored on the storage medium. When the business process visualization warning and policy response program is executed by the processor, the steps of the business process visualization warning and policy response method according to any one of claims 1-7 are implemented.

Images