Session file processing method, device, apparatus and medium

Abstract

The application provides a conversation file processing method and device, equipment and medium, and relates to the technical field of computers. The method comprises the following steps: in response to a recording request of a conversation page triggered by a user, acquiring path information of the conversation page; then based on the path information, collecting a DOM change event of the conversation page including changes of page DOM tree nodes or changes of cursors; wherein the nodes correspond to page elements in the conversation page. Next, only the Data field carrying specific change content in the DOM change event is compressed to obtain a compressed file. Finally, in response to an end recording request of the conversation page triggered by the user, the compressed file is uploaded to a server as a conversation recording file. Through the above method, the storage space occupation and network transmission overhead of the conversation recording file are greatly reduced, the plaintext readability of key metadata such as event type and timestamp is maintained to maintain efficient index query capability, and the storage efficiency and query performance are effectively balanced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and medium for processing session files. Background Technology

[0002] In enterprise web applications, recording and replaying complete session files of user actions is a key means of optimizing user experience, tracking abnormal operations, and meeting regulatory requirements.

[0003] Existing methods for processing session files primarily include recording based on the Document Object Model (DOM) and incremental changes. This involves the client calling the `record()` function to initiate recording, generating both full snapshot change events and incremental snapshot change events. These change events are then either fully compressed or uploaded to the server in real-time or in batches as raw JSON data via Hypertext Transfer Protocol (HTTP). During playback, all change events are retrieved at once (compressed data is decompressed first) and then played back sequentially by the player.

[0004] However, whether to fully compress or not compress change events leads to a dilemma in the existing session file processing methods, where storage efficiency and query performance are always at odds. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for processing session files, in order to solve the technical problem in the prior art that it is difficult to balance the reliability of data transmission and the efficiency of storage and retrieval of session recording files.

[0006] In a first aspect, embodiments of this application provide a method for processing session files, including:

[0007] In response to a user-triggered recording request for a session page, the path information of the session page is obtained;

[0008] Based on the path information, document object model (DOM) change events of the session page are collected; wherein, the DOM change events include changes in the page DOM tree nodes corresponding to the session page or cursor changes, the nodes correspond to page elements in the session page, and the page elements include at least one of text boxes, buttons, images, lists, pop-ups, or container nodes;

[0009] Selective field compression is performed on the DOM change event to obtain a compressed file; wherein, the selective field compression includes compressing only the Data field in the DOM change event, the Data field being used to carry the specific change content of the DOM change event;

[0010] In response to a user-triggered request to end recording of a session page, the compressed file is uploaded to the server as a session recording file.

[0011] In one possible implementation, the step of uploading the compressed file as a session recording file to the server based on the user-triggered session page recording end request includes:

[0012] In response to the recording end request, the compressed file is stored in a pre-configured buffer;

[0013] When the number of compressed files in the buffer is greater than or equal to a preset threshold, the session recording file is uploaded to the server through the target transmission channel.

[0014] In one possible implementation, the method further includes:

[0015] If the byte length of the compressed file in the buffer is less than the preset payload threshold, then the sendBeacon channel is determined as the target transmission channel;

[0016] If the byte length is greater than or equal to the preset payload threshold, or if the transmission of the session recording file through the sendBeacon channel fails, then the POST channel will be determined as the target transmission channel.

[0017] In one possible implementation, before collecting DOM change events of the session page based on the path information, the method further includes:

[0018] The path information is verified based on a pre-acquired path information database to obtain the verification result;

[0019] When the verification result is passed, the DOM change event and the page snapshot attribute information corresponding to the session page are collected;

[0020] The path information database includes multiple blacklisted path information and whitelisted path information. The blacklisted path information is used to indicate page paths where the collection of DOM change events is prohibited, and the whitelisted path information is used to indicate page paths where the collection of DOM change events is allowed. The page snapshot attribute information includes the Uniform Resource Locator URL of the session page, the screen size of the device displaying the session page, and the user agent information used to access the session page.

[0021] In one possible implementation, the step of verifying the path information based on a pre-acquired path information database to obtain a verification result includes:

[0022] If the path information matches at least one whitelisted path and does not match any blacklisted path, then the verification result is determined to be passed.

[0023] If the path information matches at least one blacklisted path, or does not match any whitelisted path, then the verification result is determined to be unsuccessful.

[0024] In one possible implementation, the method further includes:

[0025] During the collection of the DOM change events, the visibility duration of the DOM change events and the total session duration are obtained;

[0026] The visible duration is used to indicate the cumulative duration of the session page while it is in the foreground active state, and the total session duration is used to indicate the duration from the start of collecting the DOM change events to the receipt of the recording end request.

[0027] In one possible implementation, after the session recording file is uploaded to the server, the method further includes:

[0028] If the number of compressed files in the buffer is less than a preset threshold, then the compressed files are deleted.

[0029] In one possible implementation, the method further includes:

[0030] In response to a user-triggered playback request for a session recording file, the playback speed is calculated based on the visible duration and the total session duration.

[0031] The total session duration is divided into multiple time periods based on the playback speed.

[0032] The session recording files corresponding to each time period are decompressed in parallel to obtain multiple decompressed files, and the session recording files are then visualized and played back based on the multiple decompressed files.

[0033] In one possible implementation, dividing the total session duration into multiple time periods based on the playback speed includes:

[0034] Based on the playback speed, the preset base time window length is scaled to obtain the target time window length;

[0035] The total session duration is divided into multiple time segments by using the target time window length.

[0036] In one possible implementation, the DOM change event further includes an event type and a timestamp, and the visualization playback based on the plurality of decompressed files includes:

[0037] The multiple decompressed files are sorted in ascending order according to their timestamps to obtain a merge event sequence;

[0038] The merged event sequence is loaded into a pre-instantiated playback player to perform visual playback of the session recording file.

[0039] Secondly, embodiments of this application provide a session file processing apparatus, including:

[0040] The first processing module is used to obtain the path information of the session page in response to a user-triggered recording request for the session page.

[0041] The second processing module is used to collect Document Object Model (DOM) change events of the session page based on the path information; wherein, the DOM change events include changes in the page DOM tree nodes corresponding to the session page or cursor changes, the nodes correspond to page elements in the session page, and the page elements include at least one of text boxes, buttons, images, lists, pop-ups, or container nodes;

[0042] The third processing module is used to perform selective field compression processing on the DOM change event to obtain a compressed file; wherein, the selective field compression processing includes compressing only the Data field in the DOM change event, the Data field being used to carry the specific change content of the DOM change event;

[0043] The fourth processing module is used to respond to the user-triggered end-of-recording request of the session page and upload the compressed file as a session recording file to the server.

[0044] In one possible implementation, the fourth processing module is specifically used for:

[0045] In response to the recording end request, the compressed file is stored in a pre-configured buffer;

[0046] When the number of compressed files in the buffer is greater than or equal to a preset threshold, the session recording file is uploaded to the server through the target transmission channel.

[0047] In one possible implementation, the device further includes a fifth processing module for:

[0048] If the byte length of the compressed file in the buffer is less than the preset payload threshold, then the sendBeacon channel is determined as the target transmission channel;

[0049] If the byte length is greater than or equal to the preset payload threshold, or if the transmission of the session recording file through the sendBeacon channel fails, then the POST channel will be determined as the target transmission channel.

[0050] In one possible implementation, the device further includes a sixth processing module for:

[0051] The path information is verified based on a pre-acquired path information database to obtain the verification result;

[0052] When the verification result is passed, the DOM change event and the page snapshot attribute information corresponding to the session page are collected;

[0053] The path information database includes multiple blacklisted path information and whitelisted path information. The blacklisted path information is used to indicate page paths where the collection of DOM change events is prohibited, and the whitelisted path information is used to indicate page paths where the collection of DOM change events is allowed. The page snapshot attribute information includes the Uniform Resource Locator URL of the session page, the screen size of the device displaying the session page, and the user agent information used to access the session page.

[0054] In one possible implementation, the sixth processing module is specifically used for:

[0055] If the path information matches at least one whitelisted path and does not match any blacklisted path, then the verification result is determined to be passed.

[0056] If the path information matches at least one blacklisted path, or does not match any whitelisted path, then the verification result is determined to be unsuccessful.

[0057] In one possible implementation, the device further includes a seventh processing module for:

