Terminal application behavior data analysis method and computer equipment

Abstract

The embodiment of the invention discloses a terminal application behavior data analysis method and computer equipment, and the method comprises the steps: obtaining an interaction behavior data set of an RPA terminal application in a preset time window, the interaction behavior data set comprising a plurality of interaction behavior sequences, each interactive behavior sequence comprises at least one user interface operation event and a corresponding system response event; performing behavior track analysis processing on the interactive behavior data set, and extracting an interface circulation feature and an operation intention feature of each interactive behavior sequence; generating an interface optimization strategy according to the relevance between the interface circulation feature and the operation intention feature, wherein the interface optimization strategy comprises an interface layout adjustment rule and an interface response logic optimization rule; and feeding back the interface optimization strategy to a background management system of the RPA terminal application. Therefore, the problem that an existing RPA application interaction interface is insufficient in design and optimization can be effectively solved, and the usability of the interface and the response capability of the system are improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of data analysis technology, and specifically to a terminal application behavior data analysis method and computer equipment. Background Art

[0002] In today's digital office landscape, RPA (Robotic Process Automation) applications have been widely promoted and adopted. The design and optimization of its interactive interface are crucial for improving user experience and work efficiency. RPA applications aim to simulate human operations through automated processes, helping companies complete repetitive tasks quickly and accurately.

[0003] However, existing RPA application interfaces still lack design and optimization. For example, existing interface designs often lack in-depth analysis of actual user behavior and fail to fully consider the user's interface flow and operational intent during operation. This can lead to interface layouts that may not align with user habits, impacting operational efficiency. Furthermore, the optimization of system response logic is not precise enough, making it impossible to respond to user operations in a timely and appropriate manner, thus reducing the user experience. Summary of the Invention

[0004] The embodiments of the present application provide a terminal application behavior data analysis method and computer device for obtaining a set of interactive behavior data, performing behavioral trajectory analysis, generating interface optimization strategies, and feeding back to the backend management system, thereby effectively solving the problems of insufficient design and optimization of existing RPA application interaction interfaces and improving the interface usability and system responsiveness.

[0005] In a first aspect, an embodiment of the present application provides a terminal application behavior data analysis method, which is applied to a computer device, and the method includes: obtaining an interactive behavior data set of an RPA terminal application within a preset time window, the interactive behavior data set including multiple interactive behavior sequences, each interactive behavior sequence including at least one user interface operation event and a corresponding system response event; performing behavioral trajectory analysis on the interactive behavior data set to extract the interface flow characteristics and operation intention characteristics of each interactive behavior sequence; generating an interface optimization strategy based on the correlation between the interface flow characteristics and the operation intention characteristics, the interface optimization strategy including interface layout adjustment rules and interface response logic optimization rules; and feeding back the interface optimization strategy to the background management system of the RPA terminal application.

[0006] In a second aspect, an embodiment of the present application provides a computer device, including: processor; a storage device having a computer program stored thereon, When the computer program is executed by the processor, the processor implements any of the terminal application behavior data analysis methods.

[0007] An embodiment of the present application provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the terminal application behavior data analysis method are implemented.

[0008] It can be seen that the embodiments of the present application have the following beneficial effects: the embodiments of the present application first obtain the interactive behavior data set of the RPA terminal application within the preset time window, and then perform behavioral trajectory analysis and processing on the interactive behavior data set, accurately extract the interface flow characteristics and operation intention characteristics of each interactive behavior sequence in the interactive behavior data set, and deeply analyze the interactive behavior between the user and the system from different angles, providing strong support for understanding the user's operation mode and needs. Then, based on the correlation between the interface flow characteristics and the operation intention characteristics, an interface optimization strategy covering interface layout adjustment rules and interface response logic optimization rules is generated, which can optimize the interactive interface in a targeted manner, improve the convenience of user operation and the rationality of system response. Finally, the interface optimization strategy is fed back to the background management system, so that the RPA terminal application can make timely adjustments, continuously optimize the interactive process, and enhance the interactive usability and timeliness of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 This is a flowchart of a terminal application behavior data analysis method provided in an embodiment of the present application.

[0010] Figure 2 A schematic diagram of the basic structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0011] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the embodiments of the present application are further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0012] See also Figure 1 As shown in FIG, this figure is a flow chart of a terminal application behavior data analysis method provided by an embodiment of the present application, which can be applied to computer devices. Figure 1 As shown, the method may include steps 110 to 140.

[0013] Step 110: Obtain an interactive behavior data set of the RPA terminal application within a preset time window, wherein the interactive behavior data set includes multiple interactive behavior sequences, and each interactive behavior sequence includes at least one user interface operation event and a corresponding system response event.

[0014] In the embodiment of the present application, the RPA terminal application for supply chain business processing is taken as an example. The preset time window is set to one week. During this week, staff members in various links of the supply chain use the RPA terminal application to perform business operations. The operations of each staff member constitute an interactive behavior sequence. For example, in the procurement link, after staff member A logs in to the RPA terminal application, he clicks the "Create Purchase Order" user interface operation event, and the system immediately responds by popping up the purchase order creation page; then staff member A fills in the supplier information, purchase commodity details, etc. in turn. Each filling operation is a user interface operation event, and the system will also perform data format verification, related data query and other system response events accordingly. In the inventory management link, staff member B clicks the "Inventory Count" user interface operation event, and the system responds to generate an inventory count form. Staff member B enters information such as the actual inventory count on the form. These operations and responses also constitute an interactive behavior sequence. The operation behavior sequences of many staff members in different links together constitute an interactive behavior data set.

[0015] For each user interface operation event, the triggering timestamp is recorded in detail, accurate to the millisecond, along with the corresponding interface element identifier, such as "Create Purchase Order Button - PO001" and "Supplier Name Input Box - SPN002." System response events also record the corresponding timestamp and response content identifier, such as "Purchase Order Creation Page Loaded Successfully - POC003" and "Inventory Count Form Generated - IPF004." This recording method provides a complete collection of interactive behavior data for RPA terminal applications within a preset time window.

[0016] It should be noted that the collection and use of all user interaction behavior data involved in the embodiments of this application strictly comply with relevant industry regulations on personal information protection, and fully guarantee the user's right to know and right to choose independently. When the user logs in to the RPA terminal application for the first time, the system will display the "User Informed Agreement and Data Use Authorization" through a prominent pop-up window, clearly informing that the scope of data collection includes metadata such as interface operation events and system response events, timestamps and element identifiers, and detailed explanations that the data will be used for technical purposes such as interface experience optimization and business process improvement, and all data are anonymized to remove personal identity information. Users must actively check the "Agree to Authorization" checkbox before they can continue to use the system. The authorization process uses a two-factor confirmation mechanism to ensure the authenticity of the user's wishes.

[0017] The subsequent data storage phase uses the AES-256 encryption algorithm to desensitize behavioral sequences. Access rights are managed hierarchically, and complete operation logs are recorded via blockchain technology. Users can access the privacy settings module in their personal center to view the list of collected data types at any time and exercise rights such as data query, export, and revoke authorization. Upon revoking authorization, the system automatically triggers a data cleanup process and irreversibly deletes historical behavior records within a preset timeframe.

[0018] In one implementation, performing behavior trajectory analysis on the interaction behavior data set to extract interface flow features and operation intention features of each interaction behavior sequence includes: Step 121: for each user interface operation event in the interactive behavior sequence, identify the interface element identifier and operation triggering timestamp corresponding to the user interface operation event, and generate an interface flow path based on the interface element identifier and the operation triggering timestamp.

[0019] Continuing with the supply chain business scenario above, let's consider the interaction sequence of worker A, starting with clicking the "Create Purchase Order" button. Record the corresponding interface element identifier ("Create Purchase Order Button - PO001") and the action trigger timestamp (t1). Once on the purchase order creation page, record the "Fill in Supplier Name" action. Record the interface element identifier ("Supplier Name Input Box - SPN002") and timestamp (t2).

[0020] After that, operations are performed on the purchase product details in sequence, and the corresponding interface element identifiers and timestamps are recorded respectively. Based on these records, an interface flow path is generated. This path is not a simple linear arrangement, but takes into account the order of operations and possible branching situations. For example, if there is an "Add Product" button when filling in the purchase product details, clicking it will enter a new product selection page, then the interface element identifier and entry timestamp of the new page will also be recorded in the interface flow path. In the above way, the user interface operation events in each interactive behavior sequence are connected in chronological order based on the interface element identifier, forming an interface flow path that reflects the user's flow between different interface elements.

[0021] Taking the operation process of staff member A as an example, the interface flow path can be expressed as: "Create purchase order button-PO001 (t1)" -> "Supplier name input box-SPN002 (t2)" -> "Purchase product name input box-PPN003 (t3)" -> "Purchase product quantity input box-PQN004 (t4)"..., the arrows in the embodiment of the present application indicate the sequence of operations, and the timestamps in the brackets clarify the specific time point of each operation. The above path comprehensively demonstrates the interface flow of the user in the process of creating a purchase order.

[0022] Step 122: performing sequence segmentation processing on the interface flow path to obtain a plurality of interface flow sub-paths, each of which includes at least two consecutive user interface operation events.

[0023] Continuing with the example of worker A's interface flow path, we'll perform sequence segmentation. Within the entire purchase order creation path, we can segment operations based on their logical relevance. For example, the two consecutive operations, "Create Purchase Order Button - PO001 (t1)" -> "Supplier Name Input Box - SPN002 (t2)," are grouped into one interface flow sub-path, as they are key operations in the initial stages of purchase order creation and are closely related. Another example, the three consecutive operations, "Purchase Item Name Input Box - PPN003 (t3)" -> "Purchase Item Quantity Input Box - PQN004 (t4)" -> "Purchase Item Price Input Box - PP005 (t5)," can form another interface flow sub-path, as they revolve around filling in the purchase item details and belong to the same logical stage. Through the above segmentation method, the entire interface flow path is decomposed into multiple interface flow sub-paths. Each sub-path contains at least two consecutive user interface operation events. The above segmentation helps to more carefully analyze the user's behavior patterns in different operation stages. Each sub-path can be regarded as a relatively independent operation unit, providing a clearer structure for subsequent in-depth analysis of operation intentions and interface flow characteristics.

[0024] Step 123: Call the pre-trained intention recognition model to perform context association analysis on the user interface operation events in each interface flow sub-path, and generate an operation intention description vector for each interface flow sub-path.

[0025] In an alternative embodiment, calling a pre-trained intent recognition model to perform contextual association analysis on user interface operation events in each interface flow sub-path to generate an operation intent description vector for each interface flow sub-path includes: Step 1231: Obtain the interface element type and operation type of each user interface operation event in the interface flow sub-path, and generate an operation semantic code based on the interface element type and the operation type.

[0026] For the previously divided interface flow from "Create Purchase Order Button - PO001 (t1)" to "Supplier Name Input Box - SPN002 (t2)," this subpath is reconfigured. The interface element type for the "Create Purchase Order Button" is a button, and its action type is click; the interface element type for the "Supplier Name Input Box" is an input box, and its action type is input. Combine the interface element type and action type to create a code. For example, the button type is coded "BT," the click action is coded "CL," the input box type is coded "IN," and the input action is coded "EN." The operational semantics of the "Create Purchase Order Button" are coded "BT_CL," and the operational semantics of the "Supplier Name Input Box" are coded "IN_EN."

[0027] Through the above method, the key information of each user interface operation event is converted into a unified coding form to facilitate subsequent processing. These codes are not set arbitrarily, but according to pre-established coding rules to ensure that different interface element types and operation types have unique and reasonable coding representations, so that the operation semantics can be accurately reflected through the coding, providing basic data for subsequent intent recognition.

[0028] Step 1232: Discretize and encode the time intervals between adjacent user interface operation events in the interface flow sub-path to generate a time interval code sequence.

[0029] In the sub-path of the "Create Purchase Order Button - PO001 (t1)" -> "Supplier Name Input Box - SPN002 (t2)" interface, the time interval between adjacent operations is calculated: t2 - t1. For example, the time interval is discretized into predefined intervals: 0-5 seconds is "short" and coded as "SH"; 5-15 seconds is "medium" and coded as "MI"; and 15 seconds or more is "long" and coded as "LO". If t2 - t1 = 3 seconds, the interval is coded as "SH".

[0030] Following this method, the time intervals between all adjacent user interface operation events in an interface flow subpath are calculated and discretized to generate a sequence of time interval codes. For interface flow subpaths containing more operations, a sequence of multiple discretized codes, such as "SH," "MI," "SH," and so on, is generated. This sequence reflects the temporal relationship between operations. Different time interval codes represent different operation rhythms, providing temporal information for intent recognition.

[0031] Step 1233: Input the operational semantic code and the time interval code sequence into the intention recognition model, perform cross-modal fusion processing on the operational semantic code and the time interval code sequence through the multi-layer attention mechanism in the intention recognition model, and generate the operational intention description vector of the interface flow sub-path.

[0032] Optionally, the previously generated operational semantic encodings "BT_CL" and "IN_EN" and the time interval encoding sequence "SH" are input into the pre-trained intent recognition model. The multi-layer attention mechanism in the intent recognition model processes data from these two different modalities.

[0033] First, the attention mechanism focuses on different parts of the operational semantics encoding and time interval encoding sequence, assigning different weights based on their importance. For example, for operational semantics encoding, the encoding weight of the key operation "create purchase order" may be higher.

[0034] The two encoded information is then integrated through multiple layers of computation and fusion. In this process, the model learns the underlying relationship between operational semantics and time intervals. For example, quickly clicking a button followed by entering information may indicate that the user is eager to complete a task.

[0035] After the above processing, an action intention description vector is generated. This vector is a multi-dimensional set of numerical values, with each dimension representing a different intent characteristic. For example, one dimension might represent the intensity of the intention to create a purchase order, another dimension might represent the urgency of the action, and so on.

[0036] Through the above method, the operation information and time information in the interface flow rotor path are fused and converted into a vector form that can accurately describe the operation intention, providing core data support for the subsequent extraction of interface flow characteristics and operation intention characteristics.

[0037] Step 124: extracting interface flow features and operation intention features of the interaction behavior sequence based on the path topology structure of the interface flow path and the distribution pattern of the operation intention description vector.

[0038] In an optional design approach, extracting the interface flow features and operation intention features of the interaction behavior sequence based on the path topology structure of the interface flow path and the distribution pattern of the operation intention description vector includes: Step 1241: traverse all interface element identifiers in the interface flow path, generate an interface element node set and a jump relationship set between nodes, and generate an interface flow topology diagram based on the interface element node set and the jump relationship set.

[0039] For worker A's entire interface flow path, traverse all interface element identifiers, such as "Create Purchase Order Button - PO001," "Supplier Name Input Box - SPN002," and "Purchase Product Name Input Box - PPN003." These identifiers are treated as nodes and placed into the interface element node set. Also, record the jump relationships between nodes, such as from "Create Purchase Order Button - PO001" to "Supplier Name Input Box - SPN002," and from "Supplier Name Input Box - SPN002" to "Purchase Product Name Input Box - PPN003." These jump relationships constitute the inter-node jump relationship set. Based on these two sets, draw an interface flow topology diagram.

[0040] In this topology diagram, nodes represent interface elements, and edges represent the transitions between nodes, intuitively illustrating how users move between different interface elements. For example, the diagram clearly shows which interface elements are the starting points of a transition, which are intermediate transition points, and which elements frequently transition to each other. This provides a visual structural foundation for subsequent analysis of interface flow characteristics.

[0041] Step 1242: extracting graph structure features from the interface flow topology graph to obtain node degree distribution features and path loop features of the interface flow topology graph.

[0042] Optionally, analyze the generated interface flow topology to calculate node degree distribution characteristics. Node degree refers to the number of edges connected to a node. For example, if the "Create Purchase Order Button - PO001" node is only connected to the "Supplier Name Input Box - SPN002" node, its degree is 1. On the other hand, if the "Purchase Product Details Page" node is connected to multiple product input box nodes and the "Submit Purchase Order Button" node, its degree is higher. By calculating the degrees of all nodes, we can obtain node degree distribution characteristics. For example, we can count the number of nodes with degree 1 and degree 2, and so on. This helps us understand the importance and connectivity of interface elements in the flow process.

[0043] At the same time, look for path loop features. In a topology diagram, if there is a path that starts from a node, passes through a series of nodes, and then returns to the node, it can be understood as a path loop. For example, in the interface flow of inventory management, there may be a loop starting from the "Inventory Query Page", passing through the "Inventory Details Page" and "Inventory Adjustment Page", and then returning to the "Inventory Query Page". These path loop features reflect the cyclic operation patterns of users in certain business processes and are important for analyzing the complexity of interface flow and user behavior patterns.

[0044] Step 1243: Perform cluster analysis on the operation intention description vector to determine the cluster center distribution and intra-class dispersion of the operation intention description vector in the feature space.

[0045] Optionally, cluster analysis is performed on the generated operational intention description vectors of each interface flow sub-path. For example, there are multiple interface flow sub-paths, and each sub-path has a corresponding operational intention description vector. These vectors are placed in a feature space, and similar vectors are clustered together using a clustering algorithm, such as the K-Means clustering algorithm. During the clustering process, the distribution of cluster centers is determined. The cluster center is a group of vectors that represent the typical characteristics of a certain type of operational intention. For example, after clustering, it may be found that the cluster center of one type of operational intention description vector represents the "intent to quickly create a purchase order", and another type represents the "intent to check inventory in detail", etc.

[0046] At the same time, we calculate intra-class dispersion, which reflects the degree of variation between vectors describing the same type of operational intent. A low intra-class dispersion indicates that the vectors within that class are relatively similar and represent relatively concentrated operational intent. A high intra-class dispersion indicates that the vectors within that class are highly diverse and may contain multiple similar but not identical operational intents. Cluster analysis and determination of cluster center distribution and intra-class dispersion provide a clearer understanding of the classification of operational intent and the stability of each intent class.