[0058] During the collection of the DOM change events, the visibility duration of the DOM change events and the total session duration are obtained;

[0059] The visible duration is used to indicate the cumulative duration of the session page while it is in the foreground active state, and the total session duration is used to indicate the duration from the start of collecting the DOM change events to the receipt of the recording end request.

[0060] In one possible implementation, the device further includes an eighth processing module, configured to delete the compressed files if the number of compressed files in the buffer is less than a preset threshold.

[0061] In one possible implementation, the device further includes a ninth processing module for:

[0062] In response to a user-triggered playback request for a session recording file, the playback speed is calculated based on the visible duration and the total session duration.

[0063] The total session duration is divided into multiple time periods based on the playback speed.

[0064] The session recording files corresponding to each time period are decompressed in parallel to obtain multiple decompressed files, and the session recording files are then visualized and played back based on the multiple decompressed files.

[0065] In one possible implementation, the ninth processing module is specifically used for:

[0066] Based on the playback speed, the preset base time window length is scaled to obtain the target time window length;

[0067] The total session duration is divided into multiple time segments by using the target time window length.

[0068] In one possible implementation, the DOM change event further includes an event type and a timestamp, and the ninth processing module is specifically used for:

[0069] The multiple decompressed files are sorted in ascending order according to their timestamps to obtain a merge event sequence;

[0070] The merged event sequence is loaded into a pre-instantiated playback player to perform visual playback of the session recording file.

[0071] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0072] The memory stores computer-executed instructions;

[0073] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0074] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0075] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0076] This application provides a method, apparatus, device, and medium for processing session files. After a user triggers a recording request for a session page, the path information of the session page is obtained. Then, based on the path information, DOM change events, including changes in page DOM tree nodes (nodes corresponding to page elements in the session page, such as text boxes, buttons, images, lists, pop-ups, or container nodes) or cursor changes, are collected from the session page. Then, selective field compression processing is performed on the DOM change events, that is, only the Data field in the DOM change events is compressed to obtain a compressed file. Finally, after the user triggers a session page recording end request, the compressed file is uploaded to the server as the session recording file. By selectively compressing the Data field in the DOM change events, rather than compressing the entire event, the data volume and transmission overhead are significantly reduced while preserving the plaintext readability of key metadata such as event type and timestamp. This allows the server to continue using these metadata fields to build indexes to support efficient retrieval, thus effectively balancing storage efficiency and query performance. Attached Figure Description

[0077] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0078] Figure 1 A flowchart illustrating a session file processing method provided in this application. Figure 1 ;

[0079] Figure 2 A flowchart illustrating a session file processing method provided in this application. Figure 2 ;

[0080] Figure 3 A flowchart illustrating a session file processing method provided in this application. Figure 3 ;

[0081] Figure 4 A schematic diagram of a session file processing device provided in this application;

[0082] Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application.

[0083] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0084] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0085] The application background of this application is explained as follows:

[0086] In enterprise-level web application scenarios, recording and replaying complete session files of user actions has become a key measure to optimize user experience, accurately locate abnormal operations, and meet regulatory compliance requirements. Existing methods for processing session files mainly include the following categories:

[0087] (1) Recording method based on DOM changes and incremental changes. This method is usually based on the open-source rrweb framework. It continuously listens for DOM changes through MutationObserver, serializes the initial state of the page into a complete DOM snapshot, and continuously records subsequent incremental change events (including mouse movement, click, scrolling, input, etc.) to form a timestamped event sequence. During playback, the user operation process is restored by reconstructing the DOM and replaying the events in chronological order.

[0088] The core of this solution lies in DOM serialization and virtual DOM reconstruction algorithms, which typically only provide client-side recording and playback capabilities, lacking integrated functionality with enterprise-level backend management systems, permission systems, large-scale data storage, and transmission optimization. Specifically, before uploading the recorded session files to the server, this method either fully compresses change events or does not compress them at all. This results in the timestamps in the event sequence being compressed, hindering efficient retrieval, and also significantly increases storage costs due to the massive volume of original data. Furthermore, it lacks automatic desensitization and masking of sensitive information (such as passwords and ID numbers) during recording, and lacks necessary traffic diversion strategies during transmission, causing storage costs to skyrocket linearly with data volume. Moreover, it is highly susceptible to data loss and bandwidth waste in weak network environments.

[0089] (2) The video recording-based method mainly uses the Canvas or MediaRecorder application programming interface to encode the page rendering result into a video stream for storage. The advantage of this method is that the playback is intuitive, but its limitations are also very prominent: the data volume is huge, it is difficult to accurately restore the DOM interaction details, the retrieval capability is insufficient, the playback speed does not match the user's actual effective operation time, and the handling of privacy-sensitive information is relatively weak.

[0090] (3) Some commercial SaaS session playback products can provide a complete recording-storage-playback link for processing session files, but most of them are closed-source cloud services, do not support private deployment, and have limited deep integration capabilities with enterprise internal permission systems and business menu systems.

[0091] In view of this, existing methods for processing session files cannot achieve an effective balance between storage efficiency and query performance. If the entire event sequence is compressed, the timestamp field cannot be used as an index for retrieval, resulting in low efficiency for queries by time range. If compression is not performed, although the indexing capability of the timestamp field can be preserved to maintain the efficiency of time range queries, the original data volume is enormous, and storage costs will increase non-linearly with the expansion of data scale, which is also unsustainable in engineering practice. Therefore, providing a method for processing session files that can achieve an effective balance between storage efficiency and query performance is an urgent technical problem to be solved.

[0092] In addition, existing methods for processing session files have at least the following drawbacks:

[0093] (1) The compressed event data is uploaded to the server in real time or in batches via HTTP request. This upload method lacks a reliable request keep-alive mechanism when the page is unloaded. If the user closes the browser tab, the ongoing HTTP request will be interrupted, and the session end event and session end signal cannot be reliably delivered to the server.

[0094] (2) Long session playback loads slowly. When a single session lasts for a long time and the number of events is large, the playback end may cause interface timeout and browser memory overflow when it pulls all events at once. Users need to wait for a long time before they can start playing back the session recording file.

[0095] (3) The lack of automatic desensitization and masking of sensitive information (such as passwords and ID numbers) during the recording process makes the recording scope uncontrollable, which increases the security risk of privacy leakage and reduces the business value and usability of the recorded data.

[0096] (4) Invalid sessions occupy storage resources. Low-value sessions (with very few events) generated when users accidentally open a session page and then immediately close it cannot be automatically identified and cleaned up, resulting in a waste of storage space.

[0097] (5) The playback speed does not match the actual effective operation time of the user. The total session duration includes the time when the page is hidden (such as switching tabs or minimizing windows). Playing back directly at the original speed will cause the operation rhythm to deviate from the actual user's perception.

[0098] (6) Users cannot search and filter session recording files by business system or menu dimension, and can only selectively decide which session recording files need to be played back.

[0099] Based on the aforementioned technical problems, the inventors, in researching how to achieve an effective balance between storage efficiency and query performance for session recording files, discovered that selective field compression of the acquired DOM change events—that is, compressing only the Data field in the DOM change events while retaining metadata such as event type and timestamp as plaintext values—avoids the dilemma of timestamps becoming unindexable due to full compression. Furthermore, by selectively compressing the Data field, which constitutes the largest portion of the data, overall data redundancy is significantly reduced. This achieves a linear decrease in storage costs with almost no loss in query performance, effectively resolving the contradiction between storage efficiency and query performance. Based on this, this application provides a method, apparatus, device, and medium for processing session files.

[0100] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0101] Figure 1 A flowchart illustrating a session file processing method provided in this application. Figure 1 The execution entity of this method can be the client's session processing module, such as... Figure 1 As shown, the processing method for this session file includes a recording method, specifically including:

[0102] S101: In response to a user-triggered recording request for a session page, obtain the path information of the session page.

[0103] In this step, the session page refers to the page targeted by the user's session page recording request, and is the object for subsequent collection of DOM change events. The path information is used to uniquely identify the location of the user's current session page, serving as the basis for determining the recording object and collection scope. Specifically, it is represented by the path portion or route identifier of the Uniform Resource Locator (URL). This path information reflects the specific business function module or menu level accessed by the user in the business system, such as the pathname field obtained in a Single Page Application (SPA).