[0047] Step 1244: Concatenate the node degree distribution features, the path loop features, the cluster center distribution, and the intra-class dispersion to obtain the interface flow features and operation intention features of the interactive behavior sequence.

[0048] The previously obtained node degree distribution features, path loop features, cluster center distribution, and intra-class dispersion are concatenated. For example, the node degree distribution features are represented as a vector D, the path loop features as a vector R, the cluster center distribution as a vector C, and the intra-class dispersion as a vector V. These four vectors are concatenated in a specific order to form a new vector F = [D, R, C, V]. This vector F comprehensively represents the interface flow characteristics and operation intention characteristics of the interaction behavior sequence. The node degree distribution features reflect the importance of the connection between interface elements, the path loop features reflect the cyclical nature of the business process, the cluster center distribution identifies the main operation intention categories, and the intra-class dispersion illustrates the stability and diversity of operation intentions. Through this concatenation method, the different aspects of the features are integrated together, providing a rich and comprehensive data foundation for the subsequent generation of interface optimization strategies. This enables the analysis of user behavior and interface flow from multiple dimensions, thereby implementing targeted interface optimization.

[0049] Step 130: Generate an interface optimization strategy based on the correlation between the interface flow characteristics and the operation intention characteristics, wherein the interface optimization strategy includes interface layout adjustment rules and interface response logic optimization rules.

[0050] As an implementation method, the generating of the interface optimization strategy according to the correlation between the interface flow feature and the operation intention feature includes: Step 131: determining a frequent interface jump path based on the path loop feature in the interface flow feature, and generating an interface layout adjustment rule according to the start interface element identifier and the end interface element identifier of the frequent interface jump path.

[0051] In supply chain operations, by analyzing the path loop features in the interface flow characteristics, it was discovered that a path loop frequently appears: from the "Inventory Query Page - INVQ001" to the "Inventory Detail Page - INVD002" to the "Inventory Adjustment Page - INVD003" and finally back to the "Inventory Query Page - INVQ001". This path is determined to be a frequent interface jump path. From this frequent interface jump path, the first interface area coordinates of the starting interface element "Inventory Query Page - INVQ001" are extracted. For example, the coordinates are (x1, y1), and the second interface area coordinates of the ending interface element "Inventory Query Page - INVQ001" are extracted (because it returns to the same page, the coordinates are the same) (x1, y1). The spatial distance between these two coordinates is calculated. The spatial distance calculation in the embodiment of the present application can use a simple two-dimensional spatial distance calculation formula (but does not use a specific formula, using text to describe the logic), that is, calculating the square root of the sum of the squares of the horizontal coordinate difference and the vertical coordinate difference. Since the coordinates are the same, the spatial distance is 0.

[0052] However, in practice, if the start and end elements are on different pages, a non-zero distance value will be obtained. Based on this spatial distance and business needs, the optimization direction for the interface element layout is determined. For example, if the distance is large and users frequently jump between these pages to quickly view and adjust inventory information, the optimization direction may be to arrange the "Inventory Query Page," "Inventory Details Page," and "Inventory Adjustment Page" more closely in the interface layout to reduce the page switching cost during user operations. Based on this optimization direction, an interface element position mapping table is generated. For example, the new position of "Inventory Query Page - INVQ001" in the new interface layout is specified as (x1', y1'), the new position of "Inventory Details Page - INVD002" is specified as (x1'+Δx1, y1'), and the new position of "Inventory Adjustment Page - INVAD003" is specified as (x1'+Δx2, y1'). This mapping table clearly indicates the relative position of each interface element in the updated interface layout, providing specific guidance for interface layout adjustments.

[0053] In a preferred embodiment, the generating of the interface layout adjustment rule according to the start interface element identifier and the end interface element identifier of the frequent interface jump path includes: Step 1311: extracting the first interface area coordinates corresponding to the starting interface element identifier and the second interface area coordinates corresponding to the ending interface element identifier from the frequent interface jump path.

[0054] Continuing with the example of the frequent interface jump path just now, in the system, each interface element has its corresponding coordinate information record. For the "Inventory Query Page - INVQ001", its coordinate position (x1, y1) in the current interface is obtained through the system's interface layout information. This is the coordinate of the first interface area. For the terminal interface element "Inventory Query Page - INVQ001" (because it is returning to the same page), its coordinates (x1, y1) are also obtained as the coordinates of the second interface area. If the starting and ending interface elements are different, for example, the starting point is the "Purchase Order List Page - POL001" and the ending point is the "Purchase Order Details Page - POD002", the accurate coordinate position information of these two page elements is obtained from the system respectively. These coordinate information is accurate to the pixel level, so that accurate layout adjustment analysis can be performed later.

[0055] Step 1312: Calculate the spatial distance between the coordinates of the first interface area and the coordinates of the second interface area, and determine the interface element layout optimization direction according to the spatial distance.

[0056] It can be understood that when calculating the spatial distance between the coordinates of the first interface area and the coordinates of the second interface area, considering that the interface is a two-dimensional plane, for the coordinates (x1, y1) and (x2, y2), the calculation logic of the spatial distance is to first calculate the horizontal coordinate difference (x2-x1) and the vertical coordinate difference (y2-y1), and then square these two differences respectively, that is, (x2-x1)2 and (y2-y1)2, and then add these two square values to obtain (x2-x1)2+(y2-y1)2, and finally perform a square root operation on the sum, and the result is the spatial distance.

[0057] Then, based on this spatial distance, determine the optimization direction for the interface element layout. If the spatial distance is large, it means that users incur a high operational cost when switching between the two interface elements, such as scrolling the page or frequently clicking the switch button. Combined with business scenario analysis, if it is found that users frequently jump between the two pages to quickly view the details of an order in the order list, the optimization direction may be to display the entrance to the "Purchase Order Details Page" more prominently on the "Purchase Order List Page" or directly integrate the order details into the list page in some form of folding or expanding to reduce the user's page jumping operations. If the spatial distance is small, but the jump is frequent, it may be necessary to consider providing a more convenient way to interact between the two interface elements, such as adding a quick navigation button. Through the above analysis based on spatial distance and business needs, a reasonable interface element layout optimization direction is determined, providing a foundation for the subsequent generation of the interface element position mapping table.

[0058] Step 1313: Generate an interface element position mapping table based on the interface element layout optimization direction, where the interface element position mapping table is used to indicate the relative position relationship between the starting interface element identifier and the ending interface element identifier in the updated interface layout.

[0059] In this step, based on the previously determined interface element layout optimization direction, an interface element position mapping table is generated. For example, for the purchase order-related pages mentioned earlier, the optimization direction is to make the entrance to the "Purchase Order Details Page" more prominent within the "Purchase Order List Page." In the new interface layout design, the overall position of the "Purchase Order List Page - POL001" remains unchanged, with its upper left corner coordinates at (0, 0) (as the reference origin). The entrance to the "Purchase Order Details Page - POD002" is placed next to each order entry in the "Purchase Order List Page - POL001." For example, previously, each order entry in the list page was arranged according to a specific row and column rule. Now, a link element for the "Purchase Order Details Page - POD002" entry is added to the right of each order entry (for example, by adding a certain distance horizontally). Specifically, for the i-th order item in the list, its position coordinates in the list page are (xi, yi), then the position coordinates of the entry link element of "Purchase Order Details Page-POD002" in the new layout are (xi+Δx, yi), where Δx is the horizontal distance increment determined by the design for placing the entry link.

[0060] Organize the above position relationships into a mapping table of interface element positions. The table records the relative position information in the updated interface layout of each starting interface element identifier (such as each relevant element in "Purchase Order List Page - POL001") and the corresponding ending interface element identifier (such as the entry link element of "Purchase Order Details Page - POD002"). This mapping table details the position changes of each element in the new interface layout, providing clear guidance for interface developers to perform actual interface layout adjustments, ensuring that the positions of interface elements can be accurately adjusted according to the optimization strategy to improve the convenience and efficiency of user operations.

[0061] Step 132: Determine the target operation intention category based on the distribution of cluster centers in the operation intention features, and generate an interface response logic optimization rule according to the operation trigger timestamps of the interface transition sub-paths corresponding to the target operation intention category.

[0062] It can be understood that through clustering analysis of the operation intention description vectors, the distribution of cluster centers is obtained, and it is found that one of the operation intention categories represented by the cluster center is "Intention to Quickly Process Emergency Purchase Orders". There are multiple operation intention description vectors of interface transition sub-paths gathered around this cluster center, and this category is determined as the target operation intention category.

[0063] For the interface transition sub-paths corresponding to this target operation intention category, collect their operation trigger timestamps. For example, in these interface transition sub-paths, it is found that the average operation trigger time interval from clicking the "Create Emergency Purchase Order" button to the system popping up the order creation page is relatively long. After statistically analyzing multiple such operations, the average time interval is t seconds. At the same time, it is observed that when filling in the key information of the emergency purchase order (such as product name, quantity, etc.), the response speed of the system also affects the user experience.