[0104] For example, when a user navigates to a session page, the business web front-end application React, which has a pre-embedded recording software development kit (SDK), mounts the corresponding component according to the route. The session page renders a complete view containing the recording control. At this time, the user can trigger a recording request on the session page by clicking the recording control. In response to the recording request, the recording module rrweb-sdk in the session processing module synchronously reads the path information of the session page from the scope of the currently mounted React component.

[0105] Understandably, the acquisition of path information actually occurs earlier in the component mounting phase. Specifically, when React mounts the corresponding component based on the route, route hooks such as `useParams` and `useLocation`, or the initialization logic within the React component, have already extracted key path metadata such as the session identifier, business directory, and callback address of the current session page and saved it to the component's state or context. Therefore, after the user triggers a recording request, the recording module `rrweb-sdk` in the session processing module can directly and synchronously read the path information from the scope of the currently mounted React component.

[0106] By obtaining the path information of the session page after the session page recording request is triggered, the subsequent collection of DOM change events has a clear page ownership condition, which provides a basis for the subsequent generation and uploading of session recording files.

[0107] S102: Based on path information, collect DOM change events of the session page; wherein, DOM change events include changes in the page DOM tree nodes corresponding to the session page or cursor changes, the nodes correspond to page elements in the session page, and the page elements include at least one of text boxes, buttons, images, lists, pop-ups or container nodes.

[0108] In this step, DOM change events record discrete states when the internal structure or interactive state of the session page changes. DOM change events mainly include two categories: one is changes to the page's DOM tree nodes, such as adding, deleting, modifying attributes, or changing text content of nodes. These nodes correspond to page elements such as text boxes, buttons, images, lists, pop-ups, tables, or container nodes in the session page; the other is changes to the cursor in the session page, including related interactive behaviors such as mouse cursor movement, mouse clicks, and mouse wheel scrolling.

[0109] For example, in a business React application with an embedded recording SDK, the RRWebRecorder recording component, as a specially encapsulated React component, has the core responsibility of managing the entire lifecycle of the session recording function, from initialization upon mounting to resource release upon unmounting. After the React component is mounted, it can use the rrweb.record() method to register an emit callback function to listen to the DOM tree and capture at least one of the aforementioned DOM change events. Each captured DOM change event is stored in structured data format, including at least the event type, timestamp, and a Data field carrying the specific change content.

[0110] The event type identifies the type of interaction or change corresponding to the DOM change event, determining how to interpret the content in the Data field. Event types mainly include two categories: one is DOM structure changes captured by MutationObserver, such as node addition (childList), attribute modification (attributes), or character data change (characterData); the other is user interaction behaviors collected by event listeners, such as clicks, scrolls, mouse moves, inputs, focus, or blurs. The timestamp records the specific moment the change event occurred, usually stored as a high-precision millisecond value or an offset relative to the recording start time, ensuring all change events are arranged in strict chronological order for accurate playback. The Data field carries the specific change content. For example, for a DOM node addition event, the Data field can include a serialized snapshot of the added node and its position index within its parent node; for an attribute modification event, the Data field can include the name of the modified attribute and its previous and current values; for mouse interaction events, the Data field can include the cursor's coordinates on the page, the path of the clicked DOM element, and key press information.

[0111] Together, these three elements constitute a complete change event record. The event type indicates "what happened," the timestamp indicates "when it happened," and the Data field answers "what the specific details were," thus fully preserving every change on the session page and providing a reliable data foundation for subsequent accurate playback.

[0112] S103: Perform selective field compression on DOM change events to obtain a compressed file; wherein, selective field compression includes compressing only the Data field in the DOM change event, the Data field being used to carry the specific change content of the DOM change event.

[0113] In this step, selective field compression refers to the optimized encoding of the data structure of DOM change events. Its core is to compress only a specific part (Data field) of the change event, rather than compressing the entire event object.

[0114] The Data field stores the specific details of the DOM change content and is the largest and most information-entropy part of the event. During compression, the collected DOM change events are traversed, retaining metadata such as the event type (evevt_type) and timestamp as plaintext values. Only the Data field content is extracted and compressed using a preset compression algorithm, such as Gzip, Brotli, or LZ4, a common lossless compression algorithm. Brotli offers a higher compression ratio but has a slightly higher Central Processing Unit (CPU) overhead; LZ4 is faster but has a lower compression ratio. For example, the compression process can be represented as: CompressedData = Compress(Event.Data), where Event.Data represents the Data field in the DOM change event; Compress() represents the selected compression function; and CompressedData represents the data in the compressed file.

[0115] In one possible implementation, the compressed binary data is divided into blocks (e.g., 8KB) and then Base64 encoded to avoid stack overflow caused by calling `apply` on a large array at once, ultimately resulting in a compressed file. Understandably, calling `apply` on all bytes at once is equivalent to pushing all parameters onto the JavaScript engine's call stack simultaneously. When the array length exceeds the JavaScript engine's capacity limit (e.g., hundreds of thousands of parameters), an error exceeding the maximum call stack size will be triggered.

[0116] By selectively compressing fields of DOM change events, the storage volume of a single event is reduced by 60% to 80%. At the same time, the plaintext storage of timestamps and event types can be used to build indexes, supporting efficient range queries by time window, ensuring the efficiency of database index queries, and providing a foundation for subsequent segmented playback, so that storage efficiency and query performance are no longer mutually restrictive.

[0117] S104: In response to the user-triggered request to end the recording of the session page, upload the compressed file as the session recording file to the server.

[0118] A recording end request is a command signal to terminate the current session recording. It can be triggered by the user, such as clicking the stop recording button or closing the browser tab. In response to this recording end request, sessions / end is sent via sendBeacon. The recording module rrweb-sdk in the session processing module encapsulates the previously generated compressed file into a session recording file. This file, along with the session recording file's identity (ID), is uploaded via a network communication interface using network protocols that support real-time bidirectional communication, such as HTTP, WebSocket (high reliability but high resource consumption), or IndexedDB (suitable for unstable network environments), or via the Service Worker backend (high deployment cost). The uploaded data is then uploaded to the event table rrweb_events_v1 of the server-side MySQL database responsible for receiving, storing, and managing session data, to support subsequent retrieval, analysis, or playback.

[0119] The session file processing method provided in this application embodiment is executed by the client's session processing module. The method includes: in response to a user-triggered recording request for the session page, first obtaining the path information of the current session page, and then, based on this path information, starting to collect DOM change events of the session page. These events mainly include node changes or cursor changes in the page's DOM tree. Each captured DOM change event is stored in structured data format, including the event type, timestamp, and a Data field carrying the specific change content. Subsequently, selective field compression processing is performed on the collected DOM change events. The core idea is to compress only the Data field, which has the largest volume and highest information entropy in the DOM change events, while the event type and timestamp are retained as plaintext values. The compressed binary data is then converted into blocks and Base64 encoded. Finally, in response to a user-triggered recording end request, the aforementioned compressed file is encapsulated as a session recording file and uploaded to the event table of the MySQL database on the server, completing the persistent storage of the session recording file.

[0120] The above method realizes a closed loop from page behavior collection to data optimization and transmission, effectively solving the problems in existing technologies such as the inability to efficiently retrieve data by timestamp due to overall compression, and the high transmission and storage costs caused by excessive data volume.

[0121] Figure 2 A flowchart illustrating a session file processing method provided in this application. Figure 2 ,like Figure 2 As shown, based on the above embodiment, in S104: in response to the user-triggered request to end the recording of the session page, the compressed file is uploaded to the server as the session recording file, specifically including:

[0122] S201: In response to the recording end request, the compressed file is stored in a pre-configured buffer.

[0123] In this step, the buffer refers to a logical area in local memory or storage space used to temporarily store compressed files to be uploaded. Unlike existing real-time upload mechanisms, the buffer is used to temporarily aggregate multiple independent compressed files. The buffer's structure can be configured according to actual data throughput requirements, such as using a first-in-first-out queue structure or a circular buffer structure.

[0124] By storing compressed files in a buffer, a data foundation is provided for subsequent batch processing, avoiding a sudden impact on network bandwidth caused by a large number of concurrent upload requests at the moment recording ends.

[0125] S202: Determine whether the byte length of the compressed file in the buffer is less than the preset load threshold.

[0126] If yes, then execute S203; otherwise, execute S204.