[0064] According to these operation trigger timestamps and business requirements, determine the response delay threshold for system response events. Considering the timeliness of emergency purchase orders, the response delay threshold is set to t1 seconds (t1 < t), that is, it is required that the system give a response within t1 seconds after the user performs relevant operations.

[0065] It can be understood that in order to generate asynchronous task scheduling rules based on the response delay threshold, the background service interfaces associated with the system response events are first identified, such as the interface for creating orders, the data verification interface, etc. For these background service interfaces, their historical response time series are obtained. The fluctuation range of these historical response time series is analyzed, and the maximum number of concurrent threads is determined in combination with the response delay threshold t1 second. For example, if it is found that the historical response time of a background service interface fluctuates greatly and often exceeds t1 seconds, it means that the current concurrent processing capacity is insufficient. By analyzing historical data and business needs, the maximum number of concurrent threads of the interface is determined to be N. At the same time, based on the overall resource situation of the system and the business traffic forecast, the task queue capacity threshold is determined to be M.

[0066] Optionally, thread pool configuration parameters are generated, including the maximum number of concurrent threads N and the task queue capacity threshold M. These parameters are used to adjust the concurrent processing capabilities of the backend service interface, ensuring that the system can respond to user operations within the response delay threshold. For example, when a new emergency purchase order creation request enters the system, the thread pool will rationally allocate threads to handle the request based on current thread usage and task queue status, improving the system's response speed and satisfying the user's operational intent to quickly process the emergency purchase order, thereby generating interface response logic optimization rules.

[0067] Optionally, generating an interface response logic optimization rule according to the operation trigger timestamp of the interface flow sub-path corresponding to the target operation intention category includes: Step 1320: Count the average response time intervals between adjacent user interface operation events in all interface flow sub-paths corresponding to the target operation intention category; determine the response delay threshold of the system response event based on the average response time interval; generate asynchronous task scheduling rules based on the response delay threshold, and the asynchronous task scheduling rules are used to adjust the background resource allocation priority of the system response event.

[0068] For the target action intent category "Quickly process urgent purchase orders," we counted the response time intervals between adjacent user interface action events in all corresponding interface flow subpaths. For example, within these interface flow subpaths, we recorded the time interval from clicking "Enter urgent purchase product name" to the system responding with an input format verification response, or the time interval from clicking "Select urgent purchase supplier" to the system popping up the supplier list. After collecting a large amount of these time intervals, we calculated their average to obtain the average response time interval T.

[0069] According to business requirements and user experience requirements, determine the response delay threshold T1 for system response events. Since it is an emergency purchase order processing and requires a quick response, T1 will be set relatively small, and T1 < T. For example, if the average response time interval T is 5 seconds, considering the timeliness of emergency services, set the response delay threshold T1 to 2 seconds.

[0070] Generate an asynchronous task scheduling rule based on this response delay threshold T1. Analyze the background service interfaces corresponding to these user interface operation events in the system, such as interfaces involving data query, verification, storage, etc. For each background service interface, determine its priority in asynchronous task scheduling according to its historical response time and business importance. For example, for a key interface that directly affects the order creation process, such as an order data verification interface, set its priority to high; for some auxiliary interfaces, such as an order logging interface, set the priority to low. By the above method, adjust the priority of background resource allocation for system response events, ensure that important and time-sensitive operations can be processed first, improve the system's response speed, meet the user's operation intention of quickly processing emergency purchase orders, and thus generate an effective asynchronous task scheduling rule to optimize the interface response logic.

[0071] Further, the generating an asynchronous task scheduling rule based on the response delay threshold includes: Step 13200: Identify the background service interfaces associated with the system response events, and obtain the historical response time series of the background service interfaces; determine the maximum number of concurrent threads according to the fluctuation range of the historical response time series and the response delay threshold, and generate thread pool configuration parameters. The thread pool configuration parameters include the maximum number of concurrent threads and the task queue capacity threshold, and the thread pool configuration parameters are used to adjust the concurrent processing ability of the background service interfaces.

[0072] For system response events involving emergency purchase order processing, identify the associated background service interfaces. For example, there are interfaces such as "Order Data Verification Interface - V001", "Supplier Information Query Interface - S002", "Order Storage Interface - O003", etc. For each interface, obtain its historical response time series from the system's log records, and these historical response time series record the response time of the interface to different requests in the past period.

[0073] Furthermore, the fluctuation range of the historical response time series for each interface was analyzed. For example, the historical response time of the "Order Data Verification Interface - V001" fluctuated between 1 and 8 seconds, and the historical response time of the "Supplier Information Query Interface - S002" fluctuated between 0.5 and 5 seconds. Combined with the response delay threshold T1 (set to 2 seconds), for the "Order Data Verification Interface - V001", due to its large fluctuation range and some response times exceeding T1, to ensure responses within the threshold, the maximum number of concurrent threads for this interface was determined to be n1 by analyzing business traffic and system resources. For the "Supplier Information Query Interface - S002", its maximum number of concurrent threads was determined to be n2.

[0074] At the same time, determine the task queue capacity threshold for each interface based on the overall system resources and business needs. For example, set the task queue capacity threshold for "Order Data Verification Interface - V001" to m1, and set the task queue capacity threshold for "Supplier Information Query Interface - S002" to m2.

[0075] The maximum number of concurrent threads and the task queue capacity threshold are combined into thread pool configuration parameters. For example, for the "Order Data Verification Interface - V001," the thread pool configuration parameters are (n1, m1); for the "Supplier Information Query Interface - S002," the thread pool configuration parameters are (n2, m2). These thread pool configuration parameters are used to adjust the concurrent processing capabilities of the background service interface. When a large number of requests arrive simultaneously, the thread pool can reasonably allocate thread resources based on the configuration parameters, ensuring that each interface can process requests within the response delay threshold, thereby optimizing the system's response logic and improving the system's response speed and processing efficiency to user operations.

[0076] Step 133: sorting the interface layout adjustment rules and the interface response logic optimization rules according to their policy priorities to generate the interface optimization policy.

[0077] The generated interface layout adjustment rules and interface response logic optimization rules are prioritized. Considering the urgency of the business and the key factors of user experience, the impact of the rules on business processes is first analyzed. For urgent purchase order processing in the supply chain business, the interface response logic optimization rule directly affects whether users can complete the order quickly and has a significant impact on the timeliness of the business, so its priority is set to high. While the interface layout adjustment rule can also improve user convenience, its direct impact on urgent business is relatively small, so its priority is set to medium.

[0078] Optionally, according to the above priority ranking, the interface layout adjustment rules and interface response logic optimization rules are integrated to generate an interface optimization strategy. This strategy clarifies that when optimizing the interface, the focus should first be on optimizing the system's response logic to ensure that the system can quickly respond to user operations and meet urgent business needs. Then, without affecting the system's response performance, the interface layout adjustment rules are gradually implemented to optimize the position and arrangement of interface elements, improving user convenience and overall experience. By prioritizing the above strategies, the interface optimization strategy becomes more reasonable and effective, and can specifically address interface issues in RPA terminal applications in supply chain business, improving system practicality and user satisfaction.

[0079] Step 140: Feedback the interface optimization strategy to the backend management system of the RPA terminal application.

[0080] In an optional embodiment, feeding back the interface optimization strategy to the backend management system of the RPA terminal application includes: Step 141: Perform parameter alignment processing on the interface element position mapping table in the interface layout adjustment rule and the thread pool configuration parameters in the interface response logic optimization rule, and extract the interface layout parameter set and the thread pool parameter set. The interface layout parameter set includes the interface element identifier, the updated relative position coordinates and the element size ratio coefficient, and the thread pool parameter set includes the maximum number of concurrent threads, the task queue capacity threshold and the asynchronous task scheduling priority weight.

[0081] For the interface element position mapping table in the interface layout adjustment rules, extract each interface element identifier and its relative position coordinates in the updated interface layout. At the same time, considering that the interface elements may need to be adjusted in size to adapt to the new layout, determine the element size ratio coefficient. For example, for a certain order entry element in the "Purchase Order List Page - POL001", its relative position coordinates in the new layout are (x', y'), and the element size ratio coefficient is k (k means that the width and height are adjusted to k times the original size). This information is organized into an interface layout parameter set, where the information of each element can be expressed as (interface element identifier, updated relative position coordinates, element size ratio coefficient), such as ("Order Entry - E001", (x', y'), k).

[0082] For the thread pool configuration parameters in the UI response logic optimization rules, extract the maximum number of concurrent threads, task queue capacity threshold, and asynchronous task scheduling priority weight. For example, for the thread pool configuration parameters for "Order Data Verification Interface - V001," the maximum number of concurrent threads is n1, the task queue capacity threshold is m1, and the asynchronous task scheduling priority weight is w1 (for example, the weight is used to determine the processing order when multiple tasks compete for resources). Organize these parameters into a thread pool parameter set, such as (n1, m1, w1).

[0083] Through the above parameter alignment processing, the key parameters required for interface layout and interface response logic optimization are clarified, preparing for the subsequent generation of configuration file update instructions and system deployment, ensuring that the background management system can accurately obtain and apply these optimization parameters.

[0084] Step 142: Perform normalization processing on the relative position coordinates in the interface layout parameter set, perform multi-dimensional feature splicing on the normalized interface layout parameters and the task queue capacity threshold in the thread pool parameter set, and generate a configuration file update instruction containing a unified dimensional index. The multi-dimensional feature splicing includes: spatially encoding the relative position coordinates according to the topological sorting of the interface element identifiers, and linearly combining them with the asynchronous task scheduling priority weights in the thread pool parameter set according to a preset weight ratio.

[0085] Normalize the relative position coordinates in the interface layout parameter set. For example, the overall size of the interface ranges from (0, 0) to (W, H) (W is width, H is height). For the relative position coordinates (x', y') of a certain interface element, the normalization logic is to divide the horizontal coordinate x' by W and the vertical coordinate y' by H to obtain the normalized coordinates (x''=x' / W, y''=y' / H). After this processing, the relative position coordinates of all interface elements are within the range of 0 to 1, which facilitates subsequent unified processing and comparison with other parameters.

[0086] The normalized interface layout parameters are spatially encoded based on the topological ordering of the interface element identifiers. For example, the interface element identifiers are sorted according to their hierarchy and display order within the interface layout, such as "Interface Element 1-E1," "Interface Element 2-E2," and so on. Each normalized relative position coordinate (x'', y'') is converted into a spatial encoding form, such as a binary code. Using certain rules, the coordinate values are mapped to binary bits to reflect their spatial position information.

[0087] The spatially encoded interface layout parameters are linearly combined with the asynchronous task scheduling priority weights in the thread pool parameter set according to a preset weight ratio. For example, the preset weight ratio is α (for the interface layout parameters) and β (for the asynchronous task scheduling priority weights), and α + β = 1. For a given interface element, its spatially encoded layout parameters are P, and its asynchronous task scheduling priority weight is w. The result of the linear combination is a new eigenvalue F = α * P + β * w.

[0088] These new feature values are then combined with the task queue capacity threshold in the thread pool parameter set for multi-dimensional feature splicing. For example, the task queue capacity threshold is represented as a value T, and F and T are combined in a certain order to form a configuration file update instruction with a unified dimension index. This instruction integrates key parameter information related to interface layout and interface response logic, presenting it in a unified format for subsequent input into the version control service for processing, ensuring that the backend management system can accurately understand and apply these optimization parameters to update the system configuration.

[0089] Step 143: Input the configuration file update instruction into the version control service, calculate the parameter hash values for the interface layout parameter set and the thread pool parameter set respectively through the parameter hash generator in the version control service, and compare the difference between the current version parameter hash value and the target version parameter hash value.

[0090] Optionally, the generated configuration file update instruction containing the unified dimension index is input into the version control service. The parameter hash generator in the version control service processes the interface layout parameter set and the thread pool parameter set separately. For the interface layout parameter set, the parameter hash generator will calculate a hash value based on all parameter information in the set, such as interface element identifiers, normalized relative position coordinates, element size ratio coefficients, etc., through a hash algorithm (such as the commonly used MD5 or SHA-256 algorithm). The hash value is a unique identifier for the interface layout parameter set, and any slight change in the parameter will result in a change in the hash value.

[0091] Similarly, for the thread pool parameter set, the parameter hash generator calculates another hash value based on parameters such as the maximum number of concurrent threads, the task queue capacity threshold, and the asynchronous task scheduling priority weight.

[0092] The version control service records the version hash values of these parameters in the current system, known as the current version parameter hash values. Simultaneously, it calculates the target version parameter hash values based on the parameter information in the configuration file update instructions. The current version parameter hash values are then compared with the target version parameter hash values. This difference is calculated by comparing the similarity between the two hash values. Although a hash value is a string of numbers, due to the characteristics of the hash algorithm, even small changes in the parameters can result in significant differences. A specialized algorithm is used to measure the difference between the two hash values, such as calculating the proportion of the total number of bits that differ in the corresponding position of the two hash values. If the two hash values are very similar, the parameter differences between the current and target versions are small. Conversely, a large difference indicates a significant parameter change. This difference calculation is used to determine whether the configuration file update can be performed, ensuring the security and effectiveness of the update and preventing system anomalies caused by parameter conflicts.

[0093] Step 144: If the difference is lower than the preset conflict threshold, the configuration file update instruction is split into an interface layout update sub-instruction and a thread pool update sub-instruction, and the interface layout update sub-instruction and the thread pool update sub-instruction are associated with the same version submission record, and the version submission record includes a parameter change timestamp, a parameter effectiveness condition and a version rollback identifier.

[0094] When the calculated difference is lower than the preset conflict threshold, it means that the difference between the parameters of the current version and the target version is within an acceptable range and will not cause serious conflict problems. At this time, the configuration file update instruction is split. Parameter information related to the interface layout is extracted from the configuration file update instruction to form an interface layout update sub-instruction. For example, information such as interface element identification, updated relative position coordinates, and element size ratio coefficients are organized into an instruction set specifically for updating the interface layout. At the same time, parameter information related to the thread pool is extracted, such as the maximum number of concurrent threads, task queue capacity threshold, and asynchronous task scheduling priority weight, to form a thread pool update sub-instruction.

[0095] These two sub-instructions are associated with the same version submission record. The version submission record records detailed information, among which the parameter change timestamp specifies the specific time of the parameter update operation, accurate to the second, so as to facilitate the subsequent tracking and auditing of parameter changes. The parameter effectiveness conditions stipulate under what circumstances these updated parameters will officially take effect. For example, it may be set to take effect after the next system restart, or automatically take effect after a certain period of testing and verification, etc., to ensure that the parameter update process is controllable. The version rollback identifier provides a rollback mechanism for subsequent problems. If an abnormality is found in the system after the update, the identifier can be used to easily restore the parameters to the state before the update, ensuring the stability and reliability of the system. In this way, the update operations of the interface layout and thread pool are integrated into a version submission record, which facilitates the management and maintenance of the system configuration update process.

[0096] Step 145: Execute the grayscale release strategy through the automated deployment pipeline, and inject the interface layout update sub-instruction and the thread pool update sub-instruction into the configuration center of the background management system in sequence according to the preset phased deployment order.

[0097] In one example, a pre-defined phased deployment includes: Step 1451: In the initial deployment phase, the element size ratio coefficient in the interface layout update sub-instruction is interpolated with the current interface layout parameters to generate a transitional interface layout configuration, and the maximum number of concurrent threads in the thread pool update sub-instruction is gradually increased to the target value in a step-by-step manner.

[0098] During the initial deployment phase, for interface layout updates, interpolation is used to generate a transitional interface layout configuration, as directly applying new interface layout parameters may cause significant visual impact and change user behavior. For example, a table element on the "Purchase Order List Page" currently has a width of W1 and a height of H1. However, the element size scaling factors specified in the interface layout update sub-command require a new width of W2 and height of H2. The interpolation logic aims to smoothly transition between the current and target sizes. For example, an interpolation factor λ (0 < λ < 1) is set. Initially, the new width W = (1-λ)*W1 + λ*W2, and the height H = (1-λ)*H1 + λ*H2. As deployment progresses, the value of λ gradually increases, and the size of the table element gradually approaches the target size, thus generating a transitional interface layout configuration that allows users to gradually adapt to the new layout changes.

[0099] For thread pool updates, the maximum number of concurrent threads in the thread pool update sub-instruction is not increased to the target value一次性, but rather in a stepwise increasing manner. For example, if the target maximum number of concurrent threads is N, in the initial stage, the maximum number of concurrent threads is first increased to N1 (N1 < N). After running and monitoring for a period of time to ensure that the system operates stably at this number of concurrent threads, the maximum number of concurrent threads is then increased to N2 (N2 > N1 and N2 < N), and so on, gradually increasing the maximum number of concurrent threads to the target value N. The purpose of this is to avoid suddenly increasing too many concurrent threads, which may cause excessive pressure on system resources, leading to performance problems or system crashes in the system, and to ensure that the system can operate stably during the process of updating the thread pool parameters.

[0100] Step 1452: In the stability verification stage, based on the parameter生效条件 in the version submission record, collect the user operation response time series and the thread pool task backlog volume series under the transitional interface layout configuration, and calculate the joint evaluation index of the response time volatility and the task backlog volume growth rate; if the joint evaluation index meets the preset stability condition, then switch the transitional interface layout configuration to the final interface layout configuration, and lock the target value of the thread pool configuration parameters; package the locked final interface layout configuration and the thread pool configuration parameters into an interactive interface update package, and broadcast the interactive interface update package to the background management system through the distributed synchronization component in the automated deployment pipeline.