[0127] In this step, the byte length of the compressed file refers to the actual storage space occupied by the data packet to be uploaded after selective field compression. This value directly reflects the bandwidth resources and transmission latency required for network transmission. The preset load threshold sendBeaconMaxSize is a pre-set threshold used to distinguish between lightweight and heavyweight data. Its specific value can be determined based on the browser's limitation standards for the sendBeacon method Navigator.sendBeacon in the Navigation Timing Application Programming Interface and the receiving buffer capacity of the backend server. For example, it can be set to 51200 bytes, or 50KB.

[0128] S203: Designate the sendBeacon channel as the target transmission channel.

[0129] In other words, if the length of the compressed file in the buffer is less than the preset payload threshold, the sendBeacon channel will be selected as the target transmission channel.

[0130] The target transmission channel refers to the communication channel selected when the compressed file leaves the client buffer and finally arrives at the server receiving interface via the network. It determines how the compressed file is actually transmitted and via which network protocol endpoint.

[0131] As mentioned earlier, the compressed file is a string format after Base64 encoding. Since Base64 encoding converts every 3 original bytes into 4 characters, the string length needs to be calculated to obtain the actual number of bytes. To maintain consistency with the backend storage format and avoid additional encoding and decoding overhead, the original binary byte count of the compressed file is recorded as the byte length after selective field compression and before Base64 encoding. Specifically, the binary object corresponding to the compressed file to be uploaded is retrieved from the buffer, and its built-in size or byteLength value is read directly to obtain the byte length. If the buffer stores multiple data blocks after chunking, all blocks need to be traversed and their respective byteLengths summed to obtain the complete byte length of the compressed file.

[0132] If the byte length is less than a preset payload threshold (e.g., 50KB), the current upload task is determined to be a lightweight data transmission scenario, and the sendBeacon channel is selected as the target transmission channel. The sendBeacon channel is a data sending path built using the browser's native navigator.sendBeacon method. This method is specifically designed to send small amounts of data to the server in non-blocking states such as when the page is unloaded or hidden. Unlike traditional XMLHttpRequest (Extensible Hypertext Transfer Request) or Fetch requests, the sendBeacon channel ensures that the request is completed asynchronously before the page's lifecycle ends, and its sending process is not interrupted by page closing operations, thus greatly improving the reliability of data transmission.

[0133] S204: Designate the POST channel as the target transmission channel.

[0134] In other words, if the byte length is greater than or equal to the preset payload threshold, the POST channel will be selected as the target transmission channel.

[0135] If the byte length is greater than or equal to the preset payload threshold (e.g., 50KB), it indicates that the compressed file to be transmitted is too large, exceeding the efficient processing range of the sendBeacon channel or the browser's limit on its data packet length. In this case, continuing to use the sendBeacon channel may result in data truncation or low transmission efficiency; therefore, the POST channel is selected as the target transmission channel. The POST channel refers to a communication channel established based on the POST method in the Hypertext Transfer Protocol (HTTP) for clients to submit data to the server. The client initiates an HTTP request of type POST through the XMLHttpRequest object or the Fetch API. The request body can carry data of any size, ranging from a few KB to several GB. Its maximum length is mainly determined by the server configuration or the browser's own limit on the HTTP request body size, typically far exceeding the tens of KB level that the sendBeacon channel can handle.

[0136] In another possible implementation, if the transmission of the session recording file via the sendBeacon channel fails, the POST channel is determined as the target transmission channel.

[0137] Even if the byte length is less than the preset payload threshold, if the transmission of the session recording file via the sendBeacon channel fails, the POST channel will still be selected as the target transmission channel. Furthermore, in subsequent beforeunload / unload events, a session end signal will be sent via the sendBeacon channel to ensure reliable delivery of the end event. Transmission failures could occur due to factors such as the browser returning false indicating a full queue, a network connection error preventing the compressed file from being sent, or the server returning an unexpected error status code.

[0138] By adaptively switching between sendBeacon and POST channels, the system ensures that regardless of whether the user uploads data normally or triggers an uninstallation event by quickly closing the page, the session recording file can be reliably delivered to the server through the most suitable channel. This effectively solves the data loss problem caused by a single transmission method in complex network environments or under specific user behaviors, significantly improving data transmission reliability. Furthermore, combined with the sendBeacon channel fallback mechanism during page uninstallation, the event loss rate is greatly reduced, especially addressing the industry pain point of data loss at the end of the session.

[0139] S205: Determine whether the number of compressed files in the buffer is greater than or equal to a preset threshold.

[0140] If so, then execute S206.

[0141] The number of compressed files in the buffer reflects the cumulative scale of the data being uploaded in the current generation. The preset threshold is the critical condition for determining whether to initiate batch uploads; its value is related to the network transmission environment, the capacity of a single request, and the server's processing load capacity. This preset threshold can be dynamically adjusted according to network conditions; for example, it can be appropriately increased in a weak network environment to merge more requests, and appropriately decreased in a strong network environment to speed up data uploads. In a typical web application scenario, the preset threshold can be set to values ​​such as 5, 10, 20, 30, 40, or 50. Smaller values ​​offer higher real-time performance but also higher request frequency, while larger values ​​provide better batch efficiency but also increase the demands on client memory and network load per upload.

[0142] S206: Upload the session recording file to the server via the target transmission channel.

[0143] In other words, when the number of compressed files in the buffer is greater than or equal to a preset threshold, the session recording files are uploaded to the server through the target transmission channel.

[0144] As mentioned above, compressed files can be stored sequentially in a first-in-first-out queue or array-type data structure. After each compressed file is generated, its binary data or Blob object will be appended to the end of this array or queue using the push method. Therefore, by directly reading the length property of the array or queue, the exact number of compressed files in the current buffer can be accurately obtained.

[0145] When the number of compressed files in the buffer is greater than or equal to the preset threshold maxEventsPerBatch (e.g., 10), it indicates that the number of compressed files temporarily stored in the local buffer has accumulated to the preset single batch reporting limit. At this time, the session processing module will trigger a batch upload operation, that is, take out these 10 (or the threshold number) compressed files from the buffer queue in sequence, merge them into a multi-segment request body or encapsulate them one by one in sequence, and send them to the server through the target transmission channel (i.e., the sendBeacon channel or POST channel determined according to the byte length in the previous step).

[0146] By using a preset threshold to trigger uploads based on the number of compressed files in the buffer being greater than or equal to the threshold, a balance is effectively struck between real-time data transmission and network bandwidth consumption. Uploading each compressed file immediately upon generation minimizes data latency but leads to frequent short connections between the client and server, placing immense pressure on the server and wasting network resources. Conversely, excessively long waiting times or unlimited buffer buildup can cause excessive memory usage in the client's buffer, potentially leading to performance degradation or even page freezes, especially in long-recorded sessions. By setting the `maxEventsPerBatch` threshold, batch reporting is proactively triggered when data backlog reaches a manageable level. This ensures the server receives a continuous data stream without disconnecting due to prolonged inactivity, while effectively controlling the client's buffer memory level and preventing resource waste caused by a large number of fragmented compressed files generated in a single session.

[0147] In one possible implementation, when the session recording file is uploaded to the server via the sendBeacon channel, the server deploys a request parsing middleware called BeaconMiddleware. This middleware detects requests with Content-Type set to text / plain or without an x-requested-with header, reads the raw JSON string via raw-body, and injects it into req.body, ensuring that requests sent via the sendBeacon channel can be processed normally by the standard Controller.

[0148] The session file processing method provided in this application, after the user triggers a recording end request, first temporarily stores the generated compressed file in a pre-configured buffer. Then, the byte length of the compressed file in the buffer is determined. If the byte length is less than a preset payload threshold (e.g., 50KB), the sendBeacon channel is determined as the target transmission channel; otherwise, if the byte length is greater than or equal to the threshold, the POST channel is determined as the target transmission channel. In another implementation, if the sendBeacon channel transmission fails, it is also downgraded to the POST channel. After determining the target transmission channel, it is further determined whether the number of compressed files in the buffer reaches a preset threshold. If the number is greater than or equal to the preset threshold, a batch upload operation is triggered, and the compressed file is sent to the server as the session recording file through the target transmission channel.