[0101] In the stability verification stage, start collecting relevant data according to the parameter生效条件 set in the version submission record. For the transitional interface layout configuration, collect the user operation response time series through the system's log records and monitoring tools. For example, record the time from when the user clicks on a certain interface element until the system gives a corresponding feedback, such as the time from clicking the "Create Purchase Order" button until the order creation success prompt appears, and record these time data in sequence to form a time series. At the same time, collect the thread pool task backlog volume series, that is, record the number of tasks waiting to be processed in the thread pool at each time point, and observe the change in the task backlog over time.

[0102] It should be noted that there is an unclear expression "参数生效条件" in the original text which is directly retained in the translation. It may need to be further clarified in the actual context.Based on the collected data, a joint evaluation metric is calculated for response time volatility and task backlog growth rate. The calculation logic for response time volatility involves first calculating the average of the response time series, then squared the difference between each response time and the average, averaging these squared values, and finally taking the square root of the average to obtain the standard deviation. The ratio of the standard deviation to the average is the response time volatility, which reflects the degree of response time fluctuation. The task backlog growth rate is calculated by calculating the ratio of the difference in task backlog between adjacent time points to the time interval, reflecting the speed of task accumulation. These two metrics are combined using a specific algorithm to produce a joint evaluation metric. For example, a weighting coefficient can be set, multiplying the response time volatility by one weight and the task backlog growth rate by another weight. The two products are then added together to produce the joint evaluation metric.

[0103] If this joint evaluation metric meets the preset stability criteria, it indicates that the system's performance and user experience are in an acceptable and stable state under the transitional interface layout configuration and the current thread pool configuration. At this point, the transitional interface layout configuration is switched to the final interface layout configuration, fixing the interface elements to their final positions and sizes. At the same time, the target values of the thread pool configuration parameters are locked to ensure that the thread pool operates stably in subsequent runs according to the set parameters such as the maximum number of concurrent threads, task queue capacity threshold, and asynchronous task scheduling priority weight.

[0104] Finally, the final, locked-down interface layout and thread pool configuration parameters are packaged into an interactive interface update package. This package, incorporating all optimized configuration information, is broadcast to the backend management system via the distributed synchronization component within the automated deployment pipeline. This distributed synchronization component ensures accurate and efficient transmission of the update package to all nodes and relevant modules within the backend management system, enabling the entire system to apply the latest interface optimization strategies, complete updates to the interface and system response logic, and improve system performance and user experience.

[0105] In a non-limiting embodiment, after the interface optimization strategy is fed back to the background management system of the RPA terminal application, it also includes: monitoring the user interface operation event flow after the implementation of the interface layout adjustment rule, extracting the click frequency sequence and operation interval time series of the optimized interface element identifier; performing time window sliding statistics on the click frequency sequence, generating an interface element heat distribution map, and calculating the response delay variance of adjacent events in the operation interval time series; when it is detected that the response delay variance exceeds a preset fluctuation threshold, based on the interface element heat distribution map, weight correction is performed on the element position mapping table in the interface layout adjustment rule to generate an adaptive interface layout update instruction; the adaptive interface layout update instruction is subjected to secondary strategy fusion with the interface response logic optimization rule to generate optimization configuration information and synchronize it to the real-time strategy thread of the background management system.

[0106] After implementing the interface layout adjustment rules, the system begins continuously monitoring the user interface operation event stream. The system automatically records each user's action on interface elements. For each interface element identifier, it extracts its click frequency sequence and operation interval time sequence. For example, for the "View Attachments" button on the "Purchase Order Details Page," the system records the time each user clicks the button to form a click frequency sequence. It also records the time interval between two consecutive clicks of the button to form an operation interval time sequence.

[0107] Perform a sliding time window statistics on the click frequency series. Set a time window size, such as 1 hour, and count the number of clicks on each interface element within this time window. As time passes, the time window continues to slide, each sliding a smaller time unit, such as 1 minute. Through the above method, the click frequency of each interface element in different time periods is counted, and an interface element heat distribution map is generated. This distribution map intuitively shows the popularity of each interface element at different time points, making it clear at a glance which elements are frequently clicked and which elements are less used.

[0108] At the same time, the response delay variance of adjacent events in the operation interval time series is calculated. For the operation interval time series, the system response delay between two adjacent operations is first calculated, that is, the time difference between the user operation and the system response. Then, following the logic of calculating variance, the average of these delay times is calculated. The square of the difference between each delay time and the average is calculated, and the average of these squared values is calculated to obtain the response delay variance. The variance reflects the degree of fluctuation in the response delay time.

[0109] When it is detected that the response delay variance exceeds the preset fluctuation threshold, it means that there is a problem with the response stability of the system. At this time, the weight of the element position mapping table in the interface layout adjustment rule is corrected based on the interface element heat distribution map. For example, if it is found that some commonly used function buttons in the "Purchase Order Details Page" are clicked frequently, but the response delay variance is large, it means that the position of these buttons may not be reasonable enough, affecting user operations and system responses. According to the heat distribution map, the weights of these popular elements in the element position mapping table are adjusted. For example, the positions of these popular elements are adjusted to areas that are easier for users to operate, and the coordinate information and weight parameters in the element position mapping table are modified accordingly to generate adaptive interface layout update instructions.

[0110] The adaptive interface layout update instruction is combined with the interface response logic optimization rules for a secondary strategy fusion. Analyze the impact of the adaptive interface layout update instruction on the system response logic. For example, the new interface layout may cause the frequency of some operations to change, thereby affecting the load of the background service interface. Based on the above analysis results, the thread pool configuration parameters, asynchronous task scheduling priority weights, etc. in the interface response logic optimization rules are adjusted accordingly. The adjusted interface layout and response logic related information are integrated together to generate optimized configuration information, and synchronized to the real-time strategy thread of the background management system. The real-time strategy thread will apply this optimized configuration information in a timely manner, dynamically adjust the system's operating strategy, further improve the system's performance and user experience, and ensure that the system can be continuously optimized and adjusted according to the user's actual operation situation.

[0111] In a non-limiting embodiment, after the interface optimization strategy is fed back to the background management system of the RPA terminal application, it also includes: collecting the system resource occupancy curve and the task queue accumulation curve after the interface response logic optimization rule takes effect, performing segmented slope fitting on the system resource occupancy curve and the task queue accumulation curve, and extracting the resource consumption feature vector of the target load interval; determining the overload risk level of the thread pool configuration parameters based on the comparison result of the resource consumption feature vector and the preset resource quota indicator; performing back-propagation gradient adjustment on the asynchronous task scheduling priority weight in the interface response logic optimization rule based on the overload risk level to generate a resource balancing scheduling strategy; injecting the resource balancing scheduling strategy into the resource allocator of the background management system, and executing adaptive scaling compensation of the element size ratio coefficient in the interface layout adjustment rule.

[0112] After the UI response logic optimization rules take effect, the system begins collecting relevant data. Using the system's built-in resource monitoring tools, we collect system resource utilization curves and task queue backlog curves. The system resource utilization curve reflects the changing proportion of various system resources (such as CPU and memory) used over time; the task queue backlog curve shows the changing trend in the number of tasks waiting to be processed in the thread pool over time.

[0113] Segmented slope fitting is performed on these two curves. The time axis is divided into multiple time periods. For each time period, the slope of the curve is calculated using a fitting algorithm (such as least squares fitting). The slope reflects the rate of change of resource utilization and task backlog within that time period. This segmented fitting method provides a clearer understanding of the system's resource consumption and task processing status in different time periods.

[0114] From the results of the segmented slope fitting, we extract the resource consumption feature vector for the target load range. The target load range is a predefined time period or load range based on business needs and system performance requirements. Within this range, key information such as the rate of change of resource utilization and the rate of change of task backlog are compiled into a vector, which is the resource consumption feature vector. For example, the resource consumption feature vector can be expressed as (resource utilization change rate, task backlog change rate), which comprehensively reflects the system's resource consumption within the target load range.

[0115] Compare the resource consumption feature vector with the preset resource quota indicator. The preset resource quota indicator is a pre-set standard based on factors such as the system's hardware resources and business requirements, and specifies the upper limit of the system's resource consumption under different circumstances. By comparing each element in the resource consumption feature vector with the corresponding value in the preset resource quota indicator, it is determined whether the system's current resource consumption exceeds the reasonable range.

[0116] Based on the comparison results, the overload risk level of the thread pool configuration parameters is determined. If some values in the resource consumption feature vector approach or exceed the preset resource quota indicators, it indicates that the system is at risk of overload. The overload risk level is divided into different levels, such as low, medium, and high, based on the degree and trend of the excess. For example, if the rate of change of resource utilization approaches but does not exceed the preset indicators, and the rate of change of task backlog is small, the overload risk level is low; if both significantly exceed the preset indicators, the overload risk level is high.

[0117] Based on the overload risk level, the asynchronous task scheduling priority weights in the interface response logic optimization rules are back-propagated and adjusted. The logic of the back-propagation gradient adjustment is to adjust the scheduling priority of different tasks based on the overload risk level. For example, if the overload risk level is high, it means that system resources are tight. In this case, the scheduling priority weights of some non-critical tasks need to be lowered to allocate more resources to critical tasks. In this way, the scheduling strategy of asynchronous tasks is dynamically adjusted, so that system resources can be distributed more evenly, and a resource-balanced scheduling strategy is generated.