[0149] The above methods improve the integrity and stability of session recording file uploads. Meanwhile, the batch upload strategy triggered by a quantity threshold effectively balances the real-time nature of data transmission with network resource consumption, avoiding the pressure on the server caused by frequent short connections and preventing client performance degradation caused by infinite buffer backlog.

[0150] Based on the above embodiments, before S102, the method for processing the session file further includes:

[0151] The path information is validated based on the pre-acquired path information database to obtain the validation result. When the validation result is passed, DOM change events and page snapshot attribute information corresponding to the session page are collected.

[0152] The path information database includes multiple blacklisted and whitelisted path information. The blacklisted path information is used to indicate page paths where DOM change events are prohibited from being collected, while the whitelisted path information is used to indicate page paths where DOM change events are allowed to be collected. The page snapshot attribute information includes the URL of the session page, the screen size of the device displaying the session page, and the user agent information used to access the session page.

[0153] The path information database is a pre-configured data set whose core function is to provide access control at the path level for session recording. It includes two opposing types of path information entries: one is blacklist path information, which is used to explicitly indicate which page paths are prohibited from collecting DOM change events, such as high-privilege or high-privacy business pages involving sensitive data input, payment settlement, or backend management; the other is whitelist path information, which is used to explicitly indicate which page paths are allowed to collect DOM change events, such as user onboarding pages, ordinary customer service session pages, or product display pages.

[0154] In response to a user-triggered recording request for a session page, the routing matching module within the session processing module obtains the path information of the session page. This path information is then compared one by one with each blacklisted and whitelisted path in the path information database. The verification result is considered successful only if the path information matches at least one whitelisted path and does not match any blacklisted path, thus allowing subsequent collection of DOM change events and recording of page snapshot attribute information. Conversely, if the path information matches at least one blacklisted path or does not match any whitelisted path, the verification result is considered unsuccessful. This blacklist-whitelist combination design enables the recording function to have fine-grained access control capabilities. It ensures that user privacy on critical business pages is not accidentally recorded, while allowing recording only of specified pages, reducing invalid data collection, lowering front-end storage and reporting transmission overhead, and balancing data collection effectiveness with user privacy compliance.

[0155] If the verification result passes, recording for that session page officially begins. Specifically, sessions / create is called to create a session recording, collecting DOM change events and the corresponding page snapshot attribute information. The page snapshot attribute information includes the Uniform Resource Locator URL of the session page, the screen size of the device displaying the session page, and the user agent information used to access the session page.

[0156] The page snapshot attribute information refers to the environmental data used to reconstruct the initial context of the page during playback. This data is obtained through methods including, but not limited to: extracting the URL of the current session page from the `window.location` object; reading the device screen size displaying the session page using `window.screen.width` and `window.screen.height` to determine the viewport size during playback; and obtaining the user agent information used to access the session page, including browser type, operating system version, and device model, by reading `navigator.userAgent`. This page snapshot attribute information, together with subsequently collected DOM change events, constitutes a complete sequence of session recording data, ensuring that the subsequent playback process can accurately reconstruct the session page state and environmental context during user operations.

[0157] Understandably, the path information is verified based on a pre-acquired path information database to obtain the verification result, which specifically includes:

[0158] If the path information matches at least one whitelisted path and does not match any blacklisted path, the verification result is considered passed.

[0159] Conversely, if the path information matches at least one blacklisted path, or if it does not match any whitelisted path, the verification result is determined to be unsuccessful.

[0160] When the route matching module compares the path information with each blacklisted and whitelisted path in the path information database, it does not use a simple string equality comparison, but can perform pattern matching based on Express-style route matching rules.

[0161] Specifically, the route matching module, based on the session page's pathname (the part of the URL after the hostname and port and before the query parameters), iterates through each whitelisted path, breaking down both the rule string and pathname into an array of path segments separated by " / ", and then compares them segment by segment from left to right. If the whitelisted path information includes a dynamic parameter placeholder (such as :id), it indicates that the path segment can match any non-empty string at the corresponding position in the pathname; if the whitelisted path information includes a single-level wildcard " If the whitelist path information includes multi-level wildcards, it means that the path segment can match any single path segment at the corresponding position in pathname; If a match is found, it means that the path segment can match all remaining path segments in pathname. If all path segments in the whitelist successfully match the corresponding segment in pathname, it means that the path information matches the whitelist path information. The logic for determining whether path information matches blacklist path information is the same, and will not be repeated here.

[0162] The final verification result is determined by the matching of path information with whitelisted and blacklisted path information. Specifically, the matching of whitelisted path information is checked first. If the path information matches at least one whitelisted path information, the whitelist verification passes. Then, the matching of blacklisted path information is checked. If the path information does not match any blacklisted path information, the blacklist verification also passes. Only when both conditions are met is the verification result determined to be passed, and recording is then started.

[0163] As an alternative to validating path information, the validation result can also be determined by detecting specific page elements on the session page using Cascading Style Sheets (CSS) selectors. Specifically, after the React component is mounted, the document.querySelector or document.querySelectorAll methods are used to check whether specific DOM elements exist on the current session page. For example, whether it contains a container node with the class name "recording-enabled", whether it has the data-recording attribute tag, or whether there are specific business function components (such as a customer service chat window, a form submission button, etc.) to determine whether the page meets the recording conditions.

[0164] Based on the above embodiments, the method for processing session files further includes:

[0165] During the process of collecting DOM change events, obtain the visible duration of the DOM change events and the total session duration;

[0166] Among them, the visible duration is used to indicate the cumulative duration of the session page while it is in the foreground active state, and the total session duration is used to indicate the duration from the start of collecting DOM change events to the receipt of the recording end request.

[0167] Visibility duration accurately represents the active periods during which users actually focus on and interact with content by monitoring the visibility status of the session page. In a web application runtime environment, browser tabs may enter a hidden background state due to user switching, minimizing windows, or the operating system locking the screen. During this period, although the session page scripts are still running, the user does not actually interact with them. If such inactive time is included in the session recording duration, it will result in a large amount of blank waiting time when playing back the session recording file, failing to accurately reflect the intensity and rhythm of user operations. By distinguishing between the foreground active state and the background hidden state, and using visibility duration as an independent statistical indicator, meaningless waiting time can be filtered out, providing an accurate data benchmark for subsequent adjustments to playback speed.

[0168] For example, the browser's native page visibility API can be used to obtain the visibility duration by listening to the `visibilitychange` event of the document object. During the collection of DOM change events, the state changes of the `document.visibilityState` property are continuously monitored. When the value of `document.visibilityState` becomes `visible`, it indicates that the current session page has switched to the foreground active state. At this time, a timer is started, accumulating the foreground duration in milliseconds. When the value of `document.visibilityState` becomes `hidden`, it indicates that the current session page has switched to the background hidden state. At this time, the timer's accumulation operation is paused, maintaining the current count value. Through this reactive monitoring and accumulation mechanism, regardless of how many times the user switches between session pages, the final accumulated duration, i.e., the visibility duration, strictly corresponds to the actual time the page is displayed in the foreground.

[0169] Alternatively, the expression for the visibility duration can be:

[0170]

[0171] Where visibleTime represents the cumulative visible duration of the session page, in milliseconds; N represents the total number of times the session page switched from a hidden background state to a foreground active state during the recording period; t start,i The timestamp represents the time when the page enters the foreground active state for the i-th session; t end,i This represents the timestamp of the i-th session when the page leaves the foreground active state and becomes the background hidden state.

[0172] The total session duration (Duration) refers to the absolute time span from the start of DOM change event capture to the receipt of the recording end command. This span includes the period when the user switches tabs or minimizes the browser window, causing the session page to be hidden in the background. The total session duration can be obtained by calculating the difference between the timestamp when DOM change event capture is started and the timestamp when the recording end request is received.

[0173] In one possible implementation, the aforementioned visible duration, total session duration, start and end times, session recording file ID, session page URL, device screen size displaying the session page, and user agent information used to access the session page are all uploaded to the server along with the session recording file and stored in the server's session table `rrweb_sessions`. Upon receiving this information, the server extracts the first two path segments from the URL and then calls the `findPageInfo` interface of the permission service. Based on the extracted path, it automatically parses and writes the extracted path into the `logicId` (logical system ID) and `pid` (parent menu ID) fields, automatically labeling the session's ownership. This allows sessions to be managed by business system and menu dimensions, integrating them into the enterprise's operational workflow without additional configuration.

[0174] Based on the above embodiments, after S104, the method for processing the session file further includes:

[0175] If the number of compressed files in the buffer is less than a preset threshold, the compressed files will be deleted.

[0176] After the session recording file is uploaded to the server, the number of compressed files in the buffer represents the total number of file entries in the current buffer that have not yet been uploaded or have been uploaded but are temporarily stored locally. A preset threshold is used as a numerical limit to determine the value of a session, and its setting is based on statistical analysis of low-value user behavior. For example, by collecting data on scenarios where pages are accidentally opened and immediately closed, sessions with no more than 10 compressed files are defined as invalid sessions, and the preset threshold can be set to 10.

[0177] If the number of compressed files in the buffer is less than a preset threshold, it indicates that the current session ended within a very short time, lacking substantial interactive data and thus constituting a low-value session. To prevent such data from consuming server storage space and database index resources after being uploaded to the server, this batch of compressed files is deemed invalid and directly deleted. This process, through an immediate cleanup mechanism, intercepts invalid data from the source, making the remaining valid session data more valuable for analysis, reducing interference data during operation and maintenance retrieval, and ensuring the effective utilization of storage resources.

[0178] As an alternative to eliminating low-value sessions, an absolute threshold can be set based on the total session duration. For example, if the total session duration of a recorded file is less than 3 or 5 seconds, the session can be directly identified as low-value and discarded. This is because excessively short recording durations usually correspond to abnormal scenarios such as users accidentally pressing the record button, pages rapidly redirecting, or loading failures. Such sessions have almost no analytical value in subsequent playback and only consume storage resources and pollute the dataset. On the other hand, the ratio of visible duration to total session duration can be used to identify sessions with extremely low user engagement. For example, if a session has a total duration of 300 seconds but a visible duration of only 10 seconds, it indicates that the user kept the browser in the background, minimized the window, or locked the screen for a long time during recording, and the page was not effectively browsed or interacted with by the user. Therefore, it is marked as a low-value session and excluded.

[0179] Furthermore, a two-layer mechanism combining manual labeling and machine learning can be introduced. On the one hand, operations or quality control personnel can manually label stored session recordings, marking obviously useless recordings as invalid or deleting them directly. These manual labeling results will be used as training datasets input into the machine learning model. On the other hand, supervised learning algorithms will extract multi-dimensional features from the session recordings, including but not limited to page dwell time distribution, user operation frequency (such as number of clicks, number of characters entered, scroll distance), event density, DOM change magnitude, and number of page transitions, to train a binary classification model to predict the value probability of session recordings. Only sessions with a value probability higher than a preset threshold are allowed to be written to the database or enter the subsequent processing flow, while low-scoring sessions are judged as low-value sessions and discarded.

[0180] In one possible implementation, if the storage time of the session recording files on the server exceeds a preset time threshold, the session recording files are deleted in batches with a preset number and a preset interval as the batch unit.

[0181] The storage duration refers to the time span elapsed since the session recording file was created in the server-side MySQL database. It is typically calculated as the difference between the current system timestamp and the timestamp when the session recording file was stored. The preset duration threshold is a key parameter for defining the retention period of session recording files. The specific value is set according to business compliance requirements, for example, it can be set to 6 months.

[0182] When the storage time of the session recording file on the server exceeds the preset time threshold, it indicates that the data has lost its timeliness and needs to be cleaned up. The core of batch deletion operation is to break down a large-scale single deletion transaction into multiple smaller transactions. The preset quantity refers to the maximum number of file entries involved in each batch deletion operation, for example, it can be set to 500 entries; the preset interval can refer to the time interval between two adjacent batches, for example, it can be set to 10 minutes.

[0183] When performing batch deletion, all session recording files that have exceeded the storage duration limit are first identified. These files are then grouped according to a preset number. Execution is performed in batches with a preset number and interval, meaning that only one batch of data is deleted at a time, and the next batch is executed only after a preset interval has elapsed until all files to be deleted have been processed. This batch-based, intermittent deletion mechanism effectively avoids database table locking issues caused by deleting massive amounts of data at once, ensuring that normal read and write operations on the server side are not affected while background cleanup tasks are being performed, thus improving long-term operational stability.

[0184] Figure 3 A flowchart illustrating a session file processing method provided in this application. Figure 3 ,like Figure 3 As shown, based on the above embodiments, the session file processing method further includes a playback method, specifically including:

[0185] S301: In response to a user-triggered playback request for a session recording file, calculate the playback speed based on the visible duration and the total session duration.

[0186] In this step, a playback request refers to the instruction signal sent by the client to the server when the user operates the playback controls in the client's playback interface. This signal instructs the loading of a specified session recording file and prepares for playback. The playback request typically carries an identifier to uniquely identify the target session recording file, such as the session recording file ID or the storage path of the session recording file. The core logic of playback speed adjustment is that when the user plays back the session recording file at this speed, they can fully browse the entire session recording file within the actual viewing time equal to the visible duration, thus skipping invalid time periods where the session page is in the background or minimized, and there is actually no user interaction or visual change. Adaptive playback speed adjustment dynamically adjusts based on the user's effective operation time, avoiding meaningless slow playback during blank waiting periods.

[0187] Specifically, when a user clicks the play button corresponding to a target session recording file in the historical session list, the playback module rrweb-center of the session processing module receives the playback request and retrieves the target session recording file, its visibility duration, and the total session duration from the server to calculate the playback speed. This calculation process can be formally represented as:

[0188]

[0189] Here, rate represents the playback speed.

[0190] Understandably, if a user engages in prolonged screen switching during the recording of a session, the Duration will be significantly greater than the visibleTime, resulting in a calculated rate value greater than 1. This indicates that the playback will be faster than real-time during the playback phase, thus skipping meaningless blank waiting periods and aligning the playback rhythm with the user's actual operation rhythm.

[0191] S302: Divide the total session duration into multiple time periods based on playback speed.

[0192] To address the issues of long initial screen loading times and high memory consumption caused by loading the entire session recording file at once in long session scenarios, the total session duration can be segmented into time segments based on the playback speed after determining the playback speed. This segmentation process is not a simple equal-time division, but rather dynamically adjusts the length threshold of each time segment in conjunction with the playback speed to adapt to different accelerated playback requirements.

[0193] In one possible implementation, the total session duration is divided into multiple time periods based on the playback speed, specifically including:

[0194] (1) The target time window length is obtained by scaling the preset base time window length based on the playback speed.

[0195] The preset base time window length is a pre-defined benchmark metric used to measure the original time span covered by a single request. This parameter is not a fixed physical constant, but rather an engineered configuration based on expected playback loading performance and network interaction frequency. For example, it can be set to 20,000 milliseconds (i.e., 20 seconds) to balance the amount of data in a single data request with the user's waiting time. The target time length refers to the actual time span obtained after scaling the preset base time window length to the playback speed, which determines the recording time range that should be covered when playing back the recorded files in subsequent sessions.

[0196] After calculating the playback speed based on S301, a scaling operation is performed on the base time window length using this playback speed to generate the target time window length. Mathematically, this scaling process is represented by the product of the base time window length and the playback speed.

[0197] When the playback speed is high, it indicates that the user's actual effective operation time is relatively short compared to the total session duration, and the session recording file contains a large amount of inactive time. In this case, the target time window length is larger, allowing each subsequent time segment to cover a longer original time span, thereby reducing the total number of segments and avoiding excessive concurrent request overhead caused by too many segments and too small data size per segment. Conversely, when the playback speed is low, the target time window length is smaller to ensure playback smoothness and balanced loading.

[0198] For example, the target time window length can be expressed as:

[0199]

[0200] Where segmentSize represents the target time window length; S base This indicates the preset base time window length.

[0201] (2) Divide the total session duration into multiple time segments by the target time window length.

[0202] Based on the calculated target time window length `segmentSize`, starting from the timestamp of the session recording file where DOM change events begin to be collected (the recording start time), time periods of length `segmentSize` are sequentially extracted forward until the end time of the total session duration is covered, thus forming multiple consecutive and non-overlapping time periods. If the remaining length of the last time period is less than `segmentSize`, it is treated as an independent time period. Ultimately, the total session duration is divided into multiple time periods, with the number of time periods being M. The expression for calculating M can be expressed as:

[0203]