[0118] Inject the resource balancing scheduling policy into the backend management system's resource allocator. The resource allocator is responsible for properly allocating system resources to tasks based on the system's current state and task requirements. After injecting the resource balancing scheduling policy, the resource allocator can allocate resources according to the new policy, improving system resource utilization efficiency and avoiding system performance degradation caused by improper resource allocation.

[0119] At the same time, adaptive scaling compensation of the element size ratio coefficient in the interface layout adjustment rules is performed. The element size ratio coefficient in the interface layout adjustment rules is dynamically adjusted based on the usage of system resources and user operation feedback. For example, if system resources are tight, in order to reduce the resource consumption of interface rendering, the size of some non-critical interface elements can be appropriately reduced, and the element size ratio coefficient can be adjusted accordingly. Through the above-mentioned adaptive scaling compensation, while ensuring the basic user operation experience, the use of system resources is further optimized, ensuring that the system can run stably under different load conditions, and improving the overall performance and resource utilization efficiency of the system.

[0120] In a non-limiting embodiment, after the interface optimization strategy is fed back to the background management system of the RPA terminal application, it also includes: obtaining abnormal operation path segments in the optimized interactive behavior data set, identifying isolated interface element identifiers that do not match the preset intention category in the abnormal operation path segments; performing context dependency analysis on the isolated interface element identifiers to generate a potential jump probability matrix of the isolated interface element identifiers and adjacent interface element nodes; generating interface element hiding rules or quick access entry generation rules based on jump edges that exceed a preset probability threshold in the potential jump probability matrix; appending the interface element hiding rules or the quick access entry generation rules to the interface layout adjustment rules, and updating the intra-class discreteness constraint conditions in the operation intention features.

[0121] After obtaining the optimized interactive behavior data set, we conduct in-depth analysis of the data to identify abnormal operation path segments. Abnormal operation path segments are those that deviate from the normal business process operation pattern. For example, in a normal procurement process, users typically follow the path of "Create Purchase Order" -> "Fill in Order Information" -> "Submit Order". However, if an unusual path such as "Create Purchase Order" -> "Go Directly to Inventory Inquiry Page" occurs, this can be considered an abnormal operation path segment.

[0122] In these abnormal operation path fragments, identify isolated interface element identifiers that do not match the preset intent category. The preset intent category is a common operation intent classification determined based on previous intent identification and business analysis. For example, "create purchase order intention", "query inventory intention", etc. If an interface element appears in an abnormal operation path and its operation intent cannot be classified into the preset intent category, it will be regarded as an isolated interface element identifier. For example, in the above abnormal path, the "inventory query page entry" element involved in the operation of "jump directly to the inventory query page" is identified as an isolated interface element identifier if its operation intent does not match the existing preset intent category.

[0123] Perform context dependency analysis on the isolated interface element identifier. Analyze the relationship between the isolated interface element and the adjacent interface element nodes, such as the position relationship in the interface layout, the order of operations, etc. Calculate the potential jump probability of the isolated interface element identifier and the adjacent interface element nodes through a large amount of historical operation data and interface structure information. For example, count the number of times in past operations that jumped from a certain element of the "Purchase Order Creation Page" to the "Inventory Query Page Entry", as well as the number of times that the "Purchase Order Creation Page" jumped to other adjacent elements, and calculate the probability of jumping from the relevant elements of the "Purchase Order Creation Page" to the "Inventory Query Page Entry" through these data. Organize all jump probabilities related to the isolated interface element identifier into a matrix, namely the potential jump probability matrix.

[0124] Based on jump edges in the potential jump probability matrix that exceed a preset probability threshold, rules for hiding interface elements or creating quick access portals are generated. The preset probability threshold is a standard set based on business needs and user behavior analysis. If the probability of a jump edge exceeds this threshold, it indicates that the jump operation is common and important. For example, if the probability of jumping from the "Purchase Order Creation Page" to the "Inventory Query Page Entry" is high, exceeding the preset probability threshold, a quick access portal creation rule may be generated to add a more prominent quick access button for the "Inventory Query Page Entry" on the "Purchase Order Creation Page" to facilitate user access. Conversely, if the probability of a jump edge is very low and the interface element has little impact on the business process, an interface element hiding rule may be generated to hide the interface element from the interface layout to simplify the interface and reduce user interaction.

[0125] Append the generated interface element hiding rules or quick access entry generation rules to the interface layout adjustment rules. For example, if a quick access entry generation rule is generated, the element position mapping table in the interface layout adjustment rule clearly indicates the location of the newly added quick access button. If it is an interface element hiding rule, record the identifier of the interface element to be hidden and the conditions or timing for hiding. Through the above methods, the interface layout adjustment rules can be further improved to better adapt to optimized user operation behaviors.

[0126] At the same time, the intra-class dispersion constraints in the operation intention features are updated. Due to the discovery of new abnormal operation paths and isolated interface elements, the original operation intention classification may need to be further refined or adjusted. The intra-class dispersion constraints are used to measure the similarity between individual operation behaviors within the same operation intention category. Based on the new situation, the intra-class dispersion constraints are updated. For example, if the behavioral differences within a certain operation intention category increase due to the discovery of newly discovered isolated interface elements, the intra-class dispersion constraints for that category are appropriately relaxed. Conversely, if it is discovered that some previously scattered operation behaviors can be classified into a new, more specific intent category, the intra-class dispersion constraints for the relevant category are tightened. Through these updates, the operation intention features can more accurately reflect the user's actual operation behavior patterns, providing more precise data support for subsequent interface optimization and system performance improvement, and further improving the optimization strategy and user experience of the entire supply chain business processing RPA terminal application.

[0127] The above content comprehensively and in-depth demonstrates the complete process from acquiring interactive behavior data sets from RPA terminal applications, through behavioral trajectory analysis, generating interface optimization strategies, feeding these strategies back to the backend management system, and subsequently conducting continuous monitoring and optimization adjustments. This design improves the performance, user-friendly interface, and understanding and responsiveness of RPA terminal applications for supply chain business processing, ensuring efficient and stable system operation, meeting the complex and ever-changing needs of supply chain operations, and achieving business process optimization and digital transformation for enterprises.

[0128] In some embodiments, for the training of intent recognition models, the transfer learning framework of pre-trained models such as BERT can be used to fine-tune the intent labels of user operation sequences, combine operational semantic encoding and time interval encoding to construct multimodal input, and use the cross-attention layer in the Transformer architecture to achieve cross-modal fusion, thereby generating an operation intention description vector. For the path loop feature extraction of the interface flow topology graph, reference can be made to graph embedding algorithms (such as Node2Vec) and graph pattern mining techniques to convert the node degree distribution and loop structure into a low-dimensional vector representation. The thread pool parameter configuration can be based on the queuing theory model and load prediction algorithm, fitting the Poisson distribution or Markov chain through the historical response time series, and dynamically calculating the maximum concurrency in combination with the response delay threshold.

[0129] In other embodiments, interface layout coordinate normalization can adopt responsive design principles, using adaptive scaling algorithms based on screen resolution (such as CSS media query logic) to achieve multi-terminal adaptation. Spatial encoding can map two-dimensional coordinates into a one-dimensional sequence using the Hilbert curve or Z-order. Hash difference assessment can draw on the Sim Hash algorithm to calculate the Hamming distance, combined with a sliding window mechanism to set a dynamic conflict threshold. Grayscale release strategies can rely on Kubernetes' rolling update mechanism, using Prometheus to collect system metrics in real time, and integrating the Istio service mesh to implement phased traffic switching.

[0130] In some other embodiments, resource balancing scheduling can incorporate a reinforcement learning framework, using system resource utilization as the state and thread priority adjustment as the action, and iteratively optimizing the strategy through a Q-learning algorithm. Abnormal path detection can employ an isolation forest algorithm to identify nodes that deviate from the mainstream operating pattern, combined with a hidden Markov model (HMM) to calculate a jump probability matrix.

[0131] The embodiment of the present application first obtains the interactive behavior data set of the RPA terminal application within a preset time window, and then performs behavioral trajectory analysis on the interactive behavior data set, accurately extracts the interface flow characteristics and operation intention characteristics of each interactive behavior sequence in the interactive behavior data set, and deeply analyzes the interactive behavior between the user and the system from different angles, providing strong support for understanding the user's operation mode and needs. Then, based on the correlation between the interface flow characteristics and the operation intention characteristics, an interface optimization strategy covering interface layout adjustment rules and interface response logic optimization rules is generated, which can optimize the interactive interface in a targeted manner, improve the convenience of user operation and the rationality of system response. Finally, the interface optimization strategy is fed back to the background management system, so that the RPA terminal application can make timely adjustments, continuously optimize the interactive process, and enhance the interactive usability and timeliness of the system.

[0132] In summary, the embodiments of the present application obtain interactive behavior data sets, perform behavioral trajectory analysis, generate interface optimization strategies, and feed back to the backend management system, thereby effectively solving the problems of insufficient design and optimization of existing RPA application interactive interfaces and improving the interface usability and system responsiveness.

[0133] See also Figure 2 As shown in FIG. 1 , this figure is a schematic diagram of the basic structure of a computer device 200 provided in an embodiment of the present application. The computer device 200 includes: Processor 201; a storage device 202 having a computer program 2020 stored thereon; When the computer program 2020 is executed by the processor 201, the processor 201 implements any of the terminal application behavior data analysis methods.

[0134] Based on the above, a readable storage medium is provided, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the above method are implemented.

[0135] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the systems or devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

Claims

1. A terminal application behavior data analysis method, characterized in that: include: Obtaining a set of interactive behavior data of an RPA terminal application within a preset time window, wherein the interactive behavior data set includes multiple interactive behavior sequences, each of which includes at least one user interface operation event and a corresponding system response event; Performing behavior trajectory analysis on the interaction behavior data set to extract interface flow features and operation intention features of each interaction behavior sequence; Generate an interface optimization strategy based on the correlation between the interface flow characteristics and the operation intention characteristics, the interface optimization strategy including interface layout adjustment rules and interface response logic optimization rules; Feedback the interface optimization strategy to the backend management system of the RPA terminal application.

2. The terminal application behavior data analysis method according to claim 1, characterized in that: The performing behavior trajectory analysis on the interaction behavior data set to extract interface flow features and operation intention features of each interaction behavior sequence includes: For each user interface operation event in the interactive behavior sequence, identify the interface element identifier and operation trigger timestamp corresponding to the user interface operation event, and generate an interface flow path based on the interface element identifier and the operation trigger timestamp; performing sequence segmentation processing on the interface flow path to obtain a plurality of interface flow sub-paths, each interface flow sub-path comprising at least two consecutive user interface operation events; Call the pre-trained intent recognition model to perform contextual analysis on the user interface operation events in each interface flow sub-path, and generate an operation intention description vector for each interface flow sub-path; According to the path topology structure of the interface flow path and the distribution pattern of the operation intention description vector, the interface flow features and the operation intention features of the interaction behavior sequence are extracted.

3. The terminal application behavior data analysis method according to claim 2, characterized in that: The pre-trained intent recognition model is called to perform context association analysis on the user interface operation events in each interface flow sub-path, and generate an operation intention description vector for each interface flow sub-path, including: Obtaining an interface element type and an operation type of each user interface operation event in the interface flow subpath, and generating an operation semantic code based on the interface element type and the operation type; Discretely encode the time intervals between adjacent user interface operation events in the interface flow rotor path to generate a time interval code sequence; The operational semantic coding and the time interval coding sequence are input into the intention recognition model, and the operational semantic coding and the time interval coding sequence are cross-modally fused through the multi-layer attention mechanism in the intention recognition model to generate an operational intention description vector of the interface flow sub-path.

4. The terminal application behavior data analysis method according to claim 3, characterized in that: Extracting the interface flow features and the operation intention features of the interaction behavior sequence based on the path topology structure of the interface flow path and the distribution pattern of the operation intention description vector includes: Traversing all interface element identifiers in the interface flow path, generating an interface element node set and an inter-node jump relationship set, and generating an interface flow topology graph according to the interface element node set and the jump relationship set; Extracting graph structure features from the interface flow topology graph to obtain node degree distribution features and path loop features of the interface flow topology graph; Performing cluster analysis on the operation intention description vector to determine the cluster center distribution and intra-class dispersion of the operation intention description vector in the feature space; The node degree distribution features, the path loop features, the cluster center distribution and the intra-class dispersion are spliced together to obtain the interface flow features and operation intention features of the interactive behavior sequence.

5. The terminal application behavior data analysis method according to claim 1, characterized in that: The generating of the interface optimization strategy according to the correlation between the interface flow characteristics and the operation intention characteristics includes: Determining a frequent interface jump path based on the path loop feature in the interface flow feature, and generating an interface layout adjustment rule according to the start interface element identifier and the end interface element identifier of the frequent interface jump path; Determine a target operation intention category based on the cluster center distribution in the operation intention feature, and generate an interface response logic optimization rule according to the operation trigger timestamp of the interface flow sub-path corresponding to the target operation intention category; The interface layout adjustment rules and the interface response logic optimization rules are sorted by policy priority to generate the interface optimization policy.

6. The terminal application behavior data analysis method according to claim 5, characterized in that: The generating of the interface layout adjustment rule according to the start interface element identifier and the end interface element identifier of the frequent interface jump path includes: Extracting first interface area coordinates corresponding to the starting interface element identifier and second interface area coordinates corresponding to the ending interface element identifier from the frequent interface jump path; Calculating a spatial distance between the coordinates of the first interface area and the coordinates of the second interface area, and determining an optimization direction of the interface element layout according to the spatial distance; An interface element position mapping table is generated based on the interface element layout optimization direction, where the interface element position mapping table is used to indicate the relative position relationship between the starting interface element identifier and the ending interface element identifier in the updated interface layout.

7. The terminal application behavior data analysis method according to claim 5, characterized in that: The generating of the interface response logic optimization rule according to the operation triggering timestamp of the interface flow sub-path corresponding to the target operation intention category includes: Counting the average response time intervals between adjacent user interface operation events in all interface flow sub-paths corresponding to the target operation intention category; Determining a response delay threshold of a system response event according to the average response time interval; An asynchronous task scheduling rule is generated based on the response delay threshold, and the asynchronous task scheduling rule is used to adjust the background resource allocation priority of the system response event.

8. The terminal application behavior data analysis method according to claim 7, characterized in that: Generating an asynchronous task scheduling rule based on the response delay threshold includes: Identify the background service interface associated with the system response event, and obtain the historical response time series of the background service interface; The maximum number of concurrent threads is determined based on the fluctuation range of the historical response time series and the response delay threshold, and thread pool configuration parameters are generated. The thread pool configuration parameters include the maximum number of concurrent threads and the task queue capacity threshold. The thread pool configuration parameters are used to adjust the concurrent processing capability of the background service interface.

9. The terminal application behavior data analysis method according to claim 1, characterized in that: Feedback of the interface optimization strategy to the backend management system of the RPA terminal application includes: Perform parameter alignment processing on the interface element position mapping table in the interface layout adjustment rule and the thread pool configuration parameters in the interface response logic optimization rule, extracting an interface layout parameter set and a thread pool parameter set, wherein the interface layout parameter set includes an interface element identifier, an updated relative position coordinate, and an element size ratio coefficient, and the thread pool parameter set includes a maximum number of concurrent threads, a task queue capacity threshold, and an asynchronous task scheduling priority weight; Normalizing the relative position coordinates in the interface layout parameter set, performing multi-dimensional feature concatenation on the normalized interface layout parameters and the task queue capacity threshold in the thread pool parameter set, and generating a configuration file update instruction containing a unified dimensional index, wherein the multi-dimensional feature concatenation includes: spatially encoding the relative position coordinates according to the topological sorting of the interface element identifiers, and linearly combining them with the asynchronous task scheduling priority weights in the thread pool parameter set according to a preset weight ratio; Input the configuration file update instruction into the version control service, calculate the parameter hash value of the interface layout parameter set and the thread pool parameter set respectively through the parameter hash generator in the version control service, and compare the difference between the parameter hash value of the current version and the parameter hash value of the target version; If the difference is lower than a preset conflict threshold, the configuration file update instruction is split into an interface layout update sub-instruction and a thread pool update sub-instruction, and the interface layout update sub-instruction and the thread pool update sub-instruction are associated with the same version submission record, and the version submission record includes a parameter change timestamp, a parameter effectiveness condition, and a version rollback identifier; Executing the grayscale release strategy through the automated deployment pipeline, injecting the interface layout update sub-instruction and the thread pool update sub-instruction into the configuration center of the background management system in sequence according to the preset phased deployment order; in: In the initial deployment phase, the element size ratio coefficient in the interface layout update sub-instruction is interpolated with the current interface layout parameters to generate a transitional interface layout configuration, and the maximum number of concurrent threads in the thread pool update sub-instruction is gradually increased to the target value in a step-by-step manner; During the stability verification phase, based on the parameter validation conditions in the version submission record, the user operation response time series and thread pool task backlog series under the transition interface layout configuration are collected, and a joint evaluation indicator of response time fluctuation rate and task backlog growth rate is calculated; If the joint evaluation index meets the preset stability condition, the transition interface layout configuration is switched to the final interface layout configuration, and the target value of the thread pool configuration parameter is locked; the locked final interface layout configuration and thread pool configuration parameters are encapsulated into an interactive interface update package, and the interactive interface update package is broadcast to the background management system through the distributed synchronization component in the automated deployment pipeline.

10. A computer device, characterized in that: include: processor; A storage device having a computer program stored thereon, wherein when the computer program is executed by the processor, the processor implements the terminal application behavior data analysis method as described in any one of claims 1 to 9.

Images