[0204] This adaptive segmentation strategy based on playback speed not only breaks down the massive session recording file into discrete units that can be processed in parallel, but also ensures the coordination between segmentation granularity and playback speed, effectively avoiding request fragmentation caused by excessively small slices or loading delays caused by excessively large slices.

[0205] S303: Perform parallel decompression of the session recording files corresponding to each time period to obtain multiple decompressed files, and perform visual playback of the session recording files based on the multiple decompressed files.

[0206] After time-based segmentation, the process moves to the session recording file loading and decompression phase. For each time period generated in S302, a query request carrying start and end timestamps is constructed and sent to the server to retrieve the corresponding session recording file within that time range. To maximize network bandwidth utilization and reduce user wait time, a parallel request strategy is adopted, i.e., M findBySession requests are initiated simultaneously, and the loading progress is displayed synchronously, rather than waiting sequentially. After responding to the request, the server returns data packets that have undergone selective field compression. Understandably, these data packets only compress the Data field in DOM change events.

[0207] Therefore, after receiving the session recording files (compressed files) corresponding to each time period, the playback module rrweb-center in the session processing module immediately performs parallel decompression processing on each data packet. This process includes reading the Base64 encoded string and restoring it to binary data, and then using a decompression algorithm (such as the decompression interface of the pako library) to perform pakoDecompress decompression processing, restoring it to the original collection of JavaScript objects, thus obtaining the decompressed file. Since the decompression operation is performed in parallel for each independent data packet, it can make full use of the computing power of multi-core CPUs and avoid the main thread being blocked for a long time.

[0208] After all data packets from all time periods are decompressed, the events in the multiple decompressed files are globally sorted according to their timestamps, reassembled into a complete event stream sequence, and injected into the playback player component for visual playback. This playback process uses the reassembled event sequence to rebuild the DOM tree and trigger change events sequentially, thus reproducing the user's actions. This segmented parallel loading mechanism breaks down a single request that would normally take over 60 seconds into multiple smaller requests executed in parallel, reducing the initial interactive time, lowering peak memory usage, and supporting session playback lasting for several hours.

[0209] Specifically, the visualization playback is based on multiple decompressed files, including:

[0210] (1) Sort multiple decompressed files in ascending order according to timestamps to obtain the merge event sequence.

[0211] The system retrieves and decompresses multiple files in parallel over multiple time periods. Each decompressed file contains a set of DOM change events with timestamps. Due to network timing differences during parallel loading, the arrival order of the decompressed files does not necessarily correspond to the chronological order of the events; therefore, global sorting is required.

[0212] Specifically, by extracting the timestamp from each DOM change event and using it as the sorting key, the events in all decompressed files are sorted in ascending order. This reconnects the originally temporally continuous but physically fragmented session recording events, creating a strictly increasing sequence of merged events on the timeline. By storing the timestamps in plaintext (uncompressed), this field can be read directly without decompressing all data, significantly improving sorting and retrieval efficiency and avoiding the computational overhead of data decompression. This ensures that event merging in long session scenarios can be completed quickly.

[0213] (2) Load the merged event sequence into a pre-instantiated playback player to perform visual playback of the session recording file.

[0214] A playback player is a playback control component used to reconstruct user interaction scenarios. Its pre-instantiation can refer to the creation and configuration of the player object during the front-end page initialization phase, placing it in a ready-to-use state. After obtaining a timestamp-sorted sequence of merged events, this ordered event stream is injected into the playback player. For example, this playback player could be RRWebPlayer.

[0215] Specifically, the playback player maintains a virtual DOM mechanism that parses the instruction parameters of each event sequentially according to the event type and timestamp order in the merged event sequence. For example, when the event type is node modification, the playback player locates the corresponding DOM node and updates its properties; when the event type is cursor movement, the playback player simulates the cursor's coordinate changes on the screen. By strictly replaying events in chronological order, the playback player can gradually recreate the page state changes that are completely consistent with the recording process in an independent sandbox environment, achieving a visual playback effect. This process relies not only on the correct decompression of the data content but also on the precise sorting of timestamps. Only by ensuring the temporal continuity of the event sequence can the playback be smooth and realistic.

[0216] During playback, the playback image can be adaptively rendered based on the device screen size, ensuring good visualization across different resolutions and screen ratios. Specifically, during initialization, the playback player reads the viewport width and height of the current playback device and retrieves the screen size data of the session page during recording from the page snapshot attribute information. By calculating the proportional relationship between the two, it applies appropriate scaling transformations to the mirrored page within the playback container, ensuring that the recorded content fully fills the player window without scrolling or cropping.

[0217] If the screen ratio of the playback device is different from that of the recording device, the original aspect ratio can be maintained by adding background color areas on both sides or top and bottom of the playback screen. This visually restores the page layout seen by the user during recording, while making full use of the screen space of the current playback device, thus improving the user's viewing experience and ease of operation of the playback content.

[0218] As an alternative to the playback method, the Server-Sent Events streaming mechanism can be used to replace the traditional full file download method. The server pushes the merged event sequence to the client in chunks according to time order. The playback player can start visual playback while continuously receiving the event stream, without waiting for all data to be loaded, thus significantly shortening the time from when the user initiates a playback request to when the first screen appears. On the other hand, a lazy loading strategy can also be adopted. When the playback player initializes, it only loads the first 30 seconds of event data from the session recording file for quick playback startup. When the user drags the progress bar to a specific time position, it requests the event data for the corresponding time period from the server based on the target timestamp, dynamically loads it, and injects it into the playback player. This reduces the amount of data loaded initially and avoids invalid data transmission during non-viewing periods. In addition, to further optimize the computational load of the main thread, the time-consuming operation of decompressing compressed files can be offloaded to a Web Worker to be executed in parallel on a background thread. This ensures that the decompression process does not block the rendering and event scheduling of the main thread, so that the user will not experience interface lag or slow operation response due to the decompression of a large amount of data during playback.

[0219] The session file processing method provided in this application, after a user triggers a playback request for a session recording file, first calculates an adaptive playback speed based on the visible duration of the session recording file and the total session duration. Then, it uses this playback speed to scale a preset base time window length to obtain a target time window length. This target time window length is then used to divide the total session duration into multiple continuous and non-overlapping time segments. After segmentation, a query request carrying start and end timestamps is constructed for each time segment, and parallel requests are simultaneously sent to the server to maximize network bandwidth utilization. After the server returns the corresponding data packets processed by selective field compression, parallel decompression processing is performed on each data packet to obtain multiple decompressed files. Then, the multiple decompressed files are sorted in ascending order according to their timestamps to obtain a merged event sequence. Finally, this merged event sequence is injected into a pre-instantiated playback player (such as RRWebPlayer) to perform visual playback of the session recording file.

[0220] The above methods not only eliminate the invalid waiting time caused by user screen switching, screen locking, or browser backgrounding during recording, ensuring precise alignment between playback rhythm and actual user operation rhythm, significantly improving the efficiency of reviewers or analysts browsing recorded content; they also significantly shorten the first screen interactive time and reduce memory peaks, making it possible to support long session playbacks of several hours, which were previously difficult to support. Furthermore, it allows for global sorting of timestamp fields without decompressing all data, greatly improving sorting and retrieval efficiency and avoiding the additional computational overhead of decompression. At the same time, strict ascending timestamp sorting ensures the temporal continuity and realistic reproduction of playback footage.

[0221] Figure 4 A schematic diagram of a session file processing device provided in this application is shown below. Figure 4 As shown, the session file processing device 40 provided in this embodiment includes:

[0222] The first processing module 401 is used to respond to a user-triggered recording request for a session page and obtain the path information of the session page.

[0223] The second processing module 402 is used to collect DOM change events of the session page based on path information; wherein, the DOM change events include changes in the page DOM tree nodes corresponding to the session page or cursor changes, the nodes correspond to page elements in the session page, and the page elements include at least one of text boxes, buttons, images, lists, pop-ups or container nodes;

[0224] The third processing module 403 is used to perform selective field compression processing on DOM change events to obtain a compressed file; wherein, selective field compression processing includes compressing only the Data field in the DOM change event, the Data field being used to carry the specific change content of the DOM change event;

[0225] The fourth processing module 404 is used to respond to the user-triggered end-of-recording request of the session page and upload the compressed file as a session recording file to the server.

[0226] In one possible implementation, the fourth processing module 404 is specifically used for:

[0227] In response to a recording end request, the compressed file is stored in a pre-configured buffer;

[0228] When the number of compressed files in the buffer is greater than or equal to a preset threshold, the session recording file is uploaded to the server through the target transmission channel.

[0229] In one possible implementation, the session file processing device 40 further includes a fifth processing module 405, for:

[0230] If the length of the compressed file in the buffer is less than the preset payload threshold, then the sendBeacon channel will be selected as the target transmission channel.

[0231] If the byte length is greater than or equal to the preset payload threshold, or if the transmission of the session recording file via the sendBeacon channel fails, the POST channel will be selected as the target transmission channel.

[0232] In one possible implementation, the session file processing device 40 further includes a sixth processing module 406, for:

[0233] The path information is verified based on a pre-acquired path information database to obtain the verification result;

[0234] If the verification result is passed, collect DOM change events and page snapshot attribute information corresponding to the session page;

[0235] The path information database includes multiple blacklisted and whitelisted path information. The blacklisted path information is used to indicate page paths where DOM change events are prohibited from being collected, while the whitelisted path information is used to indicate page paths where DOM change events are allowed to be collected. The page snapshot attribute information includes the Uniform Resource Locator URL of the session page, the screen size of the device displaying the session page, and the user agent information used to access the session page.

[0236] In one possible implementation, the sixth processing module 406 is specifically used for:

[0237] If the path information matches at least one whitelisted path and does not match any blacklisted path, the verification result is considered passed.

[0238] If the path information matches at least one blacklisted path, or does not match any whitelisted path, the verification result is determined to be unsuccessful.

[0239] In one possible implementation, the session file processing device 40 further includes a seventh processing module 407, for:

[0240] During the process of collecting DOM change events, obtain the visible duration of the DOM change events and the total session duration;

[0241] Among them, the visible duration is used to indicate the cumulative duration of the session page while it is in the foreground active state, and the total session duration is used to indicate the duration from the start of collecting DOM change events to the receipt of the recording end request.

[0242] In one possible implementation, the session file processing device 40 further includes an eighth processing module 408, used to delete compressed files if the number of compressed files in the buffer is less than a preset number threshold.

[0243] In one possible implementation, the session file processing device 40 further includes a ninth processing module 409, for:

[0244] In response to a user-triggered playback request for a session recording file, the playback speed is calculated based on the visible duration and the total session duration.

[0245] The total session duration is divided into multiple time periods based on the playback speed adjustment.

[0246] The session recording files corresponding to each time period are decompressed in parallel to obtain multiple decompressed files, and the session recording files are then visualized and played back based on the multiple decompressed files.

[0247] In one possible implementation, the ninth processing module 409 is specifically used for:

[0248] The target time window length is obtained by scaling the preset base time window length based on the playback speed.

[0249] The total session duration is divided into multiple time segments by using the target time window length.

[0250] In one possible implementation, the DOM change event also includes an event type and a timestamp, and the ninth processing module 409 is specifically used for:

[0251] The multiple decompressed files are sorted in ascending order according to their timestamps to obtain a sequence of merged events;

[0252] The merged event sequence is loaded into a pre-instantiated playback player to perform visual playback of the session recording file.

[0253] The session file processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again in this embodiment.

[0254] Figure 5 A schematic diagram of the structure of an electronic device provided in this application, such as... Figure 5 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0255] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0256] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0257] In the above embodiments, it should be understood that the processor can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0258] The memory may include random access memory (RAM) in high-speed memory, and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0259] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0260] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0261] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0262] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read-Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0263] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside within an ASIC. Alternatively, the processor and the readable storage medium can exist as discrete components in a device.

[0264] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0265] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0266] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0267] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0268] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0269] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for processing session files, characterized in that, include: In response to a user-triggered recording request for a session page, the path information of the session page is obtained; Based on the path information, document object model (DOM) change events of the session page are collected; wherein, the DOM change events include changes in the page DOM tree nodes corresponding to the session page or cursor changes, the nodes correspond to page elements in the session page, and the page elements include at least one of text boxes, buttons, images, lists, pop-ups, or container nodes; Selective field compression is performed on the DOM change event to obtain a compressed file; wherein, the selective field compression includes compressing only the Data field in the DOM change event, the Data field being used to carry the specific change content of the DOM change event; In response to a user-triggered request to end recording of a session page, the compressed file is uploaded to the server as a session recording file.

2. The method according to claim 1, characterized in that, The user-triggered session page recording end request uploads the compressed file as a session recording file to the server, including: In response to the recording end request, the compressed file is stored in a pre-configured buffer; When the number of compressed files in the buffer is greater than or equal to a preset threshold, the session recording file is uploaded to the server through the target transmission channel.

3. The method according to claim 2, characterized in that, The method further includes: If the byte length of the compressed file in the buffer is less than the preset payload threshold, then the sendBeacon channel is determined as the target transmission channel; If the byte length is greater than or equal to the preset payload threshold, or if the transmission of the session recording file through the sendBeacon channel fails, then the POST channel will be determined as the target transmission channel.

4. The method according to any one of claims 1 to 3, characterized in that, Before collecting DOM change events of the session page based on the path information, the method further includes: The path information is verified based on a pre-acquired path information database to obtain the verification result; When the verification result is passed, the DOM change event and the page snapshot attribute information corresponding to the session page are collected; The path information database includes multiple blacklisted path information and whitelisted path information. The blacklisted path information is used to indicate page paths where the collection of DOM change events is prohibited, and the whitelisted path information is used to indicate page paths where the collection of DOM change events is allowed. The page snapshot attribute information includes the Uniform Resource Locator URL of the session page, the screen size of the device displaying the session page, and the user agent information used to access the session page.

5. The method according to claim 4, characterized in that, The verification process based on the pre-acquired path information database to obtain the verification result includes: If the path information matches at least one whitelisted path and does not match any blacklisted path, then the verification result is determined to be passed. If the path information matches at least one blacklisted path, or does not match any whitelisted path, then the verification result is determined to be unsuccessful.

6. The method according to any one of claims 1 to 3, characterized in that, The method further includes: During the process of collecting the DOM change events, the visibility duration of the DOM change events and the total session duration are obtained; The visible duration is used to indicate the cumulative duration of the session page while it is in the foreground active state, and the total session duration is used to indicate the duration from the start of collecting the DOM change events to the receipt of the recording end request.

7. The method according to claim 2 or 3, characterized in that, After the session recording file is uploaded to the server, the method further includes: If the number of compressed files in the buffer is less than a preset threshold, then the compressed files are deleted.

8. The method according to claim 6, characterized in that, The method further includes: In response to a user-triggered playback request for a session recording file, the playback speed is calculated based on the visible duration and the total session duration. The total session duration is divided into multiple time periods based on the playback speed. The session recording files corresponding to each time period are decompressed in parallel to obtain multiple decompressed files, and the session recording files are then visualized and played back based on the multiple decompressed files.

9. The method according to claim 8, characterized in that, The total session duration is divided into multiple time periods based on the playback speed, including: Based on the playback speed, the preset base time window length is scaled to obtain the target time window length; The total session duration is divided into multiple time segments by using the target time window length.

10. The method according to claim 8, characterized in that, The DOM change event also includes an event type and a timestamp. The visualization playback of the session recording file based on the multiple decompressed files includes: The multiple decompressed files are sorted in ascending order according to their timestamps to obtain a merge event sequence; The merged event sequence is loaded into a pre-instantiated playback player to perform visual playback of the session recording file.

11. A device for processing session files, characterized in that, include: The first processing module is used to respond to a user-triggered recording request for a session page and obtain the path information of the session page. The second processing module is used to collect Document Object Model (DOM) change events of the session page based on the path information; wherein, the DOM change events include changes in the page DOM tree nodes corresponding to the session page or cursor changes, the nodes correspond to page elements in the session page, and the page elements include at least one of text boxes, buttons, images, lists, pop-ups, or container nodes; The third processing module is used to perform selective field compression processing on the DOM change event to obtain a compressed file; wherein, the selective field compression processing includes compressing only the Data field in the DOM change event, the Data field being used to carry the specific change content of the DOM change event; The fourth processing module is used to respond to the user-triggered end-of-recording request of the session page and upload the compressed file as a session recording file to the server.

12. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 10.

Images